I want to create an smartphone in web browsers, and I've done a good job till now. However, when I call, Google Chrome shows this message:
'http://domain' the wants to use your microphone.
See this picture:
And this is a picture of my web-based smartphone:
However, when I call, user should click Allow in the Chrome's message bar. Is there any way that I ask the browser to save microphone settings for the current user, so that each time user is not asked for permission?
You need to serve your page over https. When using https, Chrome will remember the user's choice and will not ask again.
Then if the user wants to block the microphone again, they can click on the camera icon in the URL bar.
If you go to Chrome's Settings => Advanced => Content Settings => Media section, you see that there are only two options that you can choose:
To be asked EACH TIME a page wants to access your microphone or camera
To disable media altogether
Thus there seems to be no option for that. It might sound logical, as you don't want hackers starting your camera and capturing your private life without permission. ;)
Related
In this tutorial it is shown how to make browser ask user for microphone and/or camera access.
I don't need input devices access, I need user to allow site to play notification sounds. Is there a way to make a similar prompt for autoplay permissions? (Instead of giving user instructions on how to allow it).
I want to create mobile-first web-app, that will track geolocation of busses. Drivers will open site and click "track me" button. Page will use geolocation.watchposition. so I wonder, if driver will shut down display, or watch another pages in the internet,
Will geolocation.watchposition work and send geolocation in db?
Yes, if the user gives the mobile phone GPS access permission the app will track the device as long as the app is open or in the background (minimized).
No it will NOT work!
See complete example at https://github.com/RichardMaher/Brotkrumen
For the complete story of why PWAs continue to be denied this essential functionality see: -
https://github.com/w3c/ServiceWorker/issues/745
I have a PWA that works as expected when the address is entered into the Chrome browser on an Android device (Currently using Chrome 76 on Android 9). When the site is loaded I get the beforeinstallprompt event and display my installation message. However, if the site is opened from a hyperlink in an SMS message then I don't get the event until tapping on the page. Is this expect? Has anyone dealt with this issue?
As stated here, it is a requirement that the app "meets a user engagement heuristic" before beforeinstallprompt fires. Since the user came from an external link, the browser requires that the user demonstrate that they want to engage with the app that they landed on; they didn't just click a link and land there. Entering the address manually is sufficient to show engagement: they deliberately came to the site of their own accord.
It is like how a YouTube video opened from an external link will not have sound until the user interacts with it. The browser is preventing sound from playing unless the user shows that they want it since unsolicited auto-playing sound is a common annoyance for users.
I have given allow permission for Microphone in my domain. We are using our domain in multiple tabs. I am able to acquire local media (Microphone) when I am accessing in the same tab. But I am not able to acquire local media for WebRTC in the other tab(same domain) without visiting the tab .Only after visiting the tab localmedia access is acquired.
Is it intentionally done for Security & Privacy? . Is there any way to solve my problem ?
Reason: To restrict resources being used for WebRTC session. We are keeping WebRTC session in single tab for our domain and using only that resource for all the tabs to make calls.
Tried setting microphone-allow as iframe attribute . But it didnt solve the problem . It is working fine in GoogleChrome browser though. If I open a new tab(T1) and initiate webrtc in it and make webrtc call from another tab (T2)without ever visiting the tab T1 , call is connected in chrome but not in firefox unless i visit T1 .
Note : It is not asking permission for allowing microphone in the domain , it acquires it automatically . Just that it acquires only after i visit the tab .I have given microphone access permission to my domain already.
Is it intentionally done for Security & Privacy?
Yes, this is intentional to prevent background tabs from turning on the camera or mic willy nilly, to spy on users. Because that's creepy. I believe Safari works the same way.
The getUsermedia specification recently made this a requirement:
Step 6.1. "The User Agent MUST wait to proceed to the next step until the current settings object's responsible document is fully active and has focus."*
So I would expect Chrome to follow suit soon.
Is there any way to solve my problem ?
That would very much defeat the assurance.
Users can rest assured that only the currently focused tab can turn on the camera or microphone.
If I open a new tab(T1) and initiate webrtc in it and make webrtc call from another tab (T2)without ever visiting the tab T1 , call is connected in chrome but not in firefox unless i visit T1.
That's an RTCPeerConnection connection problem, which is separate from getUserMedia.
The workaround is to not block connection establishment on mic access.
There's no reason you can't connect first and add the mic later.
Or get mic ahead of time, and connect later. Basically, the two actions don't need to coincide or block each other.
I am working on a website for a women's shelter and they want a "panic button" that automatically takes you to another site. This is pretty common, but I need it to also automatically clear the cache, so the abuser can't hit the "back" button or history to see what they were looking at before being interrupted. Any ideas?
I think that the answer is "can't be done as website functionality" unless the user installs a browser plugin. For example, here's what Mozilla Development Network (MDN) says about this:
For security reasons .... there is no way to clear the session history or to disable the back/forward navigation from unprivileged code. The closest available solution is the location.replace() method, which replaces the current item of the session history with the provided URL.
Non-privileged basically means any javascript that a website might run on the browser.
Now a "panic button" plugin / add-on would be able to do this kind of thing, but:
The user has to install it. (Simple for a moderately tech-savy person ...)
If someone looks at the browser, it will be apparent that it has been installed.
There is also the issue of people how people decide to trust a plugin like this to be properly implemented, and not contain nasty stuff.
A better idea would be to educate the user in using browser incognito mode. However that still leaves traces on the user's computer (depending on your browser, and other things), and in external network logging, etc.