[HTTPS-Everywhere] persistent user-generated rules

[Vijay P]

(Also, when our extension is installed, we would need to un-set all the
directives we injected so things go back to the way they were before. It's
not clear we'd be able to do that)


On Sun, Jan 12, 2014 at 4:28 PM, Vijay P <vijayp at qwsrt.com> wrote:

>
>
>
> 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/78e7e510/attachment.html>