Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#28005: Officially support onions in HTTPS-Everywhere
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, https-everywhere, network-   |  Actual Points:  18.5
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, ux-team, TorBrowserTeam202004R |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-

Comment (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).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#28005: Officially support onions in HTTPS-Everywhere
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, https-everywhere, network-   |  Actual Points:  18.5
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, ux-team, TorBrowserTeam202004R |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-

Comment (by sysrqb):

 Replying to [comment:39 mcs]:
 > Replying to [comment:37 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`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#28005: Officially support onions in HTTPS-Everywhere
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, https-everywhere, network-   |  Actual Points:  18.5
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, ux-team, TorBrowserTeam202004R |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-
Changes (by sysrqb):

 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 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)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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.5
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, ux-team, TorBrowserTeam202004R |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-

Comment (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

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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.5
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, ux-team, TorBrowserTeam202004R |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

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

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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.5
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, ux-team, TorBrowserTeam202004R |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * actualpoints:  18.7 => 18.5


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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.7
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, ux-team, TorBrowserTeam202004R |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * status:  needs_revision => needs_review
 * actualpoints:  18.3 => 18.7


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#28005: Officially support onions in HTTPS-Everywhere
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, https-everywhere, network-   |  Actual Points:  18.3
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, ux-team, TorBrowserTeam202004R |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-

Comment (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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#28005: Officially support onions in HTTPS-Everywhere
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, https-everywhere, network-   |  Actual Points:  18.3
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, ux-team, TorBrowserTeam202004R |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

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


 Replying to [comment:46 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#28005: Officially support onions in HTTPS-Everywhere
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, https-everywhere, network-   |  Actual Points:  18.3
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, ux-team, TorBrowserTeam202004R |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-
Changes (by sysrqb):

 * status:  needs_review => needs_revision


Comment:

 (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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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.3
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202003R, ux-team |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-

Comment (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!)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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.3
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202003R, ux-team |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-

Comment (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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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.3
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202003R, ux-team |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-

Comment (by mcs):

 Replying to [comment:40 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!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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.3
  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):

 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?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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.3
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202003R, ux-team |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * actualpoints:  18.2 => 18.3


Comment:

 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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.2
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202003R, ux-team |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-

Comment (by mcs):

 Replying to [comment:37 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.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).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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.2
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202003R, ux-team |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * actualpoints:  18 => 18.2


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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 mcs):

 Replying to [comment:34 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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):

 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/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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
-+-
Changes (by acat):

 * actualpoints:  17 => 18


Comment:

 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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:  17
  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):

 Replying to [comment:31 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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:  17
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202003R, ux-team |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-

Comment (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?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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:  17
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202003R, ux-team |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-

Comment (by antonela):

 Replying to [comment:27 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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:  17
  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):

 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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:  17
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202003R, ux-team |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * keywords:
 tor-hs, https-everywhere, network-team-roadmap-november, network-team-
 roadmap-2020Q1, TorBrowserTeam202002, ux-team
 =>
 tor-hs, https-everywhere, network-team-roadmap-november, network-team-
 roadmap-2020Q1, TorBrowserTeam202003R, ux-team
 * actualpoints:  15 => 17


Comment:

 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).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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:  15
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202002, ux-team  |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-

Comment (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).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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:  15
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202002, ux-team  |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-

Comment (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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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:  15
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202002, ux-team  |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-
Changes (by antonela):

 * Attachment "httpse-v3onions.2.png" removed.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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:  15
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202002, ux-team  |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-
Changes (by antonela):

 * Attachment "httpse-v3onions.2.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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:  15
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202002, ux-team  |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-
Changes (by antonela):

 * keywords:
 tor-hs, https-everywhere, tor-ux, network-team-roadmap-november,
 network-team-roadmap-2020Q1, TorBrowserTeam202002
 =>
 tor-hs, https-everywhere, network-team-roadmap-november, network-team-
 roadmap-2020Q1, TorBrowserTeam202002, ux-team
 * reviewer:  mcs, sysrqb => mcs, sysrqb, antonela


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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, tor-ux,|  Actual Points:  15
  network-team-roadmap-november, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202002   |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by antonela):

 * Attachment "httpse-v3onions.2.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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, tor-ux,|  Actual Points:  15
  network-team-roadmap-november, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202002   |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb  |Sponsor:
 |  Sponsor27-must
-+-

Comment (by antonela):

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

 Replying to [comment:21 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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, tor-ux,|  Actual Points:  15
  network-team-roadmap-november, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202002   |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by sysrqb):

 * reviewer:   => mcs, sysrqb


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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, tor-ux,|  Actual Points:  15
  network-team-roadmap-november, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202002   |
Parent ID:  #30029   | Points:  20
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * actualpoints:   => 15


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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, tor-ux,|  Actual Points:
  network-team-roadmap-november, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202002   |
Parent ID:  #30029   | Points:  20
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * Attachment "28005.webm" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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, tor-ux,|  Actual Points:
  network-team-roadmap-november, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202002   |
Parent ID:  #30029   | Points:  20
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * status:  new => needs_review


Comment:

 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 [https://github.com/acatarineu/tor-
 browser/commit/28005#diff-f2877e5f680c088366ab9ef15860e3e1R34 here] by
 sending messages to https-everywhere, which are handled in the extension
 [https://github.com/EFForg/https-everywhere/blob/master/chromium
 /background-scripts/background.js#L856 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.).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#28005: Officially support onions in HTTPS-Everywhere
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, https-everywhere, tor-ux,|  Actual Points:
  network-team-roadmap-november, |
  TorBrowserTeam202001, network-team-roadmap-|
  2020Q1 |
Parent ID:  #30029   | Points:  20
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by antonela):

 Replying to [comment:17 acat]:
 > Replying to [comment:16 antonela]:
 > > Replying to [comment:14 acat]:
 > > > 4. 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 [https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/30024/30024%20-%20TB9%20-%20onions.png, 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.

 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/28005/O2A5.jpg, 700px)]]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#28005: Officially support onions in HTTPS-Everywhere
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, https-everywhere, tor-ux,|  Actual Points:
  network-team-roadmap-november, |
  TorBrowserTeam202001, network-team-roadmap-|
  2020Q1 |
Parent ID:  #30029   | Points:  20
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by antonela):

 * Attachment "O2A5.jpg" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#28005: Officially support onions in HTTPS-Everywhere
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, https-everywhere, tor-ux,|  Actual Points:
  network-team-roadmap-november, |
  TorBrowserTeam202001, network-team-roadmap-|
  2020Q1 |
Parent ID:  #30029   | Points:  20
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * owner:  legind => tbb-team
 * component:  HTTPS Everywhere/EFF-HTTPS Everywhere => Applications/Tor
 Browser


Comment:

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

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs