W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2015

Re: dont-revalidate Cache-Control header

From: Guille -bisho- <bishillo@gmail.com>
Date: Thu, 16 Jul 2015 11:19:09 -0700
Message-ID: <CAMSE37v6qXzNquAqGPaHgVJYwfGeC+uE1hurc7g4wvoL1nvgkA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Ben Maurer <ben.maurer@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Jul 16, 2015 at 11:01 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 16 July 2015 at 10:38, Guille -bisho- <bishillo@gmail.com> wrote:
> > The risk is still the typical ga.js url embedded in all websites. If a
> > bug/hack makes that static, you will need to ask all site owners to go
> and
> > change the url to something else, which will take ages.
>
> Shift-reload is a tool we provide our users to get around this class of
> problem.
>

I know, but you can't ask end-user to shift-reload easily... :/


> Also, we like to engineer security systems that don't have a
> point-in-time compromises of a system resulting in a persistent
> attack.
>
> Maybe we should look for alternatives.  If Facebook wanted to
> construct a service worker that handled fetch events for "static"
> resources and manage its own cache, we can't really stop that from
> happening.  We can't stop you from blocking your own requests after
> all.
>
> Note that this wouldn't work if the resources were requested by
> another origin unless you want to support foreign fetch events for
> service workers.
>

I would like to avoid a system like that.

A header or html directive indicating that sub-resources of a given domain
must not be revalidated and their ttl is for good will solve all security
issues, and still provide a really nice improvement.

- If a page adds the header by mistake, can easily remove it.
- A page can't self-reference their domain, so no risk of bricking
yourself.

-- 
Guille -ℬḭṩḩø- <bishillo@gmail.com>
:wq
Received on Thursday, 16 July 2015 18:19:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:46 UTC