WebAPI Security Discussion: Web SMS API

[Lucas Adamski]

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

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?

[Adrienne Porter Felt]

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
.

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

[Lucas Adamski]

Updated proposal per comments. Looking to close this out unless there are further concerns or discussions in the next 48 hours or so.

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: Full-featured SMS app, integrated messaging apps. Read received SMSes, send MMS/SMS.
Authorization model: Explicit
Potential mitigations: Can we filter/warn on premium numbers? Note that premium SMS trojans are currently plaguing the Android platform.

== Certified (vouched for by trusted 3rd party) ==

Use cases for certified code: SMS app

[Chris Lee]

Hi all,

Here are the use cases defined by the feature today:
Tom wants send a text message and selects the SMS app
Tom can send a new message by:
Selecting an existing contact from the Contacts app list
Entering a phone number
Tom is notified of all incoming messages whether he's in the SMS app, on the Home Screen, or in a 3rd party app
Tom also has the ability to send an MMS (deciding if this is in for v1)
MMS supports photos and short videos
Tom has the ability to search through his history of SMS sent/received
Tom has the ability to delete specific SMS threads
The cases above look to be addressed by the categories below, but wanted to confirm with the audience here.

Thanks,
Chris

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

[Lucas Adamski]

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

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 (via web activities)
Authorization model for installed web content: Explicit (via web activities)
Potential mitigations:

== Trusted (authenticated by publisher) ==

Use cases for authenticated code: Full-featured SMS app. Read & send SMS.
Authorization model: Explicit
Potential mitigations: Check your phone bill?

== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: SMS app

Authorization model: Implicit

Potential mitigations: None beyond certification

Note: Should trusted apps be able to register as handlers for SMS web activities/intents, or only certified apps?