Re: [Proposal]: Set origin-wide policies via a manifest.

On Thu, Jul 28, 2016 at 12:43 AM, Brad Hill <hillbrad@gmail.com> wrote:

> A few things:
>
> 1) If I'm reading this correctly, you could never have a more relaxed CSP
> for a specific resource than the baseline value in an Origin Policy due to
> the way header combination works for CSP.  It seems like some sort of
> escape hatch is necessary to disable Origin-Policy processing for a given
> response?  (or you have to be absolutely 100% certain about the baseline
> policy contents and probably still send large delta policies with almost
> every request)
>

Correct. The `fallback
<https://mikewest.github.io/origin-policy/#fallback-headers>` mechanism
deals with some of this concern by only applying the specified header iff
no such header is present on a response, but I agree that it's ill-suited
to a site with dynamic policies per page.

CCing Patrick Toomey from GitHub who's provided similar feedback. I
suggested to him in a private conversation that this might be an argument
for revisiting some earlier CSP proposals for mutable policies. I don't
think it makes sense to try to wedge mutability into Origin Policy in a
general way, as I think the behaviors we'd want would end up being very
feature-specific.

That said, an alternative to mutability would be the path-based
configuration alluded to in an earlier response. That is, you could imagine
a manifest that looked something like:

```
{
  "headers": [ ],
  "overrides": {
    "/api": {
      "headers": [ ]
    },
    "/articles": {
      "headers": [ ]
    },
    "/whatever": {
      "headers": [ ]
    }
  },
}
```

where the top level `headers` member's value would be applied to requests
iff their URLs didn't match one of the `override` values. That would
provide a lot of flexibility, but it would also add a _ton_ of complexity,
both to the feature and to the user agent's and server's implementation.

I think I'd like to punt that to a v2, as I think it's more important for
us to experiment with impact of the entire notion of a synchronous request
during a navigation. If we can make that work, and server push actually
solves the performance issue, then we can dig around for improvements. I'd
like to get that baseline understanding of the feature's viability, though,
before going too far afield from things we know we need.

2) Another smart person at FB points out that the benefit of having the
> client send which version it is currently enforcing for the domain is that
> you can avoid having to do an H2 push for every request to avoid blocking.
> Seems like a big deal, so maybe the "cookie-like" semantics are a big win,
> after all.
>

Hrm. That's fair. The client would be able to cancel the push, but that's
another roundtrip, and avoiding it would be ideal.

How about a compromise: we send the current version up in the header, we
tie it to cookies in terms of clearing behavior, and we also send a static
advertisement of the feature if the user agent wouldn't send cookies with a
request.

That is, if a user has enabled third-party cookie blocking, then the
request generated from `<iframe src="https://not-this-origin.test/`></iframe>`
would contain `Origin-Policy: 1` rather than `Origin-Policy: "whatever"`.
That should limit the risks of the advertisement to being strictly lower
than cookies, while enabling the performance improvements for those servers
to which a user would send cookies anyway.


> 3) Same smart person is concerned about being able to do graceful upgrade
> without thrashing if servers don't all see the same policy version as
> current simultaneously.  I think this might be best accomplished, again, by
> the original proposal, so the origin owner could encode a versioning scheme
> into the policy name and a server that is serving policy v1 doesn't try to
> override a client that says it's already enforcing v2.  (could possibly do
> this by caching all previous hashes, but that's kind of ugly in the long
> run)
>

This sounds reasonable; I hadn't considered propagation delay, as I assumed
that users would be quasi-pinned to a server or set of servers.


>
> On Wed, Jul 27, 2016 at 10:46 AM Anne van Kesteren <annevk@annevk.nl>
> wrote:
>
>> On Wed, Jul 27, 2016 at 7:18 PM, Mike West <mkwst@google.com> wrote:
>> > Granularity beyond the origin seems like a(n attractive) footgun.
>>
>> Agreed, let's not do another service worker scope.
>>
>>
>> --
>> https://annevankesteren.nl/
>>
>