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

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.


It should be pretty straightforward to extract the relevant logic out into
>> an operation that could be performed asynchronously, though we'd need to be
>> clear about the promises we're making about the current navigation and the
>> resources it loads in that scenario (namely: none).
>>
>> Would you mind filing a bug against the draft? I'll add something like
>> this in tomorrow.
>>
>> -mike
>>
>