5 ms·

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 th

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.

ss3000 7y ago
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 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.
- GoblinSlayer 7y ago
  3rd party cookies can be assumed to be always blocked, no need to detect anything.
  - ss3000 7y ago
    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.
exikyut 7y ago
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
- untog 7y ago
  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.

ss3000 7y ago

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 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.

GoblinSlayer 7y ago
3rd party cookies can be assumed to be always blocked, no need to detect anything.
- ss3000 7y ago
  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.

exikyut 7y ago

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

untog 7y ago
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.