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

Thu Jan 16 08:04:12 PST 2014

I spent a while looking at lists of add-ons on Mozilla Add-ons. I found
some interesting things, but no externally hosted add-ons.

But I did find two pieces of documentation that indicate that external
hosting is still possible, which quoted below.

https://addons.mozilla.org/en-US/developer_faq#contributing:

> Can I host my own add-on?Yes. Many developers choose to host their own
> add-ons. Choosing to host your add-on on Mozilla's add-on site<https://addons.mozilla.org>,
> though, allows for much greater exposure to your add-on due to the large
> volume of visitors to the site. mozdev.org offers free project hosting
> for Mozilla applications and extensions providing developers with tools to
> help manage source code, version control, bug tracking and documentation.

https://addons.mozilla.org/en-US/developers/docs/policies/contact:

> Add-on Security VulnerabilitiesIf you have discovered a security
> vulnerability in an add-on, even if it is not hosted here, …
>

--
Brian Drake

On Thu, Jan 16, 2014 at 1359 (UTC), Yan Zhu <yan at eff.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
>
> On 01/16/2014 12:24 AM, Drake, Brian wrote:
> > 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?
>
> I haven't heard of it, but that is basically exactly what we need. Let
> me know if you find out.
>
> >
> > 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.
>
> The person who wrote it sent an email to this list months ago asking
> if it was in scope for HTTPS Everywhere. I wrote back and asked if he
> was interested in merging the addons; no reply yet so it's low on my
> to-do list.
>
> - -Yan
>
> >
> > 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
> >
> > All content created by me: Copyright
> > <http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html> ©
> > 2014 Brian Drake. All rights reserved.
> >
> > On Tue, Jan 14, 2014 at 0430 (UTC), Yan Zhu <yan at eff.org
> > <mailto:yan at eff.org>> wrote:
> >
> >
> >
> > 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>
> > <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
> > <http://eff.org> (where most users will continue to download it,
> > probably) if we included a note on both pages about why eff.org
> > <http://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>
> >> <mailto: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>>
> >>> <mailto: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-----
>
> iQEcBAEBCgAGBQJS1+XVAAoJENC7YDZD/dnsQf0H/R1fAfeMSzIWiHsJSBleaLvj
> nHq3jDu8HkNDegR5N87PJNwpmxePDBf1pP3wMR9CC75DueJLteJoUbHZAQIuyTNT
> iHmzg7FnXIwxG8zWzDqs9s7zfhPq/Emhc+sH/cGDnxhqoQGiUZdFFVMnoGWdYwNz
> QSxlVoYXoyZySf5faR/365Fmlxjak98EF9pNlZKGAi73KM/QHOsk26Wm4gxOX+WF
> +BnwQFi4AlrteG/KV5eLvctXoVar+GJXrLhLVdj0jvEfHzxFuCN9yrpjHMCDzyEl
> tSqHqa2+upmtaT/BVH/Q7th9mb9Pj8I31BQM8HjPMXmv9wvQtdR45jK/OqF2vdA=
> =lPu/
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140117/64c479c0/attachment-0001.html>