wicg / pepc Goto Github PK
View Code? Open in Web Editor NEWExplainer for the PEPC feature
License: Other
Explainer for the PEPC feature
License: Other
To separate general feedback from PR feedback from #7 I will pull out the general points of feedback in this issue. @marcoscaceres feel free to review to make sure that I have correctly captured the feedback points. I hope I have captured/summarized everything correctly.
Summary of feedback points:
In regards to the issue of prompt position, and how it might be far from where the user's current visual focus is:
There are options to address this in different ways than the explainer proposal. For example, permission requests on Apple platforms are increasingly handled at the OS level and using a modal prompt.
In regards to the issue of regret and the user not finding it easy to revisit old settings:
This might be able to be addressed at the browser level, by finding UX that makes the surface more discoverable. If the surface was more discoverable this would not be such a big issue. Native apps solve this by allowing the user to go directly from the application to the permission sheet.
In regards to accessibility considerations:
An HTML element could improve accessibility by being easier to discover and navigate to, if screen readers implement this functionality.
In regards to benefits of having an HTML button and the benefits of it being non-interruptive, discoverable and providing contextual information:
This can already be achieved with a <button>
control in today's status quo if sites wish to implement it this way.
In regards to customization options:
5.1) Allowing too much customization will make the button meaningless of extracting user intent as it can take so many forms that users will not be able to recognize it's shared purposed across various sites
5.2) Providing native text has a good chance of becoming an interop issue: as some browsers might pick different wording which might break the site's layout on those browsers. Standardizing the text for every language and every option would be a difficult undertaking as well.
5.3) The restrictions on customization might be too strict for certain developers which means they won't be able to integrate the element into their page without it looking weird.
5.4) Heuristics that try to prevent bad faith actors might not be tenable long-term as developers keep trying to find ways around them. Having to fight developers raises a red flag around the design of this proposal.
In regards to fallback option 1 (to trigger the legacy prompt flow, if the proposed verifications do not pass, e.g. if the PEPC is covered by some other element at the time of the click):
We went down this path previously with permission.request()
and we rejected that idea previously. Ultimately it would be preferrable to fix things at the API level (w3c/geolocation-api#48, whatwg/notifications#108).
Since the PEPC content is controlled by the user agent, and it should have no child elements, the parsing model will not include content or the end tag (similarly to the input element parsing model).
Adding a new void element for HTML parsing can result in new mXSS issues. Consider e.g. https://research.securitum.com/mutation-xss-via-mathml-mutation-dompurify-2-0-17-bypass/ but instead of the form
tags you use a <permission>
tag before <mglyph>
. The onerror
script would now execute in browsers where permission
is a void element (assuming a sanitizer that allows math
).
There might be other similar cases; generally, changes to the HTML parser carry some XSS risk.
I would suggest no changes to the HTML parser here. Require the end tag.
Kick off thread for PEPC discussion.
We believe these aspects of the proposal offer the most user utility when bundled. If we only improve the user intent signal with a permission element, we fail to solve for change blindness and accessibility problems for magnification users. If we only introduce modal permission prompts without improving our confidence in user intent and context we increase the level of interruption and disruption in user journeys with blocking modals about which the user may have little or no context for decision making.
It is true that allowing websites to ask for permissions repeatedly requires a stronger signal of user intent.
On the other If we only improve the user intent signal with a permission element, we fail to solve for change blindness and accessibility problems for magnification users. doesn't mean that this needs a PEPC. This is an orthogonal problem.
PEPC should not prescribe a UI for asking users for permission.
What is the purpose of the "onvalidationstatuschange" event? It seems the purpose of the validation is to prevent clickjacking and it's not clear why the site should be informed about it.
If the goal is to help with debugging of invalid states this should be handled locally in the devtools and not exposed to content scripts.
Regret: Given the challenges of permission annoyance and abuse, it is reasonable for user agents to suppress a site's future requests for the same capability when the first request is blocked. That said, our research shows that users can and do change their minds for good reasons. When they change their mind, the site can no longer offer an interface in web content and the user must search for the appropriate user agent surface. Our research shows that users often fail when trying to do so (see example 3).
It seems this problem will get worse for users who would like to revoke a permission. They will be even less likely to be aware of any user agent UI for managing permissions and sites often don't have any incentive to do so.
Even the examples are biased in this sense:
Shouldn't the second button be called "Unshare Location" or show a checked checkbox so users are aware that they can also remove the permissions here?
Per https://w3ctag.github.io/design-principles/#casing-rules, icon-style
should be iconstyle
.
Per w3ctag/design-principles#280, dismissed
and resolved
should be dismiss
and resolve
.
Note that "resolve" in web API design usually refers to promises. I'd suggest "change".
To match other HTML elements, the IDL event handlers onresolve
and ondismiss
should be on GlobalEventHandlers
, not on HTMLPermissionElement
.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.