Possible Intention Signal stronger than a simple user-gesture requirement

[Trapfether]

Users want to enable certain web features, developers want to make that process simple, while browsers want to mitigate spam and anti-patterns designed to exhaust or trick users into granting permissions they do not truly wish to give. This is an initial discussion on better ways to accomplish these goals.

Background

Some web features enable invasive or possibly exploitable access to users. In particular Web Push and PWA installation. Especially with Safari Mobile getting ready to release Web Push. They have made the choice to lock Web Push behind an installation requirement, which will strengthen a site's ability to persuade users to install the site and give them elevated access to the user in ways unrelated to Web Push. This is likely to avoid the current situation that plagues Dekstop Safari and every other browser. The pervasive user prompts that annoy users every time they land on a page. The metrics and approaches that have been used to date are insufficient to protect users from this annoyance on sites they wish to not be annoyed by and were the main reason for Apple refusing to implement Web Push until the EUs current regulatory stint.

Idea

Users need a simple way to enable these features when they want to but avoid being annoyed by them until such time. The objective is to make non-annoying enabling easy and annoying prompting painful and unreliable. This is driven by the fact that I have to date not found a use-case unilateral prompting.

One proposal is that sites can publish a manifest (or it can be part of the PWA manifest) that specifies an HTML classname. The browser will intercept pointer-down events on matching elements prior to any client-side scripts running and prompt the user whether they are sure they wish to grant that permission. If the user grants that permission, an event will be triggered on the document object that the site can subscribe to and respond to. In particular, the browsers are able to trust this event more because of the metrics they can implement surrounding it. Currently, prompts are triggered by client-side javascript and browsers implemented a basic user-gesture requirement to attempt and alleviate abuse. Because the browser does not know which elements will cause the function call to the permission prompt, they have a hard time implementing additional metrics. Those Metrics that I foresee as compatible with declared elements are:

• Screen Coverage: How much of the screen do the element(s) cover? If the percentage is significant, and especially if it is 100%, it is ignored.
• Visibility: the element should be fully visible (not opacity:0 or occluded by visible elements with "pointer-events:none" applied)
• Reliably Stationary: the element should seldom move in relation to the document. a lower-effort metric is "last moved at" that can ignore the event if the button moved too recently (this is pretty much impossible with the current approach as it would require tracking the movement of EVERY element and caching their last moved at timestamp as we don't currently know WHICH elements will cause the prompt)
• Text Content: the element should have relevant text content that describes the permission that will be granted
• HTML children: the element can have HTML children such as SVGs for icons and TexNodes, but other types of HTML Elements could be disqualifying
• Other metrics as browsers deem appropriate. Though they should facilitate most legit use-cases. Static buttons, Buttons in modals, Buttons in flyout menus, etc.

If browser makers are too worried about the performance implications of monitoring "random" elements provided by the developer, these buttons can also be implemented as new standard HTML elements that are browser-implimented and can do this tracking / diagnostics within the element itself. The element could even go so far as to enforce overflow:hidden to guarantee that it can't have internal content that breaks out of it's borders to try and capture unrelated touch events.

These approaches would enable less annoying but simultaneously convenient access to the user's ability to enable web features such as Web Push, PWA installation, Geolocation, Local File Access, etc. Give the user a button on the site that they can click to enable said feature and measure that button to make sure it's not doing anything untoward.

Concerns

The methods that unscrupulous developers may use to try and trick browsers and or users are ever-changing. There may be gaming methods already in use that I am unaware of that circumvent these proposed metrcis. The metrics browsers use to stamp-down on misuse will need to change over time to keep up.

Final Thoughts

A stronger user intention signal can go a long way to alleviate wayward prompts. This can pave the way to a more user-friendly web in the future, allowing users to more easily trigger the events / features they want while ignoring the ones they don't.