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

-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.

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.

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