Web Apps / Native Apps

Reasons for doing native over Web:

• UI
• hardware/device integration
• Performances
• Monetization / DRM

Hardware/device integration

Two approaches

• declarative (e.g. markup, CSS)
• programmatic (APIs)

APIs

New hardware/device APIs bring new risks:

• Privacy: data leakage, fingerprinting, context leakage
• Security: increase of surface attack, social engineering

Privacy risks: Data leakage

• Giving access to mike/camera: Web page could spy a user
• Giving access to addressbook: Web page could steal user's list of contacts

→ Gate access to privacy sensitive APIs

Privacy risks: Fingerprinting

• 33 bits of entropy suffice to identify someone uniquely (see Panopticlick)
• Browsers routinely give 18 bits (UA string, plugin/font lists, screen resolution)
• Any non-gated information about the device can bring additional bits if there is variation across users (e.g. plugged audio device)

Privacy risks: Context Leakage

• Example: Network API showing type of network in usage (wifi, 3g, ...)
• Wifi → Bigger chance that user at home or at work
• Combining several hints can create unwanted profiling
• Example: Media Capture capabilities expose what audio/video devices are available
• → can profile user purchasing power

Security risks

• Write access to addressbook: can replace contact phone number with premium rate number
• With context leakage, can do more credible social engineering attacks

UI mitigation

• Prompt (e.g. geolocation)
• Integrate in workflow (e.g. input file, camera trigger)
• State indicator (camera active)
• How to keep decisions meaningful to end user?

Designing new APIs

• need informed user consent for privacy-sensitive info
• prefer integrating approval in workflow rather than prompting
• non-gated APIs should be safe (no data leakage, no context leakage, no fingerprinting)

Web APIs model

• sandboxed, with permissions granted mostly at usage time
• Goal: opening a random Web page is safe
• but difficult to deal with dependencies among permissions (ex: augmented reality game)
• combinatorial effect on development/testing
• Limits of UI approach (e.g. on mobile), esp. since one can't bundle requests

Uncoordinated approaches

Review of existing APIs and permission models

How others do?

• on desktop: free-for-all (but virus prone), or gated by administrators
• on mobile:
  • Android: sandboxed, with permissions granted by the user at installation
• trusted apps model on the Web:
  • Mozilla add-ons: curated by community (but then free for all)
  • Chrome Web store: à la Android

Extending Trusted Apps model to the Web

• model explored by SysApps
• Trusting whom for what
• Whom:
  • browser
  • service/content provider (as deteremined by origin) (but libraries?)
  • third party curators? (but how?)
• What:
  • How much hope of privacy do I have to abandon?

→ change the model of the Web

Previous W3C work in this space

• DAP policy framework (originated from BONDI/WAC), but abandoned due to lack of interest
• requestPermission() API
• Workshops: many on privacy; on APIs specifically: 2008, 2010, 2011

What do we need?

• Document known knowns, and known unknowns
• Help spread the message on known knowns
• Identify where convergence exists for filling known unknowns

Potential role of the TAG

• Cross-Working Groups/cross-technologies issue
• Further look into existing work and research results
• Identify experts on the topics
• Help convene experts task force (possibly joint with Privacy IG, Mobile IG)
• Drive work toward next step (workshop? best practices?)