I'm trying to implement a WebAuthn authenticator with a BLE transport, for a custom authenticator on Android and iOS. However, my research regarding support of CTAP2 authenticator thru BLE support in Chrome has been inconclusive. Although caniuse states that Chrome has full support, Chromestatus seems to state that BLE support was removed from Chrome in 2020.
Due to this ambiguity, I'm unsure if I should go ahead with my implementation as I do not want to waste a whole lot of time. Which one of these are accurate? Does chrome has full WebAuthn support (which I presume includes CTAP2 over BLE), or is it specifically missing support for CTAP2 over BLE?
I worked on trying to add Chrome support for Bluetooth authenticators, and made the decision not to ship.
The deprecation only affected Chrome on Mac and Chrome OS. On other platforms (Windows, Android), Chrome interacts with the platform's WebAuthn APIs. You can pair an authenticator to a Windows machine over Bluetooth and it will be available to Chrome.
Bluetooth-based FIDO authenticators typically get paired at the OS level. Chrome only handles transports if the underlying platform can't handle it itself.
Related
Originally posted here.
I was under the impression that WebGL should work on Chrome on pretty much any desktop device, but that it may fall back to software rendering in some cases (assuming you don't pass failIfMajorPerformanceCaveat=true when getting the context). However in practice this seems not to be true for a substantial number of users on both Macs and Windows (especially, but not limited to, those within some kind of managed corporate IT system).
As far as I can tell, on all hardware/setups where WebGL is disabled in Chrome, it is possible to run it using a different browser (FF, and even IE11). I believe that IE11 only uses software and FF may be less strict with its blacklisting of GPUs, but that doesn't explain why Chrome can't switch to software when hardware is unavailable. Indeed, in some cases, overriding the GPU blacklist in Chrome does seem to work (but presumably is not a good idea).
So firstly, could I check that my assessment of the situation is correct? And secondly, could anyone suggest how to force software rendering (i.e. flags etc.) and/or point me at an issue discussing this?
Any advice would be very much appreciated - even if the process is rather involved it is still worth knowing about as it may be workable for our clients.
update:
#gman points out that there is no software emulation on Macs in Chrome, but that still leaves the question of what's going on in windows.
update 2:
(to partly answer my own question): it seems that (at least on 32bit Chrome on windows) if you go to chrome://components and see SwiftShader is at version 0.0.0, then simply hitting the update button should download the latest veriso,n and hey presto..it works. Not sure about 64bit Chrome though.
update 3:
As #Nicloas says, M59 in Chrome (to be released in May/June 2017) should fix this issue in Chrome on Windows and Linux, with Mac following later.
Quoting my own answer from swiftshader#googlegroups.com:
I'm happy to let you know that with the upcoming M59 release of Chrome, we have integrated SwiftShader to provide seamless fallback support for WebGL in case the GPU is blacklisted.
We were previously only using SwiftShader as a separately downloaded component, which indeed does not work on managed corporate systems, and required a browser restart. Integrating SwiftShader was only possible after open-sourcing it and substantially reducing its binary size.
You can test it today on Windows using Chrome Canary or the Beta channel, and specifying the --disable-gpu launch flag. Linux is also supposed to work but the libraries were mistakenly not shipped as part of the beta package, which we hope will be rectified in the next update and before it reaches the Stable channel. We haven't started integrating Mac OS X support yet, because Chrome works significantly differently there, but it's on our radar.
TLDR: Can the Chrome Bluetooth API be used on the Windows mobile platform?
I'm on a quest to find a solution for bluetooth connectivity across various platforms.
We plan on having native iOS and Android versions for our app, and a web app for other platforms (limited time and budget).
The setup of our product requires a one-time bluetooth connection to configure a wireless connection if necessary. This is fine for the iOS and Android versions of the app, but presents a problem for desktops/laptops or Windows mobile users.
The option for our device to act as an accesspoint has been considered, but it's not a very user-friendly solution. It needs to be easy enough your grandmother can set it up, and switching to another wireless network doesn't qualify.
In my research, I've come across the Chrome Bluetooth API available in Chrome Browsers starting in version 37. I'm wondering how accessible this would be for, say, the Windows mobile crowd. Or laptop and desktops running Windows, ChromeOS, etc.
Thanks in advance!
First, that api is not available to the web, it is available for Chrome Packaged Apps, which are published to and installed from the Chrome Web Store (they do not have a URL you can just visit).
Second, I do not think that Chrome Apps are available for windows mobile, though they are supported for all the desktop platforms. (Make sure that the bluetooth api support you need is fully support across all platforms, though, since there are some limitations).
Finally, there is ongoing work for an upcoming web-bluetooth api which will be available for the open web -- but that is some ways away.
Best of luck.
I'm trying to find some interesting data when comparing the extension, add-on, lists of the open-source browsers Firefox and Chromium.
What I'm interested in is the multi-homing extensions (extensions that are available on both the browser lists).
But when browsing on the Chromium extension list I found out that it was the same list as the one from Chrome.
Questions:
-Can I use every extension on Chrome also on Chromium?
-If not, where can I find a list on what extensions I can use on Chromium?.
Yes, the Chrome and Chromium codebases are basically identical (besides some ancillary functionality like auto-updates). Chrome is just a branded version of Chromium, so all the same extensions will work in both.
I investigated on this subject and found 2 articles on the subject.
What Is The Difference Between Google Chrome And Chromium Browser?
And more recent
What’s the Difference Between Chromium and Chrome?
I have strong bias toward Chromium as a developer, using it as basis for testing tools, and browser tests.
Also have substantial untruest in Googles interests.
The second article above claims that Chromium is devoid from Google backdoor data collection (spyware). This claim was not backed with tests. Further recent testing and verification is required.
We have used HTML5s navigator.geolocation and found it to be very good on iOS and Android smartphones. Now the users want the same HTML5 web app to run on a laptop with external GPS. Using Windows 7 on the laptop I just can't figure a way to share the location to a HTML5 browser (tried Safari, FF, IE, Chrome). For testing I am using a GlobalStat BU-353 USB GPS which works standalone and I have found GPSDirect (cool freeware) to feed that signal to Win7 Sensor Location Services but still the HTML5 browsers do not see the GPS.
Anyone had any luck with this please ?
I was looking for similar solution and found this: GpsGate.
It is standalone application which connects to almost any GPS device and publishes it's data in several forms including browsers (through Javascript API which in turn makes jsonp call to http://localhost:12175/gps/[getVersion|getGpsInfo]?jsonp=padding). It's not compatible with Geolocation API, but I think writing simple adapter shouldn't take much time. Another good thing is that it's Express edition is free for both private and commercial use (link).
EDIT: After some digging I found this patch which adds geolocation compatible adapter for GpsGate to some other geolocation library.
Issue 45535 is beginning to address this in the Chromium feature requests. As of Jan 5 2012, the feature has been marked as "started".
Feature request: http://code.google.com/p/chromium/issues/detail?id=45535
As long as you only need a single browser for your client solution (and not a universal solution) this will solve your problem.
A great method to start testing and keeping an eye out for this issue is to download Chrome Canary, which is usually 2 versions ahead of the Chrome release. I'm right now using v18 on Canary and it's great since I've been keeping an eye on the websocket schema changes.
You can find Canary here: http://tools.google.com/dlpage/chromesxs
I'm using gears.js and geo.js in an attempt to cover all grounds, in terms of finding the user's geolocation. So if the user is using something less than IE9, I would possibly prompt install for Google Gears, so I know for desktop, IE7 + is covered.
For the mobile devices I'm looking at geo
which covers quite a few mobile devices.
I'm wondering if there is anything which accounts for WP7 geolocation as well using JavaScript, and if there is better ways of handling GeoLocation for all devices.
Not entirely sure how Google Gears work for IE7/8 also, so any elaboration on that would be great. (I'm not assuming Gears is the only/best way forward though for non geolocation supported browsers, so any correction on that is fine!)
I ran into this today: http://geosenseforwindows.com/ it basically gives Wifi based geolocation to the Windows 7 Sensor API:
Geosense is a Windows Sensor that
provides the Location and Sensors
platform in Windows 7 with accurate
and reasonably ubiquitous positioning
information without requiring or the
assistance of GPS hardware, enabling
more practical location-based
applications and scenarios on Windows
7.
Unfortunately I don't think IE can access that Sensor API without resorting to COM calls in your javascript.
We also use the free/commercial GpsGate, which lets any browser on a Windows machine directly access a real hardware GPS device on the computer.
In answer to the WP7 part of your question.
There is CURRENTLY no way to get geolocation from in the browser in IE on Windows Phone 7. This should change when the next version of the browser is released.