The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-03-06T18:39:12Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42436Allow for multiple configured (front, reflector) domain fronting pairs in Moa...2024-03-06T18:39:12ZCecylia BocovichAllow for multiple configured (front, reflector) domain fronting pairs in Moat moduleIt's happened twice now that the domain fronting settings for Moat have stopped working:
- [when `cdn.sstatic.net` moved to CloudFlare](https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/000314.html)
- [when Fastl...It's happened twice now that the domain fronting settings for Moat have stopped working:
- [when `cdn.sstatic.net` moved to CloudFlare](https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/000314.html)
- [when Fastly stopped supporting domain fronting and `foursquare.com` renewed its cert](https://github.com/net4people/bbs/issues/309)
When Moat stops working, it leaves us scrambling to find new front domains, the update process requires a new release, and it can be difficult for users to receive updates or connect if Connection Assist is unreachable. It's also difficult to choose a single front domain that will work in almost every place. Even though Connect Assist allows us offer country-specific circumvention settings, we have only a single setting for using Connect Assist itself.
Ideally, we could provide multiple (front, reflector) pairs, and iterate through them until a working pair is found. That pair can be saved for future use until it stops working and the module will re-iterate through the list until a new pair is found.https://gitlab.torproject.org/tpo/core/tor/-/issues/11101Bridges should report implementation versions of their pluggable transports2024-03-05T15:17:58ZRoger DingledineBridges should report implementation versions of their pluggable transportsOur bridges now run a variety of pluggable transports. What if there's a bug in, say, the Scramblesuit implementation (like it appears there is)? If we fix the bug, how do bridgedb or the Tor clients know whether the Scramblesuit bridge ...Our bridges now run a variety of pluggable transports. What if there's a bug in, say, the Scramblesuit implementation (like it appears there is)? If we fix the bug, how do bridgedb or the Tor clients know whether the Scramblesuit bridge they just learned about is one of the new (updated) ones or one of the old (buggy) ones?
One option would be for Tor to include a version for each supported PT in its bridge (or extrainfo) descriptor, so if we turn out to not want to use certain versions for certain situations, we can do it.
Are there better options than this one?Tor: 0.4.9.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/ux/research/-/issues/135Plan user research to test Lox2024-02-21T11:06:10ZdonutsPlan user research to test LoxLox is going to exist in Tor Browser Alpha for an extended period, e.g. 2025 at minimum, before it reaches stable. Although we have no definitive plans for its continued development yet, I've created this issue as a place we can begin co...Lox is going to exist in Tor Browser Alpha for an extended period, e.g. 2025 at minimum, before it reaches stable. Although we have no definitive plans for its continued development yet, I've created this issue as a place we can begin collecting questions while the first phase of work is still fresh in our minds.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41541Update builtin bridges from Circumvention Settings API2024-03-27T15:25:34Zmeskiomeskio@torproject.orgUpdate builtin bridges from Circumvention Settings APIRight now to update the builtin bridges we need to make a Tor Browser release, it would be nice if TB automatically updates them using [Circumvention Settings API](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/m...Right now to update the builtin bridges we need to make a Tor Browser release, it would be nice if TB automatically updates them using [Circumvention Settings API](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/moat.md#circumventionbuiltin).
There are two concerns I have about it:
* Users will not be happy with TB making a call to an external API without giving some consent about it.
* We don't want to make easier for censors to notice you are using Tor because of that.
I think it makes sense to update when we do other connections to moat (Connect Assist, captcha bridges, ...), I assume user has already consent to do a request to the API on those cases and having an extra connection over the domain fronting should not make it more noticeable than it already is. We could store when was the last time we had updated them, and don't update them is they are fresh (maybe 24h is a good freshness).
An extra that would be nice is to ask the user if they want to refresh the builtin bridges when they click on Settings to *Select a Built-In Bridge*. I think we should only ask if bridges hasn't being refreshed for a while (maybe 7days). The confirmation popup could have a check box with 'remember that option' or something like that, so the following times they enable builtin bridges we refresh or not without asking (if the bridges hasn't being refreshed in 7days).Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetma1ma1https://gitlab.torproject.org/tpo/applications/vpn/-/issues/143Convert "Add new bridges" dialog into a full-screen dialog2024-03-05T17:32:20ZdonutsConvert "Add new bridges" dialog into a full-screen dialogThe previous dialog we designed is a little claustrophobic. The text area is quite narrow, and the dialog awkwardly grows in height when new lines are entered. We could improve on this by switching to a full-screen dialog as described he...The previous dialog we designed is a little claustrophobic. The text area is quite narrow, and the dialog awkwardly grows in height when new lines are entered. We could improve on this by switching to a full-screen dialog as described here: https://m3.material.io/components/dialogs/guidelines
The Figma file can be found here: [Figma / Tor VPN for Android](https://www.figma.com/file/sjNWeIOpb0BckjmxApXd5m/Tor-VPN-for-Android?type=design&node-id=4395%3A1618&mode=design&t=QaXRFt9BKyClRF4p-1)VPN pre-alpha 07https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42429Android Connection Assist Non-Portriat-Phone Sizes Design2024-02-29T00:51:27ZclairehurstAndroid Connection Assist Non-Portriat-Phone Sizes DesignFor tor-browser#41188 we have portrait designs, but don't have landscape (and other non-protrait-phone) designs. How do we want the landscape (and other non-portriat-phone sizes) to look for connection assist? I was messing with trying t...For tor-browser#41188 we have portrait designs, but don't have landscape (and other non-protrait-phone) designs. How do we want the landscape (and other non-portriat-phone sizes) to look for connection assist? I was messing with trying to make it look better and have some references. I made the buttons have a max width, brought the toggle closer to the text, and reduced the spacing for the text so that it fits better horizontally (otherwise views start overlapping on certain screens with enough going on)
Mock Native Landscape
![Mock_Native_Landscape](/uploads/b2f313b9b51ae7a0499b3bfde3d917a7/Mock_Native_Landscape.png)
Current HTML Landscape
![HTML_Landscape](/uploads/6fa173af6b86fa10d8c1db5e072c27da/HTML_Landscape.png)
Mock Tablet
![Mock_Tablet](/uploads/bfc51dbdad8bfc6b6d60ea768e3dfb86/Mock_Tablet.png)
Mock Foldable
![Mock_Foldable](/uploads/38eb8f5c11b61ee47fd8e2c1db3d81be/Mock_Foldable.png)
Current Native Portrait
![Native_Portrait](/uploads/384005393822624e481d9a2e60a3935f/Native_Portrait.png){width=25%}donutsdonutshttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/58Better Invitation Encoding2024-03-01T11:43:41ZonyinyangBetter Invitation EncodingThe Lox invitation endpoint currently returns a string of bytes formatted like:
```
{"invite":92,149,13,240,159,9,236,1,141,15,246,61,49,4,53,142,229,56,160,137,155,86,127,166,223,8,80,114,117,17,210,3,2,0,0,0,5,36,19,41,86,145,241,114...The Lox invitation endpoint currently returns a string of bytes formatted like:
```
{"invite":92,149,13,240,159,9,236,1,141,15,246,61,49,4,53,142,229,56,160,137,155,86,127,166,223,8,80,114,117,17,210,3,2,0,0,0,5,36,19,41,86,145,241,114,93,58,10,118,162,141,183,53,200,168,179,108,34,222,21,15,252,195,121,92,185,187,78,126,17,67,153,113,32,87,109,232,90,104,27,162,141,83,26,121,195,47,249,109,50,104,220,136,183,111,7,8,93,53,3,12}
```
This is probably not ideal for a user to paste into the browser, though maybe it is fine?
We should check with the ux team to see if they have suggestions for a better user experience and consider changing this (and the interface) to accept a more user-friendly invite.Lox Ready for Open Testing Callonyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/57Create a detailed workflow for investigating and responding to blocked Lox br...2024-02-26T17:32:10ZonyinyangCreate a detailed workflow for investigating and responding to blocked Lox bridgesThough automating the detection of blocked bridges has been a [long term goal](https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40035), discussed [here](https://gitlab.torproject.org/tpo/anti-censorship/rdsy...Though automating the detection of blocked bridges has been a [long term goal](https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40035), discussed [here](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/112) as well, we should have a detailed workflow for how we will handle getting reports of blocked bridges, how often we will manually update bridge statuses for Lox bridges and who will be responsible for these updates during our test deployment.Lox Ready for Open Testing Callonyinyangonyinyanghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42413Review Lox UI wording2024-02-22T14:41:16ZhenryReview Lox UI wording/cc @jag and @donuts
In https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036 we added some new strings, and this issue is just to review them.
The new strings are all [here](https://gitlab.torproject.org/tpo/appli.../cc @jag and @donuts
In https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036 we added some new strings, and this issue is just to review them.
The new strings are all [here](https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/0efa3dd93339e7f996070d5170b4fddf5fc11b60/browser/locales/en-US/browser/tor-browser.ftl#L48-300) if you want to review them all, but only a few stand out for me.
Some deviated from the mockups as we learnt more about how Lox actually functions.
The overview:
> With a bridge pass, the bridge bot will send you new bridges when your bridges get blocked. If your bridges don’t get blocked, you’ll unlock invites that let you share bridges with trusted contacts.
After "days until you unlock", we show
> Invites for your trusted contacts
the first time the user will gain invites. And if the user already has invites, we change it to
> More invites for your trusted contacts
Note, the reason we no longer included "+N invites for your trusted contacts" was because the "+N" calculation is non-intuitive: the user doesn't actually gain a fixed number of new invites per level, instead whenever their level changes their remaining invites get reset. In particular, remaining invites at the current level are ignored. When you level up, the next level will reset to a higher number than whatever you have now, so will will gain some amount. When you level down, you can either have more or less remaining invites, depending on how many you used up before.
For the same reason, whenever the user levels up past level 1 ("bridge pass has been upgraded") or levels down ("blocked bridges have been replaced") or some mixture of both, we always show how many remaining invites they have:
> You now have { $numInvites } remaining invites for your trusted contacts
I.e. instead of the "+N" from the mockup, we just give a notice of what the new number is, which may be more or less than when the user last looked.
We also have two strings that refer to "bridge pass server":
> Connecting to bridge pass server…
and
> Unable to connect to bridge pass server.
Should these be "bridge bot" instead of "bridge pass server" to be consistent? I assumed that "bridge bot" in the other strings already referred to the Lox authority (plus Tor Browser's interaction with it).donutsdonutshttps://gitlab.torproject.org/tpo/ux/team/-/issues/87Project idea: Split circumvention settings into "easy" and "advanced" views2023-12-08T20:33:09ZdonutsProject idea: Split circumvention settings into "easy" and "advanced" viewsTor's circumvention settings are becoming increasingly complex due to the censorship arms race. While features like Connection Assist were originally envisioned as a way to spare users from manually configuration their circumvention sett...Tor's circumvention settings are becoming increasingly complex due to the censorship arms race. While features like Connection Assist were originally envisioned as a way to spare users from manually configuration their circumvention settings entirely, the reality is that users subjected to particularly heavy censorship often need to dive into these settings anyway.
Current routes to circumvent censorship include:
- Connection Assist
- Built-in bridges, including:
- Obfs4
- Snowflake
- Meek
- Bridges requested from rdsys
- User added bridges, distributed by:
- Telegram
- Email
- Web
In the near future, these options may be further expanded by the addition of:
- Lox bridges
- New pluggable transports, i.g. Webtunnel and Conjure
- Incorporating Orbot's "Ask Tor" feature
As such, there may be some benefit in splitting our circumvention settings into "easy" and "advanced" views, to prevent users from becoming completely overwhelmed by the sheer volume of routes. The "easy" view could include simple options like built-in bridges, alongside semi-automated options powered by the circumvention API (e.g. Connection Assist or Ask Tor), whereas the "advanced" view would contain options that provide for more manual configuration.https://gitlab.torproject.org/tpo/applications/vpn/-/issues/119Review strings used on "Bridges" page for length and consistency2024-03-26T22:58:47ZkwadronautReview strings used on "Bridges" page for length and consistencyThe wording is pretty long:
> **Enter bridge address**
>
> Add a bridge provided by a trusted organization or someone you know
![image](/uploads/6eed6b060be49262539f5064c635907b/image.png)
Maybe we can get something shorter, suggestio...The wording is pretty long:
> **Enter bridge address**
>
> Add a bridge provided by a trusted organization or someone you know
![image](/uploads/6eed6b060be49262539f5064c635907b/image.png)
Maybe we can get something shorter, suggestions:
- Add a bridge from a trusted organization or person
- Add a trusted bridge
- Enter a bridge from a trusted sourceVPN pre-alpha 06donutsdonutshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42086Deprecate moat CAPTCHAs2023-11-06T22:53:58ZrichardDeprecate moat CAPTCHAsanti-censorship issue: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/173#note_2941598
The moat CAPTCHA UX is going away sometime in 2024. We will need to rip out the existing UX and implement the new UX in both Deskto...anti-censorship issue: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/173#note_2941598
The moat CAPTCHA UX is going away sometime in 2024. We will need to rip out the existing UX and implement the new UX in both Desktop and Android.https://gitlab.torproject.org/tpo/web/support/-/issues/334Add onion services PoW to the glossary and other parts of the docs2023-11-06T19:44:05ZemmapeelAdd onion services PoW to the glossary and other parts of the docswe can use https://blog.torproject.org/introducing-proof-of-work-defense-for-onion-services/ as a base to add Onion Services PoW to the docs.we can use https://blog.torproject.org/introducing-proof-of-work-defense-for-onion-services/ as a base to add Onion Services PoW to the docs.https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/28Set daily max bucket distribution and adjust other settings for production2024-02-15T16:52:09ZonyinyangSet daily max bucket distribution and adjust other settings for productionWe likely need to decide on an upper bound of buckets that can be distributed each day so that we don't run out of open invitation buckets. We currently have buckets being distributed to k users before a new bucket is used but if buckets...We likely need to decide on an upper bound of buckets that can be distributed each day so that we don't run out of open invitation buckets. We currently have buckets being distributed to k users before a new bucket is used but if buckets are continuously requested, we will eventually run out of buckets each day. These variables should be part of a configuration file for Lox.Lox Ready for Open Testing Callonyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/24Implement Metrics Reporting for Lox2023-10-31T21:19:34ZonyinyangImplement Metrics Reporting for LoxFrom the [Lox Roadmap](https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/wikis/Lox-Roadmap) we want to include strategic reporting of metrics in our Lox deployment so that we are able to determine the effectiveness of Lox. The m...From the [Lox Roadmap](https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/wikis/Lox-Roadmap) we want to include strategic reporting of metrics in our Lox deployment so that we are able to determine the effectiveness of Lox. The minimum metrics to measure are the following:
- [x] Prometheus metrics for counts of how often each library function is called from distributor
- [ ] How many bridges are in each rank
- [ ] Blockages from deployed bridgestrap instance
- [x] Remaining capacity (or if/when we run out of bridges to hand out to open inv)
Discussion, development of these and additional metrics to include in the initial deployment will be tracked in this issue.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/5Rewrite Lox handling of new resources2024-02-15T17:38:19ZonyinyangRewrite Lox handling of new resourcesAt present, the Lox distributor handles `new` resources by parsing them into BridgeLines, grouping them into 3 (MAX_BRIDGES_PER_BUCKET) and then placing them into an open invitation bucket. Any additional bridges that don't group into 3 ...At present, the Lox distributor handles `new` resources by parsing them into BridgeLines, grouping them into 3 (MAX_BRIDGES_PER_BUCKET) and then placing them into an open invitation bucket. Any additional bridges that don't group into 3 are stored temporarily in the LoxServerContext until enough bridges to make up a bucket come along. Eventually, this needs to be improved to address several things:
* [ ] Smarter bridge groupings:
* What factors determine whether a set of bridges are grouped into a bucket?
* Should the distributor determine those factors or should rdsys pre-sort bridges into buckets?
* [ ] Decide on an appropriate open invitation to hot spare bucket ratio
* Some proportion of buckets *must* be hot spare buckets so that there are a pool of buckets for users to migrate to
* [ ] Ensure access to open-entry invitations
* Can we prevent sock-puppets from clogging the open-entry pathway?
* Can/should we limit which open-entry bridges are distributed to which users?
* [ ] Determine when a bridge is "blocked"?
* In reality, bridges are blocked by locale which Lox does not consider
* Issue being tracked [here](https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40035)
* [ ] Improve Lox Parameters for Tor Usecase
* Lox's parameters such as the time to level up, number of invitations distributed, etc. are untested in the real world
* Are there better parameters for Tor's usecase?https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40257Client: add config option to filter out IP address used for ICE2023-06-21T09:14:52ZitchyonionClient: add config option to filter out IP address used for ICEFrom https://www.rfc-editor.org/rfc/rfc8445#section-19.1
> ICE implementations where
such issues can arise are RECOMMENDED to provide a programmatic or
user interface that provides control over which network interfaces
are used ...From https://www.rfc-editor.org/rfc/rfc8445#section-19.1
> ICE implementations where
such issues can arise are RECOMMENDED to provide a programmatic or
user interface that provides control over which network interfaces
are used to generate candidates.
In some cases, providing an IP address as candidate could also save one STUN connection. While we still use STUN servers to determinte NAT type on the client side, this could be helpful when [censors are targeting STUN servers](https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40024#note_2829127).
This came up as I was researching https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40108https://gitlab.torproject.org/tpo/community/training/-/issues/76[Training] Prepare training material on circumventing Internet shutdowns with...2023-06-20T14:19:12Zraya[Training] Prepare training material on circumventing Internet shutdowns with TorThe aim is to create slides on fighting censorship with Tor (from a user perspective), highlighting:
- How Tor works for bypassing blocking
- Where Tor can and cannot help
- How to circumvent censorship of Tor itself: GetTor, Bridges, Co...The aim is to create slides on fighting censorship with Tor (from a user perspective), highlighting:
- How Tor works for bypassing blocking
- Where Tor can and cannot help
- How to circumvent censorship of Tor itself: GetTor, Bridges, Connection AssistGusGushttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/55Update description in Snowflake extension pages on Firefox and Chrome2023-06-27T18:34:40ZrayaUpdate description in Snowflake extension pages on Firefox and ChromeThere was a discussion in the Tor IRC channel that the description in the Snowflake extension Chrome webstore and Firefox add-ons page does not clearly distinguish between censored/uncensored users:
- https://addons.mozilla.org/en-GB/fir...There was a discussion in the Tor IRC channel that the description in the Snowflake extension Chrome webstore and Firefox add-ons page does not clearly distinguish between censored/uncensored users:
- https://addons.mozilla.org/en-GB/firefox/addon/torproject-snowflake/
- https://chrome.google.com/webstore/detail/snowflake/mafpmfcccpbjnhfhjnllmmalhifmlcie
Opening the issue to say that I could work on updating the description in the next hour if the priority is high!
cc: @arma @gus @shelikhoo @meskioCecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41193Support bridge: scheme URI to configure bridges2022-11-30T15:26:32ZNathan FreitasSupport bridge: scheme URI to configure bridgesFor easy bridge configuration on mobile, via QR code scanning, links sent in text messages or emails, TBA should support an agreed upon format for bridges sent via bridge:// encoded URI.
Copy and pasting bridge lines into a settings men...For easy bridge configuration on mobile, via QR code scanning, links sent in text messages or emails, TBA should support an agreed upon format for bridges sent via bridge:// encoded URI.
Copy and pasting bridge lines into a settings menu is highly unusable and prone to errors. The ability to one tap or one scan configure bridges with a confirmation dialog is easy and streamlined!Tor Browser 12.0Pier Angelo VendramePier Angelo Vendrame