I like this proposal. For some apps (like the Yahoo Messenger app), it might be annoying to see a full-screen preview of the text message every time. For this, I'd propose a magic button for sending SMS messages. In this proposal, the OS takes the target number as input and includes either the target number or the contact name in the text of the button, so the button says something like "Text 555-555-555" or "Text Mom." The OS could show a greyed-out button until the number is supplied so that there isn't an empty UI element. The OS sends the text message when the user presses the button. Here, the user does not verify the content but he/she does verify the target.
Could B2G implement a heuristic for guessing whether the number is a premium number? I don't know much about premium numbers, but some effort could probably be put in to compile a list of shortcodes that are affiliated with premium charges. If so, the user could be shown an extra confirmation/warning (in addition to the magic button) at least the first time an app tries to text a premium number. As far as reading SMS goes, there definitely are apps that read SMS. There's a bunch of backup apps and privacy apps that selectively backup texts that you want to keep but don't want to be visible in your standard SMS app. Here's a bunch of Android apps that use it: http://www.google.com/search?client=safari&rls=en&q=site:play.google.com+%22read+SMS+or+MMS%22&ie=UTF-8&oe=UTF-8 . On Sun, Apr 15, 2012 at 11:10 PM, Lucas Adamski <[email protected]>wrote: > Please reply-to [email protected] > > Name of API: Web SMS API > References: https://bugzilla.mozilla.org/show_bug.cgi?id=674725 > > Brief purpose of API: Send and recieve SMS messages > General Use Cases: None > > Inherent threats: > * Sending an SMS costs user money, premium SMS services, SMS payments etc > * Receiving SMS has privacy implications, SMS also used for 2-factor > authentication > > Threat severity: critical per > https://wiki.mozilla.org/Security_Severity_Ratings > > == Regular web content (unauthenticated) == > Use cases for unauthenticated code: App prompts user to send SMS > Authorization model for uninstalled web content: Explicit (OS Mediated) > Authorization model for installed web content: Explicit (OS Mediated) > Potential mitigations: Prompt user to send SMS. User reviews SMS in > trusted UI prior to sending. > > == Trusted (authenticated by publisher) == > Use cases for authenticated code: As per regular web content? > Authorization model: Explicit (OS Mediated) > Potential mitigations: Same as above > > == Certified (vouched for by trusted 3rd party) == > Use cases for certified code: Replacement SMS app > Authorization model: implicit > Potential mitigations: None beyond certification > > Notes: Can only certified apps have access to read SMS messages? > > _______________________________________________ > dev-webapi mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-webapi > _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
