Opened 20 months ago

Closed 8 weeks ago

Last modified 8 weeks ago

#28005 closed defect (fixed)

Officially support onions in HTTPS-Everywhere

Reported by: asn Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tor-hs, https-everywhere, network-team-roadmap-november, network-team-roadmap-2020Q1, ux-team, TorBrowserTeam202004R
Cc: ilf, bee, fdsfgs@…, gaba, brade, mcs Actual Points: 18.5
Parent ID: #30029 Points: 20
Reviewer: mcs, sysrqb, antonela Sponsor: Sponsor27-must

Description (last modified by asn)

The plan:

A major UX issue for onion services is their huge addresses. We want to fix this issue because an address with 56 random characters confuses people, it makes it harder to pass the address around, and it also makes it much harder to verify it.

There is a field of literature called "secure name systems" but none of the candidates are good enough for us right now. Hence, we present a hotfix that might offer a situational relief for users for the medium-term future, until we come up with something better, or while we experiment with more solutions. I suggest we keep this ticket focused to this idea, instead of debating why this and not that since we've already been doing this for far too long.

The plan is to use the HTTPS-Everywhere extension that we already have in Tor Browser, and encourage people to write their own rulesets for onions. We are talking about community-maintained rulesets and nothing that is officially maintained by The Tor Project or by HTTPS-Everywhere. This ticket is about making it easier for people to create, import and use this rulesets. We are talking about UI/UX improvements, writing blog posts and doing Q&A.

Here are some example of community rulesets we can imagine:

  • The SecureDrop ruleset: where securedrop makes a ruleset with their whole directory. People can download that to quickly visit securedrop destinations, by going to securedrop-nyt.tor.onion .
  • The Torproject ruleset: where torproject makes a ruleset with all their onions. We developers can use that to quickly visit Tor sites over onion, by going to tor-trac.tor.onion instead of remembering the onion.
  • The Bitcoin ruleset: where a "trusted" bitcoin entity publishes a ruleset with various cryptocurrency-related rules that allow people to quickly visit them.

This approach has both positives and negatives (I assure you this is the case with every "secure naming" project out there):

  • Positives: Good security if the ruleset is taken from a trusted source. No state keeping. Reachable engineering effort. No global names, hence no fear of name squatting. Easy to understand tradeoffs.
  • Negatives: Terrible security if the ruleset is evil. No global names: If you want people to use your shorten onion name, you need to persuade them to use your ruleset.

Here are some HTTPS-Everywhere issues we need to solve based on my Mexico notes:

  • Be able to stop update channels per-channel.
  • Need good UI to easily look and understand rules.
  • Need to implement file extension to install ruleset with one-click from web button.

Here are some issues we need to think about:

  • We need good user text to make sure that people don't shoot themselves in the foot too often by installing bad rulesets and whatnot (they already do it daily when they open onions from "search enginers" or reddit).
  • Which tld to use? If we use .tor we open ourselves to DNS leaks in normal browsers. If we use .tor.onion that might be confusing to people.
  • Are there any issues with SSL?

More resources:

https://trac.torproject.org/projects/tor/wiki/org/meetings/2018MexicoCity/Notes/OnionV3ux
https://trac.torproject.org/projects/tor/wiki/org/meetings/2018MexicoCity/Notes/HTTPSEverywhereNotes
https://blog.torproject.org/cooking-onions-names-your-onions

Child Tickets

Attachments (4)

httpse-v3onions.png (66.6 KB) - added by antonela 20 months ago.
O2A5.jpg (168.3 KB) - added by antonela 4 months ago.
28005.webm (2.3 MB) - added by acat 3 months ago.
httpse-v3onions.2.png (81.4 KB) - added by antonela 3 months ago.

Change History (59)

Changed 20 months ago by antonela

Attachment: httpse-v3onions.png added

comment:1 Changed 14 months ago by asn

Sponsor: Sponsor27-must

comment:2 Changed 14 months ago by gk

Cc: ilf bee added

Closing #1670 and #19812 as duplicate of this ticket. I think the onion rulesets idea fits nicely with their requests.

comment:3 Changed 14 months ago by gk

Cc: fdsfgs@… added

comment:4 Changed 14 months ago by asn

Points: 20

comment:5 Changed 14 months ago by pili

Parent ID: #30029

comment:6 Changed 14 months ago by asn

Description: modified (diff)

comment:7 Changed 13 months ago by gaba

Cc: gaba added

comment:8 Changed 10 months ago by gaba

Keywords: network-team-roadmap-november added

comment:9 Changed 8 months ago by asn

Here are some notes from the plans we made in Stockholm in the meeting between
me, antonela, sysrqb, redshiftzero, geko and dgoulet:


Scope of work:

  • First iteration will include onion rules for securedrop websites (e.g. nytimes.securedrop.tor.onion -> nyttips4bmquxfzw.onion)
  • Need to add a toolbar button in the ffox UI to show that a redirect happened
  • Rewrite URL in URL bar (only show the human-readable url)
  • Add support for viewing rulesets (?)
  • See how update channels work and whether we should disable them or not.

Out of scope:

  • First iteration will not allow people to easily add their own rules

TLD scheme:

  • Three options for tld scheme:

a) nytimes.securedrop.onion (ambiguous and probably unsafe)
b) nytimes.securedrop.tor.onion (safe but bad UX)
c) nytimes.securedrop.tor (good UX but DNS leaks in other browsers)

We decided to ditch (a) from our options and do either (b) or (c). (b) is the
safest and we should probably roll with that (?).

FPF plan:

  • FPF will change their securedrop directory to include ".tor.onion" links for their various instances.

Metadata:

  • 3 months of work are enough

comment:10 Changed 4 months ago by sysrqb

Keywords: TorBrowserTeam202001 added

Putting this on the browser team's plate.

comment:11 Changed 4 months ago by acat

Some thoughts after thinking a bit how to implement this.

