Tails

#4 Updated by sajolida 2015-12-03 10:15:23

While working on Feature #10491 we might rethink the purpose of the Unsafe browser.

#5 Updated by tailor 2016-02-13 13:14:35

Had a quick look at Unsafe Browserand whilst the rationale might make sense, to me it seems that Tails has made it even more unsafe and restrictive than it needs be.

How?

By denying users access to Add-ons which is missing from the menu items. And that’s what makes Firefox a favoured browser for so many, its wealth of Add-ons to cover practically any situation.

Add-ons which may not match the same levels of security and anonymity that Tor Browser offers but nevertheless provide ample capabilities and aid usability.

Yes we are all aware of yours and Tor’s antipathy and aversion towards Add-ons but the mere fact that they and you at Tails have chosen to include Adblock Plus, HTTPS-Everywhere and NoScript in your distribution must be an indication that Add-ons aren’t all that bad and to be avoided at all costs.

A level of anonymity in Unsafe browser can easily be achieved through a host of Proxy Add-ons which serve to hide the user’s IP address and location.

And so many other Add-ons which are helpful with Privacy and Security issues. So whilst it may not be the ideal, in an emergency Unsafe Browser can be made safer and a lot more viable if you at Tails review this inequity. And since, from what I understand of clearnet, the browser is opened in its own volatile environment and all references to it erased once the browser is closed, it surely cannot pose a huge security risk.

You might even consider shipping the browser with these free Add-ons pre-installed such as a Proxy which would give users the protection that is lacking and much, much more than what is afforded at present.

“Existence of Unsafe browser can be pointless and possible danger for them.” - not true if suggestions above are adopted.

“I confirm this is to discuss, but I kind of doubt that the risks, qhich should be technically explicited here are worth the work?” - don’t know about Greeter and it purpose but surely it would not take much to enable the use of Add-ons in Unsafe Browser.

The problem, more of an inconvenience, I suspect would be that one could not install Add-ons saved externally of clearnet and unless already included would have to be downloaded and installed every time the browser is started and before any browsing is started.

Please give it some serious consideration.

BTW - probably one other plus in its favour is that once Add-ons are installed the browser will probably restart which at present does not occur with Tor Browser, It closes but then needs to be restarted manually. Is this a bug which needs to be reported or done by design?

#6 Updated by sajolida 2016-05-03 12:07:59

My take on this is that the Unsafe Browser should die and be replaced by some browsing utility (not a full browser) that only allows connecting to captive portal. This is what we envisoned in https://tails.boum.org/contribute/how/promote/material/slides/IFF-20160306/08_autoconfiguration_captive_portal.png as part of https://tails.boum.org/blueprint/network_connection/.

Until then I’m quite against moving it to the Greeter as you might not always know in advance if you will need to connect to a captive portal or not, so moving it to the Greeter might lead to two behaviors:

• People enabling it when they don’t really need it. Then we loose the supposed benefits.
• People having to restart after realizing they are behind a captive portal or after simply changing network. That’s quite frustrating and a definite UX regression.

#8 Updated by cypherpunks 2016-07-08 04:48:04

muri wrote:
> We discussed this ticket at the monthly meeting:
>
> We agree with sajolidas reasoning on the ticket #note-6: there is already a
> blueprint for a new solution and there are some ux problems with adding that
> functionality to the greeter.
> intrigeri suggested the middle ground to block/forbid the unsafe browser as
> soon as Tor has bootstrapped, but thats not that easy to implement: one ux
> problem to solve would be how to handle roaming laptops that move into a wifi
> that requires a captive portal. thats not worth the
> coding/reviewing/documentation effort for a temporary solution.

Would you change your priorities if GTK had such a history of letting applications be controlled or hijacked through environmental variables that allowing a user to run the Unsafe Browser were tantamount to allowing the firefox process to be run with LD_PRELOAD as the clearnet user (and I’m not just talking about GTK_MODULES)? There is a very good reason that GTK libs try to prevent themselves from being executed if they are setuid or setgid, and that’s precisely because secureexec (which is used to strip dangerous environmental variables like LD_PRELOAD) does not and cannot take into account all the variables that GTK has to let the environment control an executed process. Having the Unsafe Browser executable as the clearnet user via sudoers is no different, from a security perspective. The only real difference is that Firefox does not rightly stop itself from being executed.

Of course, there’s also the issue of X11 hijacking. A hidden screen could be created and the Unsafe Browser opened in there. Perhaps Gnome also has the ability to hide windows itself too. I believe this was discussed elsewhere with regards to Vidalia, but it didn’t go much farther than “I wonder if this is possible”. GTK is a bigger threat though, because it is trivial to exploit GTK applications this way in an automated fashion, doesn’t depend on the Unsafe Browser not being open, and doesn’t rely on whimsical X11 magic. It would be as simple as “GTK_SOME_VAR=something unsafe-browser”, and a shell spawns, running “exec curl -s icanhazip” as the clearnet user, with the browser never even opening.

#9 Updated by intrigeri 2016-07-08 05:15:26

>> thats not worth the coding/reviewing/documentation effort for a temporary solution.

> Would you change your priorities if GTK had such a history of letting applications be controlled or hijacked through environmental variables […]

The decision we made took into account some of the security concerns that come with the current state of things. I don’t think that these “new” bits about GTK are a game-changer enough to make it worth investing so much time+energy into a temporary solution. But surely that’s one more good reason to implement the new thing that will replace the Unsafe Browser! I’m not up-to-date with the current state of things (there’s probably a blueprint and tickets etc. somewhere), ask sajolida if you want to help make this happen.