I’m splitting this off into a new thread since this seems to be a big change.
Context from old thread: > On 5 Apr 2015, at 12:12 am, Jonas Sicking <[email protected]> wrote: > >> >> Permissions >> >> If we want to grant permissions to apps which are not installed, I think we >> need to at least re-visit all the permissions which have the default granted >> permission as "Allow" [4]. > > Indeed. > >> Currently our permissions system assumes an >> implicit level of trust from the user from the act of installing an app. >> Allowing a permission to be used simply by navigating a web page removes >> this implicit opt-in from the user and puts a lot more responsibility on >> code reviewers at Mozilla. > > I don't agree with this. We never intended the act of installing as > something which the user should think of as making a security > decision. I.e. the user was never intended to think "is this safe" > before clicking the "yes" button. Which is why the install UI doesn't > inform the user of anything security related. I completely agree with your proposition that linkable apps should be a priority since its one advantage the web has over incumbent app models. But there’s a number of security-related issues we will need to address. 1. Implicitly granted APIs For complex APIs installation IS actually the point at which the user grants permission (even though we don’t actually surface the exact permissions that are being granted). Marketplace reviews privileged apps to ensure permissions are appropriate and used responsibly (insofar as this is possible). There is still an implied permission grant happening here though - the user is saying “I want this app and functionality it provides”. (which is obviously not the same as the web). To put this another way - lets say you have a file-sharing app that announces it’s presence to the local network using the udp-socket permission. Any website could start this app just by embedding it, maybe against the user’s wishes. Or maybe they start the fm-radio tuner in the background without your knowledge draining your battery. We can probably mitigate against this risk on a per-api basis (as suggested above). But the list of implicitly granted permissions is large: audio-channel-alarm, audio-channel-content, audio-channel-normal, audio-channel-notification, browser, desktop-notification, embed-widgets, feature-detection, fmradio, global-clickthrough-overlay, homescreen-webapps-manage, input, mobilenetwork, moz-attention, moz-audio-channel-ringer, moz-audio-channel-telephony, push, settings:wallpaper.image, speaker-control, storage, systemXHR, tcp-socket, udp-socket 2. Vulnerabilities in apps affect ALL users of FxOS The combination of no-installation and deep-linking into apps creates has a multiplicative effect for risk for our users. Currently if an attacker finds a security bug in an application on marketplace, that bug only affects the users that have chosen to install it. Without installation, this bug affects ALL FxOS devices. This is the one that scares me the most TBH. Especially when you couple it with remembered permissions. 3. Existing apps may not be safe to link to (but we should fix this anyways). I sent this internally, but copying here for wider exposure….As it turns out, 16 of the 38 apps in Gaia use URL as a state mechanism - most are not security issues, but some clearly are (e.g. lockscreen bypass based on location.hash) More details here [1] For Gaia we have this risk regardless of the install question, so we need to remediate apps it if we want to support deep-linking. Hopefully this problem doesn’t extend to privileged apps already in the marketplace but its something to keep in mind. It would be great if app owners could comment in [1] as to whether this is actually an issue or not - I think mostly it just allows setting certain view state, but its not an issue I’ve personally reviewed gaia for in the past, and I’m worried that there is a bigger risk here. [1] https://docs.google.com/a/mozilla.com/document/d/15OwJq0QOQykw01LL_RpvzzdWFktOA-PcJqvtyo3jQQE/edit#heading=h.dqb20z6zsamz <https://docs.google.com/a/mozilla.com/document/d/15OwJq0QOQykw01LL_RpvzzdWFktOA-PcJqvtyo3jQQE/edit#heading=h.dqb20z6zsamz> 4. How to handle things like web activities? Apps register to handle a certain activity upon installation. Without an installation step, at what point would we register? Would we prompt the user ? That seems painful, but otherwise I’m not sure how we can manage it. Maybe less intrusive doorhanger/toast style prompts. Same goes for push messages etc etc.
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
