Approving a screen-sharing prompt gives a website a live view of the tab, window, or screen you select. That sounds broad, but the permission is deliberately narrow in time: the browser must ask again for every new capture.
Microphone and camera prompts follow a different model. A browser can remember those decisions for a site. Understanding that difference makes the prompts easier to judge and the permissions easier to undo.
What the screen-share prompt grants, and for how long
One call, one prompt, one surface
Screen-capture permission cannot be saved for later use. The W3C specification says a browser must never set this permission to a standing granted state. Starting another capture means making another choice in another browser prompt.
You pick the surface, not the site
The browser, not the site, presents the available sources and lets you choose one. The resulting stream contains the selected browser tab, application window, or monitor. If you choose one tab, the site does not receive the contents of your other tabs or windows. As a practical rule, choose the smallest surface that contains what you need to show. Our guide to sharing one browser tab explains that choice in more detail.
No gesture, no prompt
A page cannot open the capture picker merely because it loaded. getDisplayMedia requires a recent user action and a secure context, normally an HTTPS page. Without that user action, the request fails instead of opening the picker.
Microphone and camera work differently
getUserMedia, the camera and microphone API, must get your permission before opening either device. Browsers may also let you remember that decision for a site. Chrome documents Allow while visiting the site and Allow this time choices; Firefox offers Remember this decision; Safari provides per-site Ask, Deny, and Allow settings.
That is why a call site may stop asking for your microphone while it must keep asking before each new screen capture. A remembered camera or microphone grant allows future access from that site, subject to the browser’s rules. A screen-share approval applies only to the capture you just started.
| Permission | When the browser asks | Can approval be remembered? | How to end or remove it |
|---|---|---|---|
| Screen share | Before every new capture | No | Stop the share; there is no saved approval to remove |
| Microphone | Before access, unless a site grant already exists | Yes | Stop current use; remove the site grant to require a new ask |
| Camera | Before access, unless a site grant already exists | Yes | Stop current use; remove the site grant to require a new ask |
How you know capture is live
Look at the browser interface, not only the website’s controls. Browsers are required to indicate when a camera or microphone is in use, and to show when permission exists even if the device is currently idle. During display capture, the browser also shows a sharing indicator and provides a way to stop.
What a website can never do
A website cannot:
- start display capture without a recent action from you and a fresh approval;
- silently reuse yesterday’s screen-share approval;
- choose the tab, window, or monitor on your behalf; or
- receive other tabs or windows when you selected one tab.
The Permissions API has no revoke() method. That does not make a permission irreversible. It means the website does not control the browser’s saved permission record; you manage it in the browser.
How to revoke each permission
Stopping a live device and removing future permission are separate actions.
- Screen sharing: use the browser’s sharing control or the site’s stop button. The capture ends, and there is no remembered screen permission to clean up.
- Chrome camera or microphone: open Settings → Privacy and security → Site settings → Camera or Microphone, then delete the site’s grant.
- Firefox camera or microphone: clear the permission from the address-bar permissions panel, or open Settings → Privacy & Security → Permissions and remove the site.
- Safari camera or microphone: open Safari → Settings → Websites, then change the site’s Camera or Microphone setting.
Stop the active stream to end access now. Remove a saved camera or microphone grant if you also want the browser to ask next time.
What Linkside asks for, straight from our code
In the Linkside sharing app, there are two capture entry points, and both follow a button click:
// share button (host only):
navigator.mediaDevices.getDisplayMedia({ video: true, audio: true });
// mic button:
navigator.mediaDevices.getUserMedia({ audio: true });Only a host can start the screen request. The call does not constrain the surface, so the browser presents the picker. The separate microphone request happens only when that participant selects the mic button. Creating or joining a room requests no media, and joining as a guest never opens the screen-capture picker.
The app never requests a camera. When the room interface loads, it makes one read-only check of the browser’s existing microphone permission so the mic control can show the right state; that check does not open a prompt. If you deny screen capture, Linkside returns the room to idle and explains what happened. If you deny the microphone, it points you to browser settings. The browser’s own stop-sharing control ends the Linkside share just like Linkside’s stop button.
The separate gear-check page can test a camera, microphone, or screen, but each check starts only when you choose its button. Stopping a check or leaving the page releases the device.
Permission answers what the browser may capture. It does not, by itself, answer where the stream goes or whether it is stored. Linkside prefers a direct browser-to-browser WebRTC connection and uses an encrypted TURN relay only when a direct path cannot be established. Linkside does not record sessions, transcribe audio, or analyse screen contents. What WebRTC encryption protects covers the transport side of that trust decision.
If you want to see the prompts before sharing anything important, create a Linkside room, open the picker, inspect the choices, and cancel or stop when you are done.