Description of the issue:
When my clients try to reach my teleconferencing service located on the Psychology Today Sessions platform, they are redirected to a screen telling them that their browser is not compatible and that Chrome or Firefox needs to be used instead of Brave.
**Did the issue present with [default Shields settings] YES
Does the site function as expected when Shields are turned off? NO.
Although the darn thing does not stay on the exact page long enough to lower shields. So I have shields lowered for the main URL, but can’t lower them on my specific landing page as it immediately detects the wrong browser and redirects to https://sessions.psychologytoday.com/upgrade/en-GB.html .
Is there a specific Shields configuration that causes the site to break? If so, tell us that configuration. (yes/no):
NO – Not that I am aware of. I uninstalled and reinstalled Brave for this test so should be on default settings with shields turned off (at least for main sessions.psychologytoday.com URL).
Does the site work as expected when using Chrome? YES
Also worked perfectly in Firefox.
Brave version (check About Brave):
Version 1.30.89 Chromium: 94.0.4606.81 (Official Build) (64-bit)
This is an especially annoying problem as psychotherapy security is particularly important – so I don’t want to be using Chrome! I can’t just use Firefox either for other reasons not having to do with this support issue.
I should note that I have both Firefox and Chrome locked down as tightly as I can and Sessions by Psychology Today still works.
So for Firefox:
I have “Strict” security rather than “Standard” selected.
I have “Send websites a ‘Do Not Track’ signal that you don’t want to be tracked” selected as “Always”.
Between these Firefox settings and my Pihole DNS server settings, I have their one data tracker I am able to detect blocked – and the site still works for by clients and myself. ( rum-http-intake.logs.datadoghq.com )
The location of a few settings changed in the last Chrome update but are not hard to find.
I modified his directions for Chrome security slightly:
– I set the default search engine to https://duckduckgo.com for privacy so my searches are not stored by Google, Microsoft, or whomever.
– Under “Cookies and Other Site Data” I set Chrome to block all 3rd party cookies, clear cookies and site data when you close all windows, and send “do not track” requests.
– Download the DuckDuckGo extension for Chrome at https://duckduckgo.com/app
If you guys find anything, would you mind reporting back the root cause afterwards? Spent a little time looking at this and didn’t find the exact issue, it didn’t seem as simple as a User-Agent string match, maybe it’s some broken JS.
I am reaching out to them through their email support. I seriously doubt they will be helpful as they support Chrome and Firefox – but hope springs eternal. They have a tendency to just not answer support emails, but I will post if I hear back.
Work by both of you appreciated on this issue so far.
“At this time, the userbase for Brave browser is unfortunately not sufficient to justify this however I will keep this ticket as an example for future reviews - so I do thank you for bringing this up.”
So – NO – there will be no resolution to this issue on their end.
I would like to stop using Chrome sufficiently strongly that I would be willing to pay $100-$200 to find a way to make Brave work. Any takers? I’m not sure that is anything approaching real money for security folks, but still.
This is spin by Psychology Today. Not a “user base” issue. No “extra code or support” is needed to support Brave vs Chrome, we use the exact same web rendering engine.
They’re intentionally added code to check for Brave then break. All they have to do is remove this code.
Fanboynz – Very interesting! I had not yet had a chance to reach back out to Sessions, yet I have their product manager writing me today saying she is taking this issue to their team to ensure Brave can be used in the future. Score. I’m wondering if your info above got seen on Twitter or if it was my earlier email to them?
I will write her back right now with a big piece of your note above pointing out the JS code you identified.
Response was positive – namely, that their telephony provider does not have time to prioritize testing Brave, but they will unblock it soon with the understanding that if malfunctions occur it will not be a priority.
To which I replied fine – if there are any issues, I will do some rudimentary beta-testing for them. Not expecting issues.
I checked the site, https://sessions.psychologytoday.com/michael-reeder no longer breaks in Brave.
Note, no fixes from psychologytoday.com side, the Anti-Brave code is still there. We just developed a work around for it. Is disappointing that this code exists on the site and they refuse to remove it for reasons.
a) Restarted Brave to allow it to relaunch with an update it had already downloaded.
b) Checked “About Brave” for further updates – I was told it was up-to-date.
c) Completely closed and reopened Brave.
Just tried again after manually clearing all cookies – no luck. Not sure if my settings are factory default settings.
I notice that sessions.psychologytoday.com was set as a “Sites that can always use cookies” – looks like this was the problem (at least – after the custom coding work-around was implemented). This had been set – I believe – when I tried turning shields off to see if that would help sessions.psychologytoday.com work many weeks ago.