Chromium for DevelopersOne-time permissions in Chrome
Alex Russell@developers Did this get reflected in the Permissions API? If not, we need to fix that.
Simeon.__proto__@slightlyoff @developers Do you exposing the temp nature of the grant via navigator.permissions.query(), having navigator.permissions.request() also trigger this UI, or something else?
@dotproto @developers Both. It should be possible to request a one-time grant and/or grants with limited time windows
@slightlyoff @developers Hm… might exposing that capability provide more entropy for fingerprint utilities to uniquely identify a user? I guess once it's rolled out that wouldn’t provide any more info than checking the UA string or version number would. Mmm, but if that data wouldn't be exposed for privacy budget reasons…
I could see an argument that the site doesn't need to know what type of grant it receives, it only needs to know what it can do in the moment, but I'm not totally sold on that
@dotproto @developers unpopular take: most of the entropy hand-wringing is nonsense because the fingerprinting vectors will only move locations, and the effort being expended on them, particularly for actions that put up infrequently use permission grants, are an absolute waste of time.
Jeffrey Yasskin@dotproto @slightlyoff @developers The UA major version is irrevocably exposed, and the existence of time-limited permissions is subsumed by it.
Justin Schuh@slightlyoff @dotproto @developers The site is asking for a sensitive resource, so it's only appropriate that it can gracefully handle any instance of non-availability. This is honestly one spot where native platforms are way ahead of the Web, because they defaulted to temporary permissions years ago—including removing permissions from apps that haven't been launched for a while. Native app developers handled all of that just fine, and users are all the better for it. There's no reason that the Web ecosystem can't do the same.
@jschuh @dotproto @developers : native didn't do "temporary permissions", it went with "permissions that expire behind your back" which, I agree, is much better. And we should have that too. I'm frustrated we got stuck in a bad place because Privacy Sandbox's good ideas got warped into a futile errand.
@slightlyoff @jschuh @developers temporary grants as described in the original article feel to me like "permissions that expire behind your back," but with the grand timespan bound to the duration of your session. Maybe extensions are biasing me, but my first impression was to associate this behavior with activeTab grants. As a quick reminder, activeTab grants are bound to a tab and only last as long as the user continues to navigate on the granted origin
@slightlyoff @dotproto @developers Android has "Only This Time" and iOS has "Allow Once". That's the textbook definition of temporary permissions, and functionally identical to what browsers are doing.
@jschuh @dotproto @developers Sorry, I should have been clearer: there's a version of this that's runtime imposed, and a version that's developer exposed. They can be introduced in parallel or serially. I was noting that Android took the runtime-imposed-retrofit route, and that I wish we had done both that, along with developer exposed config, many years ago. Half the reason to build the Permissions API in my mind, then we dropped the ball.
@slightlyoff @dotproto @developers I'm not sure I follow. If you're suggesting that the site should be able to explicitly request only a temporary permission, then yeah, I guess that would be nice.
Thomas Steiner 
@jschuh @slightlyoff @dotproto @developers There was some discussion around adding a new permission state for one-time granted permissions in https://github.com/w3c/permissions/issues/414.
Add another permission state "always-ask" (from one-time grants)? · Issue #414 · w3c/permissions
In browsers that support non-persisted permissions, or maybe doesn't support persisted ones, "granted" isn't always attainable. In these browsers, the strongest available positive signal is that th...
Mike West@slightlyoff @dotproto @developers This change is one we could do without any web-facing changes. I agree that it would be lovely to give developers more granular request options, and `.request()` with a dictionary would be one reasonable approach to that problem.
I'm less convinced that we need to expose the temporary nature of a grant via `.query()`. "Yes, you have access to X right now." is true, but is never guaranteed to remain true (users can revoke permission just as UAs can).
@slightlyoff @developers https://developer.chrome.com/en/blog/one-time-permissions/#permissions-api discusses the implications for the Permissions API.
Note that several permissions in Firefox have had this behavior for a long time, and Jan-Ivar has complained about it in places like https://github.com/w3c/mediacapture-main/issues/928. I haven't researched whether Chrome's behavior makes more or less sense than adding a new state.