Supporting local redirects from human-memorable addresses (.tor.onion -> .onion) can be done with https-everywhere extension as is, either by adding a 3rd-party update channel or by adding custom rulesets in debug mode (the latter is less usable I assume). With respect to update channels, it should not be difficult to modify https-everywhere to allow enabling/disabling automatic updates per channel and not globally as it is currently implemented, and this is something that might be interesting also for non Tor Browser https-everywhere users (although I don't think many people have more update channels than the default one).

Then we need to show the human-memorable URL in the urlbar, plus possibly some visual feedback indicating that there was some kind of local redirect (I guess the concrete UX solution still needs to be decided). This has to be implemented in Tor Browser, since AFAIK there is no way to achieve that using a WebExtension like https-everywhere only. There are several ways this can be implemented from the Tor Browser side, but at the end of the day we need some way to know whether for the current .onion page we have some .tor.onion human-memorable "alias" that the user trusts.

With the current implementation, it would be difficult from Tor Browser side to ask https-everywhere questions like: is there any .onion mapping for this .tor.onion domain the user just entered? So I think the simplest is to observe .tor.onion -> .onion redirects and assume that when this happens it's because the original .tor.onion is a human-memorable alias for the corresponding .onion that the user trusts. Observing http requests like that should be quite simple to do from Tor Browser side, and this implementation would work independently of https-everywhere: we just observe .tor.onion -> .onion redirects, but we don't need to know how or by whom these redirects were done.

A few questions/issues regarding showing short .tor.onion in urlbar:

  1. Whenever there is a .tor.onion -> .onion redirect, should we display the full original URL in the urlbar, or just replace the hostname for the human-memorable one in the final URL? For example, let's say we observe a redirect from http://nytimes.securedrop.tor.onion to https://www.nyttips4bmquxfzw.onion (upgrade to https + translate from .tor.onion + adding www). In this case I think it would not make much sense to show the original URL, but just display https://www.[nytimes.securedrop.tor.onion] (and if we follow the solution I mentioned, show https://www.nyttips4bmquxfzw.onion when user clicks on it).
  1. What should we do when user keeps navigating in subpages of some .onion, given the fact that the .tor.onion -> .onion is only observed in the first navigation? Should we show the human-memorable .tor.onion in the urlbar for that tab until the user navigates away from the underlying .onion? Do we also need to show .tor.onion for links opened in a new tab from there?
  1. Do we need to show .tor.onion when user navigates directly to a .onion page for which we have some .tor.onion "rule"? (mentioned by sysrqb in a IRC conversation)

If we were to implement 3) I think we would need to be able to ask https-everywhere for some kind of reverse lookup to obtain a .tor.onion for a given .onion hostname, so the current approach of just observing http redirects from Tor Browser would not work.

Note that if we had an explicit list of .tor.onion -> .onion pairs indicating this mapping (like a /etc/hosts file) we would not need to be looking for redirects to infer the .tor.onion -> .onion relationship, and doing a "reverse lookup" (finding a .tor.onion that corresponds to some .onion) would be trivial. I also think that designing a UI to view/edit .tor.onion rules/mappings would be much easier than doing one for https-everywhere rules, since https-everywhere rulesets are more powerful (and more complicated) than just .tor.onion -> .onion mappings. So, depending on what we want to support, especially if we want to do UI to view/edit rules, I would consider implementing the full feature in Tor Browser directly instead of partially using https-everywhere.

So I would suggest discussing/deciding about the Add support for viewing rulesets (?) feature, as I'm not sure how it could look like if we are going to do this with https-everywhere.

Prototype

For now to move forward my plan is to implement some UI to replace .onion by .tor.onion in the urlbar, by observing request redirects as I mentioned before. I know the concrete UX still needs to be decided, but I'll try to implement the urlbar logic and I think most of this code will be needed independently of the final solution. I'll try to show .tor.onion in the urlbar whenever there is a redirect from .tor.onion and as long as the user does not navigate away from the real .onion. As I said, I think this would be easier if we had something like an explicit hosts-like .tor.onion -> .onion mapping instead of delegating this to https-everywhere, but we can still do a good job by observing redirects.

Then, it should be possible to test the feature by adding some custom update channel to https-everywhere that has .tor.onion mappings in it. For example:

Path Prefix: https://people.torproject.org/~acat/misc/rulesets/

JWK: {"kty":"RSA","e":"AQAB","n":"2IGvrYj_UwpO8EMNeEiitb8imzuJA-BGngLYtMkY72wx6aPhuWWvGs-Dlh4lHB4fi8rxfeb0N6ZwCyfCKBeHgfuTgbH14HB-ZSA47JHKEO4fSiay1jjhsGDzQlZDVdn_Wfyxi5je80pizMsOulHKEKzRx4HIcrXY1nf8iiOHEWaB0GX8H1pJjyIlqTxN9Pm5Q4h7kRLUoq3O9EE3o7q1dVeaxYM221WPqaSq9mawAhih4wo_79mb6JinG--s9F3jfqmnOvQk-xAoSTA-XNqTvO-7Mg_WajoA7Lnx1pJbGuvhqNOdodWOFxdMMNaPL8JXmPywl6zAqMESU1rXcaVKVdx1LpcmTyz8dGi3u_GTb6fo5GqXUgByvvRcOXA6DAFC7tbLEy1QinU0q4cRZJYf6s4QxgyRsCgxrcJ9kuDwDHviAm9Yn3eEFRbD2e3hRFfZyvkkLepEWywEfBGdBjQ_Kz9gkQTzmpVef1J-sSD6dnW5OEVEXAPO0sEdr5o-Ng9NSvDGZ3Sw-4AgFO6aynLnpvbVOYneppLF7MKwGVQv0tQ8XY3zBEsxidTIkvmpzKZp6QElpfCwbYnl9aQ9hQ3BmOPIhM2VunP47MPOgyAp4s2m3knwCWbPSR5Gm8agDwIGA1Va1eFAtS-YAYk8v-J20iTyuXrpWqrQmFjEnVLsav8"}

This should not take long, I would say at most 5 points. From there we could discuss about the .tor.onion urlbar replacement UX, and decide about the UI to view rules/mappings. Depending on that, we could still go for https-everywhere or implement everything in Tor Browser.

Last edited 4 months ago by acat (previous) (diff)

comment:12 Changed 4 months ago by mcs

Cc: brade mcs added

comment:13 Changed 4 months ago by gaba

