WebAPI Security Discussion: Settings API

[Lucas Adamski]

Please reply-to dev-w...@lists.mozilla.org

Name of API: Settings API
Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=678695

Brief purpose of API: API to configure device settings
General Use Cases: None

Inherent threats:
*Access sensitive configuration data (wifi passwords etc)
*Change settings which might cost user money (data settings, roaming etc)
*Safety implications (airplane mode? If you believe a plane can be brought down by a mobile phone...)

Threat severity: High

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code:None
Authorization model for normal content: None
Authorization model for installed content:None
Potential mitigations: N/A

== Trusted (authenticated by publisher) ==
Use cases for authenticated code: Modify a specific setting - e.g. e-book app modifies brightness in response to lighting conditions
Authorization model: Implicit
Potential mitigations: Limit access to benign settings

== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: replacement settings manager app
Authorization model: Implicit access to all settings
Potential mitigations: None

[Adrienne Porter Felt]

I'm not sure all Settings should be treated as either one of two levels
(accessible with no user involvement, or not accessible at all). I think
different Settings should be handled individually. Here are some
suggestions for a few possible Settings parameters:

-- Vibrating the phone and changing the time: Let all apps* do it, but the
default Settings app should say what app last changed this setting.

-- Changing the wallpaper or ringtone: Let all apps do it, but provide an
"undo" mechanism in Settings that changes it back to what it was prior to
that app altering it.

-- Turning the sound up or down: Let all apps do it, but have the OS throw
a short, slightly-transparent notification saying that the app is doing it
the first 5(?) times an app changes the setting.

-- Adding words to the dictionary: Only let apps do this if they are
installed as IME apps; there should only be one IME app at a time.

-- Connecting or disconnecting from bluetooth: All apps can get a list of
nearby devices. If an app initiates pairing to a new device, show a special
runtime dialog that includes information about the target device. Whenever
a bluetooth connection is active, display a Bluetooth icon.

-- Connecting or disconnecting from WiFi: Apps can connect to known
networks, or disconnect from any network. If an app is connecting to a new
network, ask the user with the standard OS prompt for connecting to new
networks. The Settings WiFi control panel should have some small text that
says what app last disconnected you from the network if the current state
of the phone is disconnected.

-- Reading current WiFi state: Any app can do this, but the SSIDs should be
treated like geolocation.

*Whenever I say "apps" in this e-mail I mean trusted/certified apps, not
arbitrary web sites.

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>

[Jim Straus]

Comments inline below

On Apr 16, 2012, at 10:24 AM, Adrienne Porter Felt wrote:

> I'm not sure all Settings should be treated as either one of two levels
> (accessible with no user involvement, or not accessible at all). I think
> different Settings should be handled individually. Here are some
> suggestions for a few possible Settings parameters:
>
> -- Vibrating the phone and changing the time: Let all apps* do it, but the
> default Settings app should say what app last changed this setting.
>
> -- Changing the wallpaper or ringtone: Let all apps do it, but provide an
> "undo" mechanism in Settings that changes it back to what it was prior to
> that app altering it.

Or have the API throw up a confirmation dialog. A wallpaper app can preview wallpapers as much as it wants (even going full screen with the wallpaper image). Then when the user asks to set their wallpaper , a system dialog comes up with the wall paper and a confirmation dialog. Similarly for ringtones. Thus these settings don't need permission control.s

>
> -- Turning the sound up or down: Let all apps do it, but have the OS throw
> a short, slightly-transparent notification saying that the app is doing it
> the first 5(?) times an app changes the setting.
>

A question on the API in general. If I set the volume for background sounds in a game, does that affect the volume of the phone ringer? I don't think it should. Also, we need to distinguish between setting volume in-app with something like a slider and using the physical buttons that most phones provide.

> -- Adding words to the dictionary: Only let apps do this if they are
> installed as IME apps; there should only be one IME app at a time.
>

Do you mean only one IME in use at a time or installed at a time?

> -- Connecting or disconnecting from bluetooth: All apps can get a list of
> nearby devices. If an app initiates pairing to a new device, show a special
> runtime dialog that includes information about the target device. Whenever
> a bluetooth connection is active, display a Bluetooth icon.
>
> -- Connecting or disconnecting from WiFi: Apps can connect to known
> networks, or disconnect from any network. If an app is connecting to a new
> network, ask the user with the standard OS prompt for connecting to new
> networks. The Settings WiFi control panel should have some small text that
> says what app last disconnected you from the network if the current state
> of the phone is disconnected.
>

I don't want arbitrary apps disconnecting my wifi. Doing so may interrupt background processes and I may not notice it for a while. Why should any app besides a Settings app need to muck with my networks?

