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-weba...@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 > _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
