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

On Thu, Jul 28, 2016 at 12:27 PM Mike West <mkwst@google.com> wrote:

>
>
> -mike
>
> On Thu, Jul 28, 2016 at 7:54 PM, Patrick Toomey <patrick.toomey@github.com
> > wrote:
>
>>
>>
>> On Thu, Jul 28, 2016 at 11:33 AM Patrick Toomey <
>> patrick.toomey@github.com> wrote:
>>
>>> On Thu, Jul 28, 2016 at 11:18 AM Mike West <mkwst@google.com> wrote:
>>>
>>>> On Thu, Jul 28, 2016 at 6:00 PM, Brad Hill <hillbrad@gmail.com> wrote:
>>>>
>>>>> One more suggestion.  If the client tells the server it has "v10.0.1"
>>>>> and the server is OK with that but has "v10.0.2" available, it would be
>>>>> nice if the server could reply with:  "Origin-Policy: v10.0.2; async", (or
>>>>> something) which tells the client, don't block on loading the new policy
>>>>> for this request, but queue a task to update your policy to the new one
>>>>> asynchronously.    For something like a "Like" button (or an ad) where TTI
>>>>> is really important, we would love the transfer savings this could provide,
>>>>> but also probably very rarely if ever want to block for a synchronous
>>>>> update unless the client doesn't have a policy at all.
>>>>>
>>>>
>>>> Huh. I'd only thought about this as an all-in synchronous system, or a
>>>> TOFU-style system. It didn't occur to me that the developer might actually
>>>> be best positioned to make that decision. :)
>>>>
>>>
>>> I can’t recall if this was discussed before or not. But, how often do we
>>> expect
>>>
>>> 1) Baseline policies to change (I’m not talking about folks that want
>>> dynamic additions on specific endpoints)
>>>
>>> 2) People to need instant updates to their baseline policy
>>>
>>> In other words, I wonder how often this `async` might be fine as the
>>> normal course of events for when a policy changes. A more general way to
>>> approach this is a `max-age` directive. Assuming most sites would be fine
>>> with some window to roll out changes to their policies, then it could be up
>>> to the browser to fetch a new version when convenient. And, if a site
>>> really wants to force an updated policy, an potentially incur a synchronous
>>> delay , they can send down some sort of `max-age: 0` with their response.
>>>
>>>>
>>>>
>> Thinking for another minute, providing a site-controlled `max-age` sounds
>> maybe too flexible (why given someone the opportunity to cache their policy
>> for a week). Instead, maybe async could be the default (with some defined
>> upper bound on how long a policy would be cached) and provide an option
>> like `force-update` to disable the async behavior if you really need to
>> force an update and incur the performance hit.
>>
>
> 1. I think I'd be sad if we threw away the synchronous option altogether.
> I'm totally behind it being optional, and I suppose I could even be
> convinced that it's the wrong default, but moving to an entirely
> asynchronous model seems to me like a missed opportunity.
>

Agreed. There is no way we can drop synchronous all together. If a site has
no cached policy yet then synchronous seems unavoidable. I’m only proposing
that it might be possible that async is the default if we already have a
cache policy and that there could be a means of the an app opting in to
synchronous behavior on policy change (i.e. if they really need the policy
updated now).

If I look at most CSP policy changes we make, a rolling window would be
fine. For example, if we are deprecating an `img-src` we ensure that we
have actually removed our reliance on it, and then update our policy. It
would be totally fine for that extra `img-src` to stay a while. I guess the
reverse is more of a sharp edge that could catch folks by surprise. If I
don’t currently allow an `img-src`, and I open a change that starts using
it, I might not be totally obvious that the origin policy change needs to
get deployed before the actual code that uses it. I guess it all comes down
to how much of a performance hit it is in reality. Some experimentation is
probably warranted before arbitrarily choosing a solution.


> 2. The nice thing about the manifest being an actual resource on a server
> is that we don't have to reinvent the wheel with regard to caching.
> Developers can serve the cache headers they've learned to love, they can
> check their results with tools like Mark's redbot <https://redbot.org/>,
> and we don't have to teach the browser any interesting and exciting new
> concepts: we make a request, it's cached like any other, and that's it.
>

Fair…I spend so little of my time with actual HTTP caching I often forget
about it as a tool that is at our disposal :-)

>
> In my head, folks would probably be best served by delivering "forever"
> cache headers, of course, so maybe there's an argument for a one-off thing
> here where we just keep a manifest around forever and ever and ever, but if
> we can get away with off-the-shelf primitives, that seems best.
>
> -mike
>