Tor Browser issueshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues2024-03-28T10:07:16Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42489Lox module notifications2024-03-28T10:07:16ZhenryLox module notificationsCurrently the Lox module does not give out notifications for when its internals change, so:
+ `TorSetting` is not notified when the bridges change. So it is only set to the new value when restarting Tor Browser.
+ "about:preferences" is...Currently the Lox module does not give out notifications for when its internals change, so:
+ `TorSetting` is not notified when the bridges change. So it is only set to the new value when restarting Tor Browser.
+ "about:preferences" is not notified when the invites change or when there is a blockage or upgrade event.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42476Only allow Lox (invites) in alpha and nightly builds2024-03-25T14:14:39ZhenryOnly allow Lox (invites) in alpha and nightly buildsWe should add some kind of guard to prevent Lox invites for the stable 13.5 release.
I imagine we could use a preference. In terms of the UI, I think we only need to change [one line](https://gitlab.torproject.org/tpo/applications/tor-b...We should add some kind of guard to prevent Lox invites for the stable 13.5 release.
I imagine we could use a preference. In terms of the UI, I think we only need to change [one line](https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/b7fc915f3ed100830bd8574a62f9cd653c1ec250/browser/components/torpreferences/content/provideBridgeDialog.js#L79-80) to disallow Lox invites in the "Add new bridges" dialog.
Do we also want some extra safety checks in other places to prevent the Lox module from doing anything?
/cc @richard @pierovhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42457Loading icon for bridge pass (Lox) invites2024-03-12T15:11:00ZhenryLoading icon for bridge pass (Lox) invitesIn both the dialog for users to supply bridge pass invites, and for the dialog to generate their own invites, we have a loading state whilst we wait for the network response.
The mockup had a loading icon, which was not implemented in h...In both the dialog for users to supply bridge pass invites, and for the dialog to generate their own invites, we have a loading state whilst we wait for the network response.
The mockup had a loading icon, which was not implemented in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036.
@donuts the mockups had a purple loading icon. Should we just use the existing [blue icon from Firefox](https://searchfox.org/mozilla-esr115/rev/889f6c547212101edc0e758c5134ff17f9a37f78/toolkit/themes/shared/icons/loading@2x.png)?henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42456Lox module background tasks are too infrequent.2024-03-28T10:07:17ZhenryLox module background tasks are too infrequent.Currently, the Lox module only checks for upgrade and blockage events every 12 hours. This can mean that the user ends up waiting too long for their upgrade, and that the user can be stuck with blocked bridges for longer than necessary.
...Currently, the Lox module only checks for upgrade and blockage events every 12 hours. This can mean that the user ends up waiting too long for their upgrade, and that the user can be stuck with blocked bridges for longer than necessary.
Moreover, their remaining invites number can become stale, and generating an invite might fail unexpectedly.
@cohosh and @pierov was there any reason why 12 hours was chosen?
For the upgrade, we can just perform a background request once at the expected time.
For the blockage, @cohosh or @onyinyang is there some frequency at which the Lox authority handles the blockage? I.e. bridge blockages are evaluated every N minutes. Or is it entirely dynamic?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42454Bridge pass (Lox) behaviour when bridges are disabled2024-03-12T13:04:47ZhenryBridge pass (Lox) behaviour when bridges are disabledWhat should the behaviour of the preferences and Lox module be if a user has added a bridge pass (Lox bridges), but has disabled bridges ("use bridges" is toggled off in the UI)?
Currently, the `Lox` module will not run any background t...What should the behaviour of the preferences and Lox module be if a user has added a bridge pass (Lox bridges), but has disabled bridges ("use bridges" is toggled off in the UI)?
Currently, the `Lox` module will not run any background tasks whilst the bridges are disabled. I believe that this would have some side effects:
1. The UI would continue to show "N days until you upgrade", even *after* the upgrade date has passed. Note, it won't show negative days, but will instead always show "1 day".
2. The UI would not show any blockage events, which would reset the "N days until you upgrade" counter.
3. The user can still access the option to generate invites. Not sure if this desired or not. But I think the remaining invite count would be outdated.
Moreover, I'm not sure the module is guaranteed to *not* communicate with the Lox authority.
So I guess the UX question is, which of the following does the user expect:
1. Disabling bridges also disables their bridge pass. In particular, related network requests should never be sent. In which case, we would probably need to hide parts of the UI.
2. Disabling bridges does not disable their bridge pass, it just stops Tor from using the bridges. In particular, the background network requests should still be sent.
/cc @donuts @cohosh @pierovhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42453Review bridge pass (Lox) invites2024-03-28T09:42:43ZhenryReview bridge pass (Lox) invitesWe have a few features related to Lox invites that could do with some review.
/cc @cohosh, @onyinyang for infomation about Lox.
/cc @donuts for UX.
## Should we keep invites when the Lox credentials change?
Currently, whenever `TorSet...We have a few features related to Lox invites that could do with some review.
/cc @cohosh, @onyinyang for infomation about Lox.
/cc @donuts for UX.
## Should we keep invites when the Lox credentials change?
Currently, whenever `TorSettings.bridges.lox_id` changes we loose all the invites we have generated in the past. However, in principle those invites are still valid. Especially since they haven't been shared.
In particular, if the user removes `lox` but then restores it later, we should give them access back to their invite codes.
Are there any potential problems that could arise from sharing invites for a bridge pass you are no longer using?
## Do invites have an expire date?
If an invite is generated, will it expire after some time if it is not redeemed? I seem to remember @cohosh mentioning something like this.
Is there a way for Tor Browser to determine when an invite will expire in the future, or a way to determine that an invite has already expired?
If there was, we could show the expire date in the invite dialog, and we could automatically hide expired invites (or just drop them entirely if enough time passes).
## Can we check whether an invite has been redeemed?
Is there a way for a user to check that the invite they generated has already been redeemed?
If there was, we could show the status in the invite dialog.
## Can we know why an invite is rejected?
I feel like an invite can be rejected for a few reasons:
+ A non-existing invite code.
+ The invite has already been used.
+ The invite has expired?
Right now the UI does not distinguish between these error cases. It would be nice if the Lox authority could give some kind of error code for *why* an invite was rejected, so we can pass on some message to the user.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42452Allow restoring bridge pass (Lox credentials) with the same invite2024-03-12T12:26:19ZhenryAllow restoring bridge pass (Lox credentials) with the same inviteWe want to support the following in Tor Browser:
1. A user redeems an invite to get new lox credentials.
2. Later, they remove the Lox bridges.
3. The user re-inputs the *same* invite.
In this case, we should restore their credentials ...We want to support the following in Tor Browser:
1. A user redeems an invite to get new lox credentials.
2. Later, they remove the Lox bridges.
3. The user re-inputs the *same* invite.
In this case, we should restore their credentials after step 3 using our Lox cache. Bypassing the Lox authority.
@donuts or @cohosh, do you see any potential problems with allowing this?henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42425Improve accessibility of the bridge emoji cells2024-03-04T15:14:34ZhenryImprove accessibility of the bridge emoji cellsWhen testing https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42413 with screen readers I noticed:
+ NVDA does not like to read the table cell accessible name, but will instead read the content of the cell only.
+ Orc...When testing https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42413 with screen readers I noticed:
+ NVDA does not like to read the table cell accessible name, but will instead read the content of the cell only.
+ Orca will not read the `aria-describedby` in a table.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42421Remove bridge option should be hidden for Lox bridges2024-03-04T15:14:03ZhenryRemove bridge option should be hidden for Lox bridgesCurrently we allow individual Lox bridges to be removed through the "Bridge options" menu.Currently we allow individual Lox bridges to be removed through the "Bridge options" menu.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42359Handle firewall and proxy in TorSettings.setSettings2024-01-11T15:52:44ZPier Angelo VendrameHandle firewall and proxy in TorSettings.setSettingsWe have TODO about that, but it would be useful to actually implement if we end up having these settings on Android, where we use only the `setSettings` method.We have TODO about that, but it would be useful to actually implement if we end up having these settings on Android, where we use only the `setSettings` method.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42358Separate the domain fronted requests from Moat2024-01-11T15:51:13ZPier Angelo VendrameSeparate the domain fronted requests from MoatLox is doing domain fronted requests as well, so we could reuse the code, but it'd be easier if we moved it to a separate file than `Moat.sys.mjs`.Lox is doing domain fronted requests as well, so we could reuse the code, but it'd be easier if we moved it to a separate file than `Moat.sys.mjs`.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42348TorSettings.defaultSettings() removed but still referenced by Moat.sys.mjs2024-01-11T15:51:19ZrichardTorSettings.defaultSettings() removed but still referenced by Moat.sys.mjsIt seems the `defaultSettings()` call was removed as part of a970113bcc16eda0f4806903e887c98929139fc1, but the method is required for the Moat module in `MoatRPC.#fixupSettings()`. As a result the censorship-circumvention backend fails t...It seems the `defaultSettings()` call was removed as part of a970113bcc16eda0f4806903e887c98929139fc1, but the method is required for the Moat module in `MoatRPC.#fixupSettings()`. As a result the censorship-circumvention backend fails to apply the settings it applies and the user is unable to bootstrap.
This can be simulated by setting the `torbrowser.debug.censorship_level` number pref to `1`.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42343Consume pt_config.json in the browser2024-01-09T13:22:02ZPier Angelo VendrameConsume pt_config.json in the browserRecently we switched to make `pt_config.json` the authoritative file for bridge lines, however we're converting it to prefs for desktop, and we're doing strange things on Android.
I think we could just consume the JSON inside the browse...Recently we switched to make `pt_config.json` the authoritative file for bridge lines, however we're converting it to prefs for desktop, and we're doing strange things on Android.
I think we could just consume the JSON inside the browser, instead.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42323Add a checkbox to enable the connect assist experiments on alpha2023-12-21T22:39:33ZPier Angelo VendrameAdd a checkbox to enable the connect assist experiments on alphaFor S96 we're doing a lot of work, but we want to gate it somehow.
Initially we thought of gating it to nightly, which isn't ideal because nightly has also all the various Moz experiments, which probably make it easy to tell from alpha ...For S96 we're doing a lot of work, but we want to gate it somehow.
Initially we thought of gating it to nightly, which isn't ideal because nightly has also all the various Moz experiments, which probably make it easy to tell from alpha and form release (can we schedule #41989 pretty please? :slight_smile:).
So, the second idea we had is to add an opt-in in alpha.
We talked of a checkbox in #tor-browser-dev, but I think there's some misunderstanding of where the efforts are going.
Right now, only the legacy tor daemon works in our builds.
There are two developments effort:
- firefox-android!48, which is in part built on top of the legacy daemons, in part no-op
- !852, which is working on the backend, but once merged will enable the bootstrap independently of the legacy daemons (almost, it'll use the file they provide). Since we don't have a frontend for it, we've enabled `about:torconnect` also on Android, and I've written some CSS to make it look like the Android version we'll have.
Eventually, the native UX will replace about:torconnect, but until that happens, I think we should allow users to use about:torconnect.
So, I'm not sure a checkbox will be okay.
We might have 3 states:
1. legacy bootstrap (which should also be the default)
2. about:torconnect (to allow us to test the backend and possibly the settings - tor-browser#42301)
3. the new native UX (which also hasn't been merged)
**Big warning: !852 updates the proxy preferences. In addition to changing the frontend, changing opting in/out of the new experience, should reset the proxy preferences.**
This needs some plumbing, but it's a pref, so we know how to implement it quite easily.
/cc @clairehurst @dan @richard @donutsclairehurstclairehursthttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42321Draw new icons for built-in bridges: obfs4, snowflake, and meek-azure2024-01-30T19:23:26ZnicobDraw new icons for built-in bridges: obfs4, snowflake, and meek-azureWe need custom icons for built-in bridges to :sparkles: jazz up :sparkles: the bridge cards.
@donuts off the bat do you have any suggestions for obfs4 and meek-azure conceptually?We need custom icons for built-in bridges to :sparkles: jazz up :sparkles: the bridge cards.
@donuts off the bat do you have any suggestions for obfs4 and meek-azure conceptually?Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetnicobnicobhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42301Make TorSettings interact with the old Android Settings2023-12-22T08:47:38ZPier Angelo VendrameMake TorSettings interact with the old Android SettingsWe want to re-use desktop's connection assist, which is integrated with `TorSettings`.
TorSettings uses Firefox prefs, but on Android we're currently using something native that Android provides.
We need to decide which mechanism we wa...We want to re-use desktop's connection assist, which is integrated with `TorSettings`.
TorSettings uses Firefox prefs, but on Android we're currently using something native that Android provides.
We need to decide which mechanism we want to keep using and write some plumbing (and even a migration procedure, if we end up using prefs, even though Mozilla seems to prefer the native Android one, which is something to consider).Dan BallardDan Ballardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42292 Draw new icons for Telegram, web and email bridge channels2023-12-05T00:58:18Zdonuts Draw new icons for Telegram, web and email bridge channelsHey @nicob, see the "Telegram", "Web" and "Gmail or Riseup" bridge distribution channels at the bottom-left of this page: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-not-connected.png
The globe ...Hey @nicob, see the "Telegram", "Web" and "Gmail or Riseup" bridge distribution channels at the bottom-left of this page: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-not-connected.png
The globe for "Web" makes sense as the default favicon that Fx uses, however could you draw custom icons in the Acorn style for Telegram (i.e. based on their paper plane logo) and Email (i.e. a standard mail icon) please?Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetnicobnicob2023-11-30https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42274Draw a new "bridge-pass" icon for lox bridges2023-12-04T20:33:23ZdonutsDraw a new "bridge-pass" icon for lox bridgesI've just grabbed an icon from Material Symbols and rotated it 45 degrees as a placeholder in these designs: [Figma / Tor Browser 13.5 / lox](https://www.figma.com/file/rWgMwiiFTDFp4ujuP3PKbq/Tor-Browser-13.5?type=design&node-id=151%3A92...I've just grabbed an icon from Material Symbols and rotated it 45 degrees as a placeholder in these designs: [Figma / Tor Browser 13.5 / lox](https://www.figma.com/file/rWgMwiiFTDFp4ujuP3PKbq/Tor-Browser-13.5?type=design&node-id=151%3A9289&mode=design&t=wDYnw2iq2A868OmH-1) (see the top-right of the bridge card for lox bridges). Could you draw a custom icon based on this please @nicob?Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetnicobnicob2023-11-30https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42273Prepare the "bridge" icon for production2024-01-30T19:24:48ZdonutsPrepare the "bridge" icon for productionI created a super quick version here: [Figma / Tor Browser assets / bridge](https://www.figma.com/file/sd4yASXsToxFECsraTlAsw/Tor-Browser-assets?type=design&node-id=122%3A301&mode=design&t=BSRSZc8GO5ieWvFS-1), which you can see in use on...I created a super quick version here: [Figma / Tor Browser assets / bridge](https://www.figma.com/file/sd4yASXsToxFECsraTlAsw/Tor-Browser-assets?type=design&node-id=122%3A301&mode=design&t=BSRSZc8GO5ieWvFS-1), which you can see in use on these designs: [Figma / Tor Browser 13.5 / lox](https://www.figma.com/file/rWgMwiiFTDFp4ujuP3PKbq/Tor-Browser-13.5?type=design&node-id=151%3A9289&mode=design&t=wDYnw2iq2A868OmH-1). However it needs a little refinement – namely the bottom of each stroke should probably be fully rounded, and also descend a little lower past the horizon for optical balance?
The icon should also be compatible with both Acorn and Material Symbols styles, however you may not need to draw two separate icons in this case (I guess stroke width will be the determining factor).Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetnicobnicob2023-11-30https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42270Implement design changes to QR code dialog2024-02-13T10:46:53ZdonutsImplement design changes to QR code dialogSee: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-qr.pngSee: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-qr.pngSponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethenryhenry2024-01-18