[HTTPS-Everywhere] persistent user-generated rules

Vijay P vijayp at qwsrt.com
Sun Jan 5 09:30:05 PST 2014


Hi Yan,

Thanks for the quick reply!

As far as the XML change is concerned, why is speed of processing a
concern? Is it because it slows development? Or because making a deployment
binary takes too long? There are solutions for both of these possibilities
that don't require a wholesale change to XML.  I'd argue that a shift to
JSON would make sense for simplifying the process of adding rules, and
unifying the structure of user-generated and static rules, not so much as a
performance fix.

I personally think there would be great benefit to allow people to
"suggest" / upload their custom rules. It is non-trivial to send a special
request to add a site, and if the goal is to maximize the reach of this
tool, making it as easy as possible to add random sites to the extension,
we should make that at easy as possible.  We could then have some process
to integrate suggested rules into static rule-set at some point in the
future.

(In fact, I'd even argue that long-term, the rulesets should be totally
decoupled from the extension, the extension should be able to download
rulesets from any source, with the EFF source being the default source)

Vijay



On Sun, Jan 5, 2014 at 12:09 AM, Yan Zhu <yan at eff.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
>
> On 01/04/2014 08:40 PM, Vijay P wrote:
> >
> >
> >
> > On Sat, Jan 4, 2014 at 11:39 PM, Vijay P <vijayp at qwsrt.com
> > <mailto:vijayp at qwsrt.com>> wrote:
> >
> > Hi everyone,
> >
> > I'm a huge fan of the EFF and  HTTPS Everywhere extension!
> >
> > The one feature I felt it really needed was the ability for users
> > to add arbitrary rules, and to have those rules persistent across
> > restarts, and the ability for the users to submit rules to the EFF
> > so that the extension can be updated more frequently.
> >
> > I've put together a change that is a partial implementation of
> > this feature, you can build it by checking out my branch below. I'd
> > love comments and/or suggestions before I go too far down the path
> > of implementation. Stuff in "what's missing" still has to be
> > implemented, but it should be functional as is.
> >
>
> Thanks! This is a great idea that some people have requested. I'll
> check it out next week along with Jacob's feature.
>
> > What it does: - enables the httpseverywhere action icon thing on
> > _all_ https pages - when on an https page, allows you to create a
> > rule for that host. It pre-fills the matching regex and redirect-to
> > fields with sane defaults.
> >
> >
> > What's missing: - cookie rules, and exceptions are unimplemented -
> > you can't edit or delete rules (but disabling them works). - there
> > is no way to upload these rules (not sure how you guys want to
> > handle that; I'd probably use a GAE endpoint, but you guys might
> > have thoughts about this)
> >
>
> I wouldn't worry about this for now, since people who really want to
> submit rules can do so by email or pull requests. :)
>
> > Future work? - my changelist uses java objects
> >
> > Uh, I (obviously) meant javascript objects
> >
> >
>
> Phew, my heart stopped for a second there!
>
> >
> > to send and persist rules on the extension. Perhaps we should
> > change the XML structure to using JSON and match the object format
> > used by user rules at some point? Jacob Hoffman-Andrews (we used to
> > work together at Google a long time ago) mentioned that there was
> > discussion on this list about this topic before I joined, and I'd
> > be happy to help with that if people would find it useful.
>
> This is indeed something that we've been talking about more and more
> as ruleset loading/processing gets slower. I will very happily review
> any pull requests to change the XML ruleset structure to JSON! Perhaps
> convert all the existing rules to JSON first and check whether there's
> a noticeable performance improvement from doing so?
>
> Another possibility is to convert default.rulesets into a sqlite
> database, which we can work with using the web SQL API's in Chrome or
> Mozilla's storage API's in Firefox
> (https://developer.mozilla.org/en-US/docs/Storage). Feel free to play
> with that idea.
>
> - -Yan
>
>
> >
> https://github.com/vijayp/https-everywhere/compare/vijayp.add-persistent-user-rules
> >
> >
> - --
> > Vijay Pandurangan vijayp at vijayp.ca <mailto:vijayp at vijayp.ca>
> > twitter:@vijayp www.vijayp.ca <http://www.vijayp.ca> www.mitro.co
> > <http://www.mitro.co>
> >
> >
> >
> >
> > _______________________________________________ HTTPS-Everywhere
> > mailing list HTTPS-Everywhere at lists.eff.org
> > https://lists.eff.org/mailman/listinfo/https-everywhere
> >
>
> - --
> Yan Zhu                           yan at eff.org
> Technologist                      Tel  +1 415 436 9333 x134
> Electronic Frontier Foundation    Fax  +1 415 436 9993
> -----BEGIN PGP SIGNATURE-----
>
> iQEcBAEBCgAGBQJSyOjqAAoJENC7YDZD/dnsN+4IAI54rWvZ6ec6RurpwGQmo7Bf
> ICG/oSIP/evgyHBJBpByVT4g1eR9qU87veZ1YIakllcOnGRYinXg/InQ6xY4Y3oa
> oUKiPoHokrVJdla3GglClR8TbR641rtjCl/ihrJiEEl3yzlXaZGClIV+QxnDshLv
> YIbbXatCpymOfWpji0BzitZbPfSJlGLPPrYmBybqPkY1LTs3AnzMpg3HqPvXWG+p
> 38zV7DdJ+Z9VW9gvwV+p0Bya9KOqsQs+bptKqJX7wX6lbtqgsWtwSQNFoGZiLeZA
> Y7Nfboi0jPf12PLlkdp17NNnzcE/cDkfrocuvD6ggJvjPHDlmNVtnfwVfzgwG0M=
> =3zOK
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140105/ed10336f/attachment-0001.html>


More information about the HTTPS-Everywhere mailing list