> -- Reading current WiFi state: Any app can do this, but the SSIDs should be
> treated like geolocation.
>
> *Whenever I say "apps" in this e-mail I mean trusted/certified apps, not
> arbitrary web sites.

Do you mean trusted, certified and granted permission to use the Settings API or any trusted, certified app?

> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g

[Mounir Lamouri]

On 04/16/2012 04:24 PM, Adrienne Porter Felt wrote:
> I'm not sure all Settings should be treated as either one of two levels
> (accessible with no user involvement, or not accessible at all). I think
> different Settings should be handled individually. Here are some
> suggestions for a few possible Settings parameters:
>
> -- Vibrating the phone and changing the time: Let all apps* do it, but the
> default Settings app should say what app last changed this setting.

Vibration is a setting?

> -- Adding words to the dictionary: Only let apps do this if they are
> installed as IME apps; there should only be one IME app at a time.

I think we will have a separate API for that.

> -- Connecting or disconnecting from bluetooth: All apps can get a list of
> nearby devices. If an app initiates pairing to a new device, show a special
> runtime dialog that includes information about the target device. Whenever
> a bluetooth connection is active, display a Bluetooth icon.

I think that should be handled by the Bluetooth API.

> -- Connecting or disconnecting from WiFi: Apps can connect to known
> networks, or disconnect from any network. If an app is connecting to a new
> network, ask the user with the standard OS prompt for connecting to new
> networks. The Settings WiFi control panel should have some small text that
> says what app last disconnected you from the network if the current state
> of the phone is disconnected.

I think that should be handled by a kind of Network API.

> -- Reading current WiFi state: Any app can do this, but the SSIDs should be
> treated like geolocation.

Same for this one.

--
Mounir

[Mounir Lamouri]

On 04/16/2012 08:16 AM, Lucas Adamski wrote:
> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code: Modify a specific setting - e.g. e-book app modifies brightness in response to lighting conditions
> Authorization model: Implicit
> Potential mitigations: Limit access to benign settings

We need to have individual settings permissions for each kind of
settings. For example, if an app wants to change the timezone, it should
be a specific setting only for timezone. Another one should exist for
wallpaper change or screen brightness.
Actually, should we have READ/WRITE setting differences for that kind of
settings?
Should some settings be readable only but not writable? For example, I
guess it wouldn't hurt if an app knows if you are currently in airplane
mode but changing that value might be a bit more sensitive.

--
Mounir

[Adrienne Porter Felt]

On Mon, Apr 16, 2012 at 7:42 PM, Jim Straus <jst...@mozilla.com> wrote:

> On Apr 16, 2012, at 10:24 AM, Adrienne Porter Felt wrote:
>
> > -- Changing the wallpaper or ringtone: Let all apps do it, but provide an
> > "undo" mechanism in Settings that changes it back to what it was prior to
> > that app altering it.
>
> Or have the API throw up a confirmation dialog. A wallpaper app can
> preview wallpapers as much as it wants (even going full screen with the
> wallpaper image). Then when the user asks to set their wallpaper , a
> system dialog comes up with the wall paper and a confirmation dialog.
> Similarly for ringtones. Thus these settings don't need permission
> control.s
>

What do you mean by a confirmation dialog? I am imagining that you mean a
preview of what the phone will look like with the new wallpaper for a
second, followed by an OS dialog that says "Keep this new
wallpaper/Revert". Is that right? If so, I like that idea.

> > -- Adding words to the dictionary: Only let apps do this if they are
> > installed as IME apps; there should only be one IME app at a time.
> >

> Do you mean only one IME in use at a time or installed at a time?
>

I mean in use at a time, mostly because I cannot imagine what it would mean
to have multiple IMEs operational at once. (If you have 2 keyboards
installed, some setting must control which one is shown to the user when a
keyboard is needed.)

> > -- Connecting or disconnecting from WiFi: Apps can connect to known
> > networks, or disconnect from any network. If an app is connecting to a
> new
> > network, ask the user with the standard OS prompt for connecting to new
> > networks. The Settings WiFi control panel should have some small text
> that
> > says what app last disconnected you from the network if the current state
> > of the phone is disconnected.
> >

> I don't want arbitrary apps disconnecting my wifi. Doing so may interrupt
> background processes and I may not notice it for a while. Why should any
> app besides a Settings app need to muck with my networks?
>

There are apps out there that try to save you battery life by disconnecting
WiFi when it doesn't seem needed. I personally wouldn't use one but they
do exist, so I see why it might be desirable to have that as a setting.

Is there any motivation for an app to abuse the ability to disconnect WiFi?
I can see buggy applications screwing up (in which case you can look at
Settings and then uninstall them), but unlike the SMS API there is nothing
to gain by intentionally disconnecting WiFi against the user's will. Even
if there were some malware out there that did this as a way to annoy you,
the audit mechanism (showing who last disconnected WiFi) would let you fix
the problem by immediately identifying and uninstalling the annoying app.

> > *Whenever I say "apps" in this e-mail I mean trusted/certified apps, not
> > arbitrary web sites.
>
> Do you mean trusted, certified and granted permission to use the Settings
> API or any trusted, certified app?

Any trusted, certified app. I was saying that there should not be any
single way to grant permission to the Settings API as a whole, but rather
the privilege to use individual settings should be handled on a
per-Settings basis. (Controlling WiFi via Settings is very different from
changing your wallpaper, so I don't think it makes sense to grant an
application access to do both with a broad "Grant access to settings?"
permission.)

[Jim Straus]

Comments in line below

On Apr 17, 2012, at 4:08 PM, Adrienne Porter Felt wrote:

>
>
> On Mon, Apr 16, 2012 at 7:42 PM, Jim Straus <jst...@mozilla.com> wrote:
> On Apr 16, 2012, at 10:24 AM, Adrienne Porter Felt wrote:
>
> > -- Changing the wallpaper or ringtone: Let all apps do it, but provide an
> > "undo" mechanism in Settings that changes it back to what it was prior to
> > that app altering it.
>
> Or have the API throw up a confirmation dialog. A wallpaper app can preview wallpapers as much as it wants (even going full screen with the wallpaper image). Then when the user asks to set their wallpaper , a system dialog comes up with the wall paper and a confirmation dialog. Similarly for ringtones. Thus these settings don't need permission control.s
>
> What do you mean by a confirmation dialog? I am imagining that you mean a preview of what the phone will look like with the new wallpaper for a second, followed by an OS dialog that says "Keep this new wallpaper/Revert". Is that right? If so, I like that idea.

I was actually thinking of a dialog with a shrunk version of the wallpaper and "Set wallpaper"/"Cancel". But either one works and is the same principal of the system mediating the setting and getting consent from the user.

>
> > -- Adding words to the dictionary: Only let apps do this if they are
> > installed as IME apps; there should only be one IME app at a time.
> >
> Do you mean only one IME in use at a time or installed at a time?
>
> I mean in use at a time, mostly because I cannot imagine what it would mean to have multiple IMEs operational at once. (If you have 2 keyboards installed, some setting must control which one is shown to the user when a keyboard is needed.)
>

Actually, I can see there being an IME selection button that allows for changing on the IME on the fly (for example, iOS has a special button that allows you to select which language to use if you have more than one language enabled), but that doesn't doesn't change the fact that only the current IME should be allowed to add words to the dictionary.

> > -- Connecting or disconnecting from WiFi: Apps can connect to known
> > networks, or disconnect from any network. If an app is connecting to a new
> > network, ask the user with the standard OS prompt for connecting to new
> > networks. The Settings WiFi control panel should have some small text that
> > says what app last disconnected you from the network if the current state
> > of the phone is disconnected.
> >
> I don't want arbitrary apps disconnecting my wifi. Doing so may interrupt background processes and I may not notice it for a while. Why should any app besides a Settings app need to muck with my networks?
>
> There are apps out there that try to save you battery life by disconnecting WiFi when it doesn't seem needed. I personally wouldn't use one but they do exist, so I see why it might be desirable to have that as a setting.
>
> Is there any motivation for an app to abuse the ability to disconnect WiFi? I can see buggy applications screwing up (in which case you can look at Settings and then uninstall them), but unlike the SMS API there is nothing to gain by intentionally disconnecting WiFi against the user's will. Even if there were some malware out there that did this as a way to annoy you, the audit mechanism (showing who last disconnected WiFi) would let you fix the problem by immediately identifying and uninstalling the annoying app.
>

Well, an app could disconnect your wifi so you fall back to cellular data where there may be real costs. I don't know how an app would take advantage of that, but it could lead to the user getting unexpectedly high bills.

