Exposing Privileges to the Web
The basic problem is that web content is completely untrustworthy, so our APIs are too dangerous to expose to such content. Current Certified/Privileged APIs can need to be made safer through a combination of:
- only exposing safe parts of APIs
- adding mitigating controls to APIs
- creating more specific APIs to safely solve use cases
- creating more sophisticated security UI
- mandating adoption of existing web security controls (TLS, CSP etc)
General Security Requirements
The following requirements are high level, and there are exceptions, but these are the sorts of things which currently prevent certified & privileged APIs from being more widely exposed.
- Avoid fingerprinting: don’t expose unique user or device identifiers (especially permanent hardware addresses)
- Prevent access to underlying OS & data - all access must be mediated by user (e.g. file input)
- Prevent direct access to local devices - access mediated by the user (e.g. navigator.getUserMedia)
- Cause system instability due to resource consumption (CPU, bandwidth, disk space, battery etc)
- Limit network connectivity to protect local networks (same-origin policy, port limitations etc)
API Categories
In going through all of the permissions, some categories of APIs emerged, with each category having differing security control options.
Device Access
A number of FxOS are created to provide access to various hardware devices: e.g. Bluetooth, NFC, Motion Sensors, fmradio, wifi. Making these more safe depends completely on the device being accessed. Relatively safe devices like motion sensors and fmradio only pose a mild privacy risk and could perhaps be mitigated user mediation (prompts). But devices like bluetooth & nfc are significantly more complex. The W3C bluetooth group has a good enumeration of privacy & security risks [5] for just BluetoothLE. The approach they have taken is to abstract away detail, and provide high level APIs which don’t have the same security risks as the low-level hardware APIs. For example, instead of exposing an API which allows control of bluetooth adaptors (like how mozBluetooth currently does) expose a service which allows connected to a remote service like “heart-rate monitor”. See [6] for an example.
Data Access
Some APIs provide direct access to local data stores, e.g. contacts, Device-Storage (pictures, video, music, sdcard). Access can be read-only or full read/write access. There are several things to consider here:
- a user might grant pictures access at a time when they don’t have any private photos, but forget to revisit that decision later after taking photos that are more sensitive
- access can permanently destroy data
- if website XYZ gets hacked, the hackers gain access ALL data for ALL users, not just the data the user has uploaded to the website. Basically the user needs to understand that by granting the permission, they are effectively uploading ALL of their data onto the app’s service.
Mitigation suggestions:
- silo data: e.g. put photos in albums, and allow users to only grant access to specific photos or albums
- make web APIs data safe: prevent overwrite and make delete “move to trash folder” instead so user can always recover data
- Provide auditing so users can trace what app access
Unrestricted network access
Some APIs provide local network access - e.g. SystemXHR, tcp-socket & udp-socket. These are very commonly requested APIs (in marketplace stats, but also anecdotally on list and dev meetups). The risk is that untrusted web code will access internal systems that were not intended to be exposed to the internet. There have been some suggestions around solving the single server access case, but the general case of allowing unrestricted network access is problematic.
Mitigation suggestions:
- request access on a single access basis. E.g. "Do you want to allow http://foo.com to make connections to http://bar.com”
- enforce anonymous access (ie no cookies, no http-auth, SystemXHR already does this)
Detailed Analysis:
Push Events & Notifications
Ability to receive push events, and display notifications to the user. We already provide access to “push” permission. Why is wappush more restricted? How do extend support to the web, not just web apps?
Audio Control
The main audio related risks are annoyances and DoS of vital telephone services. These are likely solvable using a combination of granting priority for system/certified applications and also figuring out a safe way for a user to switch audio priority to 3rd party apps. NB currently competing audio policy is only allowed between loop and the dialer and requires both to co-operate. We need a solution for hostile or poorly implemented apps.
SMS
SMS is risky mainly due to the cost involved. Risks include cost of sending SMS, SMS often used in 2-factor auth (e.g. banking)
But there are different use cases. For example, many use cases just need the ability to receive SMS - instead of granting SMS permission, we could expose a read-only SMS datastore which other apps could observe changes on which removes the cost risk (but not the sensitive data risk).
Telephony & Mobile
Telephony & mobileconnection seem more dangerous - not sure that there is a strong use case here? Thoughts? Do you really want websites making phone calls, locking your SIM card?