HTTPS Everywhere EFF issueshttps://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues2020-06-27T14:15:35Zhttps://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/1578Split off a development branch2020-06-27T14:15:35ZPeter EckersleySplit off a development branchNew features and rules will need to be tested by an appropriately sized population before they're pushed out to all of the users of this plugin.
We could achieve this by using an alternative update.rdf for people who are willing to be b...New features and rules will need to be tested by an appropriately sized population before they're pushed out to all of the users of this plugin.
We could achieve this by using an alternative update.rdf for people who are willing to be bleeding and edgy.Peter EckersleyPeter Eckersleyhttps://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/3413Review HTTPS Everywhere Observatory Alpha2020-06-27T14:15:26ZMike PerryReview HTTPS Everywhere Observatory Alphapde has a branch he wants me to test and review.pde has a branch he wants me to test and review.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/4176Check that there are no holes left by the removal of nsIContentPolicy2020-06-27T14:15:20ZPeter EckersleyCheck that there are no holes left by the removal of nsIContentPolicySince this commit:
https://gitweb.torproject.org/https-everywhere.git/blobdiff/eb212b2e785b1760f976d2b7358a187f2adc82b1..445aa51a61fa2ec50998ac802c3d0c4261787929:/src/components/https-everywhere.js
To close legacy/trac#3882 , we should ...Since this commit:
https://gitweb.torproject.org/https-everywhere.git/blobdiff/eb212b2e785b1760f976d2b7358a187f2adc82b1..445aa51a61fa2ec50998ac802c3d0c4261787929:/src/components/https-everywhere.js
To close legacy/trac#3882 , we should run more tests to ensure that no HTTP requests are escaping redirection.
We have done a bit of this without plugins, but we should also perform more and with plugins. Methodology:
Run a wireshark capture with the BPF set to "port 80" (or a protocol-level equivalent?).
Do a lot of browsing.
Filter out the HTTP Request packets.
See if any of them should have been rewritten.Peter EckersleyPeter Eckersleyhttps://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/5224Allow rulesets to be different in Firefox and Chrome releases2020-06-27T14:15:15ZPeter EckersleyAllow rulesets to be different in Firefox and Chrome releasesWorking around#5196 is going to require a temporary divergence in the GoogleAPIs ruleset in order to work around a Chrome bug.
Right now I can think of two ways to do this. One is to add a new attribute to <rule> elements which specifi...Working around#5196 is going to require a temporary divergence in the GoogleAPIs ruleset in order to work around a Chrome bug.
Right now I can think of two ways to do this. One is to add a new attribute to <rule> elements which specifies that the only work on some platforms. Another is to build the Chrome releases from a different git branch.
The new rule element is probably slightly more elegant, and also slightly more work.Peter EckersleyPeter Eckersleyhttps://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/5257Translate the Chrome port of HTTPS-E2022-08-15T21:59:32ZPeter EckersleyTranslate the Chrome port of HTTPS-EThe FF and Chrome builds should use the same translation sources. This probably means we need a script to parse the FF translation .dtds during the chrome build process, and write them out into whatever format Chrome uses for its transl...The FF and Chrome builds should use the same translation sources. This probably means we need a script to parse the FF translation .dtds during the chrome build process, and write them out into whatever format Chrome uses for its translations.https://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/5274Port various Firefox features to the Chrome port.2022-08-15T21:59:33ZPeter EckersleyPort various Firefox features to the Chrome port.This is a parent ticket; the content is in the children.This is a parent ticket; the content is in the children.https://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/5818Merge NoScript 2.3.7 with HTTPS-Everywhere2020-06-27T14:15:08ZMike PerryMerge NoScript 2.3.7 with HTTPS-EverywhereWe thought this fixed bug legacy/trac#5477, but it did not. It still took two days though, so I'm adding it in for the historical record so I can remove the tag from legacy/trac#5477.We thought this fixed bug legacy/trac#5477, but it did not. It still took two days though, so I'm adding it in for the historical record so I can remove the tag from legacy/trac#5477.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/6199Write docs for other extension developers on how to be HTTPS Everywhere compa...2020-06-27T14:15:04ZPeter EckersleyWrite docs for other extension developers on how to be HTTPS Everywhere compatibleSince legacy/trac#3190 doesn't seem to be going anywhere, we should write and publish a guide for extension developers on how to make their extensions play nice with us.
As part of this, we should also consider whether we can do a bette...Since legacy/trac#3190 doesn't seem to be going anywhere, we should write and publish a guide for extension developers on how to make their extensions play nice with us.
As part of this, we should also consider whether we can do a better job of the API for receiving notifications / new channels when rewrites occur.Peter EckersleyPeter Eckersleyhttps://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/6975Tag for Chrome & FF23+ all the rulesets where mixed content breaks things (!)2020-06-27T14:14:56ZPeter EckersleyTag for Chrome & FF23+ all the rulesets where mixed content breaks things (!)Recent versions of Chromium and Chrome have implemented an automatic mechanism to block the loading of insecure HTTP scripts from HTTPS origins. At first there was a loud popup message whenever that happened, but now the only indication...Recent versions of Chromium and Chrome have implemented an automatic mechanism to block the loading of insecure HTTP scripts from HTTPS origins. At first there was a loud popup message whenever that happened, but now the only indication in the UI is a small shield in the address bar, which the user can click on to force the insecure scripts to load.
Google has replied "won't fix" to any UX or extension API requests we made about this: https://code.google.com/p/chromium/issues/detail?id=144637
As a result, we are going to need a major push to identify rulesets that break sites in Chrome because of this mechanism, and disable them on that platform. This ticket will track that task.Micah LeeMicah Leehttps://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/7865Disable ruleset for Ping.fm2020-06-27T14:14:39ZcypherpunksDisable ruleset for Ping.fmThe certificate for Ping.fm expired a few months ago.
Firefox warning
---------------
ping.fm uses an invalid security certificate.
The certificate expired on 10/29/2012 04:36 PM.The certificate for Ping.fm expired a few months ago.
Firefox warning
---------------
ping.fm uses an invalid security certificate.
The certificate expired on 10/29/2012 04:36 PM.Peter EckersleyPeter Eckersleyhttps://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/7886Implement a network-layer test harness for HTTPS Everywhere corectness2022-08-15T22:00:10ZPeter EckersleyImplement a network-layer test harness for HTTPS Everywhere corectnessSince various changes to Mozilla internals break HTTPS Everywhere on a semi-regular basis, we should build a simple test harness that can watch the network for HTTP requests and automatically figure out whether any of them should have b...Since various changes to Mozilla internals break HTTPS Everywhere on a semi-regular basis, we should build a simple test harness that can watch the network for HTTP requests and automatically figure out whether any of them should have been rewritten by the ruleset library.
Known corner cases for this include URLs that redirect back to HTTP (these can be found out by watching the console output from Firefox with HTTPS Everywhere) and disabled rulesets.
But overall, this would be a very simple way to increase our confidence in HTTPS Everywhere's corectness as Mozilla's code changes.https://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/7907disable ruleset for dafont.com2020-06-27T14:14:39Zcypherpunksdisable ruleset for dafont.comwww.dafont.com uses an invalid security certificate.
The certificate expired on 11/28/2012 05:29 AM. The current time is 01/10/2013 10:39 AM.
(Error code: sec_error_expired_certificate)www.dafont.com uses an invalid security certificate.
The certificate expired on 11/28/2012 05:29 AM. The current time is 01/10/2013 10:39 AM.
(Error code: sec_error_expired_certificate)Peter EckersleyPeter Eckersleyhttps://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/8182Explicitly figure out handling of internationalized domain names2022-08-15T22:00:13ZSeth SchoenExplicitly figure out handling of internationalized domain namesWe should explicitly figure out and document how HTTPS Everywhere works with internationalized domain names (IDN), and make sure that it actually works according to the documented behavior. Do you write rules using UTF-8 internationaliz...We should explicitly figure out and document how HTTPS Everywhere works with internationalized domain names (IDN), and make sure that it actually works according to the documented behavior. Do you write rules using UTF-8 internationalized names, punycode-encoded names, or neither? Do the rules actually trigger and rewrite correctly?
A potential problem about this was reported at
https://mail1.eff.org/pipermail/https-everywhere/2012-May/001435.htmlhttps://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/8437Prevent invalid rules from being committed, or at leat warn when they are2020-06-27T14:14:34ZSeth SchoenPrevent invalid rules from being committed, or at leat warn when they areSometimes people commit rules that we can automatically detect are invalid, for example with utils/trivial-validate.py. It would be good to have a system to prevent these from being committed at all or to immediately warn someone when t...Sometimes people commit rules that we can automatically detect are invalid, for example with utils/trivial-validate.py. It would be good to have a system to prevent these from being committed at all or to immediately warn someone when they have been, rather than having to wait until someone tries to build the extension later.
I've never used commit-hooks, so I don't know exactly what options are available in the git infrastructure to help with this. Another alternative is a daemon that periodically runs validation scripts across the current tree and generates e-mail if anything invalid is present.Yan ZhuYan Zhuhttps://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/8759Include Arabic https-everywhere.properties translation2020-06-27T14:14:28ZSheriefInclude Arabic https-everywhere.properties translationTranslation for https-everywhere.properties was revised and completed, Please include it.Translation for https-everywhere.properties was revised and completed, Please include it.Peter EckersleyPeter Eckersleyhttps://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/8867Include Arabic translation for HTTPS Everywhere - ssl-observatory.dtd2020-06-27T14:14:26ZSheriefInclude Arabic translation for HTTPS Everywhere - ssl-observatory.dtdArabic Translation for HTTPS Everywhere - ssl-observatory.dtd was revised and completed, Please include it.Arabic Translation for HTTPS Everywhere - ssl-observatory.dtd was revised and completed, Please include it.Peter EckersleyPeter Eckersleyhttps://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/9293Javascript code is all mixed camelCase and snake_case, we should stick to one2020-06-27T14:14:18ZMicah LeeJavascript code is all mixed camelCase and snake_case, we should stick to oneI suppose we should stick to camel case since that's the Douglas Crockford's convention? http://javascript.crockford.com/code.html
This ticket is to clean up the code to make it all consistent.I suppose we should stick to camel case since that's the Douglas Crockford's convention? http://javascript.crockford.com/code.html
This ticket is to clean up the code to make it all consistent.Peter EckersleyPeter Eckersleyhttps://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/9311Disable Mozdev rule2020-06-27T14:14:18ZcypherpunksDisable Mozdev ruleThe certificate for mozdev.org expired on 01 July 2013 and Firefox throws up an "Untrusted Connection" error.The certificate for mozdev.org expired on 01 July 2013 and Firefox throws up an "Untrusted Connection" error.Peter EckersleyPeter Eckersleyhttps://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/9480Merge non-ruleset changes from Master -> Stable2020-06-27T14:14:13ZYan ZhuMerge non-ruleset changes from Master -> StableThis is for keeping track of non-ruleset files with changes that should get merged immediately from master to stable. Some of these fix UI bugs - ex: change the color of the HTTPS Everywhere icon when enabled/disabled, make the number of...This is for keeping track of non-ruleset files with changes that should get merged immediately from master to stable. Some of these fix UI bugs - ex: change the color of the HTTPS Everywhere icon when enabled/disabled, make the number of applicable rules show up next to the icon.
toolbar_button.js
toolbar_button.xul
ApplicableList.js
HTTPSRules.js
makexpi.sh (includes --fast option)
https-everywhere.js
fetch_source.xul
fetch_source.jsHTTPS-E 4 stableYan ZhuYan Zhuhttps://gitlab.torproject.org/tpo/applications/https-everywhere-eff/-/issues/9599HTTPS Everywhere builds should be deterministic2020-06-27T14:14:09ZMicah LeeHTTPS Everywhere builds should be deterministicI just did a quick test, and it looks like HTTPS Everywhere builds are not deterministic even on the same computer.
Here's a quick shell script that clones HTTPS Everywhere, checks out the 3.4.1 tag, makes a Firefox build, and then take...I just did a quick test, and it looks like HTTPS Everywhere builds are not deterministic even on the same computer.
Here's a quick shell script that clones HTTPS Everywhere, checks out the 3.4.1 tag, makes a Firefox build, and then takes a checksum of it: https://gist.github.com/micahflee/6346081
If you run this twice in a row you get different checksums.
I suspect that when the package gets zipped there's a timestamp in there or something and that's what's throwing the checksum off.
I'm excited that TBB 3.0 is doing deterministic builds, and I'd love HTTPS Everywhere to get there too: https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromiseMicah LeeMicah Lee