Keywords: network-team-roadmap-2020Q1 added

Move s27 must tickets into new roadmap.

comment:14 Changed 4 months ago by acat

I was not sure whether it was worth implementing this in Tor Browser directly instead of using https-everywhere, so as suggested by asn I made some list of pros/cons and time estimates for each option.

TLDR: I think it's ok to stick to https-everywhere.

Features to be implemented

Listing (sub)features so that these can be referenced later.

  1. Have some local knowledge of mappings from memorable *.tor.onion to *.onion in Tor Browser.
  1. Have a way to subscribe to sources of .tor.onion -> .onion mappings, in a way that these can be automatically updated (update channels).
  1. Automatically redirect known human-memorable *.tor.onion addresses to the corresponding .onion.
  2. Via "some UX solution", show the human-memorable .tor.onion in the urlbar even though the actual location is a "long" .onion.
  1. (Maybe) also do 3) when the user navigates to some .onion directly for which we know some *.tor.onion ("reverse lookup").
  1. (Maybe) allow users to view the local .tor.onion -> .onion mappings.
  1. (Out of scope, but maybe later) allow users to edit the local .tor.onion -> .onion mappings.

Pros/cons of using https-everywhere

Pros:

  • Update channels already implemented (feature 2).
  • Automatic redirect already implemented (feature 3).
  • Might be easier to get third-parties to maintain .tor.onion update channels than if we implement our own update channel mechanism.

Cons:

  • We might need to do a custom build of the extension if we can't get the changes we need upstreamed to https-everywhere, and that would mean dealing with [1].
  • With the current rules format, it's not obvious how to extract reliable, explicit .tor.onion -> .onion mappings (see [3] for an example of a torproject.org ruleset extracted from [4]). I think a list of explicit .tor.onion -> .onion mappings would be more desireable, as https-everywhere can do arbitrary url rewrites, and depending on how a rule is written it might not be obvious whether it's a .tor.onion -> .onion mapping or something else.
  • If for some reason one day https-everywhere is not maintained anymore, we will probably have to reimplement it in Tor Browser anyway.

Work needed

I'll list the concrete changes that would need to be done if we were to implement it with https-everywhere, with Tor Browser, and finally the ones that need to be done in any case in Tor Browser (common), with time estimation.

HTTPS-Everywhere:

Initially I was considering trying to make https-everywhere support a new kind of rules which would explicitly express a .tor.onion -> .onion mapping. However, after thinking a while I think it's too unclear how much time this change would take or if a possible PR would be accepted at all. So, trying to be pragmatic here and suggesting to leave the rules as they are now, and somehow implement a function in Tor Browser side that receives a .tor.onion https-everywhere ruleset and returns a (conservative) .tor.onion -> .onion mapping, so that we can do urlbar .tor.onion rewriting and rules viewing in a simple way.

  • 3 points: Implement message passing in https-everywhere similar to the one we use for NoScript, so that from Tor Browser side we can receive .tor.onion rulesets and features 4, 5, 6 and possibly 7 can be implemented.
  • 1 point: Implement message passing to be able to setup/control update channels programatically from Tor Browser side (feature 1). This should allow us to install an update channel without needing a custom build and having to deal with [1], which I'm not sure how difficult would be.

Everything in Tor Browser:

  • 5 points: Implement update channels feature.
  • 2 points: Implement automatic redirects based on .tor.onion mappings.

Common items (need to be implemented in Tor Browser in any case):

  • 2 points: UI to view .tor.onion -> .onion mappings (I'm assuming we don't want this in https-everywhere).
  • 3 points: Replacing .onion by human-memorable .tor.onion in urlbar.

According to these estimates, https-everywhere path would be 4 + 5 = 9 points, and doing everything in Tor Browser 7 + 5 = 12 points.

I think it's preferrable to keep the plan and implement it using https-everywhere, and only switch to doing everything in Tor Browser if, at some point, we are forced for technical reasons (which I hope will not be the case).


[1] https://trac.torproject.org/projects/tor/ticket/10394
[2] https://github.com/EFForg/https-everywhere/blob/83642b8e7024a7c4ddc8c6f062c2306882f7f3c0/chromium/background-scripts/update.js
[3]

<ruleset name="TorProject Onion" default_off="See https://trac.torproject.org/projects/tor/ticket/11567">
	<target host="torproject.org" />
	<target host="www.torproject.org" />
	<target host="archive.torproject.org" />
	<target host="media.torproject.org" />
	<target host="trac.torproject.org" />
	<rule from="^https?://trac\.torproject\.org/" to="http://vwp5zrdfwmw4avcq.onion/" />
	<rule from="^https?://media\.torproject\.org/" to="http://p3igkncehackjtib.onion/" />
	<rule from="^https?://archive\.torproject\.org/" to="http://j6im4v42ur6dpic3.onion/" />
	<rule from="^https?://(www\.)?torproject\.org/" to="http://idnxcnkne4qt76tg.onion/" />
</ruleset>

[4] https://github.com/chris-barry/darkweb-everywhere

comment:15 in reply to:  11 Changed 4 months ago by antonela

Replying to acat:

Some thoughts after thinking a bit how to implement this.

thanks for sharing this walking through, acat :)

A few questions/issues regarding showing short .tor.onion in urlbar:

  1. Whenever there is a .tor.onion -> .onion redirect, should we display the full original URL in the urlbar, or just replace the hostname for the human-memorable one in the final URL? For example, let's say we observe a redirect from http://nytimes.securedrop.tor.onion to https://www.nyttips4bmquxfzw.onion (upgrade to https + translate from .tor.onion + adding www). In this case I think it would not make much sense to show the original URL, but just display https://www.[nytimes.securedrop.tor.onion] (and if we follow the solution I mentioned, show https://www.nyttips4bmquxfzw.onion when user clicks on it).

Right. The urlbar should display the onion icon + the .onion name:
[⊚] https://www.[nytimes.securedrop.tor.onion]

  1. What should we do when user keeps navigating in subpages of some .onion, given the fact that the .tor.onion -> .onion is only observed in the first navigation? Should we show the human-memorable .tor.onion in the urlbar for that tab until the user navigates away from the underlying .onion? Do we also need to show .tor.onion for links opened in a new tab from there?

