The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-02-27T19:07:30Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42279Investigate UX impact of removing window titles2024-02-27T19:07:30ZJag TalonInvestigate UX impact of removing window titlesInvestigate UX issue of removing window titles in Tor for GNOME and KDE and possibly Windows.
Background: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41988
## Design estimate:
* Complexity: medium (3 days)
*...Investigate UX issue of removing window titles in Tor for GNOME and KDE and possibly Windows.
Background: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41988
## Design estimate:
* Complexity: medium (3 days)
* Create an option in `about:preferences#privacy` that toggles the titles from being shown on the window.
* Decide if the option should be enabled by default. [Preliminary findings show that it will have minimal impact to usability](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41988#note_2971226), but perhaps more research and discussion is warranted.
* Create copy for help pages.
* Uncertainty level: moderate (1.5)
* This is a small, but far reaching change especially when releasing to multiple platforms. I imagine there's some uncertainty in this task.
* Total: 3-4.5 dayshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42278The browser is playing media notification has Firefox branding2024-01-09T13:50:46ZPier Angelo VendrameThe browser is playing media notification has Firefox brandingSpotted on my Ubuntu Mate VM, Tor Browser alpha 13.5a1:
![Screenshot_from_2023-11-15_08-44-31](/uploads/9af3c15cb22e9ac71d2bb2c7c6546f01/Screenshot_from_2023-11-15_08-44-31.png)
I haven't checked other OS, they might have the same prob...Spotted on my Ubuntu Mate VM, Tor Browser alpha 13.5a1:
![Screenshot_from_2023-11-15_08-44-31](/uploads/9af3c15cb22e9ac71d2bb2c7c6546f01/Screenshot_from_2023-11-15_08-44-31.png)
I haven't checked other OS, they might have the same problem.https://gitlab.torproject.org/tpo/web/support/-/issues/355Please add a FAQ to explain users that disabling RFP is very bad2023-11-23T15:32:50ZPier Angelo VendramePlease add a FAQ to explain users that disabling RFP is very badStarting with Tor Browser 13.0, we decided to lock `privacy.resistFingerprinting`.
RFP is a very important setting.
Disabling RFP makes you easily fingerprintable in a lot of ways, including hardware!
Generally speaking, Mozilla is well...Starting with Tor Browser 13.0, we decided to lock `privacy.resistFingerprinting`.
RFP is a very important setting.
Disabling RFP makes you easily fingerprintable in a lot of ways, including hardware!
Generally speaking, Mozilla is well aware of these fingerprinting vectors and continuously add even more.
At the moment, the protection isn't granular, it's all or nothing (and I'm not saying it's bad - quite the opposite - it's the same philosophy of Tor Browser: normalize everything).
Also, when we send patches to Mozilla, we often gate them behind RFP.
Setting RFP to false is like telling that you don't want a bunch of our patches.
RFP has usability issues (e.g., it constantly resets the zoom level, which can be a big accessibility problem).
We're aware of that and it's in our roadmap.
We've received some feedback against our decision after the release, and we still get from time to time.
I think we could have a FAQ about this.ebanamebanam@torproject.orgebanamebanam@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42262Mask icon not centered and should either be removed or centered2024-01-09T13:51:01ZclairehurstMask icon not centered and should either be removed or centered<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
On the tabs screen, there is a mask icon at the top signalling private tabs. All tabs are private so I would be fine to...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
On the tabs screen, there is a mask icon at the top signalling private tabs. All tabs are private so I would be fine to remove it entirely. If we don't want to remove it, it should be centered to look better.
### Steps to reproduce:
**How one can reproduce the issue - this is very important.**
1. Connect to Tor
2. Tap on the tabs icon in the bottom right, it looks like a square with a "0" inside it (or how ever many tabs you have open)![Screenshot_2023-11-13_at_18.19.25](/uploads/fac0b19b976ba4da275b59556632e43b/Screenshot_2023-11-13_at_18.19.25.png)
3. Notice the mask icon not being centered (screenshot shown below)
### What is the current bug behavior?
**What actually happens.**
Mask icon is off center, off to the left
### What is the expected behavior?
**What you want to see instead**
Mask icon either being centered, or removed
### Relevant logs and/or screenshots
![Your_private_tabs_will_be_shown_here.](/uploads/286ccc6b280d3e42eecb8881a89cedd4/Your_private_tabs_will_be_shown_here..png){width=25%}clairehurstclairehursthttps://gitlab.torproject.org/tpo/web/community/-/issues/329webtunnel-from-source instructions close your ORPort without explaining that ...2023-11-15T09:46:36ZRoger Dingledinewebtunnel-from-source instructions close your ORPort without explaining that your bridge will seem downOn https://community.torproject.org/relay/setup/webtunnel/source/ we tell the bridge operator to set ORPort to 127.0.0.1 and set AssumeReachable. This is so their ORPort isn't reachable from the outside world. But at present it will resu...On https://community.torproject.org/relay/setup/webtunnel/source/ we tell the bridge operator to set ORPort to 127.0.0.1 and set AssumeReachable. This is so their ORPort isn't reachable from the outside world. But at present it will result in two surprises for bridge operators:
* They will get "The IPv4 ORPort address 127.0.0.1 does not match the descriptor address <redacted: IP of the relay server>" scary log messages, which make them think something is wrong with their configuration
* In tor metrics, the bridge is shown in "Red" status being "down" since a couple of hours. That's because they don't have the Running flag from the bridge authority.
We should either (A) change the instructions to explain that we're having them do the experimental new closed-ORPort approach, and tell them what side effects to expect; or (B) change the instructions to have an open ORPort for now until we've finished https://gitlab.torproject.org/tpo/core/tor/-/issues/7349
Issue reported by a new webtunnel bridge operator on #tor-relays. Thanks!https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40191Debian package: solve systemd unit permissions when enabling apparmor2024-02-05T08:25:05ZjugaDebian package: solve systemd unit permissions when enabling apparmorsbws: 1.9.x-finaljugajugahttps://gitlab.torproject.org/tpo/community/policies/-/issues/13Delete the master branch2024-01-24T21:10:23ZSilvio RhattoDelete the master branchThis branch was [phased out](tpo/community/policies#12). Next step is to remove it from GitLab after a while, giving time to people update their refs.This branch was [phased out](tpo/community/policies#12). Next step is to remove it from GitLab after a while, giving time to people update their refs.https://gitlab.torproject.org/tpo/community/l10n-for-markdown/-/issues/1Document how to integrate with the translation repository2024-01-24T21:11:33ZSilvio RhattoDocument how to integrate with the translation repositoryDocument how this project can be used in an integrated workflow with the [translations repository](https://gitlab.torproject.org/tpo/translation), in accordance with the [Localization for developers](https://gitlab.torproject.org/tpo/com...Document how this project can be used in an integrated workflow with the [translations repository](https://gitlab.torproject.org/tpo/translation), in accordance with the [Localization for developers](https://gitlab.torproject.org/tpo/community/l10n/-/wikis/Localization-for-developers) document.https://gitlab.torproject.org/tpo/community/hackweek/-/issues/33Add license2023-11-15T15:08:32ZSilvio RhattoAdd licenseThis project needs a copyright/copyleft license.
This is not a regular Hackweek proposal. Instead, it's is an actual task to improve it's documentation.This project needs a copyright/copyleft license.
This is not a regular Hackweek proposal. Instead, it's is an actual task to improve it's documentation.https://gitlab.torproject.org/tpo/community/hackweek/-/issues/32Improve formatting for past Hackweek documentations2024-02-13T20:06:20ZSilvio RhattoImprove formatting for past Hackweek documentationsWhile working on tpo/community/hackweek#13, Hackweek got a website: https://tpo.pages.torproject.net/community/hackweek/
Now it's way easier to browse and search for past projects, but this also exposes the need to fix formatting at som...While working on tpo/community/hackweek#13, Hackweek got a website: https://tpo.pages.torproject.net/community/hackweek/
Now it's way easier to browse and search for past projects, but this also exposes the need to fix formatting at some pages.
This ticket is about fixing the formatting for the existing docs.
This is not a regular Hackweek proposal. Instead, it's is an actual task to improve it's documentation.https://gitlab.torproject.org/tpo/community/training/-/issues/124Index of presentations in the home slide deck2024-01-24T21:10:16ZSilvio RhattoIndex of presentations in the home slide deckBuild an index of presentations in the [home slides]:
* Listing the ones from the current year, and the outdated ones.
* Linking to all available assets for a given slide (ODP, PDF, HTML etc).
* To be built as part of the CI Pipeline.
...Build an index of presentations in the [home slides]:
* Listing the ones from the current year, and the outdated ones.
* Linking to all available assets for a given slide (ODP, PDF, HTML etc).
* To be built as part of the CI Pipeline.
[home slides]: https://tpo.pages.torproject.net/community/training/https://gitlab.torproject.org/tpo/tpa/status-site/-/issues/37merge "experiment" support upstream2023-11-16T10:37:19Zanarcatmerge "experiment" support upstreamit would be nice if some of our most important divergences were merged upstream.
right now, we have this:
```
anarcat@angela:status.torproject.org$ find layouts/ -type f
layouts/README.md
layouts/partials/custom/meta.html
layouts/part...it would be nice if some of our most important divergences were merged upstream.
right now, we have this:
```
anarcat@angela:status.torproject.org$ find layouts/ -type f
layouts/README.md
layouts/partials/custom/meta.html
layouts/partials/index/noscript.html
layouts/partials/index/components.html
layouts/experiments/small.html
layouts/experiments/single.html
layouts/experiments/single.json
layouts/experiments/experiment.html
```
out of those:
* `layout/experiments/*` doesn't actually override anything upstream: it's all new, so that's relatively safe
* `meta.html` is an expected override (upstream is just a commented out example)
* `noscript.html` is an expected override: we silence the upstream warning about noscript... we *could* upstream this as a toggle, but it seems overkill
* `layouts/partials/index/components.html`, on the other hand, is quite a diff
In !46, I actually tried to merge that file with the latest upstream, to fix broken links in review apps (#36)... the merge wasn't quite trivial, but more importantly, it wasn't obvious we even *had* to merge something in there.
It would be nice to consider upstreaming our changes here. We could find a way to patch the upstream repo to add support for experiments. I think that would involve sending a PR upstream, alongside some docs fixes to document the feature.
What do you think, @gk? Is that something you think could be done?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42255lock pdfjs.disabled to false in stable2024-01-09T14:37:09ZThorinlock pdfjs.disabled to false in stablein FF116 [1838415](https://bugzilla.mozilla.org/show_bug.cgi?id=1838415) in [Don't spoof explicitly disabled pdfJS](https://phabricator.services.mozilla.com/D180938) RFP no longer ignores the pref `pdfjs.disabled`. The original RFP prote...in FF116 [1838415](https://bugzilla.mozilla.org/show_bug.cgi?id=1838415) in [Don't spoof explicitly disabled pdfJS](https://phabricator.services.mozilla.com/D180938) RFP no longer ignores the pref `pdfjs.disabled`. The original RFP protection was done to help against disk leaks and to provide a uniform fingerprint [1]
Given these two aspects, we should just lock the pref in stable release
[1] There are only two possible values for combined plugins, mimeTypes and pdfViewerEnabledhttps://gitlab.torproject.org/tpo/community/training/-/issues/123Switch from "master" to "main" branch2024-03-05T16:32:50ZSilvio RhattoSwitch from "master" to "main" branch# Tasks
* [ ] Switch the repository from "master" to the "main" branch.
* [ ] Update references on the [Training resources page at the Community Portal][] pointing to the correct branch, like in [this file][].
[Training resources page ...# Tasks
* [ ] Switch the repository from "master" to the "main" branch.
* [ ] Update references on the [Training resources page at the Community Portal][] pointing to the correct branch, like in [this file][].
[Training resources page at the Community Portal]: https://community.torproject.org/training/resources/
[this file]: https://gitlab.torproject.org/tpo/web/community/-/blob/main/databags/community-training-materials.jsonhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41387create an alert if a machine's network interface goes down2023-11-08T15:17:51ZKezcreate an alert if a machine's network interface goes downwe should crate some kind of big, scary, hard to miss alert when one of our machines has a network interface go down. a network interface going down could be a sign of an attack, hardware/software failure, misconfiguration, or other bad ...we should crate some kind of big, scary, hard to miss alert when one of our machines has a network interface go down. a network interface going down could be a sign of an attack, hardware/software failure, misconfiguration, or other bad things. this alert shouldn't disappear when the interface comes back up, and ideally TPA should be able to temporarily disable the alert for planned maintenance.https://gitlab.torproject.org/tpo/web/snowflake/-/issues/9unify volunteer instructions from support entry onto snowflake website2024-02-27T14:24:07ZRoger Dingledineunify volunteer instructions from support entry onto snowflake websiteWe have this support entry: <br>
https://support.torproject.org/censorship/how-to-help-running-snowflake/
which tells people to install the Firefox or Chrome extension, or load the embed in a page. It doesn't mention the Edge extension ...We have this support entry: <br>
https://support.torproject.org/censorship/how-to-help-running-snowflake/
which tells people to install the Firefox or Chrome extension, or load the embed in a page. It doesn't mention the Edge extension or the standalone proxy.
Rather than trying to keep both sets of instructions in sync, I think we should put the instructions on the snowflake.torproject.org page, and point to them from a much slimmer support entry.
To achieve this goal, there are currently two things that the support entry says that the snowflake.torproject.org website does not:
* You need to enable WebRTC in your browser, to usefully run the extension or to usefully load the embed. (If we could reliably have the extension or the embed page report that your WebRTC is missing and you need to fix that, then we could get away with not saying it on the webpage. So, feel free to do that instead if it is easier, but I am suspecting it is not easier. :)
* "Due to censorship of VPN servers in some countries, we kindly ask you to not run a snowflake proxy while connected to a VPN" as advised by @cohosh at https://forum.torproject.org/t/running-a-snowflake-proxy-behind-a-vpn-consequences-for-tor-users/2047/4 and then recorded by gus at https://gitlab.torproject.org/tpo/web/support/-/issues/296. Feel free also to change your mind about the "not on a VPN please" advice.
Once we have these two items either make their way onto the snowflake.torproject.org proxy instructions or have you tell us you don't intend to, then we should be all ready to remove the (redundant, already not as correct) text from the support entry.
Thanks!https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41011Remove tor-onion-proxy-library project2023-11-06T23:31:41ZrichardRemove tor-onion-proxy-library projectThis will be deprecated with the remaining ~"Sponsor 96" work.This will be deprecated with the remaining ~"Sponsor 96" work.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41010Create a project to ship tor binaries in an Android-developer friendly way2024-02-05T18:15:26ZrichardCreate a project to ship tor binaries in an Android-developer friendly way`tor-onion-proxy-library` is going away, we need to setup the torrc and populate tor+PTs using the `tor-expert-bundle` project`tor-onion-proxy-library` is going away, we need to setup the torrc and populate tor+PTs using the `tor-expert-bundle` projectSponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/core/arti/-/issues/1098Rethink publisher retry loop2024-01-09T17:28:02Zgabi-250Rethink publisher retry loopThe publisher currently retries any failed uploads using its `PublisherBackoffSchedule`. The retry mechanism involves retrying the failed upload until it succeeds, or until the the timeout specified in `PublisherBackoffSchedule::timeout(...The publisher currently retries any failed uploads using its `PublisherBackoffSchedule`. The retry mechanism involves retrying the failed upload until it succeeds, or until the the timeout specified in `PublisherBackoffSchedule::timeout()` elapses.
However, if the descriptor can't be uploaded after `PublisherBackoffSchedule::timeout()` time units of trying, it will be declared a failure (UploadStatus::Failure), and never retried again. We should consider improving the situation: the publisher shouldn't idle if there are some known, retriable failed uploads. We should have some sort of (almost) infinite retry loop, somewhat like the one sketched out in !1823 (but we shouldn't have two retry loops).
The upload result reporting makes this a bit complicated. The "dirtiness" of each HsDir needs to be updated after the upload, and we can't acquire the lock to do that in the function where the upload happens. This ticket will involve rethinking how we report and update the HsDir statuses.Arti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42243backport 1664278 Expose an "always underline links" checkbox in settings2023-11-07T00:16:08ZThorinbackport 1664278 Expose an "always underline links" checkbox in settings[1664278](https://bugzilla.mozilla.org/show_bug.cgi?id=1664278) - _seems_ like a simple patch, otherwise we wait a year til ESR128 - maybe someone could ask emilio if they could backport it to ESR115
![tada](/uploads/4da1397bafcf493159b...[1664278](https://bugzilla.mozilla.org/show_bug.cgi?id=1664278) - _seems_ like a simple patch, otherwise we wait a year til ESR128 - maybe someone could ask emilio if they could backport it to ESR115
![tada](/uploads/4da1397bafcf493159ba5b54680b3d63/tada.png)richardrichard