Apply an Origin Policy to *request*

[igrigorik]

MegaCorp, Inc. wishes to ensure that an opt-in feature is enabled for each of the pages on https://example.com, while avoid the overhead associated with large response headers, and ensuring that the navigation request is subject to opt-in as well.

For example, example.com wants to enable Client-Hints for all requests on its origin. They can achieve this by specifying a policy that enables Client-Hints for supporting browsers:

{
  "headers": [
    {
      "name": "Accept-CH",
      "value": "DPR, Viewport-Width, Width",
      "type": "baseline"
    },
   ...
  ]
}

Once such a policy is active, the client should apply the opt-in policy to every request and, following the example above, enable Client-Hints advertisements on all outbound requests to example.com.

---

This same pattern can be used for any opt-in feature; it'll remove the need for browsers to develop custom "remember this opt-in" policy mechanism.

WDYT?

p.s. more color here for how/why this would be valuable for Client Hints specifically.

[grigs]

I apologize for my ignorance here. Where does the server advertise the origin policy? My searches keep routing my to CORS information which, unless I'm missing something, isn't what you're talking about her.

[yoavweiss]

@grigs https://wicg.github.io/origin-policy/#origin-policy-well-known

@igrigorik - huge +1 for the use-case. IIUC, that's already enabled by current spec.

[igrigorik]

IIUC, that's already enabled by current spec.

I don't believe that it is, because current processing policy only applies the origin policy on the response; policy doesn't affect browser behavior on the request.. which is what we're asking for here.

[annevk]

It does for CORS preflights, no?

[igrigorik]

Ah, hmm.. that's true. I guess we could similarly define a custom member (ala cors-preflight) and then add a Fetch integration step to check for it when initializing the request? It'd be nice if there was a generic mechanism to express these opt-in's.. instead of having to hand-craft hooks for each one. (Granted, I can only think of one right now.. CH).

[yoavweiss]

It's true that current processing won't apply to navigation requests, and it would be nice for the purpose of opt-ins if we could "pretend" the policy headers were received before sending navigation requests.

• Accept-Ranges headers might benefit from such an opt-in as well.
  • It's not extremely useful ATM, but one interesting use could be browsers requesting only the first X KB of HTML content, which could speed up first render in some cases.
• HSTS is an opt-in that might have benefited from something similar, but is already well defined (including expiration lifetimes) elsewhere.
• One problem with applying the headers wholesale before navigation requests are sent is that CSP headers might start blocking the very first navigation request. We probably want to avoid that footgun.

[igrigorik]

One problem with applying the headers wholesale before navigation requests are sent is that CSP headers might start blocking the very first navigation request. We probably want to avoid that footgun.

I don't think that's the case; there is no directive that controls "navigations" today.. Such a thing has been discussed before, but AFAIK, we don't have anything concrete.

Re, HSTS: that's a great example of why what we're discussing here would be useful. If this mechanism existed, I don't think HSTS would need to invent own "remember this policy" mechanism. Ditto for Client-Hints and any other feature that wants to affect the request before it hits the wire.