Maybe, ideally, yes. I wonder what sysrqb or pospeselr think about this. It is hard for me to map all the problems it could carry.

  1. Do we need to show .tor.onion when user navigates directly to a .onion page for which we have some .tor.onion "rule"? (mentioned by sysrqb in a IRC conversation)

This is a good question and I think we should define it before anything because it can be very weird. If we have a strong communication about onion names (via trusted parties, like SecureDrop), then showing an unmemorable onion address to end-users is not smart. If a user writes/copypaste the .onion we can think about how to communicate the .tor.onion redirect for first time users with any UI fashion (a doorhanger can do this work very nicely)

So I would suggest discussing/deciding about the Add support for viewing rulesets (?) feature, as I'm not sure how it could look like if we are going to do this with https-everywhere.

Maybe this is out of scope. We will not allow users to add nor remove .onion related rulesets. IMO showing them at the UI is not needed on this sprint.

comment:16 in reply to:  14 ; Changed 4 months ago by antonela

Replying to acat:

  1. Via "some UX solution", show the human-memorable .tor.onion in the urlbar even though the actual location is a "long" .onion.

Yes. We should show the memorable .tor.onion in the url bar and we should rely on the circuit display for showing the long onion. I made some props here. Look at the image 4.0.

  1. (Maybe) also do 3) when the user navigates to some .onion directly for which we know some *.tor.onion ("reverse lookup").

I'm thinking about this flow.

  1. (Maybe) allow users to view the local .tor.onion -> .onion mappings.

I don't think this is prior to this release.

comment:17 in reply to:  16 ; Changed 4 months ago by acat

Replying to antonela:

Replying to acat:

  1. Via "some UX solution", show the human-memorable .tor.onion in the urlbar even though the actual location is a "long" .onion.

Yes. We should show the memorable .tor.onion in the url bar and we should rely on the circuit display for showing the long onion. I made some props here. Look at the image 4.0.

What if the user wants to copy-paste or inspect the real address (the .onion one)? Or is this not a use case we would need to support?

Besides, I was thinking that perhaps we should make it more noticeable that we are displaying (just) a short .tor.onion local "alias" instead of the actual .onion in the urlbar. In the current design, unless I'm missing something, we would show it exactly as if the .tor.onion was the real page address. I think that might lead to surprises for some users, especially the more technical ones. For example, I would expect that the hostname displayed in the urlbar is the actual origin of the page (e.g. the one that is sent as Host: header in the page HTTP requests, etc.). But that would not be the case here, since we would show .tor.onion in the urlbar the but the true origin of the page would be .onion (the .tor.onion urlbar replacement would be just "cosmetic").

I'm not completely sure how this could be done in terms of UI. Note that now we already show the domain in a highlighted color in the urlbar (Firefox change). Perhaps in these cases we could show the .tor.onion domain in a different color, and when user clicks on the urlbar show the real .onion so that it can be copy-pasted if needed? I'm not sure.

comment:18 Changed 4 months ago by acat

Component: HTTPS Everywhere/EFF-HTTPS EverywhereApplications/Tor Browser
Owner: changed from legind to tbb-team

I think the changes here belong more to Tor Browser than to HTTPS Everywhere component.

Changed 4 months ago by antonela

Attachment: O2A5.jpg added

comment:19 in reply to:  17 Changed 4 months ago by antonela

Replying to acat:

Replying to antonela:

Replying to acat:

  1. Via "some UX solution", show the human-memorable .tor.onion in the urlbar even though the actual location is a "long" .onion.

Yes. We should show the memorable .tor.onion in the url bar and we should rely on the circuit display for showing the long onion. I made some props here. Look at the image 4.0.

What if the user wants to copy-paste or inspect the real address (the .onion one)? Or is this not a use case we would need to support?

When we talked about having the onion address at the circuit display, we also thought about making it available to copy with a click for users. What do you think? Could we allow users to click and copy the origin onion address from the circuit display?

Besides, I was thinking that perhaps we should make it more noticeable that we are displaying (just) a short .tor.onion local "alias" instead of the actual .onion in the urlbar. In the current design, unless I'm missing something, we would show it exactly as if the .tor.onion was the real page address. I think that might lead to surprises for some users, especially the more technical ones. For example, I would expect that the hostname displayed in the urlbar is the actual origin of the page (e.g. the one that is sent as Host: header in the page HTTP requests, etc.). But that would not be the case here, since we would show .tor.onion in the urlbar the but the true origin of the page would be .onion (the .tor.onion urlbar replacement would be just "cosmetic").

Technical users might want to learn more about onion origin and how the ruleset is being implemented. We could have more information about how it happened on second level navigation. I'd like to talk during the next meeting about this with the dev team. Nothing fancy is needed for this release but we can see what we can do to stay in scope.

I'm not completely sure how this could be done in terms of UI. Note that now we already show the domain in a highlighted color in the urlbar (Firefox change). Perhaps in these cases we could show the .tor.onion domain in a different color, and when user clicks on the urlbar show the real .onion so that it can be copy-pasted if needed? I'm not sure.

Highlight the url bar seems quite confusing for me. I think that if we rely on the circuit display for showing the origin onion address and also allow users to copy it from there is a good path to follow.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/28005/O2A5.jpg

comment:20 Changed 4 months ago by pili

Keywords: TorBrowserTeam202002 added; TorBrowserTeam202001 removed

Moving tickets to February

comment:21 Changed 3 months ago by acat

Status: newneeds_review

Patches for review in https://github.com/acatarineu/tor-browser/commit/28005 and https://github.com/acatarineu/torbutton/commit/28005. Test builds in https://people.torproject.org/~acat/builds/28005_testbuild/. I will also attach a short video.

Some comments:

