Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-16T01:13:11Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34347The Tor Network part on the onboarding is not new anymore2020-06-16T01:13:11ZGeorg KoppenThe Tor Network part on the onboarding is not new anymoreFor 9.0 we added a "New" item to the Tor Network part explaining our changes on `about:preferences`. But that's not new anymore. :) We should have removed that for 9.5 but it's not too late.For 9.0 we added a "New" item to the Tor Network part explaining our changes on `about:preferences`. But that's not new anymore. :) We should have removed that for 9.5 but it's not too late.https://gitlab.torproject.org/legacy/trac/-/issues/33672Force include https-everywhere in incremental mar update2020-06-16T01:11:57ZMatthew FinkelForce include https-everywhere in incremental mar updateWe should include an older version of https-everywhere in the upcoming release. This won't be a problem for new installations. However, any recently run instance of Tor Browser mostlikely automatically upgraded to the newest https-e vers...We should include an older version of https-everywhere in the upcoming release. This won't be a problem for new installations. However, any recently run instance of Tor Browser mostlikely automatically upgraded to the newest https-e version (2020.3.16), so we should include the older version (2019.11.7) in our incremental mar files.
2019.11.7 is the version we included in the last Tor Browser version, so it won't be included in the incrementals. It seems like we can force inclusion in `make_incremental_update.sh`.
I see two options:
1. (tor-browser) Patch `tools/update-packaging/make_incremental_update.sh` so it always include https-everywhere (and then we revert/drop that patch at the next rebase)
1. (tor-browser-build) Patch `tools/update-responses/gen_incrementals` so it passes `-f $ext_path/$https_everywhere_dir/* $packed_https_e_path` (with appropriate paths) when it calls `make_incremental_update.sh`?
If there are alternatives, we can consider those, too.https://gitlab.torproject.org/legacy/trac/-/issues/33403Add nightly mar key to tor-browser2020-06-16T01:11:19ZboklmAdd nightly mar key to tor-browserIn #31988 I created a mar signing key for nightly builds. We should add it to tor-browser nightly builds.
It seems the path used by nightly build is `toolkit/mozapps/update/updater/nightly_aurora_level3_primary.der` (and `nightly_aurora...In #31988 I created a mar signing key for nightly builds. We should add it to tor-browser nightly builds.
It seems the path used by nightly build is `toolkit/mozapps/update/updater/nightly_aurora_level3_primary.der` (and `nightly_aurora_level3_secondary.der`).boklmboklmhttps://gitlab.torproject.org/legacy/trac/-/issues/33402Set app.update.url for nightly builds2020-06-16T01:11:19ZboklmSet app.update.url for nightly buildsWe won't use the same `app.update.url` for releases and nightly builds. So we need to change this pref in the nightly builds.
https://nightlies.tbb.torproject.org/nightly-updates/updates/ is where the updates xml for nightly builds are ...We won't use the same `app.update.url` for releases and nightly builds. So we need to change this pref in the nightly builds.
https://nightlies.tbb.torproject.org/nightly-updates/updates/ is where the updates xml for nightly builds are located.boklmboklmhttps://gitlab.torproject.org/legacy/trac/-/issues/33342Disconnect search addon causes error at startup2020-06-16T01:11:14ZMatthew FinkelDisconnect search addon causes error at startupFollowing #32767, it seems Firefox is throwing an exception. I don't think it's too important.
```
1581718500372 addons.xpi-utils WARN addMetadata: Add-on disconnect@search.mozilla.org is invalid: Error: File re[/search-extensio...Following #32767, it seems Firefox is throwing an exception. I don't think it's too important.
```
1581718500372 addons.xpi-utils WARN addMetadata: Add-on disconnect@search.mozilla.org is invalid: Error: File re[/search-extensions/disconnect/](/search-extensions/disconnect/) does not contain a valid manifest(re[/gre/modules/addons/XPIInstall.jsm:671:11)](/gre/modules/addons/XPIInstall.jsm:671:11)) JS Stack trace: loadManifest@XPIInstall.jsm:671:11
awaitPromise@XPIProvider.jsm:228:15
syncLoadManifest@XPIInstall.jsm:750:24
addMetadata@XPIDatabase.jsm:2721:32
processFileChanges@XPIDatabase.jsm:3162:26
getNewSideloads@XPIProvider.jsm:3005:28
1581718500362 addons.xpi-utils WARN Not uninstalling invalid item because it is a proxy file
```
We may not need to do anything about this, but if there is a way we can prevent this error then that'll be even better (reducing noise in logging is helpful).
acat, what do you think? I haven't looked at the code in the stacktrace at all.https://gitlab.torproject.org/legacy/trac/-/issues/32645Update URL bar onion indicators2020-12-11T13:05:04ZAntonelaantonela@torproject.orgUpdate URL bar onion indicatorsSince FF70, the green locks at the URL bar are gone. The current Firefox approach to security indicators is detailed here[1]. Chrome is leading towards this intention, too[2].
As part of S27, I'm working on unifying (and simplifying) t...Since FF70, the green locks at the URL bar are gone. The current Firefox approach to security indicators is detailed here[1]. Chrome is leading towards this intention, too[2].
As part of S27, I'm working on unifying (and simplifying) the brand presence of onions in Tor Browser, either for referring to the network or to the onion services.
I'm opening this ticket to discuss the following:
- are we ok following the Firefox approach and removing green icons from the URL bar?
- are we ok unifying the visual anchor for onions and onion routing at the URL bar and also at the circuit display?
- are we ok removing EV label from the URL bar and leave it at the identity doorhanger?
[1]FF70 https://blog.mozilla.org/security/2019/10/15/improved-security-and-privacy-indicators-in-firefox-70/
[2]CH69 https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html
[*]TB8 https://trac.torproject.org/projects/tor/wiki/org/teams/UxTeam/Misc/OnionSecurityIndicatorrichardrichardhttps://gitlab.torproject.org/legacy/trac/-/issues/32470Backport fix for bug 15905382020-06-16T01:09:37ZGeorg KoppenBackport fix for bug 1590538Mozilla landed a fix for our #31764. We should backport their fix and remove our workaroundMozilla landed a fix for our #31764. We should backport their fix and remove our workaroundhttps://gitlab.torproject.org/legacy/trac/-/issues/31988Generate a mar signing key for nightly builds2020-06-16T01:11:20ZboklmGenerate a mar signing key for nightly buildsWe should generate a signing key for the nightly build.
Also see ticket:18867#comment:15.We should generate a signing key for the nightly build.
Also see ticket:18867#comment:15.boklmboklmhttps://gitlab.torproject.org/legacy/trac/-/issues/31395Remove inline <script> in aboutTor.xhtml2020-06-16T01:06:28ZAlex CatarineuRemove inline <script> in aboutTor.xhtmlWe should move the inline script in aboutTor.xhtml to some .js file so that we can remove the 'unsafe-inline' from about:tor CSP. See #31322.We should move the inline script in aboutTor.xhtml to some .js file so that we can remove the 'unsafe-inline' from about:tor CSP. See #31322.https://gitlab.torproject.org/legacy/trac/-/issues/28005Officially support onions in HTTPS-Everywhere2022-09-01T22:43:24ZGeorge KadianakisOfficially support onions in HTTPS-EverywhereThe 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 hard...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-onionshttps://gitlab.torproject.org/legacy/trac/-/issues/25013Move TorButton code to the tor browser repository2020-06-16T00:58:41ZIgor OliveiraMove TorButton code to the tor browser repositoryAs discussed in the[1], this is the first step to make the tor button to work on mobile.
[1] https://lists.torproject.org/pipermail/tbb-dev/2018-January/000740.htmlAs discussed in the[1], this is the first step to make the tor button to work on mobile.
[1] https://lists.torproject.org/pipermail/tbb-dev/2018-January/000740.htmlhttps://gitlab.torproject.org/legacy/trac/-/issues/21952Onion-location: increasing the use of onion services through automatic redire...2021-03-22T16:56:26ZLinda LeeOnion-location: increasing the use of onion services through automatic redirects and aliasing= Background =
People can't remember, or type in onion sites very easily. We should try to fix this somehow.
ilf is experimenting with automatically redirecting Tor users to .onion versions of websites that they visit (because they ...= Background =
People can't remember, or type in onion sites very easily. We should try to fix this somehow.
ilf is experimenting with automatically redirecting Tor users to .onion versions of websites that they visit (because they want more people to visit onion sites and they will do so if it is painless to them). But when users were redirected automatically to an onion site, they freaked out about it because they didn't know what happened, didn't know what onion sites were, and the "https" was dropped.
asn and dgoulet also were trying to find a solution to make onion sites more accessible to use. Specifically, onion addresses are quite long and random-ish, making them hard to remember and hard to type. There were many solutions discussed casually to try and resolve this, but none stood out as a clear winner.
= Discussion =
I like the idea of redirecting users to .onion sites automatically when they type in the websites non-onion address. This way, users don't need to remember anything else, need to type in anything long, or really even know what onion sites are.
My suggestion is to follow the https design pattern, and create a similar indicator for .onion sites.
![onion-address-idea.png,600px](uploads/onion-address-idea.png,600px)
The proposed solution would be this: when a user types in a website (pad.riseup.net), they would automatically be redirected to the onion site. When this happens, there would be an onion icon next to the address bar (replacing the https lock icon if there is one, or just being there an https lock icon would be if redirection from an http website), similar to that of the https lock icon. The address in the address bar can turned a different color or indicated in some way that this is an alias for the onion site.
From my observation, people don't mind automatically being redirected to https sites from http sites, but freak out when redirected from an http/https site to an onion site. I don't think that this is because people know what https is and find the idea comforting (although this can help). I speculate that they don't mind because they don't notice, and the reason why users freaked out at the redirect to onion sites is that they saw the website address visibly change in the address bar.
Also--
If we want to show users the address of the onion site, we can additionally have a feature to reveal the onion site when the user clicks in the address bar.
![onion-address-secondary-idea.png,600px](uploads/onion-address-secondary-idea.png,600px)
I don't know how I feel about this, since it may just be confusing, and just shock the user later. Users don't know that pad.riseup.net resolves to some numerical IP address, and that isn't displayed to users. So there could be an argument made for just indicating that the address is an alisas and not ever showing the .onion address, either. This will confuse way less of the general population.
= Considerations =
* how should the redirect behavior work?
* how can we implement this without tracking?
* should we allow users to turn off this redirecting behavior?
* should we hide the .onion address from the users more so than the proposal above?Alex CatarineuAlex Catarineu