[HTTPS-Everywhere] [HTTPS-E Rulesets] HTTPS Everywhere 3.4.5 / Chrome 2014.1.3 released

Wed Jan 15 21:24:07 PST 2014

It used to be that you could have an add-on listing on Mozilla Add-ons but
distribute the add-on itself through another site. But I can’t find any
mention of that now. Did they get rid of that?

There’s an add-on on Mozilla Add-ons called HTTP Nowhere [1]. It sounds
good, is licensed under GPL 3.0 and, according to the author of the add-on,
has been tested with HTTPS Everywhere and Tor Browser Bundle. With a quick
look at the source code, the thing that stands out is that it stores its
rules using JSON. I wonder if someone should try merging HTTPS Everywhere
and HTTP Nowhere.

It has a not-very-nice review [2] that also mentions HTTPS Everywhere.

[1] https://addons.mozilla.org/en-US/firefox/addon/http-nowhere/
[2]
https://addons.mozilla.org/en-US/firefox/addon/http-nowhere/reviews/524316/

--
Brian Drake

On Tue, Jan 14, 2014 at 0430 (UTC), Yan Zhu <yan at eff.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
>
> On 01/13/2014 07:14 AM, Drake, Brian wrote:
> > Yay!
> >
> > At the risk of being annoying, with all my recent messages about
> > the FAQ, this one might need updating soon:
> >
> > “Q. Why isn't HTTPS Everywhere available for download from
> > addons.mozilla.org <http://addons.mozilla.org> like most other
> > Firefox add-ons?”
>
> BTW, I really appreciate all these updates to the FAQ. We need to get
> our docs in shape! :)
>
> Will update when I'm back from travel. In the meantime, feel free to
> keep pointing them out.
>
> >
> > It would also be interesting to know what the reason is for this
> > change. I think I’ve seen discussion about this issue, but nothing
> > that indicated that this change would actually be made.
> >
>
> There's a ticket for it:
> https://trac.torproject.org/projects/tor/ticket/9769.
>
> Note that none of the security issues raised in that thread were
> actually resolved. On the contrary, Mozilla has told me that there's
> no way for us to sign our own extension and have it verified by users
> if they download it from the addons store. This is sad, because it's
> less protection than the Chrome web store offers (we sign the
> extension and updates with a key on an airgapped machine, and Chrome
> refuses to accept updates that are not signed with this key; the hash
> of the public key is actually in the URL of the extension in the
> Chrome Web Store).
>
> It worries me that HTTPS Everywhere in AMO is therefore only as secure
> as the login credentials to our AMO account + review process by
> Mozilla folks. :/
>
> On the other hand, pde and I decided it would be okay to put it in the
> Mozilla addons store in addition to hosting it from eff.org (where
> most users will continue to download it, probably) if we included a
> note on both pages about why eff.org is the more secure and
> privacy-respecting distribution channel of the two for HTTPS Everywhere.
>
> - -Yan
>
>
>
>
> >
> > -- Brian Drake
> >
> > All content created by me: Copyright
> > <http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html> ©
> > 2014 Brian Drake. All rights reserved.
> >
> > On Mon, Jan 13, 2014 at 1438 (UTC), Yan Zhu <yan at eff.org
> > <mailto:yan at eff.org>> wrote:
> >
> >
> >
> > On 01/13/2014 06:00 AM, Drake, Brian wrote:
> >> I don’t really know anything about Chrome and Opera add-ons, but
> >> I am surprised to see something about a “Mozilla addon store”
> >> being updated. This add-on is not on https://addons.mozilla.org/
> >> and I don’t know what else it could be referring to.
> >
> >
> > It's not on the Mozilla store yet, but I was planning to put it
> > there as of this release. This is blocking on Mozilla fixing a bug
> > where HTTPS Everywhere won't upload to the store because Mozilla
> > thinks that it's there already for some reason (ugh).
> >
> > -Yan
> >
> >> -- Brian Drake
> >
> >> All content created by me: Copyright
> >> <http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html> ©
> >> 2014 Brian Drake. All rights reserved.
> >
> >> On Sat, Jan 4, 2014 at 0149 [WST (UTC+8)], Yan Zhu <yan at eff.org
> > <mailto:yan at eff.org>
> >> <mailto:yan at eff.org <mailto:yan at eff.org>>> wrote:
> >
> >> HTTPS Everywhere 3.4.5 has been released:
> >
> >> https://www.eff.org/files/https-everywhere-3.4.5.xpi
> >
> >> - From the Changelog:
> >
> >> 3.4.5 * Updated license * Updated README.md * Updated
> >> contributors list * Fix a performance bug when re-enabling
> >> HTTPS-Everywhere from its menu * Observatory cert whitelist
> >> update * Updated rules: Atlassian, Brightcove, MIT, Pidgin,
> >> Microsoft, Whonix, Skanetrafiken, Stack-Exchange,
> >> Stack-Exchange-mixedcontent
> >
> >
> >
> >> HTTPS Everywhere for Chrome 2014.1.3 has been released:
> >
> >> https://www.eff.org/files/https-everywhere-chrome-2014.1.3.crx
> >
> >> - From the Changelog:
> >
> >> chrome-2014.1.3 * Various ruleset fixes * Various performance
> >> improvements, thanks to Nick Semenkovich and Jacob
> >> Hoffman-Andrews! * Add LRU caching for rules * Refactor out
> >> unused code * Reload page when rule is disabled * Upgrade URI.js
> >> * Add fi translation
> >
> >
> >> (The Chrome, Opera, and Mozilla addon stores have not yet been
> >> updated with these releases but will be soon!)
> >
> >> -Yan
> >
> >
> >
> >
> >
>
> - --
> Yan Zhu                           yan at eff.org
> Technologist                      Tel  +1 415 436 9333 x134
> Electronic Frontier Foundation    Fax  +1 415 436 9993
> -----BEGIN PGP SIGNATURE-----
>
> iQEcBAEBCgAGBQJS1L1xAAoJENC7YDZD/dnsLSMIAJJgU47Vut9sJsuvOSuvNR0J
> NksAJGlvEKTxSX2pII/uE9HDYPcBeWn8dlh21NWmRA9pHqwS/wsUPPADA2J2mMoQ
> EVS4UVhUt+4G/yAc1ovuVPI/7FgQ7zaAQRIqmOmKZXMZeY3uAAHbJ4KNm644XvVK
> I+kh+RBntb1hqvjhc47HU9qWWVBy+g6ZaHOuvl315CGI/KvsW7QmyvFnOTl9GX1K
> fMPxrmSBXq5NqTLH4ea/72m4SfA7mpZIGNrHao5blg3MxeLiWlyh0VjwJjgFMX/l
> A0Wu+ySPyj7xdnaCgt6MQnGfF3y7zF7vwPLV9QpsFfcZqMiKsb06Z5qDdBVg2+c=
> =Gwqg
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140116/20e5c431/attachment-0001.html>