Hacker News new | past | comments | ask | show | jobs | submit login

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact