>From my (personal) security-team perspective this is a fine pragmatic approach. Our overriding primary concern is whether exposing these new CSS features over insecure transport puts our users at additional risk. I don't see any meaningful privacy exposure here since these new features will be in a stylesheet that's already insecure, and style doesn't typically contain user data. There will be additional "attack surface" of course (more features ~= more bugs) but it's trivially easy for an attacker to use a secure stylesheet instead if that's required to access a buggy feature.
Coercing site authors into better behavior is a secondary concern (user safety, once removed), and some amount of pragmatism is acceptable. These features are being standardized through the W3C, and given W3C statements about the importance of switching the web to secure transport we should give those standards bodies a chance to do the appropriate thing. Web compatibility with other browsers is important given Mozilla's market share, and while we can take a stand against compatibility (and have) when there's demonstrable user harm from a feature, these incremental additions to CSS don't appear to come anywhere close to that bar. -Dan Veditz _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
