W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2016

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

From: Patrick Toomey <patrick.toomey@github.com>
Date: Thu, 28 Jul 2016 17:54:22 +0000
Message-ID: <CAN4Q8dCpgGf2X_TOp+aoPfcnE6C7S7JWbb7pff+6etuR4_5amg@mail.gmail.com>
To: Mike West <mkwst@google.com>, Brad Hill <hillbrad@gmail.com>
Cc: "Mike O'Neill" <michael.oneill@baycloud.com>, Anne van Kesteren <annevk@annevk.nl>, Joel Weinberger <jww@google.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, WebAppSec WG <public-webappsec@w3.org>
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
>>
>
Received on Thursday, 28 July 2016 17:55:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:20 UTC