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:34:00 +0000
Message-ID: <CAN4Q8dBFovRQi+yF5rQ3U+nBNHeh8=K4VjV6bghoYRNy2wwJog@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: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.

>
> 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:34:38 UTC

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