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

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

From: Mike West <mkwst@google.com>
Date: Thu, 28 Jul 2016 19:18:34 +0200
Message-ID: <CAKXHy=e=xba4wOXNso2gRcRV7oP-J+S23btWUVTbjmK0r1yz4Q@mail.gmail.com>
To: Brad Hill <hillbrad@gmail.com>
Cc: "Mike O'Neill" <michael.oneill@baycloud.com>, Anne van Kesteren <annevk@annevk.nl>, Patrick Toomey <patrick.toomey@github.com>, Joel Weinberger <jww@google.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, WebAppSec WG <public-webappsec@w3.org>
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. :)

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.

Received on Thursday, 28 July 2016 17:19:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:56 UTC