From 88e6d69c0fa0c1bb3947055493b9d78e70610e01 Mon Sep 17 00:00:00 2001
From: Malvoz <26493779+Malvoz@users.noreply.github.com>
Date: Wed, 25 Jul 2018 11:29:18 +0200
Subject: [PATCH] Change "From-Origin" to "Cross-Origin-Resource-P.. (#3)

Changed "From-Origin" to "Cross-Origin-Resource-Policy" and its link destination from: https://github.com/whatwg/fetch/issues/687 to its specification.

Also thought it would be nice to link to the bikeshed issue.
---
 README.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/README.md b/README.md
index 1677f48..91eecfa 100644
--- a/README.md
+++ b/README.md
@@ -1,4 +1,4 @@
-# `Sec-Metadata` (TODO: Bikeshed the name)
+# `Sec-Metadata` (TODO: [Bikeshed the name](https://github.com/mikewest/sec-metadata/issues/2))
 
 ## A Problem
 
@@ -35,11 +35,11 @@ So, what labels and values are interesting and valuable enough that we'd want to
 
 ## FAQ
 
-### Isn't [`From-Origin`](https://github.com/whatwg/fetch/issues/687) enough to handle the threats discussed above?
+### Isn't [`Cross-Origin-Resource-Policy`](https://fetch.spec.whatwg.org/#cross-origin-resource-policy-header) enough to handle the threats discussed above?
 
-No. The `From-Origin` proposal is an _a posteriori_ mitigation against a response's content falling directly into the hands of unsavory actors. That is, it takes effect client-side, once a response has been generated server-side and served across the network to the client. CSRF attacks will still reach the application and do damage. Timing attacks based both on the work the server does when responding to requests, and on the length of the delivered content itself, will still be possible client-side and through passive network observation.
+No. `Cross-Origin-Resource-Policy` is an _a posteriori_ mitigation against a response's content falling directly into the hands of unsavory actors. That is, it takes effect client-side, once a response has been generated server-side and served across the network to the client. CSRF attacks will still reach the application and do damage. Timing attacks based both on the work the server does when responding to requests, and on the length of the delivered content itself, will still be possible client-side and through passive network observation.
 
-This proposal is valuable above and beyond `From-Origin` insofar as it gives servers the opportunity to more actively filter incoming requests _a priori_, before doing any work. Applications can quickly reject requests based on testing a set of preconditions, and that work can even be lifted up above the application layer (to reverse proxies, CDNs, etc) if desired. Also, the fact that the server is capable of rejecting the request itself means that we don't need to come up with a reporting story: the server can do its own reporting to itself.
+This proposal is valuable above and beyond `Cross-Origin-Resource-Policy` insofar as it gives servers the opportunity to more actively filter incoming requests _a priori_, before doing any work. Applications can quickly reject requests based on testing a set of preconditions, and that work can even be lifted up above the application layer (to reverse proxies, CDNs, etc) if desired. Also, the fact that the server is capable of rejecting the request itself means that we don't need to come up with a reporting story: the server can do its own reporting to itself.
 
 ### What about including the request's origin?