Potential other uses for origin policy brought up at BlinkOn

[domenic]

Yesterday at BlinkOn folks brought up two potential uses for origin policy I hadn't heard before. I'd like to record them here and get folks' thoughts, if any.

• Resurrecting the entry point regulation spec: apparently a big problem with that spec was where the manifest should exist. Origin policy seems like the exact right place for it.

  I'm not sure why entry point regulation was abandoned exactly, so I'm not sure whether this is a good or bad idea, but it's certainly interesting.

• Tweaking the processing model for CSP frame-ancestors: it's possible to DDOS a server by iframing it a lot. Currently you can prevent the browser from displaying the contents of the iframe using CSP frame-ancestors, but that only happens after the request has already been sent, the response has been rendered, and then the browser looks at the headers and says "oh, nevermind, we don't want to display that response". (IIUC.) If the browser knew, via origin policy, that a particular page was prohibited from being used in an iframe, then it could just refuse to issue the request entirely, which would save server operators the CPU time spent responding to the request.

  This seems related to some of the other ongoing work around embedder policy and sec-fetch-metadata, which I haven't yet read up on in detail.

[annevk]

I'm not sure what you mean by rendered, but the browser has the ability to block the moment the headers are processed as part of HTML's navigation algorithm (not entirely integrated yet, there's an open issue). I agree that blocking before the request is even made (when there's a cached policy) is a nice win though.

[mikewest]

ERP

My recollection is that the objections to ERP were philosophical, not practical. If there's interest in spinning it up again, I agree that origin policy would be a good place to put its configuration.

frame-ancestors

A few thoughts here:

1. Fetch Metadata will allow servers to distinguish frame requests via Sec-Fetch-Dest: iframe, and refuse to pass them on to the backend, which should both save resources and limit potential leakage.

2. I think the rendering point is an artifact of Blink's current behavior in stable, wherein CSP is processed in the renderer, while XFO is processed in the browser. For frame-ancestors, we do commit the navigation, then discover that we ought to block it. @annevk is entirely correct that we can block the response in the network service instead, and indeed there's work underway to move our implementation there (https://cs.chromium.org/chromium/src/content/browser/frame_host/ancestor_throttle.cc?rcl=aeec2ba175b9cbefda5d7d416edff684f2db97ef&l=150).

3. Making decisions a priori is, indeed, a great way to make use of the cached policy. That's very much in line with what we want to do for CORS preflights, I think it's a great idea to do it for ancestor checks as well.

[eeeps]

Something that came up in discussions after the Origin Trials session was the potential to use Origin Policy to opt into an Origin Trial.

Makes sense; also probably doesn't belong in the spec, as a vendor-specific thing.

It does make me wonder if there will be other vendor-specific things, and if that's something the spec should either be on guard against or make affordances for.