The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-09-21T14:57:30Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42040Maybe enable CRLite2023-09-21T14:57:30Zma1Maybe enable CRLiteFollow up to the discussion and the closing of #41115.Follow up to the discussion and the closing of #41115.ThorinThorinhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42039Make the warning of about:config not skippable2023-11-04T01:42:54ZThorinMake the warning of about:config not skippableWe think we could force release users to always see the `about:config` warning, to remind that it can be dangerous.
We thought of:
- always show the warning (by locking `browser.aboutConfig.showWarning` = true)
- remove the warning che...We think we could force release users to always see the `about:config` warning, to remind that it can be dangerous.
We thought of:
- always show the warning (by locking `browser.aboutConfig.showWarning` = true)
- remove the warning checkbox
- spruce up about:config interstitial (FF example below)
- use TB colors?
- change warning to at least mention fingerprinting (and drop `performance` to keep it short)
- maybe a learn more to the about:manual entry
- we need some RED somewhere ... RED WINDOW OF DEATH sounds good
![FF](/uploads/3e6dafea04251f19575243ecee8f8bf4/FF.png)
from https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41797#note_2934868
cc: @pierov @donutshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42025Purple elements (e.g. Tor buttons) need dark theme variants2024-01-29T19:17:37ZdonutsPurple elements (e.g. Tor buttons) need dark theme variantsThere are several components in the browser that use the Photon purple color scheme instead of Fx's default blue, including (but potentially not limited to):
- "Tor Browser" in the identity block
- "Connect" buttons
- ".onion" available...There are several components in the browser that use the Photon purple color scheme instead of Fx's default blue, including (but potentially not limited to):
- "Tor Browser" in the identity block
- "Connect" buttons
- ".onion" available buttons
- "Connected" status in the title bar
- "Connected" flag on bridge cards
- Connection status spinners
And in the new homepage being developed in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41333:
- Links
- Onionize toggle
Typically, these use the following values for light theme:
- default: purple-60 `#8000D7`
- hover: purple-70 `#6200A4`
- pressed: purple-80 `#440071`
- focus: purple-60 `#8000D7`
And were designed to use the following values for dark theme, however this never happened:
- default: purple-30 `#C069FF`
- hover: purple-40 `#AD3BFF`
- pressed: purple-50 `#9400FF`
- focus: purple-60 `#C069FF`
There are three issues here:
1. Semantic color tokens for dark theme were never created.
2. As @henry has rightfully pointed out, the previous design for dark theme went darker on interaction – which is unusual, and not accessible. However we were limited by a lack of having anything lighter than purple-30 in the browser.
3. The purples used are out of date (having originated from Photon), and have since been superseded by new purple color tokens documented in the [Acorn](https://acorn.firefox.com/latest/styles/color-MZHBVuZc) and [Protocol](https://protocol.mozilla.org/docs/fundamentals/color.html) styleguides.
In order to fix this, we'll need to update our existing purple color tokens to include lighter steps. This could be done by migrating to the new values documented in Acorn/Protocol, or by using a custom purple palette.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42000firefox-android: remove telemetry package entierly2023-11-06T21:32:04ZDan Ballardfirefox-android: remove telemetry package entierlyOur current patch
https://gitlab.torproject.org/tpo/applications/firefox-android/-/commit/2e06dbd096d60d78fea23bfc2a744ce6dc62b8c4#b7ca54bdb7940dd3e5124ad20125980c080cb45b_38_37
Just added a runtime check for adjust
we've updated it i...Our current patch
https://gitlab.torproject.org/tpo/applications/firefox-android/-/commit/2e06dbd096d60d78fea23bfc2a744ce6dc62b8c4#b7ca54bdb7940dd3e5124ad20125980c080cb45b_38_37
Just added a runtime check for adjust
we've updated it it to nuke it more
https://gitlab.torproject.org/tpo/applications/firefox-android/-/commit/2e2c4d37842ed1e3af5b472a60dd8766b2b7baa5
because it was still pulling in adjust packages which updated to use google permissions for AD_ID which added it to our app (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41997)
based on this incident it is agreed we take a heavier hand with the metrics package, it would be nice to refactor the "Disable features and functionality" commit to remove the metrics pacakge and use of it as much as possiblehttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/222Hide "List all tabs" when the tabs don't overflow2023-09-28T17:41:51ZruihildtHide "List all tabs" when the tabs don't overflowA new Firefox (or is it chromium?) innovation is to add an icon at the end of the tab bar with a dropdown showing a list of all tabs open.
It's possible only display the icon when tabs are overflowing by setting `browser.tabs.tabmanager...A new Firefox (or is it chromium?) innovation is to add an icon at the end of the tab bar with a dropdown showing a list of all tabs open.
It's possible only display the icon when tabs are overflowing by setting `browser.tabs.tabmanager.enabled` to `false`.
This was the default behavior until ESR 115.
It feels to me that it may be better to keep that option, because it keeps it cleaner for those who don't tab hoard and will appear when you need it.
If users really want it, then we could change it a that point to default.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41989Apply branding while staying on Moz release channel for Android2023-12-07T08:57:48ZPier Angelo VendrameApply branding while staying on Moz release channel for AndroidWe build Android in several channels:
- stable/release for our release channel
- beta for alpha
- nightly for our nightlies
I think the main reason is to swap assets.
However, Mozilla uses the channel also to enable/disable features.
...We build Android in several channels:
- stable/release for our release channel
- beta for alpha
- nightly for our nightlies
I think the main reason is to swap assets.
However, Mozilla uses the channel also to enable/disable features.
We are not interested in them, our experience must be the same as Mozilla's release channel.
So, we would like to have our custom channels (which at the moment we use only for branding) all of them with the stable release configuration.
Somewhere there's code like `isRelease`, `isBeta`, `isNightlyOrDebug` and so on.
Maybe it's a good starting point.https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/219Enable third party protocol handlers2024-02-15T14:49:00ZruihildtEnable third party protocol handlersAs written in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/5556, there are good reasons for Tor Browser not to support magnet (or any other third party protocol handlers).
But, the threat probably doesn't always e...As written in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/5556, there are good reasons for Tor Browser not to support magnet (or any other third party protocol handlers).
But, the threat probably doesn't always exist for most Mullvad Browser users.
There are roughly 4 cases:
1. no proxy or VPN are in use in the system
1. all connections are going through a VPN Tunnel
1. the whole system is going through a VPN tunnel, except the browser
1. no proxy or VPN are in use in the system, except the browser
1. the whole system is going through a VPN tunnel, the browser is going through a different proxy
For case 1 and 2, there are no proxy/bypass or linkability concerns. (Which would be the big majority of Mullvad Browser users)
For cases 3, 4 and 5, the concerns are similar to Tor Browser.
So I think it would be ok to optionally enable external app links to open in apps.
A good example of how it can be implemented is in Firefox Android, there is a preference called "Open links in apps", where you can chose between "Always" / "Ask before opening" / "Never".
![image](/uploads/b44fd48f67b5442a2f16b0fa3726483b/image.png)
We could offer similar choices.
(Then there is still the scheme flooding concern: https://bugzilla.mozilla.org/show_bug.cgi?id=1711084)https://gitlab.torproject.org/tpo/applications/rbm/-/issues/40057Allow setting target, target_replace, target_prepend in projects config2023-08-02T16:21:30ZboklmAllow setting target, target_replace, target_prepend in projects configCurrently to use the `target`, `target_replace` or `target_prepend`
options, they need to be defined in `input_files`.
For some projects where we always want to change targets, it could be
useful to be able to define those options direc...Currently to use the `target`, `target_replace` or `target_prepend`
options, they need to be defined in `input_files`.
For some projects where we always want to change targets, it could be
useful to be able to define those options directly in the project's
config to avoid the need to redifine them in all the places where the
project is used in `input_files`.
/cc @richardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41919Add a message, tooltip or icon to explain letterboxing2024-03-11T15:49:36Zma1Add a message, tooltip or icon to explain letterboxingWhile we're trying to make the letterboxing appearance look more intentional, we may want also to let user easily access an explanation of what it is.
Possible (alternative or combined) approaches variously surfaced in parent #32324:
1...While we're trying to make the letterboxing appearance look more intentional, we may want also to let user easily access an explanation of what it is.
Possible (alternative or combined) approaches variously surfaced in parent #32324:
1. Informative tooltip when user hovers the letterboxing area
2. "?" shaped cursor, making the letterboxing area clickable to open the relevant manual section (or the options page if/when
#41916 gets implemented)
3. "?" button appearing somewhere in the letterboxing area when there's enough space, instead of making the whole area clickable.
/cc @ruihildt, @thorinma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41913Add validation and improve the formatting of manually added bridge lines2024-02-27T19:07:40ZdonutsAdd validation and improve the formatting of manually added bridge linesThe updated copy was added in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40552, but not the trickier parts relating to the fancy formatting and validation going on in the text box.
See the Figma file here: [Figm...The updated copy was added in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40552, but not the trickier parts relating to the fancy formatting and validation going on in the text box.
See the Figma file here: [Figma link](https://www.figma.com/file/RS584DcR4emXrw1F8g3l5x/Tor-Browser-12.5?node-id=102%3A13802&t=41hhHGHnJTkIHnmo-1)https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41902Add "New Circuit" to right-click context menu2023-07-20T17:00:02ZdonutsAdd "New Circuit" to right-click context menuSee [this suggestion](https://forum.torproject.org/t/suggestion-right-click-on-tab-and-offer-new-tor-circuit-for-this-site-option/8352) from a forum user.
The natural position would seem to be below "Reload" in the context menu. We shou...See [this suggestion](https://forum.torproject.org/t/suggestion-right-click-on-tab-and-offer-new-tor-circuit-for-this-site-option/8352) from a forum user.
The natural position would seem to be below "Reload" in the context menu. We should probably use the existing string in title case (i.e. "New Tor Circuit For This Site"), however that's very wordy and I think "...For This Site" can be inferred based on the context, so I'd be in favor of slimming it down to "New Circuit" here.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41889Improve bridge cards update2023-08-22T17:02:09ZPier Angelo VendrameImprove bridge cards updateThe bridge cards mechanisms could be improved. From https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/699#note_2922312:
> Right now there is a bit of a delay to unchecking and the connected label being removed,...The bridge cards mechanisms could be improved. From https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/699#note_2922312:
> Right now there is a bit of a delay to unchecking and the connected label being removed, which leads to a more "jumpy" UI. This can be resolved right now by moving the logic in `_updateConnectedBridges` to the end of `_populateBridgeCards`, adding the `TorSettings.bridges.enabled` condition, and removing the call to `_populateBridgeCards` that would cause a loop.
In general, we could even clean the whole thing, especially if this helps further improvements.https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/206Signing script updates to support publishing/signing Flatpaks2023-09-12T22:13:42ZrichardSigning script updates to support publishing/signing FlatpaksI suspect the existing pgp sign-everything system will handle any new build targets, but we should look and see if Flatpak packages support any kind of code-signing, and if so update our signing scripts to do so.I suspect the existing pgp sign-everything system will handle any new build targets, but we should look and see if Flatpak packages support any kind of code-signing, and if so update our signing scripts to do so.boklmboklmhttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/205Flatpak build for Mullvad Browser in tor-browser-build2023-10-10T13:53:56ZrichardFlatpak build for Mullvad Browser in tor-browser-buildWe should (maybe) build+distribute our own Flatpak package for end-users.We should (maybe) build+distribute our own Flatpak package for end-users.boklmboklmhttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/204Flatpak package-specific UX for updater2023-09-12T22:14:19ZrichardFlatpak package-specific UX for updaterWe are aiming to officially support Flatpak for Mullvad Browser distribution on Linux. We need to either:
1. Add an update check+notification for Flatpak installs
2. Update the flathub package to support our existing in-place no-root re...We are aiming to officially support Flatpak for Mullvad Browser distribution on Linux. We need to either:
1. Add an update check+notification for Flatpak installs
2. Update the flathub package to support our existing in-place no-root required updater
Homebrew for macOS (for example) lets packagers specify their packages update themselves (using the `auto_updates true` flag) so perhaps Flatpak support a similar mechanism. If not, we will need a way to signal to users they can get an update from their package manager.https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/202Update Updater UX to support System Installs on Windows2024-01-31T18:36:03ZrichardUpdate Updater UX to support System Installs on WindowsMullvad Browser installed to `%PROGRAMFILES%` would need elevation to perform incremental updates. We have a few options here:
- Update the UX to notify users of when an update is available :disappointed:
- this pathway *is* kind of n...Mullvad Browser installed to `%PROGRAMFILES%` would need elevation to perform incremental updates. We have a few options here:
- Update the UX to notify users of when an update is available :disappointed:
- this pathway *is* kind of needed for various Linux packages (flatpak, deb, rbm, etc)
- Enable the update pathway the default Firefox uses to get around this problem
- Probably involves running some system service which can with elevated privileges; Mullvad Browser doesn't care about disk leaks like Tor Browser does, so maybe this is fine
- Somehow *hand waving* enable the browser to self-elevate and update
/cc @pierov @ma1 @ruihildt @donuts
## Design estimate:
* Complexity:
* Uncertainty level:
* Total:https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/201Update signing scripts to handle system installers2023-09-12T22:14:41ZrichardUpdate signing scripts to handle system installersDepends on #200
Whatever solution we come to there, we will need to update our signing scripts to handle it.Depends on #200
Whatever solution we come to there, we will need to update our signing scripts to handle it.boklmboklmhttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/200Build system installer for Mullvad Browser on Windows2024-03-26T16:07:58ZrichardBuild system installer for Mullvad Browser on WindowsCurrently Mullvad Browser inherits Tor Browse's portable-only installer on Windows. We should either:
1. Add support to existing installer to support portable OR system `%PROGRAMFILES%` installs
2. Create a second installer which can in...Currently Mullvad Browser inherits Tor Browse's portable-only installer on Windows. We should either:
1. Add support to existing installer to support portable OR system `%PROGRAMFILES%` installs
2. Create a second installer which can install to a system location, separate from the portable installer
3. Update existing installer to be a classic system installer and instead ship portable as a zip archive
Some things to consider:
- System installation requires Admin/Elevation privileges on Windows. NSIS installers can be built such that the elevation prompt happens automatically on launch, but this will likely/possible prevent portable installation on systems which the user does not have admin access (such as in library/univeristy/corporate terminals). I don't know if you can conditionally elevate in an NSIS installer based on install location.
- A second installer to counter the previous constraint would work, but could cause user confusion
- Providing a zip bundle may make it easier for dowstream package maintainers if any were to appear (eg for [chocolatay](https://chocolatey.org/))Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/194Hide the History section in `about:preferences#privacy`2023-11-14T08:36:27ZruihildtHide the History section in `about:preferences#privacy`May also be applicable to Tor Browser.
Since we don't support non PBM and changing that has an effect on the design/threat model of the browser, why do we keep exposing the UI to change it?
I suggest we hide it as to not encourage user...May also be applicable to Tor Browser.
Since we don't support non PBM and changing that has an effect on the design/threat model of the browser, why do we keep exposing the UI to change it?
I suggest we hide it as to not encourage users to change anything. If they feel like they know better, they can change stuff in `about:config`.
Visual interpretation:
![image](/uploads/50f52eb6ba78a0280f970f5407cea34f/image.png)
(and no, I'm not suggesting drawing a red cross on top it @ma1 ;) )https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/193Customizing `about:config` warning2023-11-01T18:06:52ZruihildtCustomizing `about:config` warningHere's the current message:
![image](/uploads/5f5c4efe7e8a42c81240ad546a045fa4/image.png)
Instead, I suggest we change the message to warn, changing stuff here will probably break the privacy and security design of the browser.
And als...Here's the current message:
![image](/uploads/5f5c4efe7e8a42c81240ad546a045fa4/image.png)
Instead, I suggest we change the message to warn, changing stuff here will probably break the privacy and security design of the browser.
And also take the opportunity for the user to tell us why they want to change a setting there, so we can learn from it.
With a message along these lines: "If you need to change a setting, please tell us so we can better evaluate your needs"; with an easy was of contacting us.