The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-01-24T21:10:16Zhttps://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/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)richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42236Let users decide whether to load their home page on new identity.2024-03-26T20:24:43Zmicahmicah@torproject.orgLet users decide whether to load their home page on new identity.In https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41765 the custom home page was disabled due to a very low-security issue. However, this has created a number of complaints from users.
Thus this issue to implement a...In https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41765 the custom home page was disabled due to a very low-security issue. However, this has created a number of complaints from users.
Thus this issue to implement a way to deal with both cases.
Options on the table are adding a setting/pref to restore old behavior, display a chrome banner with a string explaining why its not loaded, with a button to load it anyways; finally a combination of the two: add a setting/pref to restore the old behavior and display a chrome banner with a short explanation about why it is not loaded, as well as instructions for how to turn that behavior back onma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42233Check network.preconnect2023-11-07T20:22:39ZPier Angelo VendrameCheck network.preconnect@thorin says we could benefit from setting `network.preconnect`: https://github.com/arkenfox/user.js/issues/1756.@thorin says we could benefit from setting `network.preconnect`: https://github.com/arkenfox/user.js/issues/1756.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42230"Address bar" settings in Tor Browser for Android has many options we don't use2023-11-06T23:47:31Zclairehurst"Address bar" settings in Tor Browser for Android has many options we don't use<!--
* Use this issue template for reporting a new bug.
-->
### Summary
"Search Browsing History", "Search synced Tabs", "Show in private sessions" are irrelevant to us and should be removed.
Not sure about "Show clipboard suggestions"...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
"Search Browsing History", "Search synced Tabs", "Show in private sessions" are irrelevant to us and should be removed.
Not sure about "Show clipboard suggestions", "Show voice search", "Show search suggestions"
### Steps to reproduce:
**How one can reproduce the issue - this is very important.**
1. Launch Tor
2. Tap on the search engine icon (e.g. DuckDuckGo) to the left of the search bar
2. (Also notice that there is a search history option, that is irrelevant to us too)
3. Tap on Search settings (bottom of the list)
4. Notice all the mentioned items above
### Relevant logs and/or screenshots
![Screenshot_2023-11-01_at_16.19.25](/uploads/348f872fa2910e225f899fc2ba7d4a64/Screenshot_2023-11-01_at_16.19.25.png){width=50%}clairehurstclairehursthttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41002Enable GeckoDriver on all desktop platforms2023-11-01T19:36:16ZrichardEnable GeckoDriver on all desktop platformsWe will need this for future tests on desktopWe will need this for future tests on desktophttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40190Low consensus weight and measurements for relays with high capacity2024-03-25T14:41:22ZjugaLow consensus weight and measurements for relays with high capacityIn concrete: F7755E9EB5C17ABB4887CA7750AAADB6BA665E49
Facts and things the operator checked:
- hardware and kernel
- other services work fine
- unlimited hardware/network
Tor related:
- family: big family, afaik it shouldn't affect (...In concrete: F7755E9EB5C17ABB4887CA7750AAADB6BA665E49
Facts and things the operator checked:
- hardware and kernel
- other services work fine
- unlimited hardware/network
Tor related:
- family: big family, afaik it shouldn't affect (though paths will be built with only 1 of the relays in the family)
- not overloaded
Things to check:
- 0. [X] BandwidthRate/Burst are at 1GB
- 1. [X] consensus weight seems correct with respect its `bw_mean` and observed bandwdith:
weight: 35MB
raw measurements: 25MB
observed: 15MB
- 2. [X] policies:
- is it failing to get measured as entry? no (by logs)
- as exit? no (by logs)
- 3. [X] use the relay as entry en tor client circuit [0]
- 4. [X] use https://gitlab.torproject.org/juga/relay_bw
- 5. [ ] some other torrc configuration?
- 6. [ ] test cpu with chutney
Hypothesis:
- [X] exit policy that restrict being measured as an exit (port 443) or entry . This is not the case
[0] https://support.torproject.org/it/relay-operators/why-is-my-relay-slow/jugajugahttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42220Flip all the possible preferences to prevent any automatic download2023-11-01T18:10:30ZPier Angelo VendrameFlip all the possible preferences to prevent any automatic downloadWe should make sure that no automatic downloads happens.
In normal Firefox for example the webp images from our blog are downloaded automatically when you open them in new tabs.
Also, I think we could force our browsers to ignore [`Con...We should make sure that no automatic downloads happens.
In normal Firefox for example the webp images from our blog are downloaded automatically when you open them in new tabs.
Also, I think we could force our browsers to ignore [`Content-disposition: attachment`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition) (maybe we already do it, I haven't checked).https://gitlab.torproject.org/tpo/core/arti/-/issues/1091Make sure that guard selection algorithm handles restriction-based behavior c...2023-11-15T19:00:05ZNick MathewsonMake sure that guard selection algorithm handles restriction-based behavior correctlyWe want to avoid a recurrence of tor#40876 here; to do so, we need to make sure that our guard selection algorithm obeys restrictions in the particular way described in torspec!182, possibly as amended by torspec!184. (We should wait un...We want to avoid a recurrence of tor#40876 here; to do so, we need to make sure that our guard selection algorithm obeys restrictions in the particular way described in torspec!182, possibly as amended by torspec!184. (We should wait until the dust settles on those MRs a bit, of course.)Arti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42218"Tor log" screen not scrollabe on android2023-11-27T19:07:19Zclairehurst"Tor log" screen not scrollabe on android<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
### Steps to reproduce:
**How one can reproduce the issue - this is very important.**
1. Open app
2. Connect to Tor
...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
### Steps to reproduce:
**How one can reproduce the issue - this is very important.**
1. Open app
2. Connect to Tor
3. Immediately swipe left to see logs
4. try to scroll, notice that you can't
### What is the current bug behavior?
Log doesn't scroll
### What is the expected behavior?
Log scrolls as expected
### Relevant logs and/or screenshots
https://share.riseup.net/#KJ4nynqOx6L2AL9XXUQcHwclairehurstclairehursthttps://gitlab.torproject.org/tpo/core/arti/-/issues/1087What to do with data and keys from no-longer-configured onion services?2024-02-21T15:09:58ZNick MathewsonWhat to do with data and keys from no-longer-configured onion services?We should define some mechanism to decide how long to keep persistent state and keys for onion services that are **not configured** or **not running**.
(For deleting expired keys from running onion services, see #1198)
If we were to de...We should define some mechanism to decide how long to keep persistent state and keys for onion services that are **not configured** or **not running**.
(For deleting expired keys from running onion services, see #1198)
If we were to delete them immediately, it wouldn't be possible to turn an onion service off and on again, which might surprise some users. But if we were were to keep them forever, that would present a surprising behavior, since users might not expect to retain information about expired onion keys forever.Arti: Onion Service Securityhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42213Fluent migration: tor launcher2023-11-06T23:11:11ZhenryFluent migration: tor launcherMigrate "torlauncher.properties" to Fluent.Migrate "torlauncher.properties" to Fluent.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42212Fluent migration: onion services2023-11-07T16:13:42ZhenryFluent migration: onion servicesMigrate onion services strings found in "torbutton.dtd" and "torbutton.properties" to Fluent.Migrate onion services strings found in "torbutton.dtd" and "torbutton.properties" to Fluent.henryhenry