AdamSobieski
commented
1 year ago New markup and metadata would be useful for webpages to declare which permissions and configuration items they want to present to end-users in Web browsers' menu systems, e.g., in the menu system which opens from the lock or tune icon.
Beyond toggle-switch permissions, configuration items could be declared and subsequently provided in Web browser menu systems. The following example intends to show markup supporting extensible permissions and configuration items.
The markup, below, is a rough draft sketch intending to show capabilities including extensibility and searchability with respect to permissions and configuration items (as seen in many operating systems and Web browsers). Below, a non-custom configuration item is depicted of type color-scheme (as color scheme is a media query property) and a custom configuration item is also depicted, a-custom-item, in this case for hue.
<html>
<head>
<settings>
<permissions>
<permission type="notifications" domain="true" />
<permission type="camera" />
<permission type="microphone" required="true" />
<permission type="a-custom-permission" custom="true">
<title>A Custom Permission</title>
<keywords>...</keywords>
<description>...</description>
</permission>
</permissions>
<configuration>
<item type="color-scheme" />
<item type="a-custom-item" custom="true">
<title>Hue</title>
<keywords>...</keywords>
<description>...</description>
<select>
<option value="red">Red</option>
<option value="green">Green</option>
<option value="blue">Blue</option>
</select>
</item>
</configuration>
</settings>
</head>
<body>
...
</body>
</html>As envisioned: (1) only those permissions and configuration items declared in a <settings> element would need to be displayed for end-users, others could be displayed as inactive, and (2) only those permissions and configuration items declared in a <settings> element could be accessed with JavaScript. However, these two points might not be backwards compatible with the existing permissions system.
<settings> elements could access remote resources instead of having to provide inline content.
<html>
<head>
<settings src="file.xml" />
</head>
<body>
...
</body>
</html>JSON could be explored for these purposes.
<html>
<head>
<settings type="application/json" src="file.json" />
</head>
<body>
...
</body>
</html>Interestingly, the EULAs of pages and services can be made more readily available to end-users via the lock or tune menu system. Relevant metadata could resemble:
<html>
<head>
<link rel="eula" href="eula-2023.html" />
</head>
<body>
...
</body>
</html>Permissions and configuration items could link to one or more than one explanatory (EULA) document, to sections thereof, and/or to highlighted contents therein:
<html>
<head>
<link rel="eula" href="eula-2023.html" />
<settings>
<permissions>
<permission type="notifications" domain="true" href="eula-2023.html#notifications" />
<permission type="camera" href="eula-2023.html#camera" />
<permission type="microphone" required="true" href="eula-2023.html#microphone" />
<permission type="a-custom-permission" custom="true" href="eula-2023.html#custom">
<title>A Custom Permission</title>
<keywords>...</keywords>
<description>...</description>
</permission>
</permissions>
</settings>
</head>
<body>
...
</body>
</html>A further topic for exploration is whether and how to nest permissions and configuration items into recursive submenu structures in a Web browser menu system.
Combining the above ideas with those ideas in the explainer, it could be that a permission available through a Web browser menu system, e.g., the lock or tune icon menu system, would be required to authorize a webpage or service to enable page-embedded permission controls.
As shown in the following example, <permission> elements could also occur in hypertext documents for end-users to utilize to interact with the permissions system. Such <permission> elements could have :enabled and :disabled states. To be enabled, such <permission> elements would require the pepc permission and that the particular permission which they allow interaction with to be declared in settings.
<html>
<head>
<link rel="eula" href="eula-2023.html" />
<settings>
<permissions>
<permission type="pepc" domain="true" />
<permission type="notifications" domain="true" href="eula-2023.html#notifications" />
</permissions>
</settings>
</head>
<body>
<p>Here is a page-embedded permission control: <permission type="notifications" />.</p>
</body>
</html>
mikewest
yoavweiss
andypaicu
Introduction
The permission flow on the web is generally straightforward (varying slightly from user agent to user agent). However there are common scenarios where the user experience of this flow is not great:
Having an in-content dedicated HTML element that serves as the entry point for the permission flow would address these scenarios and significantly improve the UX of permission prompts on the web.
Read the complete Explainer.
Feedback
Please provide all feedback below.