Yes; but we like permissions just because they allow app to run least privilege. Measurements indicate less than 20% of apps use the API anways.
Further, responding to ianG's phrasing, if all apps in the market that use vibration can be easily discovered through a manifest grep, it might be easier to update and fix a risk discovered late. --- We might later discuss APIs that are medium risk, but we decide are not worthy of a UX prompt. In that case, for least privilege (i.e., in case app gets pwned), it still makes sense to declare such a permission. In general, lets disassociate permissions with UI dialogs. Permissions are a useful security mechanism that the developer can opt in to. I don't really see much argument for *not* having this permission: is the burden on developers really that high? =dev On 19 April 2012 19:31, ianG <[email protected]> wrote: > >> someone wrote: >> >>> So long as this is easily user configurable, then I don't see this as a >>> huge >>> risk. > > > > Right - low risk. At this stage, we're into idle speculation as to finding > some weirdo threat. > > Don't be tempted by movie plot threats. What you want to do now is declare > it low risk, refer to the conversation, and make the judgement call: "this > risk is accepted. I say it again. The risk of vibration abuse is not > mitigated. So there!" > > Then, you go out there into the marketplace, *accepting the risk* and if > there is any reason why you got it wrong, the market will find the reason > and tell you. Say sorry, update, move on. > > In all risk modelling, you must accept some risks. > > The common trap with trivial risks is that because we can mitigate them, we > do so, instead of accepting them. Meanwhile, by wasting time mitigating > unimportant risks, we distract from other more important risks...... which > require more brain power to deal with. > > The common trap with hard risks is that we declare them /out of scope/ > because we haven't figured out how to mitigate them. > > > > iang > > _______________________________________________ > dev-security mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
