[HTTPS-Everywhere] persistent user-generated rules

[Vijay P]

On Sun, Jan 12, 2014 at 3:18 PM, Yan Zhu <yan at eff.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hey! Thanks for getting back on this. I'm on travel next week and
> might be slow to respond/merge stuff, but it'll happen! :)
>
> One quick comment:
>
> > 4. Code review comments regarding injecting STS. Chrome doesn't
> > have an API to edit STS records. We could inject STS headers but
> > this would be dangerous, since without a way to remove such
> > directives, sites that stop working with https would be broken
> > forever.
> >
>
> I mentioned this on Github, but you can nullify STS directives by
> injecting a STS header with max-age=0 into the response. Note that
> this doesn't actually remove the original STS directive from the
> database (at least not in Firefox).
>

Ah yes, would could of course do this. The only concern is if we do, things
become substantially more complicated. We have to handle these cases
correctly:

1. site that used to be http, now should be https.
2. site that we previously added to https should now be http only.
3. site that itself set STS before, but had one of our rules removed.


In the current system, all of these are stateless: if there's a rule, then
redirect, otherwise, don't.

 If we start injecting STS without a way to query the current STS state,
I'm not even sure we can do this correctly.  (1) is obvious (we inject a
header). (2) and (3) are much more problematic. We'll have to keep track of
which sites we added STS directives for, versus which sites had their own
STS directives. Then, every time we have new rules, we have to diff the old
state against the new state, and remember to inject a max-age=0 header for
those sites.  This is very hard to get right, but what happens when a site
pushes an STS header when our extension is disabled, then we add, then
remove a directive? There's really no way for us to know if it's safe to
remove the STS header.

Thus I think we shouldn't inject STS headers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140112/453ba00f/attachment.html>