Re: dont-revalidate Cache-Control header

[Guille -bisho- <[e-mail]>]

On Thu, Jul 16, 2015 at 11:01 AM, Martin Thomson <[e-mail]>
wrote:

> On 16 July 2015 at 10:38, Guille -bisho- <[e-mail]> 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 -ℬḭṩḩø- <[e-mail]>
:wq