Re: [tor-bugs] #8776 [EFF-HTTPS Everywhere]: Changes to default ruleset state need to work even if the rule was previously present

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#8776: Changes to default ruleset state need to work even if the rule was
previously present
----------------------------------+-----------------------------------------
 Reporter:  pde                   |          Owner:  micahlee       
     Type:  defect                |         Status:  assigned       
 Priority:  critical              |      Milestone:  HTTPS-E 4.0dev7
Component:  EFF-HTTPS Everywhere  |        Version:                 
 Keywords:                        |         Parent:  #8774          
   Points:                        |   Actualpoints:                 
----------------------------------+-----------------------------------------

Comment(by micahlee):

 schoen, good call on not needing to save default rules since we already
 have them in memory.

 I have a working patch. I think it still needs a bit of work, but I've
 pushed it the ruleset-migration-8776 branch on my github repository:
 https://github.com/micahflee/https-everywhere/tree/ruleset-migration-8776

 Will people here please try it out and help test it? It's kind of a
 significant change, and HTTPS Everywhere doesn't have unit tests (!), so
 manually have to be thorough.

 This code now ignores all of the ruleset about:config prefs. Instead, when
 you toggle a rule it saves a new pref in a new namespace,
 extensions.https_everywhere.rule_toggle.*. If you haven't toggled a rule,
 it defaults to what's in the xml file.

 In this way, we can change default_off and platform attributes of rules
 whenever we want and it will change the default rule state in people's
 browsers after they upgrade. The only prefs that will be saved between
 upgrades are rulesets that people manually enable or disable.

 Resetting rulesets to defaults now just deletes the associated
 extensions.https_everywhere.rule_toggle.* rule, so it falls back to the
 default.

 All of this seems to work fine now with this patch, including the
 preferences dialog.

 Now here's the zinger. With this next upgrade, everyone's saved
 preferences will get reset back to defaults. Can anyone think of a way
 around this?

 If, on upgrade, we loop through their existing
 extensions.https_everywhere.* prefs and make new
 extensions.https_everywhere.rule_toggle.* prefs only if they differ from
 the default, that would work. Only it would totally defeat the purpose of
 this ticket: when we add platform="mixedcontent" to rules their new
 default state will be off (what we want), but this logic would save a new
 rule_toggle pref that will keep them on.

 Right now I'm thinking of attaching a notification box to the top of the
 browser just for users who are upgrading (new users won't see it) that
 lets them know that all of their enabled/disabled rules prefs have been
 reset to default. Is this acceptable? I have a feeling that the majority
 of our users never toggle any rules on or off, though I don't have data to
 back that up.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8776#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs