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? > On Sun, Apr 15, 2012 at 11:16 PM, Lucas Adamski <[email protected]>wrote: > >> Please reply-to [email protected] >> >> 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 >> >> _______________________________________________ >> dev-webapi mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-webapi >> > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
