I'm trying to implement an application that can communicate with USB smart card reader on Chromebook.
But I got problem when claiming the interface with USBDevice.claimInterface():
DOMException: The requested interface implements a protected class.
According to other questions been answered such as:
WebUSB API protected interface class error and
USB device interface has been blocked
I know that CCID is blocked and not supported with WebUSB on chrome.
Is there any way out or will chrome support CCID class in the future?
There is no plan to remove this restriction from WebUSB. The recommended interface for hardware security tokens is the WebAuthn API.
Related
I am developing an app that makes use of Chrome's Bluetooth API. The development is highly annoying because everytime I change my code, the page reloads and I need to request permissions to connect to the Bluetooth device again and those permissions can only be granted through a manual process of clicking through an interface
const device = await navigator.bluetooth.requestDevice(options);
will trigger this (sorry the screenshot is german)
It is not possible to save and restore the permissions for Bluetooth
navigator.permissions.query({name:'bluetooth'})
this is intended to be possible someday but it's a work in progress in the chromium project.
Now I wonder, is it in any way possible to change settings in chrome to loosen a security setting to allow me to just access bluetooth without having be be granted access? Not via JavaScript but by maybe through some setting in Chrome or some sudo command I can execute?
Apologies for the very late response to this question.
I recently implemented a new permissions backend as well as two APIs that will enable previously permitted Bluetooth devices to be used.
The new permissions backend is implemented behind the chrome://flags/#enable-web-bluetooth-new-permissions-backend. The new backend will persist device permissions granted through requestDevice() until the permission is reset in Site Settings or the Page Info dialog box.
The getDevices() and watchAdvertisements() are implemented behind the chrome://flags/#enable-experimental-web-platform-features flag for Chrome 85.0.4165.0 or greater. The recommended use of these APIs is to use getDevices() to retrieve an array of permitted BluetoothDevices and then calling watchAdvertisements() on these devices to start a scan. When advertisement packets are detected from the devices, the advertisementreceived Event will be fired on the device that it corresponds to. At this point, the Bluetooth device is in range and can be connected to.
Please give this new feature a try, and file any bugs at https://crbug.com using the Blink>Bluetooth component.
We have a windows phone native app (and building for android, iOS also) which uses ADAL to get token for ex:graph. ADAL is asking for credentials for the first time.
Now inside of this native app on some frame we have a WebView control which launches another website (our own) or say login.microsoftonline.com which is asking to login again. How can I achieve SSO in this case and don't prompt login for the second time. Is there a way I can reuse the same WebView control which ADAL is using so the cookies will be shared. What are the alternatives in achieving this.
ADAL on Windows Phone does not use a WebView. It uses the WebAuthenticationBroker (WAB), a system API specifically designed to keep the cookie jar used during authentication isolated form the app itself. That prevents apps from using cookies to silently access protected resources without the user knowledge, while at the same time pooling the cookie jar across all the apps that use the WAB for authentication.
Furthermore: there is no native app to browser SSO mechanism today.
Hence, as of today there is no way of sharing SSO state between the app itself and a WebView hosted by the application.
I got a public mashup in my fiware instance. Is it possible to block the redirecting to the mobile site? (I think its not an url, I cant find a redirecting in the logs. Maybe some javascript code?)
And how does fiware/wirecloud determine if I'm using a mobile device or a desktop ?
WireCloud currently uses the user agent provided by the client to detect if the user is running on a mobile device. This detection is based on user-agents python module. This mechanism is specific to WireCloud, other FIWARE GEs can use other mechanism.
Finally, currently WireCloud doesn't allow you to disable the use of the mobile version in a general way. You can append a ?mode=classic to the URL (e.g. https://mashup.lab.fiware.org/alvaro-arranz-garcia/ckan-valencia?mode=classic) for forcing the use of the desktop version of WireCloud, but any user not using this modifier will get the mobile version when accessing from a smartphone.
Feel free to create a feature request :-)
I'm trying to interpret the Google Maps API terms of use. It says an app must be "freely and publicly accessible". But there is an exception for mobile apps in section "9.1.2 Exceptions" shown below. It's not clear to me if "for a fee" means that the app must have a non-zero price. In my case, I have a purely mobile app that would be available in app stores for free, but the full use of the app would be limited to a select set of users. The terms also say I can require users to log in to use it. Is there a requirement to provide log in credential to anyone?
9.1.2 Exceptions.
(b) Mobile Applications.
(i) The rule in Section 9.1.1(a) (Free Access) does not apply if your Maps API Implementation is used in a mobile application that is sold for a fee through an online store and is downloadable to a mobile device that can access the online store.
The ToS exception for mobile applications essentially fully excludes Android applications from both the Free Access and Public Access requirements. You do not need to to require users to log in nor do you need to provide public access to all users.
The rule in Section 9.1.1(a) (Free Access) does not apply if your Maps API Implementation is used in a mobile application that is sold for a fee through an online store and is downloadable to a mobile device that can access the online store.
The rule in Section 9.1.1(b) (Public Access) does not apply if your Maps API Implementation is an Android application that uses the Google Maps Android API.
I need a notification for the client application about an authentication problem in Chrome browser (for IE we used IHttpSecurity:: OnSecurityProblem ).
I found an experimental API chrome.experimental.ssl.onCertificateVerify but it is not working. I get error “chrome.experimental.ssl is undefined”. I added the “experimental” permissions to the manifest and enabled the flags. So I assume that this interface is obsolete.
Is there a way to get the notification in Chrome?