Permissions for Web Applications

W3C TAG F2F, April 3rd

Dominique Hazaël-Massieux

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)
Web Intents
But difficulty with transcluded content, phishing, etc
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 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)

How others do?

on desktop: free-for-all (but virus prone), or gated by administrators
on mobile:
- AppStore: curated by Apple (but then free for all)
- 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
- proposed new W3C work on "system-level APIs": no sandbox

Extending Trusted Apps model to the Web?

Abandon hope all ye who enter here
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; Webinos exploring this further
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)
Drive work toward next step (workshop? best practices?)