I want to identify and authenticate a user's device permanently so that he doesn't need to authenticate again and again from the same device. How can I identify the user's device uniquely?
One approach could be to use Client IP, but there may be more than one devices using the same IP. I may use local storage or cookies but what if someone copies local storage's device identification data to a different device or sniff cookies (having the same IP)?
Is it possible to identify a device uniquely and permanently authenticate it for a particular user in a foolproof manner?
I think this is a standard and long solved problem. Use HTTPS, set http_only and secure attributes on your cookie and you should be fine, unless someone replicates the whole browser data on device, which anyway is out of your control, and hence you shouldn't bother about solving a problem that you don't have control over.
Related
WebUSB API documentation introduces new powerful feature with name "usb" to permissions infrastructure (https://wicg.github.io/webusb/#permission-api). But when I try to use permissions api to query permissions for "usb":
navigator.permissions.query({name:'usb'})
I got error:
TypeError: Failed to execute 'query' on 'Permissions': The provided value 'usb' is not a valid enum value of type PermissionName.
I use Chrome Version 83.0.4103.97 (Official Build) (64-bit) on Ubuntu. My first question:
Does permissions api support "usb" feature? If yes, what I do wrong in upper code?
Specification on WebUSB defines where to store allowed devices, but it again offered to use permissions infrastructure as I understood (https://wicg.github.io/webusb/#request-the-usb-permission). My second question:
If permissions api not yet support "usb" feature, where/how allowed devices are stored in browser? Can I programmatically get access to this storage?
Can website request user to allow permissions to group of devices (in my case by vid+pid) which not only connected right now, but also can be connected in future? In other words, I want to ask user "Please, let me work with usb devices (with this vid+pid) which you connect in a future, because I don't want to bore you with permission question every time you connect new device of particular type".
Does permissions api support "usb" feature? If yes, what I do wrong in upper code?
No. While the Permissions API integration defined in the specification is implemented in Chromium-based browsers it is not exposed through the Permissions API's query() method. This is tracked by issue 638721 but has not been a priority given the available alternatives.
If permissions api not yet support "usb" feature, where/how allowed devices are stored in browser? Can I programmatically get access to this storage?
Permissions are stored in the browser's user preferences file and internal data structures which are not directly accessible to Javascript. The only way these permissions are currently exposed are through the settings UI (chrome://settings/content/usbDevices) and the navigator.usb.getDevices() method, which only returns allowed devices if they are currently connected.
Can website request user to allow permissions to group of devices (in my case by vid+pid) which not only connected right now, but also can be connected in future? In other words, I want to ask user "Please, let me work with usb devices (with this vid+pid) which you connect in a future, because I don't want to bore you with permission question every time you connect new device of particular type".
No. It is important to the security design of the API that the user make the decision based on the devices currently connected rather than a hypothetical future device.
For enterprise managed devices the WebUsbAllowDevicesForUrls policy allows an administrator to make this type of decision on behalf of their users.
I have to create a webrtc application (using JsSIP) where the goal is only to be able to listen to the remote call.
I am searching a way to setup my JsSIP sip stack / sip session to disable the local microphone.
I want to make it that the browser doesn't ask for access to the microphone, as it is not needed.
Thanks.
Currently, it is not possible with JsSip, and to make it clear it is not possible on modern secure browsers.
The problem is not with JsSip but with the browsers, for security reasons browsers don't allow websites to access the microphone without the user permission as hackers can use this to monitor user conversations without their permission.
But I have observed from using JsSip on some browsers, the browser will automatically allow the user after permission has been giving to your site for the first time, ( at least on google chrome).
Solution
If there is a need to allow a smooth transition of audio permission-giving to your website, you should prompt your users to enable their browsers to always allow the permission. This has worked on chrome mobile and Firefox web browsers. Permissions are giving automatically.
I hope this solves your problem. you can contact me for anything with JsSip, ready to help you.
I want to use circuit as a videocall system in a B2C environment in which only the backend call agents are Circuit users (but the end-clients are not!!).
The only way I see to establish a videocall would be by creating a new conversation, get the url guest link and send it to the end-client.
This could be a “not-that-bad” possibility in a PC web portal front end….but in the case of a smartphone app (ie Ionic-Cordova) that link would redirect the end client to the Circuit app download site, forcing the user to install Circuit app which would not be accepted in the general case.
Is there any other possibility to implement a use case like this from Smartphone apps by embedding the guest connectivity in the app making Circuit transparent for the end client? Any possibility by using a pool of dummy Circuit users to be assigned temporarily to the app users?
That's a good question. There are two problems as pointed out by you.
1. SDK cannot be used without an authenticated Circuit user
I.e. the SDK has no support for guest access other than retrieving the guest access link. Workarounds are:
a) use the guest link and have the non-Circuit users join using their Circuit web or mobile client, or
b) create a new conversation each time and use a pool of users. But this workaround does not look intuitive and have actually never tried it in an app.
2. Guest users require Circuit app
Again as pointed out correctly, if going with a) above, the mobile client users would need the Circuit app to join a guest session.
Conclusion
For desktop users 1a is probably the best option. But for mobile users you'd have to try a workaround with a pool of users.
We are aware of these limitation and are looking into a better solution to address your use case. I will update this post once we have more information of the details and timeframe.
Sonos 5.5 beta seems to have changed SMAPI somehow. Spotify for example seems to know the local time of the client, as it changes its response to getMetadata("root") depending on it, but as both the Spotify uris are https I can't sniff them to see. Anyone know what has changed?
This can be done today by looking at the Client's IP address to determine their geographic location. By refreshing the catalog (via getLastUpdate) at a regular interval you are able to update the root browse as you see in Spotify, Google and Songza to provide time specific playlists or radio.
I have a requirement to allow mobile devices access to a website only after those devices have been registered, is there anyway I can get any kind of device information through javascript that would match up to a registered user or registered device without entering a password everytime someone wants to use the site.
I was hoping to register the IMEI number and have it passed to me in the mobile browser, but obviously I can't have that.
Security isn't really the biggest deal in this situation, convienance is, and someone taking enough time to spoof the system is not something I care about.