Application Foundations/SecurityPrivacyNotes

---

Security and Privacy Tools

What tools do we provide (or need to provide) to developers looking to increase app security?

• WebCrypto
  • W3C Workshop on Authentication, Hardware Tokens and Beyond
• Securing the Web (TAG)
• WebAppSec
  • Content Security Policy
    • CSP Pinning
  • Privileged Contexts
  • Mixed Content
  • Upgrade Insecure Requests
  • Subresource Integrity
  • CORS
  • Credential Management
  • Referrer Policy

Review Guidance:

• Privacy Considerations
  • Fingerprinting Guidance
  • Specification Privacy Assessment
• Security Self-Review Questionnaire

• Secure Authentication
• Identity and authorization management
• Migration path assistance for http -> https deployment

What tools do others provide or work on

• Authentication
  • FIDO Alliance 2nd factor authentication
  • OpenID Connect Authentication Protocol and Formats
• Identity Management
  • Account Chooser
• Minimal Disclosure
  • Attribute-based Credentials for Trust
• Transport Security
  • TLS
  • HTTP/2
• IETF SAAG

Security and Privacy by Default

Developers and designers, like users, are often thinking "I want (to build) an app that does X" where X may be "make a purchase," "play a game," "share a photo," "navigate a car" ... Without having to add the clause "securely and privately," we should be making secure and private the easiest way to build. Does the Application Foundation encompass building pattern libraries or best practices? does it include revising APIs so their new versions are by default secure and privacy-preserving?

Plan

• Component and gap analysis:
  • Review the components we're providing through W3C (WebCrypto, WebAppSec, PING, WebApps) and describe how they fit together
  • Review additional security and privacy components from other sources (IETF, other standards bodies, laws?, other infrastructure and software)
  • Identify gaps in the security and privacy available through these components, and sketch out the components needed to fill gaps

• Threat modeling: Security and privacy depend on an understanding of the context and threats -- secure against what risks? private from whom? Threat modeling the Web architecture should help us to understand where we need additional tools to help end-users and application developers to meet their goals.
  • attacker models: active and passive attacks; targeted vs pervasive; individual vs mass-scale; heavily resourced or connected to infrastructure; script kiddie
  • use cases: application security against 3d party apps; application security against malicious users; user security against 3d party apps; user security against subverted apps; user peer-to-peer security; anonymity; end-to-end encryption; app-provider risk mitigation; trust-scoping

Research Questions

Tradeoffs: how can we design security into a composable, extensible system? Where do we set the pointer between affordances for innovation and deterministic behavior? How do we support credible assurances of privacy when the browser and web app have only partial control of information flows?

- Cross-layer security: How can we account for the fact that a secure outcome depends on the secure interoperation of elements across many layers of the stack? If an answer is encryption everywhere, how will we accommodate the performance, key management, and re-use (caching, but also remix/mash-up) considerations? related, our Secure Device Permissions proposal - How can we help build secure interactions between elements with different security models?

- Resilience against component failures: We've repeatedly seen security compromised by failures of a common piece of infrastructure (OpenSSL, bash, glibc). How can we better respond to these failures of complex stacks, when the operators at the application layer may not even realize all the dependencies on which they rely?

- Threat modeling of Web security: Security of what, from whom? How should the Web and Web standards accommodate the range of different threat models its users may operate under?

- Privacy "background radiation": When everything we do online and in sensor-rich environments generates data, often in the hands of others than the information subject, how can we respect individuals' interests in privacy? Does Dwork's differential privacy help, or do its assumptions of a trusted entity managing information aggregation not match the opportunistic databases we're generating?

- Trusted computing and openness: How can we enable users to trust their Web browsing environment? Should the browser user-agent mediate among user-controlled roots of trust? How can we grant user-override of trusted computing elements, to preserve user autonomy, without inviting phishing?

- Primitives: What's missing from the web development toolkit to enable the building of secure-by-default and private-by-default applications?

- Multiple security models: We have multiple security models and goals, yet low ability to communicate these to users comprehensibly (e.g. "secure site" labels and mixed content warnings). How do we address the often orthogonal goals?

- Security, privacy, and incentives: We can generate great ideas, but when things seem good enough (or enough folks are profiting enough from the status quo), how do we get change? Legislative changes to shift liabilities or provide safe harbors? Government purchasing standards?

- Secure upgrades: how do we do the upgrade dance securely: get people communicating using the most secure means available to them, without introducing them to new downgrade attacks. Upgrading trust roots; how do we do that without breaking old stuff.

- Multiple roots of trust: can the user-agent mediate among multiple sources of trust, where the web origin is only one?