WebKit
Page Embedded Permission Control
WebKittens
@marcoscaceres
Title of the spec
Page Embedded Permission Control
URL to the spec
No response
URL to the spec's repository
https://github.com/WICG/PEPC
Issue Tracker URL
No response
Explainer URL
No response
TAG Design Review URL
No response
Mozilla standards-positions issue URL
https://github.com/mozilla/standards-positions/issues/908
WebKit Bugzilla URL
No response
Radar URL
No response
Description
The Page Embedded Permission Control (prev Permission Element) is a new HTML element embedded into web content that allows users to initiate a permission request flow (vs. permissions api which lets developers prompt users). This reframes the current permission model from developer-push to user-pull, where we can be confident of user intent.
- Discussion at TPAC 2023 Breakout: https://github.com/w3c/tpac2023-breakouts/issues/35
- Discussion at TPAC 2023 Web App Sec WG: https://github.com/w3c/webappsec/blob/main/meetings/2023/2023-09-15-TPAC-minutes.md
- Discussion at w3c Permissions Workshop (2022): https://www.w3.org/Privacy/permissions-ws-2022/report#novel-building-blocks-for-capability-control
Sorry for the delay, @b1tr0t. I left some feedback in the latest PR. We are drafting a position but a lot of people are away at the moment so we might not be able to publish it until early Jan.
This is draft position. Unless folks object, we would like to make it our official position in a week or so.
The PEPC proposal introduces a new HTML element (<permission>) to integrate permission requests into webpages. While promising, several concerns arise, categorized as follows:
Complexity
-
UX and Design Complexity: Embedding
<permission>within UI increases design challenges, especially with browser variations potentially causing layout issues. - Security Complexity: Proposed security measures (styling constraints, timing, and position mitigation) add substantial complexity, indicating possible fundamental issues with the approach.
- Contradictory requirements: The ability to style the element means that, even with restrictions, it might be possible to make the element look like anything (and potentially obscure it entirely).
Device Independence
- Variability Across Devices and Browsers and Platforms: Different devices and browsers (e.g., Safari's modal prompts) show permission prompts differently, suggesting a need for a more device-independent approach to be taken by browsers.
Duplication
- Fallback Mechanisms: For unsupported browsers, developers must implement fallback solutions, leading to code duplication or additional layers of complexity. Because the proposals doesn’t address issues with the existing API itself, those problems remain in the platform. We should work to address those, either in parallel or instead of this proposal.
- Delineation and separation of concerns: to succeed, CPEP would need to become the primary means by permissioning would be done for new APIs. However, we are unconvinced that CPEP will provide the flexibility or sufficient developer and user experience advantages over existing means of requesting permission.
Internationalization
- Language and Cultural Differences: Ensuring that the PEPC is effectively internationalized across various languages and cultures in different browsers presents a significant challenge. These challenges might compound over time and browser versions.
Maintenance
- Updating and upkeep: Continuous updates and maintenance will be required to ensure that PEPC remains effective across different browser versions. This could lead to usability issues for users as sites cannot account for the changes being made by future browsers.
Portability
- Cross-Browser Functionality: Ensuring consistent functionality and appearance of PEPC across different browsers is challenging, affecting its portability. OS or browser conventions may dictate different layout, wording, or iconography.
Usability
- User Experience Consistency: Achieving a balance between standardized appearance and allowing customization for seamless website integration is crucial for usability. It is likely in cases where PEPC doesn’t meet the needs to developers, they will need to fall back to current means for getting permission to use an API.
While the PEPC proposal aims to address certain limitations of the current web permission model, it introduces new challenges in terms of complexity, device independence, duplication, internationalization, maintenance, portability, and usability. We are also concerned about adding yet another mechanism for requesting permission to use a powerful feature, which is something that has been rejected in the past by several browser vendors (i.e., this looks a lot like a markup equivalent to permissions.request()).
We instead suggests that we collaborate on an evolutionary approach by focusing on enhancing the existing permission request model of the web, addressing permission spam issues in specific APIs (like Notifications and Geolocation), and exploring enhancements to HTML’s user activation model.
Position summary
Given the above, we are "opposed" to this proposal as it currently stands, but would like to continue to collaborate on a solution.