Hacker News Reader

Comment by anilshanbhag | Hacker News Reader

The trigger for this was most likely the Brave/Vivaldi browsers. Brave used to 'Brave/X.y' at the end of user agent. Whatsapp didn't work with that useragent. Now Brave uses Google Chrome's useragent.

In my app Dictanote (https://dictanote.co) - which uses Chrome's speech-to-text API, I have no way to distinguish Brave/Vivaldi and user doesn't understand why its not working :/

View on HN

Shouldn't you be using feature detection[1] here anyway? Making browsers unsupported in a blanket fashion via user-agent is the exact thing people should stop doing.

[1] https://developers.google.com/web/updates/2014/01/Web-apps-t...

The webkitSpeechRecognition object shows up on both browsers. When you start recognition, it acts like you are not connected to the network. Not connected to the network is a common error , so you cannot fingerprint it to Brave.

This specific API only works in Google Chrome unfortunately. So we need to stop people from trying in another browser and getting frustrated as to why its not working.

We should of course default to feature detection whenever possible, but non-standard behavior like this in certain browsers is exactly why feature detection alone is never going to cover 100% of current use cases for UA detection.

To add to OP's point, this thing in Safari also comes to mind as an example of something that isn't easy to detect and address outside of UA detection: https://github.com/vitr/safari-cookie-in-iframe

Deprecating UA Strings and moving towards UA Client Hints seems like a move in the right direction though.

3rd party cookies can be assumed to be always blocked, no need to detect anything.

Some pages are intended to be embedded in iframes (which have their own security context isolated from the embedding page), and happen to use cookies for authentication. Safari not allowing cookies from third party domains in iframes is the issue here.

Assuming these iframes will never work means degrading the experience for all users, when only users on Safari are actually affected. Detecting the UA and branching based on that is a much more pragmatic solution.

IMO Brave should remove this API, then.

- It's not likely to work anytime soon

- "The property doesn't exist or throws an exception or does something else that Chrom{e,ium} doesn't do" provides the necessary fingerprinting

- Adding the feature back later can just be chalked up to "growing pains", it doesn't really set especially unique precedent

Absolutely they should. But they haven't. Checking the UA string allows a developer to get around the issue, but once it's gone an individual developer will be powerless to fix the issue for their users.

Using user agents to detect features is the wrong way to do it because you’ll have these exact problems.

To determine if a browser has the text to speech API just check if the webkitSpeechRecognition object exists (if that’s the one you’re using). It will exist in Chrome and will not exist in other browsers that lack the feature.

> * It will exist in Chrome and will not exist in other browsers that lack the feature.*

An incorrect assumption stated as fact with such great confidence. Good job.

Even on the face of it, any engineer would know this can't be true.

Just test whether the API works or whether the properties are missing or methods throw exceptions?

The kind of testing you are complaining you can't do is exactly why user agent is broken, what if you test for Chrome and then Brave/Vivaldi start supporting the speech-to-text API and your broken website still says "sorry, you need Chrome" for no reason?

so show this as a hint in the UI :) people can still solve problems better than machines often

I can imagine the popup now:

"Somethings wrong! You might be using Chrome and having connectivity issues, or you might be using Brave who have a dispute with Google about usage of their speech recognition API. In the former case, get better WiFi, and in the latter case there's nothing you can do, switch browsers."

Reply on news.ycombinator.com