> > *Whenever I say "apps" in this e-mail I mean trusted/certified apps, not
> > arbitrary web sites.
>
> Do you mean trusted, certified and granted permission to use the Settings API or any trusted, certified app?
>
> Any trusted, certified app. I was saying that there should not be any single way to grant permission to the Settings API as a whole, but rather the privilege to use individual settings should be handled on a per-Settings basis. (Controlling WiFi via Settings is very different from changing your wallpaper, so I don't think it makes sense to grant an application access to do both with a broad "Grant access to settings?" permission.)

I agree. Personally, I would like to see the Settings app not be a single app but a collection of settings apps (maybe tagged as settings in their manifests.) This would allow for isolating the separate settings and also allowing the settings to be extended easily. But that is a different matter.

[Lucas Adamski]

Hmm, so I'm not sure exactly where we came out on this discussion. As Mounir pointed out, discussion of Wifi, Bluetooth and other network-y APIs should be held in those respective APIs (and yes, those have not yet been posted). Is it likely that this API is really focused on certified apps that have the ability to change device settings, and trusted apps should limit access to either low risk and/or OS mediated settings (wallpaper being a good example)?
Lucas.

--
"No one can make you feel inferior without your consent" - Eleanor Roosevelt

On Apr 15, 2012, at 11:16 PM, Lucas Adamski wrote:

> Please reply-to dev-w...@lists.mozilla.org
>
> Name of API: Settings API
> Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=678695
>
> Brief purpose of API: API to configure device settings
> General Use Cases: None
>
> Inherent threats:
> *Access sensitive configuration data (wifi passwords etc)
> *Change settings which might cost user money (data settings, roaming etc)
> *Safety implications (airplane mode? If you believe a plane can be brought down by a mobile phone...)
>
> Threat severity: High
>
> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code:None
> Authorization model for normal content: None
> Authorization model for installed content:None
> Potential mitigations: N/A
>

> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code: Modify a specific setting - e.g. e-book app modifies brightness in response to lighting conditions
> Authorization model: Implicit
> Potential mitigations: Limit access to benign settings
>

[Lucas Adamski]

On 4/16/2012 2:43 PM, Mounir Lamouri wrote:
> On 04/16/2012 08:16 AM, Lucas Adamski wrote:

>> == Trusted (authenticated by publisher) ==
>> Use cases for authenticated code: Modify a specific setting - e.g. e-book app modifies brightness in response to lighting conditions
>> Authorization model: Implicit
>> Potential mitigations: Limit access to benign settings

> We need to have individual settings permissions for each kind of
> settings. For example, if an app wants to change the timezone, it should
> be a specific setting only for timezone. Another one should exist for
> wallpaper change or screen brightness.
> Actually, should we have READ/WRITE setting differences for that kind of
> settings?
> Should some settings be readable only but not writable? For example, I
> guess it wouldn't hurt if an app knows if you are currently in airplane
> mode but changing that value might be a bit more sensitive.

So I'm not sure we actually have a coherent set of use cases for non-certified apps. Seems like the urgent use cases
are already covered by other APIs, and the rest can be covered by web intents? Airplane mode is really just a network
connectivity which should be covered by network apis. If so, the Settings API is purely a certified app use case...
which makes sense if we don't envision implementing similar settings mappings in browsers on windows, mac os, android,
etc.

In other words I'm proposing:

Name of API: Settings API
Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=678695

Brief purpose of API: API to configure device settings
General Use Cases: None

Inherent threats:
*Access sensitive configuration data (wifi passwords etc)
*Change settings which might cost user money (data settings, roaming etc)
*Safety implications (airplane mode? If you believe a plane can be brought down by a mobile phone...)

Threat severity: High

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code:None
Authorization model for normal content: None
Authorization model for installed content:None
Potential mitigations: N/A

== Trusted (authenticated by publisher) ==

Use cases for authenticated code: None
Authorization model: None
Potential mitigations: None

[Mounir Lamouri]

On 05/01/2012 06:05 PM, Lucas Adamski wrote:
> On 4/16/2012 2:43 PM, Mounir Lamouri wrote:
>> On 04/16/2012 08:16 AM, Lucas Adamski wrote:
>>> == Trusted (authenticated by publisher) ==
>>> Use cases for authenticated code: Modify a specific setting - e.g. e-book app modifies brightness in response to lighting conditions
>>> Authorization model: Implicit
>>> Potential mitigations: Limit access to benign settings
>> We need to have individual settings permissions for each kind of
>> settings. For example, if an app wants to change the timezone, it should
>> be a specific setting only for timezone. Another one should exist for
>> wallpaper change or screen brightness.
>> Actually, should we have READ/WRITE setting differences for that kind of
>> settings?
>> Should some settings be readable only but not writable? For example, I
>> guess it wouldn't hurt if an app knows if you are currently in airplane
>> mode but changing that value might be a bit more sensitive.
>
> So I'm not sure we actually have a coherent set of use cases for non-certified apps.

What about the above use cases? Timezone, wallpaper, screen brightness?
There will likely be other use cases going forward.

Cheers,
--
Mounir