BrainstormPrivacy
Privacy reviews and self-reviews
- PING conducts privacy reviews, inviting participants to
- Complete the Privacy self-review
- Join a PING call to discuss issues
- Review specs and their privacy considerations sections
- Recent reviews include Performance APIs, Web Annotation, Data on the Web Best Practices, WebRTC/rtcweb (Media Capture and Streams), High Resolution Time, Battery Status, Presentation API
- Pending reviews: HTML5.1, Web Payments
- All newly adopted charters include specific requirement for Privacy & Security Considerations
- Tracking Protection
- Chartered 2011; current charter expires June 31, 2016.
- 2 Candidate Recommendations: Tracking Preference Expression and Tracking Compliance and Scope
- Little interest from group participants or from Websites in adoption (only 4% of sites OTA surveyed responded to the DNT signal).
- Suspending the group pending further interest, and moving discussion to PING.
- WebAppSec
- Secure Contexts, a WebAppSec/TAG joint product, enables us to make better privacy and security requirements of new features by mandating that they operate only in secure (HTTPS) contexts, thus enabling the including site and its users to assure their integrity and confidentiality.
- Permissions API offers users better control of WebApps' access to their devices and information through standard access to permission dialogs and revocation.
- W3C and IETF work on cookie scoping, sub-domain origins.
- WebAuthn (FPWD)
- An alternative to phishable passwords; uses strong cryptographic keys stored on local "authenticator" devices. Keying material is never revealed. WebAuthn is origin-bound authentication, to guard against the leakage of identifiers or activity across sites.
- WebCrypto (CR)
- Enables privacy-preserving use of strong crypto, e.g. Signal Desktop
- Analysis: Feature development with privacy considerations and support has been more successful than privacy-centered spec work. (Note also P3P's limited uptake and obsolescence.) Privacy can be a feature too, but unfulfilled promises of privacy, or features whose privacy impact depends on multiple parties, expose contradictory incentives: some parties want to enable users to choose privacy, while others want to defeat that choice. That suggests focusing new work on places where unilateral action can improve privacy, or privacy can be supported at the specification and architecture level by committed implementers.
Possible new work
- DANE: support more narrowly-scoped delegation of signing authority over domain names and associated Websites. Use DNSSEC-authenticated TLSA certificates for HTTPS, just as they can now be used for other protocols including SMTP. What are the barriers? Do TLSA certificates need to be logged in certificate transparency (CT) logs? (And is that a barrier?)
- Delegation of authorization: How can users share and revoke privileges without sharing credentials? (Use case: user wants to share access to some account with family member.) Do mutli-site credentials (e.g. U2F tokens, Yubikeys) make this a bigger problem?
- Private browsing mode consistency: would user expectations be better met if incognito mode, private browsing mode, etc. behaved the same across browsers?
- Private browsing mode for servers: Most users believe that PB mode protects them at the server, whereas servers are currently unaware. How can we extend PB mode to servers (e.g. the 'persona' idea)?
- Signed statements of compliance: Can we 'even the playing field' by enabling users to state "I will only let you have <this> data if you promise to comply with at least <this> policy?" and sites to offer "I only need <this> data and if you let me have it I promise to comply with <these> policies"?
- Containers / profiles / private browsing mode: Many browsers now provide ways for users to segment (sandbox) their usage. Can standards work from the best practices of these implementations to improve the consistency of this experience for users and Webapps?
- e.g., allow sites to "hint" that they would like to be opened in a sandbox / private browsing window.
- Captive Portals: we've heard reports of captive portal (e.g. hotspot) operators attempting to make sandboxed login windows (e.g. on iOS) not work - they want access to a more capable sandbox (and to users' identifying information for ad targeting). But there is a high chance for sensitive data to leak in this mode (e.g. autoloading many tabs). Would providing a richer, video-capable sandbox help? Is there anything to standardize here?
Questions for the AB
- What else? Who else? How should we move forward? What should we cut?
- How should we incubate privacy work?
- Anything we're doing that's dangerous?