Project 'tpo/applications/privacy-browser' was moved to 'tpo/applications/mullvad-browser'. Please update any links and bookmarks that may still have the old path.
Bad UX when attempting run multiple instances of Mullvad Browser
So we disable remote execution (if I recall correctly) which prevents the desktop environment from creating new tabs/windows in an existing process(jump list commands in Windows). However, when we attempt to launch a duplicate instance from the desktop environment we get this dialog which is less than helpful:
We probably want to tweak this to be more accurate useful.
I think defense in-depth, preventing running applications from messing with tor-browser instances. Would need to see to do some issue archaeology to figure out if there is a particular threat beyond "don't allow 3rd parties to mess with tor-browser". In theory a malicious program could navigate to some URL to establish a link between the tor session and the real identity.
We could just enable remote execution for Mullvad Browser since linkability is less of a concern. Mullvad Browser users very likely wouldn't be using an in-browser proxy, so 3rd party applications opening links in Mullvad Browser is potentially less of a threat.
Alternatively we could enable a https-only style error page preventing the user from loading links from outside the browser w/o first understanding what's happening, risk of out of proc links, etc.
Edit: actually it seems that Mullvad does support SOCKS5 proxies (even lets you set them within the Mullvad companion extension)
I'm not sure what remote execution is. Is it only related to Windows jump list?
Does that mean an external program could spawn another browser instance to a separate process; and if this second browser instance doesn't have the proxy set in the same manner, then somehow a link could be made between the two browser instances (proxied/non proxied)?
If my understanding is somewhat correct, is there any valid usecase to have 2+ browser instances running in parallel?
So suppose you are using discord.com to chat with some anonymous identity using some anonymity layer (Tor or VPN). You perform some actions on said website but they don't know anything about you apart from the exit you're coming from.
Now suppose another application not behind this anonymity layer (exit node, VPN relay, etc) can make the web browser navigate to an arbitrary website on the internet, including discord.com.
For example, perhaps the same user is also using the native Discord app with another online identity which they feel does not need to be anonymous. Through normal operation, this native app could attempt to have the user's browser navigate to something like https://discord.com?user_ip=1.1.1.1&other_params... (for external links, image hosting, or a url shortner, etc which also sends along telemetry).
If the anonymous browser is already running and allows remote execution, it will pop open a new tab and send the request along with any relevant cookies for that domain (including the anonymous session info). If the browser is not running and the user has enabled persistent cookies (ie disabled always-on private browsing mode) then browser will launch a new instance and make the request along with any relevant cookies. If we don't allow remote execution and don't persist cookies between sessions then this particular scenario is mitigated.
Either way, if the web request is made, Discord knows the user that comes in from behind that anonymity layer has a real IP address of 1.1.1.1 along with whatever else telemetry was passed along.
This is a pretty realistic 'harmless' scenario for services which have both web-apps and native apps, but I think it illustrates the point.
This is general class of problems is what we're talking about when we say 'linkability'.
Remote Execution
Remote execution allows you perform actions on an already running instance of the browser. This includes opening up a new window/new tab from the desktop environment chrome, opening new urls from the command line, etc.
@pierov should multiple instances with different profiles work?
@ruihildt just wanted to ping you here, there are two short-term resolution of fixing this issue:
enable the remoting feature (and the associated linkability issues discussed above) OR
disable setting Mullvad Browser as your default browser (though if a user were to do this manually through their OS's provided Control Panel'esque mechanisms they woudl still run into this issue).
Longer term, we can implement some UX which prevents links from automatically opening in Mullvad Browser, instead provide some sort of captive-portal style screen requesting the user's consent to open the link. This would definitely have to happen after the initial release but would also potentially be valuable in Tor Browser as well.
EDIT: neither of the short-term fixes are particularly difficult, though enabling remoting is easier.
It's fine to temporarily enable the remoting feature, as the scenario listed is unlikely with Mullvad Browser+VPN: it would only work if the user behind their VPN decides to use an app with split tunneling, in which case, privacy is not their main concern.
We can then revisit the UX after the initial release.
Related to that, but probably not to the linkability concern, this screens popup in Windows when you have installed Mullvad Browser and run it, then launch at the same time a portable Mullvad Browser in parallel.
I don't think it's a concern, but just wanted to point out another occurence of it.