This was implemented without any change to the https-everywhere code, just the official latest version. For now I went for just observing the https-everywhere local redirects as a way to learn the .tor.onion -> .onion mappings. A test securedrop update channel (https://people.torproject.org/~acat/misc/rulesets/) is installed programatically on startup here by sending messages to https-everywhere, which are handled in the extension background script. Probably it's not an ideal solution for release, but maybe it's ok for nightly? Ideally, replacing the test update channel by an official securedrop one if it's available. For testing: note that it might take a while on first startup to fetch the update channel and add the rules, so the .tor.onion addresses might not work immediately. Currently, only one .tor.onion address is available: http://nytimes.securedrop.tor.onion.

This implementation does not display .tor.onion in the urlbar if the user has navigated to the corresponding .onion directly, only when it has done so with .tor.onion. We also keep the human-memorable hostname in the urlbar for navigations triggered from that page, as long as they are in the same origin. This made the implementation a bit more complicated than I would have liked, since we have to keep track for each "tab" whether we should rewrite the urlbar to .tor.onion (we navigated to a .tor.onion) or not (we navigated to .onion directly). The implementation would be significantly simpler if we would treat the two cases in the same way (always show .tor.onion, even if user navigated directly to the corresponding .onion). But I'm not sure if that's acceptable UX-wise. If so, we could do that in a next revision, although that would require changes to https-everywhere (we should be able to ask, for a given .onion, whether https-everywhere knows of some human-memorable .tor.onion).

Regarding the Click to Copy + ellipsis implementation in the circuit display, something I'm not sure of is whether we should be copying just the .onion domain, or the full URL. I would say I expect it to copy just the domain (since that's the text we are showing), so I'm not sure if that's fine as a solution for the "I want to copy the real .onion URL when it's rewritten to .tor.onion" use case. Besides, should we also show the trimmed .onion with ellipsis in the "Site information for ..."? The mockups do not show that, in that case the name from the EV certificate is used (Pro Public, Inc.).

Changed 3 months ago by acat

Attachment: 28005.webm added

comment:22 Changed 3 months ago by acat

Actual Points: 15

comment:23 Changed 3 months ago by sysrqb

Reviewer: mcs, sysrqb

comment:24 in reply to:  21 Changed 3 months ago by antonela

Thanks for your build acat! It works really smoothly on my end :)

Replying to acat:

Some comments:

This implementation does not display .tor.onion in the urlbar if the user has navigated to the corresponding .onion directly, only when it has done so with .tor.onion. We also keep the human-memorable hostname in the urlbar for navigations triggered from that page, as long as they are in the same origin. This made the implementation a bit more complicated than I would have liked, since we have to keep track for each "tab" whether we should rewrite the urlbar to .tor.onion (we navigated to a .tor.onion) or not (we navigated to .onion directly). The implementation would be significantly simpler if we would treat the two cases in the same way (always show .tor.onion, even if user navigated directly to the corresponding .onion). But I'm not sure if that's acceptable UX-wise. If so, we could do that in a next revision, although that would require changes to https-everywhere (we should be able to ask, for a given .onion, whether https-everywhere knows of some human-memorable .tor.onion).

I really expect to render the memorable name at the URL bar in both cases: using the .onion and using the .tor.onion. If it requires a patch on https-e then we can work with https-e folks on it for the next release.

Regarding the Click to Copy + ellipsis implementation in the circuit display, something I'm not sure of is whether we should be copying just the .onion domain, or the full URL. I would say I expect it to copy just the domain (since that's the text we are showing), so I'm not sure if that's fine as a solution for the "I want to copy the real .onion URL when it's rewritten to .tor.onion" use case. Besides, should we also show the trimmed .onion with ellipsis in the "Site information for ..."? The mockups do not show that, in that case the name from the EV certificate is used (Pro Public, Inc.).

