Performance & Privacy Restriction Modules

(Apologies if this is a little awkwardly stated, it’s almost 3 AM and I’m on vacation so I’m trying to keep it brief.)

Some CSS features like ::selection have a whitelist of supported rules to keep them performant and/or secure. (I believe ::selection doesn’t support background images because it is considered a hole that would allow easy spying on user activity, and doesn’t support many other rules because they would trigger a reflow.)

I think it’d be better if all of these features pulled from common pools of restrictions (ie. all rules that don’t support loading assets from a URL have the same fallback behavior).

This would also help manage some of the overly-broad spec amputations made in the name of perf / privacy (eg. disallowing all images when it’s really network requests that are the problem).

(This was originally named CSS Privacy & Performance Restriction Modules and filed under CSS, but now that I think about it, these kind of restriction concerns are present in more standards than just CSS.)

3 Likes

This would also be a great basis for standardizing the way that private browsing modes work (stating that certain features are only subjected to privacy-based restrictions in private browsing mode).

Yeah, the main reason we haven’t codified that kind of thing yet is there hasn’t been enough cases to bother generalizing. Now there probably is.

I think this rationale could be included in whatever abstract document is used to define Security Restrictions, as something each of these kinds of things could link to for the edification of content authors.

Now that we have WICG for advancing this stuff, I’ll see about putting a draft repo for this together.