I’ve posted a few topics that touch on discussions pertaining to security, describing various combinations of increasing and/or relaxing constraints in the service of safety and privacy:
- Canvas “clear taint” permission
- Rethinking cookies
- Synchronous WebCrypto
- HTML Server Relief: Password Input Attributes for Client-side Hashing
- API for requesting explicit permission to ignore security policies
- Performance & Privacy Restriction Modules
- Suspicion-based counter-fingerprinting
I’ve also posted replies in some threads on topics that I feel are safety-and-privacy-related:
- Wake Lock API (suppressing power management/screensavers)
- Getting rid of cookie warnings
- Programmable tab context menus
- Interrogate default outgoing XMLHttpRequest headers, i.e. Accept-Encoding
And, of course, there have been other great topics on security that have been outside my field of interest, over my head, or above my ability to meaningfully comment:
- Getting a little bit formal about securing all the Web
- Is “HTTPS Everywhere” harmful?
- Write-only input fields
- Disable “show password” if autofilled
- Credential Management suggestion CertificateExchangeCrendential type
What I’ve been gesturing at with the topics I’ve posted, more than the specific mechanisms I’m describing, is that there are approaches not yet explored on the web platform that strike a better balance between keeping users safe, being paranoid as a platform, providing low intrusiveness for user freedom, and providing high capability for web-platform apps, than the cross-sections we’re currently holding.
I feel that these not-as-outstanding-as-they-could-be solutions stem, to an extent, from discussion of these kinds of concerns having been limited to the one-aspect-oriented thoughts of a handful of spec participants in the past, and that WICG should be a place where users can participate in that discussion, providing thoughts (and understanding the concerns!) in this space that might give us somewhere better, as a web community, to head toward.
I think it’s important that we tackle these security concerns from all sides (not just slamming the door at “that would be insecure”) because, to my mind, it’s all risk: if the platform doesn’t allow something users/authors want in the name of “security”, users/authors often just gravitate to something that does - and that’s frequently a platform that will introduce them to more vulnerabilities than if they’d just been exposed to the little bit of risk in the first place. (I believe this topic made some similar points.)
(Of course, there should still probably be a trusted private channel the public can disclose platform-wide vulnerabilities in the live web to, but that’s out-of-scope considering that this Discourse is primarily focused on proposing changes that, when locking down an existing behavior, are known widespread problems some parties have become accustomed to, like tracking cookies.)
