WebSocket sometimes fails to reconnect until browser restart or website access from incognito mode

[davidhq]

Description

Websocket sometimes fails to reconnect. Only solution is to access the website in incognito mode or restart the browser.

WebSocket is closed before the connection is established.

Steps to Reproduce

1. have a tab open
2. close the laptop lid, reopen and reconnect to wifi
3. websocket stays disconnected and keeps retrying to reconnect with no success

Actual result:

websocket keeps trying to reconnect but it is not able to

Expected result:

Should reconnect

Reproduces how often:

Intermittent issue

Brave version (brave://version info)

Latest: Version 1.23.71 Chromium: 90.0.4430.72 (Official Build) (x86_64)

Other Additional Information:

Miscellaneous Information:

[aguadeowo]

+1

[markg85]

Create a site with a websocket connection. Probably best to use your own server for this. Rapidly refresh so you get lots op closed before open.

Now enjoy waiting, what seems like, forever till any websocket connection is established again. Entirely depending on how long you kept refresh bashing.

Something somewhere now blocks the websocket connection. I'm 99.99% confident that this is in the browser itself. Why?

• open the same site in a different browser: works
• close the browser and reopen: works

Now this specific test isn't what's reported here. You don't even see the socket error message as that is gone before you can see it due to the refresh. But... It does provide.a stable point to search from. Suffice to say, rapidly opening and closing a socket connection is what's going on here and is causing a weird timeout to kick in. If a site (without refreshing) does the same behavior (rapidly opening and closing a socket) you'll likely have the very issue that is reported here.

[babashark]

please help.... >_<

[rroller]

This is happening to me when using Brave to access Frigate (Live streams from cameras stop working) and Unraid (CPU stats stop working which are driven from a ws)

[jokaorgua]

@brave-dev

are there any plans to fix this?

[cheald]

I've been experiencing this in local development. I am using Vite, which uses a websocket channel to do hot module reloads. When the websocket connection breaks, my hot reloads stop working until I restart Brave, which is a serious bummer.

https://github.com/brave/brave-browser/issues/19990

I do tend to keep a large number of sites open, and who knows how many of them use websockets. I closed a bunch of tabs, and my websockets immediately began working again, which suggests to me that this is a global pool limit of some sort.

My development happens against localhost:port, and I don't have Brave's shields on for localhost, but it doesn't seem to matter either way.

My running suspicion is that another of the sites I use is exhausting the websocket pool, and closing a bunch of tabs closes down whatever's exhausting it, but I haven't validated that yet.

[rasa2k]

Just spent 10 hours debugging/rewriting some backend/frontend application socket connection, due to issues of not being stable. I just found this ticket and started testing my socket issues in "edge" (of all the browsers) everything works. This is definitely an issues in Brave.

[Inlustra]

Do yourselves a favour and move to ungoogled-chromium. More of the privacy, none of the pain.

Appreciate that a lot of people have been saying that they have issues with their users using Brave, I guess all you can do in that situation is ask your users to stop, add a banner to your webpage explaining that you don't support Brave.

I've been subscribed to this issue for over 2 years and will finally be unsubscribing from it.

[acnebs]

@Inlustra I'm fairly certain this is actually an upstream Chromium issue – I've also noticed it happening with Electron apps and similar. I think you'll eventually see the same things in ungoogled-chromium when you've spent enough time with it.

[markg85]

@Inlustra I'm fairly certain this is actually an upstream Chromium issue – I've also noticed it happening with Electron apps and similar. I think you'll eventually see the same things in ungoogled-chromium when you've spent enough time with it.

Any chromium-based browser seems to have this effect.

This is just speculation on my part but i would not at all be surprised if this, as in the actual root cause of this behavior, is a security feature or done for security purposes. Why? Most my developer annoyances with chrome eventually end up being "security" related. Can't load resource from server (cors, had to fix headers), can't load site as file (had to spin up a server so it's localhost instead of file://...), etc...

It would be super if some knowledgeable about the chrome code could dive into this one.

[pejrich]

@markg85 those things you mention are legitimate security concerns. CORS is in place to stop JS code making requests as a signed in user to a website that is expecting requests only to come from itself. The inability for the browser to have free reign on your filesystem is equally a valid security measure. Are these things sometimes annoying to work around? Sure, but nevertheless the are completely valid and sensible security concerns. They are there to stop very real, and very easy attacks that would exist if they weren't there.

Randomly breaking websockets on a regular basis however is NOT a security feature.

[Inlustra]

@acnebs @markg85 I've been using ungoogled-chromium for the past year and haven't seen the issue at all, and I leave my browser windows open for weeks in code-server (I was experiencing this issue weekly in Brave)

My personal dashboard uses Websockets, they're open on every new tab. I use code-server, also driven by websockets. I use Unraid, Frigate, all of which are powered by websockets. If there was an issue in Chrome or ungoogled-chromium, I would have noticed it already.

Not saying you're wrong, I did see this issue in Vivaldi too in my hopping for a replacement, so it's likely a chromium issue, but Chrome and ungoogled-chromium has this fixed, at least from my anecdotal evidence. Would be good to see if anyone else can reproduce in these browsers.

[markg85]

@pejrich Thank you for your analysis but that's unnecessary.

I hadn't put more thought into it other than to go by my own grievances. But apparently that provokes actually answering why the cause of those grievances exist, that wasn't the point at all.. The point is that i assume - without knowing - that a security mediation at some point in time had an effect on websocket behavior. Like DOS/DDOS protection could very realistically be a thing. I think, couldn't find the actual limit though, that even pressing F5 (or CTRL+F5 or SHIFT+F5) has a max limit of refreshes it allows you to do per second to prevent flooding.

The issue here resembles DOS/DDOS so it's only logical to assume some preventative measure in the browser itself is affecting this.

[pejrich]

@markg85 You mentioned those two specific examples or CORS and file system access followed by "security"(in quotes), as if to suggest that they are not actually security features, when in reality they are in place for a very good reason. If my comment correcting your inaccuracies is unnecessary, then what pray tell is the necessity of your original comment?

[markg85]

Hi @pejrich, I'll happily explain it! We are drifting off-topic though, sorry for that.

To me CORS is a security measurement that frustrates development. Why can't i do local development if my URL is file://? It can be assumed that i'm working on my local filesystem so why throw in CORS to ruin it? That - note the file:// in the URL bar too! - is just pointless security nerfing for no reason as running it on a localhost webserver is merely a step to satisfy the browser.

I genuinely hate CORS because there are some sites that provide json data that is meant to be fetched but them not having setup CORS correctly makes that hard. So i made a "cors proxy" site that wraps a request in a CORS request and fetches the data behind the scenes outside the browser to circumvent such ill configured sites. It's frustrating that the browser decides to block a request in such cases. In my opinion the browser should stay out of my way and let me do what i tell it to do. If a site doesn't like that then they should fix their server settings to prohibit it. Now it works like this: "hey, i'm chrome, do you allow me to request this info? No or you don't know? Then i'll preemptively block the request for my user!" while i want it to be: "hey i'm chrome, give me the data for this resource. Not blocked? Sweet, here's the data!". Or to put it differently, i think CORS should be server side configuration that, when configured, is something the client listens too. No CORS on the server should be a free unobstructed fetch.

I'm not questioning the protection CORS offers, i just find it to be too strict.

The point of my original post was to highlight my educated guess that looking for security related measures along with websocket connections could well be a cause of the symptoms we're seeing. It's a "I've got a hunch" starting point that might be useful if someone decided to take a look at the code.

[pejrich]

@markg85 You seem to fundamentally misunderstand why these measures are in place.

If the browser were to simply assume that because you opened a local HTML file, that it should serve any local file, then merely getting someone to open an html file on their computer(which by default would open in the browser) would be enough for me to copy the entire contents of their hard drive and send it to myself. I think it's safe to assume that not everyone who deliberately or accidentally opens an HTML file wants whoever wrote that file to have access to their entire computer.

And your "CORS bypass" proxy is not in any way bypassing CORS protection. Sure, you might be able to access the information on the server, but CORS isn't merely there to stop you accessing the information on the server, it's there to stop a request to that server looking like the user made it. After all, any requests in JS are coming from the user's browser. If they just logged into their bank before visiting my website, then my site makes a JS request to "bank.com/transfers?amount=1000000&to=MY_ACCOUNT_NUMBER", the browser would include the users cookie and to the bank it would look like a request from the user. Your "CORS bypass" has no such issue since when you request the CORS bypass server, the browser won't be including a cookie for the website you ultimately want to access, and therefore there's no security risk.

It's best to understand why these measures are in place before you just assume they exist only to annoy you, or that merely because they annoy you, that they're therefore "too strict"

[markg85]

@pejrich There is a persistent misunderstanding here. I dont't mean or imply to say that a local file:// site should allow fetch('file://...'). No, just no! That would be a severe security failure, i can totally see that and i'm not advocating for that at all.

What i mean is that running a site (we're just talking about html/css/js from the same folder) from file://... should relax cors rules as-if you run on localhost. Hope that makes more sense

After all, any requests in JS are coming from the user's browser. If they just logged into their bank before visiting my website, then my site makes a JS request to "bank.com/transfers?amount=1000000&to=MY_ACCOUNT_NUMBER", the browser would include the users cookie and to the bank it would look like a request from the user.

My understanding is different. I wasn't aware a CORS request also sends a browsers cookie. In fact, i'm fairly sure that's not happening when you use fetch. I just want to send a fetch request to something, it should allow that. It doesn't because of cors so cors is getting the beating for being too strict. Please do explain the cookie case as it seems like an edge case to me. And in that mindset it seems like insanity to let the browser block a request just to handle a possible nefarious edge case. The browser knows a lot about cookies (like who placed them) so why not use that knowledge in requests to allow or deny even getting the cookie? This to me all smells like a "fixed the symptoms, not the cause" case. But then again, i might be completely misunderstanding it so i'd happily hear your thoughts on it!

It's best to understand why these measures are in place before you just assume they exist only to annoy you, or that merely because they annoy you, that they're therefore "too strict"

It is surprisingly difficult to find the actual reasons for CORS. All i can find is "because of security" and some include very minimal example usecases. It's hard to find a true in depth explanation of the actual symptoms cors was meant to fix. You're doing a better job at that then most of the results i could find! Thank you for that :) (even though we drift off-course from the topic, feel free to mail me instead (email is on my github profile).