Regarding access to telephony. We hoped that fxos would get to the point where it is so hackable that users could potentially replace the dialer app with something third-party. It's a bold move, but it's proof we've succeeded in making 'the phone for makers'.
*W I L S O N P A G E* Front-end Developer Firefox OS (Gaia) London Office Twitter: @wilsonpage IRC: wilsonpage On Tue, Feb 10, 2015 at 2:29 AM, Shih-Chiang Chien <[email protected]> wrote: > Hi Paul, > > Thanks for aggregating such a huge analysis. I would like to add more > information about the unclassified "presentation-device-manage" permission. > > The API that depends on "presentation-device-manage" permission allows to > obtain the list of available devices that can be used as external display > in your home environment, so we want to make it certified-only because it > contains users' privacy information. > > Best Regards, > Shih-Chiang Chien > Mozilla Taiwan > On Mon, Feb 9, 2015 at 7:41 PM, Paul Theriault <[email protected]> > wrote: > >> Following up on the previous discussions [1] [2] I’ve been doing some >> analysis of the current app permission model for FxOS. This email is to >> start discussion around exposing APIs to web content - i.e. hosted apps and >> regular websites. I made some notes [3] and a table of all permissions [4] >> and below is a summary of observations to get the discussion started. Note >> the premise of this exercise was to explore what is possible to expose to >> websites. Im still currently of the opinion that an app signing mechanism >> is going to be needed, and we should improve our packaging model to be more >> web friendly, but I wanted to explore how far we can get without app >> packaging/signing. This email is long, but it basically comes down to 2 >> questions: >> >> 1. What APIs (or use cases) are the highest priority to expose to web >> content? >> 2. What security controls are we prepared to invest engineering resources >> in in order to make these APIs safe enough for web? >> >> == Approach == >> The web’s threat model is that content is untrusted, so existing >> privileged/certified APIs are too dangerous to expose to such content. >> APIs 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 (beyond just prompts) >> - 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. >> >> - 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) >> - Avoid fingerprinting: don’t expose unique user or device identifiers >> (especially permanent hardware addresses or private user data) >> >> == API Categories == >> In going through all of the permissions, some categories of APIs emerged, >> with each category having differing security control options. >> >> === 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 >> * once private data is public, no way to make it private again >> * 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 transferring all 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. Allow users denote “public” data which >> can be accessed by websites, and prevent access to other data (i.e. make it >> clear to users that this data is available to the web) >> * 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 >> >> ===Device Access=== >> A number of FxOS APIs 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 exposing 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. Thats just one example - I’ve >> been working with the bluetooth team to get to a point where we can expose >> bluetooth to privileged APIs but much more work is need to get even just >> bluetooth exposed to web. >> >> >> === 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) >> >> === 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? (Im not >> familiar enough with these APIs to answer this, maybe someone else can >> comment). >> >> === Audio Control === >> Audio API (audio-channel-* & speaker-control) risks are mainly annoyance >> and DoS of vital telephone services. These are likely solvable using a >> combination of granting priority for privileged/certified applications, and >> also figuring out a safe way for a user to switch audio priority to >> foreground 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 and also SMS are very sensitive - e.g. 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). >> >> Sending an SMS is a use case available via web activity. >> >> === 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? >> >> === Others === >> Theres lots of other permissions that don’t really fall into a category >> but are possible. See [3] for more detail (and please feel free to comment!) >> >> Thanks for getting this far! We’ll need to dive in to a per-api basis >> eventually but I wanted to start from a holistic approach. Suggestions >> welcome. >> >> - Paul >> >> >> [1] Can we deprecate packaged apps? >> https://groups.google.com/d/msg/mozilla.dev.b2g/Cepl-i0Epn8/GsHzE-An7o4J >> [2] Proposal: Privileged Hosted Apps >> https://groups.google.com/d/msg/mozilla.dev.webapi/pCY77YAg_i4/NoDBbEziyzoJ >> [3] Permissions Review Notes >> https://docs.google.com/document/d/1Ew5xEQYD_pBKZdoU_A986au6LiRWxjVkgb72Hj3kzUA/edit?usp=sharing >> [4] Permissions Analysis (Nightly 2.2+ permissions, 2 Feb 2015) >> https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0Ap-jgPe0UrMhdGVpcVpuMS1meVlDNmVFRFJ1X1JPbXc#gid=0 >> [5]https://wiki.mozilla.org/Security/B2G/PermissionReview >> [6] >> https://webbluetoothcg.github.io/web-bluetooth/#security-and-privacy-considerations >> [7] >> https://github.com/WebBluetoothCG/web-bluetooth/blob/gh-pages/explainer.md >> >> _______________________________________________ >> dev-b2g mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-b2g >> > > > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g > >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
