Settings vs. Permissions

[reillyeon]

I am concerned about overloading the term "permission" to refer to other types of settings a user may want to apply to a site. The terms "allow" and "block" seem strained in this context. The user isn't "allowing" the site to launch at startup. The user is configuring the site to launch at startup. The site has no choice in the matter other than to highlight this as a setting the user may want to toggle.

Thinking of these as settings avoids adding new "permission prompts" for them. Rather than the proposed navigator.runOnOsLogin.set() method I propose a navigator.siteSettings.show() method which opens the appropriate user agent or operating system UI for adjusting installed application settings. In Chrome this would open chrome://settings/content/siteDetails?site=${document.location.origin} or the like. For a set of specification-defined settings this method could take an additional parameter which would highlight the desired setting for the user.

I think this distinction also helps avoids tying the "Run on OS Login" proposal to the "Install Time Permissions Prompt" proposal given that the latter seems significantly more controversial. It seems reasonable for the user agent to show some installed web app settings in the install prompt itself. Unlike permissions in general, these settings can be immediately relevant to the user installing the web app.

[reillyeon]

This proposal could also improve the UI for things like protocol handlers, which currently look like permissions but similarly don't quite fit that model.

[pwnall]

/cc @slightlyoff

[inexorabletash]

Storage durability is also currently modeled as a permission, but it's awkward.

[jungkees]

Thanks @reillyeon for opening up thoughts from a different angle.

About Permissions vs Settings, I feel like they are similar as both are for powerful features that need users' acknowledge and consent. But they seem to be different as Permissions on the web today are a set of user choices that developers can ask for whereas Settings are what browsers maintain (including exposing the states of those Permissions).

It seems to me that navigator.siteSettings.show() will only allow developers to just open the browser settings for what's available. I have questions with the proposed approach:

• How can we support developers who would want to enable their web apps to provide their own settings UI experience that is consistent across OSes and browsers?
• How should we drive the standardization of the capability if we defer to the browser settings?

[reillyeon]

I'm still mulling over precise definitions but I think the distinction I would like to draw is that a permission represents the user's control over the capabilities of an web app while a setting is a control over user agent behavior as it applies to the site. There is definitely some overlap between permissions and settings with regard to other considerations like privacy. For example, the 'run-on-login' setting has privacy considerations because it allows a site to observe every instance when the user logs into their system. It is not a permission however because it is the user who requests that the application run on login, not the application.

• How can we support developers who would want to enable their web apps to provide their own settings UI experience that is consistent across OSes and browsers?

I think it is reasonable to limit the extent to which web apps can provide their own settings UI experience. We see this pattern applied on other platforms for which sensitive settings must be configured through a trusted UI that the application can trigger programmatically. In my proposal the show() method takes an optional parameter which is a suggestion to the user agent that the user should be directed to a particular setting. For example, this could open the settings UI and highlight the "Launch this application when I log in" toggle,

navigator.siteSettings.show('run-on-login');

I think this is a better user experience than an model in which modifying each setting requires its own prompt.

• How should we drive the standardization of the capability if we defer to the browser settings?

Like permissions, settings and their desired behavior could be standardized. To take 'run-on-login' as an example the specification could read,

This specification defines a setting named 'run-on-login'. When this setting is enabled the user agent must run the window open steps with the start_url from the web application manifest.

[dominickng]

@reillyeon brings up a really good point here. We also tried to remodel beforeinstallprompt on the web app manifest spec as a permission a few years ago as that is conceptually a permission allowing the site to show an installation prompt. It ended up being far too awkward to implement (it was a "permission" to show a permission prompt).

In general, just because it kind of looks like a permission doesn't mean we should shoehorn it into the permissions API. A question I like to pose is "does this permission make sense if queried from a non-installed context?". If the answer is "no", then I usually feel that it's a poor fit for the permissions API.

[carlosfriasand]

@reillyeon, @dominickng,
Thanks for bringing this to our attention. After careful consideration on the "setting vs. permission" topic and on reflection, we agree with you that this is indeed a better way to expose the Run on OS Login capability through the Web Platform. This is, using the site settings API approach as you mentioned previously.

We plan on moving toward this direction of controlling Run on OS Login through site settings as soon as more details on these new site settings APIs (navigator.siteSettings.get() and navigator.siteSettings.show()) become available.

[reillyeon]

We plan on moving toward this direction of controlling Run on OS Login through site settings as soon as more details on these new site settings APIs (navigator.siteSettings.get() and navigator.siteSettings.show()) become available.

To be clear, these APIs will need to be designed. This was a suggested direction, not an existing project.