I’m just going to lead with the headline: I keep my web browser sandboxed for security. Unity cannot run correctly sandboxed. I don’t really expect it to run sandboxed because of all the hooks into various things it has, but this creates a huge problem when trying to launch Unity from the hub (which is the only way to do it anymore).
The hub wants to sign in. Apparently it wants to use my web browser to sign in and it can’t. Fortunately if I click the login button 5 times it launches a webform. However that webform is soo broken. I often have to spend hours trying it over and over until it successfully issues a log in. I don’t know why it errors most of the time when you enter your user name and password, but it does.
This is basically the front door to unity, and you can’t use it in any capacity without logging in, so why is it so difficult to do? Is it just considered normal that everyone allows apps to open their web browser to any arbitrary address willy-nilly? Does no one at unity use a sandbox to secure their web browser?
I keep thinking that the next hub update is surely going to fix the issue, but it never seems to.
1 Like
Hi @DustinDigital
For what it’s worth, this is the first time we’ve heard of users sandboxing their browser like that. Could we have some more details so we can see what we can do to help here. For example, what you see with the build-in login form and some logs/or a bug report number.
Thanks for the feedback! We’ll try make improvements in the v3.21 or v3.22 timeframe
Ok, I’ll go through the painful process again. I’m using Windows.
After I click “Sign in” a bunch of times quickly it pops up a webform fallback
The webform doesn’t seem to remember context, so it always asks about cookies. I enter my user name and password and the webform closes and goes back to the unity hub which shows this
If I repeat it 5 - 30 times it will eventually succeed. Closing hub with ctrl-shift-esc doesn’t seem to help. I used to be able to trick it into half logging in by opening something from the asset store in a non-sandboxed browser, but a recent update made that not work either, so now all I can do is fill out my user name and password over and over.
Other login systems that want to use the web browser that I’ve tried send you an email and then accept a number that you type in as a response. If it allowed me to copy the link its trying to open that would be half of a solution. I could copy that into my sandboxed browser. I would have to have a way to copy it back out again… or the webform could work properly. Or from my point of view the best thing would be to have it do the login authentication itself without relying on a web browser. I know there’s always a lot of rhetoric about only having one system to update, but IMO that’s countered by having a much larger failure surface if unity relies on web browsers to be functional as an application.
To me it seems like a basic security precaution to not allow executables to hook directly into a web browser. I don’t know why more people don’t do it.
Thanks for the screenshots @DustinDigital there’s definitely something misbehaving here. The error is a bug so I can slip that into the next available release. The UX changes will take longer.
Could we have the logs? Or the ticket number if you submit a bug report.
Neither did I. Best I can guess is a VM or containerizing, but it’s definitely not a normal thing to do.
@DustinDigital Are you aware that browsers themselves sandbox everything? You’re pretty much running a sandboxed sandbox.
@DustinDigital
Are you referring to deep linking? Ie URLs like steam://your-login-request?sessionId=12345... are pretty common and a standard (and safe) way to refer back to an application on the user’s system while transferring information between them.
There’s no direct hook. It practically works the same as any other URL except that it establishes a two-way communication between the browser and a locally installed application. The browser ensures this is all perfectly safe (sandboxed).
Perhaps reconsider your browser sandboxing. Unless you can name a specific security breach that this sandboxing actively prevents, you’re likely sandboxing just for the sake of “feeling more secure” rather than actually being more secure.
In any case, I’m curious how exactly you make the browser sandboxed?
I’m not sure how I would capture a log or make a ticket on this. If I click on the support button I just get this
(it would certainly be nice if it actually gave you the link so you could see what it’s trying to do)
By the time I can access a unity editor I’ve already logged in.
No, I’m talking about programs trying to shuttle traffic through your web browser. Do you know how many times they do it? My video card software tries to bypass my firewall by sending data silently through my default web browser every 2 hours. The browser lets it do this without popping up any notifications. I had to disable notifications on that event because it happens so often.
The browser has a sandbox but that doesn’t keep shady sites from exploiting vulnerabilities that get around the in browser sandbox. Sandboxie tricks websites into thinking they’ve hacked your computer but they’ve really just created files that only they can see that get cleanly wiped whenever you reset the sandbox.
I’ve been using sandboxie for years and it has saved my computer several times.
The logs are here on Windows: %UserProfile%\AppData\Roaming\UnityHub\logs\info-log.json
Thanks for sending the logs, I found the issue! There’s a race condition. Every time you clicked the login button we were resetting the challenge secret. So when you did enter the login info, the secret was stale. I’ll see if I can get this into v3.20.0 or v3.20.1
1 Like
That makes sense, the webform only appears if I spam the login button. There doesn’t seem to be a way to make it appear when I only press it once. When I did finally get logged in it was from disabling the sandbox temporarily and this made the webform come up with only one press.
