#28005: Officially support onions in HTTPS-Everywhere -------------------------------------------------+------------------------- Reporter: asn | Owner: tbb- | team Type: defect | Status: | needs_review Priority: Medium | Milestone: Component: Applications/Tor Browser | Version: Severity: Normal | Resolution: Keywords: tor-hs, https-everywhere, network- | Actual Points: 18 team-roadmap-november, network-team-roadmap- | 2020Q1, TorBrowserTeam202003R, ux-team | Parent ID: #30029 | Points: 20 Reviewer: mcs, sysrqb, antonela | Sponsor: | Sponsor27-must -------------------------------------------------+-------------------------
Comment (by acat): Thanks again for the review. Revised branches: https://github.com/acatarineu/tor-browser/commit/28005+4, https://github.com/acatarineu/torbutton/commit/28005+2. Replying to [comment:35 mcs]: > Is there a version of HTTPS-E available that supports the new `get_simple_rules_ending_with` API? When we tested with HTTPS-E 2020.3.16 we saw some strange behavior, but if that is supposed to work we can try again. I originally tested by building a non-signed xpi with https-everywhere master and installing it manually, but now installing the official https://eff.org/files/https-everywhere-2020.3.16-eff.xpi is working fine for me (after a browser restart). > Related to `browser/components/onionservices/HttpsEverywhereControl.jsm`: > * Should we open a new ticket for the "lock the channel to prevent user changes" issue? Is it a foot gun? I guess the idea is that we do not want users to substitute their own URL, etc. with the SecureDrop ruleset. On the other hand, I think users can add their own .tor.onion rules. What I was thinking is to be able to setup the ruleset in a way that behaves like the default EFF (Full) ruleset, so that it cannot be edited via UI (perhaps just allow to disable? but that might require more work on https-everywhere side). But yes, this does not protect against .tor.onion mappings being overriden by other rulesets that a user may add. I think it's a good to have change, but not strictly needed for now. I created #33694 for this. Replying to [comment:36 mcs]: > One thing I forgot to mention: the SecureDrop ruleset maps `www.nytimes.com.securedrop.tor.onion` to the NYT SecureDrop service. It is inconvenient to require the `www.` prefix as well as `.com`. But I am not sure what process was used to create the ruleset and how it will be maintained by SecureDrop people going forward. I think they wanted to keep exactly the same original domain: there are cases without `www.` like `home.coworker.org.securedrop.tor.onion` or `theintercept.com.securedrop.tor.onion`. By the way, I did not do a review of all rulesets, but just noticed a weird case: `img.huffingtonpost.com.securedrop.tor.onion`. Here the argument of keeping the original domain would not hold, since `img.huffingtonpost.com` webpage does not work, so perhaps it's a bug. In any case, regarding `www.` prefix, I think we agree that it's preferable not to have it, so perhaps we should contact asking whether it would be possible to remove it - even if it does not match the original domain. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28005#comment:37> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs