A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Performance & Privacy Restriction Modules

stuartpb
2015-01-27

(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.)

stuartpb
2015-01-27

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).

tabatkins
2015-01-27

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.

stuartpb
2015-08-07

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.

stuartpb
2015-09-29

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