The main reason for the click to copy feature is allowing users to (manually) check integrity. So, yes. The circuit display should render the onion address, always. I remember a discussion about using (https://trac.torproject.org/projects/tor/ticket/30024#comment:4)., trimmed addresses).

Also, we should use the memorable name at "Site information for.." header. From now, memorable names are onion services alias. Something that might be interesting for the next iteration is working on the second level navigation of the identity doorhanger (Site Security) to improve the information showed there. We may want to show the origin entire onionsite address and also if it exists, data about certificates. There is room for improvement on that section for advanced users.

I updated the mockup UI:

https://trac.torproject.org/projects/tor/raw-attachment/ticket/28005/httpse-v3onions.2.png

Last edited 3 months ago by antonela (previous) (diff)

comment:25 Changed 3 months ago by antonela

Keywords: ux-team added; tor-ux removed
Reviewer: mcs, sysrqbmcs, sysrqb, antonela

Changed 3 months ago by antonela

Attachment: httpse-v3onions.2.png added

comment:26 Changed 3 months ago by legind

https://github.com/EFForg/https-everywhere/pull/18994 creates a get_simple_rules_ending_with message handle returns an array of simple rules, which Tor can use to reverse-lookup .tor.onion addresses.

Example from Chrome HTTPSE popup console with the above update channel installed:

chrome.runtime.sendMessage({type: "get_simple_rules_ending_with", object: ".tor.onion"}, rules => console.log(rules));

undefined
VM51:1 [{…}]0: from_regex: "/^http[s]?:\/\/nytimes.securedrop.tor.onion\//"host: "nytimes.securedrop.tor.onion"scope_regex: "/^https?:\/\/[a-z0-9-]+(?:\.[a-z0-9-]+)*\.securedrop\.tor\.onion\//"to: "https://nyttips4bmquxfzw.onion/"__proto__: Objectlength: 1__proto__: Array(0)

This works currently in the pure JS implementation of the RuleSets, and I've also added it to the WASM code so that when/if Tor Browser enables WASM in extensions this will not cause breakage.

comment:27 Changed 3 months ago by mcs

Kathy and I did a quick review of the patches (comment:21). Overall, very impressive work! We know you are working on a revision already, but here are some comments:

  • UX: For the circuit display, does it make sense to show the full onion address on hover? (in addition to the "Click to Copy" functionality). That could be done with a tooltip and would allow users to see the complete name without pasting somewhere else.
  • Please add some more detail to the tor-browser commit message.
  • Please add copyright notices to the new files (browser/components/onionalias/*).
  • We wish that the tor-browser patch did not have to touch the Firefox code in so many places. That might be unavoidable though. Please add some comments near the added codeblocks; for example, to explain the places you perform origin checks.
  • In docshell/base/nsDocShell.cpp, there is no need to check that oldURI and newURI are defined since they are checked by code immediately above the code you added.
  • In toolkit/content/widgets/browser-custom-element.js, this._allowOnionUrlbarRewrites is initialized to null but it would be clearer and more consistent to initialize it to false.
  • In toolkit/content/widgets/browser-custom-element.js, there is a typo: this.docShell.allowOnionUrlbarRewritesu (trailing u).
  • In browser/components/onionalias/OnionAliasStore.jsm, it seems that nothing is ever removed from _onionMap while the browser is running. Will this cause any problems? For example, what happens if an HTTPS-E rule update removes some mappings?
  • The .tor.onion illusion is not complete. For example, I noticed that when I created a bookmark the unfriendly .onion name was stored in the bookmark. It might be difficult to find and fix all cases like this though. In the long run, I wonder if we can learn something from how things like AltSvc are implemented (I assume AltSvc is handled at a much lower level than the URL bar but I have not looked closely).

comment:28 in reply to:  27 Changed 2 months ago by acat

Actual Points: 1517
Keywords: TorBrowserTeam202003R added; TorBrowserTeam202002 removed

Thanks for the review. I addressed the issues in https://github.com/acatarineu/tor-browser/commit/28005+1.

Apart from this, I also added support for get_simple_rules_ending_with which was introduced in https://github.com/EFForg/https-everywhere/pull/18994. I think this handles your concern

In browser/components/onionalias/OnionAliasStore.jsm, it seems that nothing is ever removed from _onionMap while the browser is running. Will this cause any problems? For example, what happens if an HTTPS-E rule update removes some mappings?

better than the previous patch. However, since this is still not in the release version of HTTPS Everywhere there is a fallback using the first patch approach, a http observer. I hope these are not too many changes for a second review. Most of the code for this was added in OnionAliasStore.jsm, and some in HttpsEverywhereControl.jsm. I also added some logging in OnionAliasStore.jsm and added some more comments too.

The only comment I did not address yet was

UX: For the circuit display, does it make sense to show the full onion address on hover? (in addition to the "Click to Copy" functionality). That could be done with a tooltip and would allow users to see the complete name without pasting somewhere else.

as I thought we could wait for antonela's thoughts about it.


We wish that the tor-browser patch did not have to touch the Firefox code in so many places. That might be unavoidable though. Please add some comments near the added codeblocks; for example, to explain the places you perform origin checks.

Indeed, me too. I think we could avoid these changes if it would be fine to treat the case when user types a .tor.onion exactly the same way as when the user types the .onion directly, meaning that both end up showing the same memorable URL in the urlbar, and there is no other UI element that is shown in one case and not in the other, for example. In this case, I think we would not need to maintain the state of whether the user started the navigation with a .tor.onion, and we could get rid of all the code tracking this for all the subnavigations. In part, this should now be possible because of the new "get_simple_rules_ending_with" (once this is released in https everywhere).

comment:29 Changed 2 months ago by acat

Sorry, I forgot to mention that I also moved the browser/components/onionalias to browser/components/onionservices, following your comment in https://trac.torproject.org/projects/tor/ticket/21952#comment:111, which I assumed would also apply here. I also changed the update channel to use the testing securedrop one, instead of mine.

Besides, one comment I had not answered:

The .tor.onion illusion is not complete. For example, I noticed that when I created a bookmark the unfriendly .onion name was stored in the bookmark. It might be difficult to find and fix all cases like this though. In the long run, I wonder if we can learn something from how things like AltSvc are implemented (I assume AltSvc is handled at a much lower level than the URL bar but I have not looked closely).

I had thought about this one, I was not completely sure if this was the desired behaviour, but it probably is. Something we might want to consider: is there a reason for someone to want to bookmark explicitly the .onion and not the .tor.onion? If we later implement the urlbar rewrites when user types the .onion directly, it might be difficult for a user to do this (although technically still possible, by editing the bookmark manually via Bookmarks menu). Perhaps we can discuss this (in the next S27 meeting?), and I can revise the patch if it's decided it has to be done.

comment:30 in reply to:  27 Changed 2 months ago by antonela

Replying to mcs:

  • UX: For the circuit display, does it make sense to show the full onion address on hover? (in addition to the "Click to Copy" functionality). That could be done with a tooltip and would allow users to see the complete name without pasting somewhere else.

We can show the full onion at the alt label for users who don't want to click copy. I like that idea. A custom tooltip seems too much, but a default hover seems appropriate.

  • The .tor.onion illusion is not complete. For example, I noticed that when I created a bookmark the unfriendly .onion name was stored in the bookmark. It might be difficult to find and fix all cases like this though. In the long run, I wonder if we can learn something from how things like AltSvc are implemented (I assume AltSvc is handled at a much lower level than the URL bar but I have not looked closely).

Saving the memorable address is a must! Maybe alt-svc or onion-location make it easier, yes.

comment:31 Changed 2 months ago by asn

Random question: Is there an issue with cookies and SSL and multiple websites falling under *.tor.onion? I think mike was raising concerns about this at some point?

comment:32 in reply to:  31 Changed 2 months ago by acat

Replying to asn:

Random question: Is there an issue with cookies and SSL and multiple websites falling under *.tor.onion? I think mike was raising concerns about this at some point?

The urlbar rewrites to .tor.onion are cosmetic: they should just affect the UI. For everything else other than what is displayed in the urlbar, the actual URL is still the .onion one. That includes TLS (which is checked against the .onion, not the .tor.onion) and cookies.

comment:33 Changed 2 months ago by acat

Actual Points: 1718

Updated patches to handle the case of bookmarks not being done with the memorable .tor.onion (https://github.com/acatarineu/tor-browser/commit/28005+2), and to show a tooltip in the circuit display on domain hover (https://github.com/acatarineu/torbutton/commit/28005+1),

For the latter, I could not make the standard tooltip via title or alt attributes work with the HTML span, so I had to convert it to a XUL html:span element, and use the tooltiptext attribute.

comment:34 Changed 2 months ago by acat

The issue with https://trac.torproject.org/projects/tor/ticket/21952#comment:117 would also affect this one, so I made a small revision to not use onStateChange and use onLocationChange instead: https://github.com/acatarineu/tor-browser/commit/28005+3.

Besides, I made some testbuilds (of 28005+2 patch) that might be useful for UX review: https://people.torproject.org/~acat/builds/28005+2/

comment:35 in reply to:  34 ; Changed 2 months ago by mcs

Replying to acat:

The issue with https://trac.torproject.org/projects/tor/ticket/21952#comment:117 would also affect this one, so I made a small revision to not use onStateChange and use onLocationChange instead: https://github.com/acatarineu/tor-browser/commit/28005+3.

Good catch. Just a few more comments from Kathy and me:

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.

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.
  • In getRulesetTimestamp() please add a comment to explain the structure of the rulesets returned by HTTPS-E via get_ruleset_timestamps (or maybe the comment can point to some HTTPS-E doc or code). For example, why do we have return securedrop[1];?

Related to browser/components/onionservices/OnionAliasStore.jsm:

  • Within the _periodicRulesetCheck() comment s/preferrable/preferable/
  • Within the init() comment: s/a http observer/an http observer/
  • In the "Found ruleset" debugging output, there is a space after the first timestamp, e.g., OnionAlias: Found ruleset timestamp 1582940785 , current is 1582940785. I wonder if you can use string substitutions to construct the log messages instead of a list of JS values (https://developer.mozilla.org/en-US/docs/Web/API/Console#Using_string_substitutions).

Related to Torbutton's chrome/content/tor-circuit-display.js:

  • Within xmlTree() the let element = block is indented too much.
Last edited 2 months ago by mcs (previous) (diff)

comment:36 Changed 2 months ago by 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.

comment:37 in reply to:  35 ; Changed 2 months ago 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 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 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.

comment:38 Changed 2 months ago by acat

Actual Points: 1818.2

comment:39 in reply to:  37 ; Changed 2 months ago by mcs

Replying to 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.

The torbutton patch looks good.

We see one tiny issue with the tor-browser patch: there is a stray " in the log message that begins with Found ruleset timestamp.

But we did experience a significant problem when using the newer HTTPS-E (​https://eff.org/files/https-everywhere-2020.3.16-eff.xpi). Using our own browser build on macOS, if we start clean by removing the browser-extension-data/https-everywhere-eff@eff.org/ directory from the browser profile, then no rules are added to the _onionMap in OnionAliasStore.jsm. Although the ruleset is preset, logging shows that zero rules were installed:

OnionAlias: Checking for new rules
OnionAlias: Found ruleset timestamp" 0, current is null
OnionAlias: New rules found, updating
OnionAlias: Loading 0 rules
...
OnionAlias: Checking for new rules
OnionAlias: Found ruleset timestamp" 1582940785, current is 0
OnionAlias: New rules found, updating
OnionAlias: Loading 0 rules
...
OnionAlias: Checking for new rules
OnionAlias: Found ruleset timestamp" 1582940785, current is 1582940785

At the end, since the timestamp is unchanged no attempt is made to add the rules to _onionMap. But I guess the first time a non-zero timestamp was returned the rules should have been present. HTTPS-E does have the rules; we can tell because we are redirected to the .onion (but the ugly .onion name is displayed in the URL bar, which it should not be).

Maybe this is an HTTPS-E bug with the get_simple_rules_ending_with API or some kind of race, because if we start the browser a second time it does work correctly:

OnionAlias: Checking for new rules
OnionAlias: Found ruleset timestamp" 1582940785, current is null
OnionAlias: New rules found, updating
OnionAlias: Loading 38 rules

A workaround might be to ignore the timestamp if no rules are returned by HTTPS-E (but Kathy and I did not try that).

comment:40 Changed 2 months ago by acat

Actual Points: 18.218.3

This is a bit unfortunate, nice catch. I think this must be an https-everywhere issue, but I'd have to investigate a bit to be sure. I will open a ticket about it.

For now, I changed the logic to always start the http observer fallback and remove it when we are able to load some rules directly, which should handle this case.

This is the revised branch: ​https://github.com/acatarineu/tor-browser/commit/28005+5.

comment:41 Changed 8 weeks ago by acat

I created https://github.com/EFForg/https-everywhere/issues/19102 and https://github.com/EFForg/https-everywhere/issues/19101 to address the issue mentioned in comment:39 and some other issue for which we have a workaround in the code. I think these would be good to be addressed, but not strictly a blocker for nightly.

Is it fine to open the issues in https-everywhere Github directly, or do we usually do this in trac?

comment:42 in reply to:  40 Changed 8 weeks ago by mcs

Replying to acat:

This is a bit unfortunate, nice catch. I think this must be an https-everywhere issue, but I'd have to investigate a bit to be sure. I will open a ticket about it.

For now, I changed the logic to always start the http observer fallback and remove it when we are able to load some rules directly, which should handle this case.

That is a good solution.

This is the revised branch: ​https://github.com/acatarineu/tor-browser/commit/28005+5.

r=brade,r=mcs
Looks good to us!

comment:43 Changed 8 weeks ago by sysrqb

acat and I were chatting about why the tor-browser patch uses a same-origin check (this check triggers a urlbar change when the user navigates from the current "aliased" site to a different .onion). However, we began thinking about how a same-origin check should be applied on .tor.onion domains. The same-origin check works because it uses the underlying .onion address for the current site and new site. Every .onion address is a separate origin, so the same-origin policy applies correctly. For the current patch, we should not need a same-origin policy for the .tor.onion aliases because they are only cosmetic. However, I expect in the future .tor.onion could be handled differently where a same-origin check should be evaluated correctly (as an example, maybe we populate the alt-svc cache mapping at startup instead of relying on https-everywhere rewriting).

In any case, the current patch correctly adds .tor.onion as a new eTLD, however maybe it should go further and add securedrop.tor.onion as an eTLD because all sub-domains of securedrop.tor.onion are distinct origins. To make this explicit, currently www.abc.net.au.securedrop.tor.onion has (potentially) the same "origin" as www.2600.com.securedrop.tor.onion because they share the same eTLD (.tor.onion).

Adding all new *.tor.onion scopes as new eTLDs doesn't scale very well (and it is a completely manual process and integrated in the browser at compile-time), so we should think about how we can improve this process, too. This also means that including arbitrary rulesets in the future could be a security risk (if/when .tor.onion is not simply a cosmetic UI layer). Currently, it is not a security risk.

comment:44 Changed 8 weeks ago by sysrqb

browser/actors/ClickHandlerChild.jsm

Can you initialize json.allowOnionUrlbarRewrites:

json.allowOnionUrlbarRewrites = false;

so it follows the same pattern?

browser/base/content/browser.js

      if (gBrowser.selectedBrowser.allowOnionUrlbarRewrites) {
        gBrowser.selectedBrowser.currentOnionAliasURI = OnionAliasStore.getShortURI(
          gBrowser.selectedBrowser.currentURI
        );

Is aLocationURI equal to gBrowser.selectedBrowser.currentURI at this point?

docshell/base/nsDocShell.cpp

Should we have a pref that prevents mAllowOnionUrlbarRewrites being true?

    if (NS_SUCCEEDED(oldURI->GetHost(oldHost)) &&
        StringEndsWith(oldHost, NS_LITERAL_CSTRING(".tor.onion")) &&
        NS_SUCCEEDED(newURI->GetHost(newHost)) &&
        StringEndsWith(newHost, NS_LITERAL_CSTRING(".onion")) &&
        !StringEndsWith(newHost, NS_LITERAL_CSTRING(".tor.onion"))) {

Is the "newHost ends with .onion" helpful here?

(I'll finish reviewing this tomorrow, but so far it looks really good! Thanks!)

comment:45 Changed 8 weeks ago by pili

Keywords: TorBrowserTeam202004R added; TorBrowserTeam202003R removed

We are no longer in March

comment:46 Changed 8 weeks ago by sysrqb

Status: needs_reviewneeds_revision

(Continuing)

Duplicating allowOnionUrlbarRewrites in both the DocShell and SHEntry is concerning, but I don't see an alternative right now.

browser/components/onionservices/OnionAliasStore.jsm

+    // If the timestamp is 0, that means the update channel was not yet updated, so
+    // we schedule a check soon.

I believe this applies for both ts === 0 and null, correct? Can you mention null in the comment, as well?

+    // Setup .tor.onion rule loading.
+    this._loadHttpObserver();
+    try {
+      await this.httpsEverywhereControl.getTorOnionRules();
+      this._canLoadRules = true;

Ah. Can you add a comment that the httpObserve is removed in _loadRules()? That wasn't immediately obvious.

comment:47 in reply to:  46 Changed 8 weeks ago by acat

Thanks for the review, addressed the comments in https://github.com/acatarineu/tor-browser/commit/28005+6.

Replying to sysrqb:

Is aLocationURI equal to gBrowser.selectedBrowser.currentURI at this point?

I'm not completely sure, but even if it is, that might change in the future so I think using aLocationURI is more reasonable. I fixed that.

Should we have a pref that prevents mAllowOnionUrlbarRewrites being true?

I think it's reasonable. I added the check in the getter, in docShell.cpp.

Is the "newHost ends with .onion" helpful here?

Currently we check for "is it a redirect from .tor.onion to .onion (and not .tor.onion)"

Do you mean we could just check for "redirect from .tor.onion to anything", or "redirect from .tor.onion to .onion (including .tor.onion)"?

I believe this applies for both ts === 0 and null, correct? Can you mention null in the comment, as well?

I changed the code to check explicitly for 0. I think the only case where it could return null is if the SecureDropTorOnion update channel has been removed, and in that case we don't want to reschedule another check soon.

comment:48 Changed 8 weeks ago by acat

Tomorrow I'll do an Android build to make sure this patch does not break there, and the .tor.onion redirects work without any other UI changes, as we expect.

comment:49 Changed 8 weeks ago by acat

Actual Points: 18.318.7
Status: needs_revisionneeds_review

comment:50 Changed 8 weeks ago by acat

Actual Points: 18.718.5

comment:51 Changed 8 weeks ago by acat

Sorry, the timestamp check was wrong, fixed in https://github.com/acatarineu/tor-browser/commit/28005+7.

comment:52 Changed 8 weeks ago by acat

In any case, the current patch correctly adds .tor.onion as a new eTLD, however maybe it should go further and add securedrop.tor.onion as an eTLD because all sub-domains of securedrop.tor.onion are distinct origins. To make this explicit, currently www.abc.net.au.securedrop.tor.onion has (potentially) the same "origin" as www.2600.com.securedrop.tor.onion because they share the same eTLD (.tor.onion).

I forgot addressing this. However, note the eTLD+1 is highlighted in the urlbar, so adding securedrop.tor.onion does make a UX change in the urlbar. For example, with that change for www.nytimes.com.securedrop.tor.onion we will highlight com.securedrop.tor.onion (instead of securedrop.tor.onion with the current patch). But perhaps it's still the right thing to do, and this issue is just a consequence of how the SecureDrop rules were defined.

In any case, this patch adds the securedrop.tor.onion eTLD: https://github.com/acatarineu/tor-browser/commit/28005+8

comment:53 Changed 8 weeks ago by sysrqb

Resolution: fixed
Status: needs_reviewclosed

Awesome, let's see how this looks in nightlies. Thanks for all of you hard work on this!

Cherry-picked as commit 7306a08365be9212f621b396513352d19549c487.

(Remember #33694 later)

comment:54 in reply to:  39 Changed 8 weeks ago by sysrqb

Replying to mcs:

Replying to 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.

The torbutton patch looks good.

Almost missed this. torbutton patch merge with commit b2d4c6348cb7cc604ef705b04837baf5db59041f.

comment:55 Changed 8 weeks ago by acat

Note: on Android the patch does not have any effect, the SecureDrop update channel is not installed, since that is triggered from OnionAliasStore.init() in BrowserGlue.jsm, and that is desktop only. Making OnionAliasStore work in Android (to install the update channel) should be simple, but I'm not sure about the rest of UI changes, probably would take a bit longer (at least 5 points I guess).

Note: See TracTickets for help on using tickets.