Tor Browser issueshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues2024-03-12T12:26:19Zhttps://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/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/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/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/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/42453Review bridge pass (Lox) invites2024-03-28T22:55:21ZhenryReview 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/42492Should Lox credentials be locked when they might be updated?2024-03-28T16:44:21ZhenryShould Lox credentials be locked when they might be updated?Currently the Lox module has some methods that read the current `Lox.#credentials` and then after some async time write to `Lox.#credentials`. In principle, we could run simultaneously:
1. `#blockageMigration`.
2. `#attemptUpgrade`.
3. ...Currently the Lox module has some methods that read the current `Lox.#credentials` and then after some async time write to `Lox.#credentials`. In principle, we could run simultaneously:
1. `#blockageMigration`.
2. `#attemptUpgrade`.
3. `generateInvite`.
So in principle, the credentials from one operation might overwrite the credentials from another. And it is not clear which credentials *should* be kept.
@cohosh or @onyinyang what actually happens at the Lox authority level? How does it handle simultaneous requests? How are clients expected to interact with it to update their credentials? Is there a way to tell which credentials are the *newest* ones, and therefore the ones we should keep?
Otherwise, do we just need to "lock" the credentials in the module whilst any of these operations are ongoing?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, & Tibetma1ma1