Bugzilla

(In reply to Johann Hofmann [:johannh] from comment #8)
> Ok, thanks, that makes sense to me, though I do have to say that outside of fixing this edge case this feels really inconvenient, because it
> 
> - creates *a lot* of additional complexity and overhead for development and maintenance, I'm already very unhappy with the quirks in the initial patches, e.g. https://phabricator.services.mozilla.com/D106279

Yes, but that's not the fault of the model, which is simpler than our current implementation. I believe the current implementation is a tradeoff based on incremental design decisions with better short-term risks. I believe we can increment and remove this complexity over time. But I also think bug 1693677 works and can be landed this cycle to start testing and feedback.

> - shows permission indicators at somewhat random times from a user's perspective (they're clearly connected to a user interaction when granted after the permission prompt was accepted)
> - violates an essential piece of the privacy contract of web permissions (permissions are always controlled by the user) by making it possible for websites to control when a permission is set without any user consent or even interaction

Specifically, the two observations above are wrong. The observable permission model is simpler:
 1. Users see temporary permission starting at the point of grant, with a red blinking indicator and the words *"Allowed Temporarily"*. Its duration is infinity while capture is active. Sites see `getUserMedia` calls succeed unprompted during this time (thanks to `webrtcUI.activePerms`).
 1. When capture ends, users see the red blinking indicator turn gray (with bug 1697487 fixed), but the words *"Allowed Temporarily"* remain. Its duration is 60 minutes if capture never resumes. Sites see `getUserMedia` calls succeed unprompted during this time (thanks to `SitePermissions.ALLOW, ... SCOPE_TEMPORARY, ... gracePeriodMs`).

> I feel like being re-prompted after 60 minutes when you haven't given permanent access might actually be a feature in some regards. :|

This I disagree with. I think the heuristics need to cover sustained usage, much like a screen blanker. It might even interfere with some security camera use cases.

(In reply to Johann Hofmann [:johannh] from comment #8)
> Ok, thanks, that makes sense to me, though I do have to say that outside of fixing this edge case this feels really inconvenient, because it
> 
> - creates *a lot* of additional complexity and overhead for development and maintenance, I'm already very unhappy with the quirks in the initial patches, e.g. https://phabricator.services.mozilla.com/D106279

Yes, but that's not the fault of the model, which is simpler than our current implementation. I believe the current implementation is a tradeoff based on incremental design decisions with better short-term risks. I believe we can increment and remove this complexity over time. But I also think bug 1693677 works and can be landed this cycle to start testing and feedback.

> - shows permission indicators at somewhat random times from a user's perspective (they're clearly connected to a user interaction when granted after the permission prompt was accepted)
> - violates an essential piece of the privacy contract of web permissions (permissions are always controlled by the user) by making it possible for websites to control when a permission is set without any user consent or even interaction

Specifically, the two observations above are wrong. The observable permission model is simpler:
 1. Users see temporary permission starting at the point of grant, with a red blinking indicator and the words *"Allowed Temporarily"*. Its duration is infinity while capture is active. Sites see `getUserMedia` calls succeed unprompted during this time (thanks to `webrtcUI.activePerms`).
 1. When capture ends, users see the red blinking indicator turn gray (with bug 1697487 fixed), but the words *"Allowed Temporarily"* remain. Its duration is 60 minutes if capture never resumes. Sites see `getUserMedia` calls succeed unprompted during this time (thanks to `SitePermissions.ALLOW, ... SCOPE_TEMPORARY, ... gracePeriodMs`).

> I feel like being re-prompted after 60 minutes when you haven't given permanent access might actually be a feature in some regards. :|

This I disagree with. I think the heuristics need to cover sustained usage, much like a screen blanker respects movie playback. It might even interfere with some security camera use cases.