Questions about permissions

[lukewarlow]

I've added an integration with the permissions API and required a permission is granted before being able to requestOverride. This was in response to feedback in #27 (comment) aswell as just being a general attempt at mitigating concerns about this API. I've subsequently reverted the permission integration and replaced it with a UA defined algorithm so it's up to the UA to decide if they want a permission prompt etc.

However I am worried this will put a lot of people off using the API, permission prompts are pretty "scary" things and in this case provides little actual benefit imo.

This API doesn't really introduce any new dangerous (or otherwise) capabilities beyond that which are already possible. Aside from the very core capabilities this seeks to resolve.

[rschristian]

I'm vehemently opposed to adding permissions to this proposal.

As you mention, nothing groundbreaking (functionality-wise) is being done here -- this "simply" addresses a) the non-standard routes developers need to go in order to support this and b) the less than optimal mechanisms in which developers have to trigger this. If a a permission system were added on top, I feel that developers would be quite unlikely to adopt this over already existing solutions as those solutions offer a far better DX. The ideal, for me, is to get developers to start relying on media queries over custom .dark-like classes and reduce the amount of client-side JS needed for toggles, not for the browser to start deciding for users how sites can present content.

Until browsers have ways to force user preferences upon web content, wanting to permission-gate changing preferences seems to indicate a lack of understanding as to the modern web.

[FremyCompany]

I think different settings/overrides require different permission strategies.

Overrides go above what's currently possible by just ignoring the media query, as they disable browser behaviors such as disabling some animations and sending headers.

While some overrides such as dark theme are probably less worrying and could get away with just a UA notification that the setting was changed by the site, disabling accessibility features (e.g. reduced motion) or money-saving features (e.g. reduced data) are different beasts entirely.

My preference is that a general permission is added in case a website wants a blanket right to change all settings without UA involvement, but otherwise it should be possible to call the API without the permission and it's then up to the UAs to decide which level of involvement they want to have (e.g. just a notification of change for dark theme, but confirmation dialog for reduced motion).

[lukewarlow]

Right I think for now I'll remove the permissions checks from the algorithm and replace it with a UA defined algorithm. So it's down to the UA to decide what to do. I'm thinking if we do want a permission to say give me free reign we potentially need a new requestPermission function is needed?)

[lukewarlow]

disabling accessibility features (e.g. reduced motion) or money-saving features (e.g. reduced data) are different beasts entirely.

I already exclude the "custom" value from the contrast option. It's possible that we could exclude the no-preference option from contrast, reducedMotion, reducedTransparency and reducedData? That way the overrides can only be to enable those options NOT disable?

The case for enabling these options feels a lot stronger than the case for disabling them? #30 to discuss this

[lukewarlow]

To update this, I've removed the ability to set a "no-preference" override. So I think the case for permissions is strongly diminished as a result. The API shape is a promise such that it can be adjusted to the UAs desire.

I'll leave this issue open for now in case anyone else wants to chime in.