WebAPI Security Discussion: Contacts API

39 views
Skip to first unread message

Lucas Adamski

unread,
Apr 26, 2012, 10:47:56 AM4/26/12
to dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, dev-b2g list
Name of API: Contacts API
Reference:https://wiki.mozilla.org/WebAPI/ContactsAPI

Brief purpose of API: Access to users contacts.
General Use Cases:

Inherent threats: Access to confidential information, destroy user's data, upload contacts to site. Denial of service by filling storage or obscuring real contacts in a ton of bogus contacts.
Threat severity: high

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: Access to users name to personalize interaction.
Authorization model for uninstalled web content: OS mediated (intents)
Authorization model for installed web content: OS mediated (intents)
Potential mitigations:
* System address app provides contacts back to requesting app

== Trusted (authenticated by publisher) ==
Use cases for authenticated code: Address book
Authorization model: Explicit
Potential mitigations:
* Let user configure what data is accessible (globally?)

== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: Built-in address book
Authorization model: Implicit
Potential mitigations:

Notes:

Mounir Lamouri

unread,
Apr 26, 2012, 12:47:30 PM4/26/12
to dev-w...@lists.mozilla.org
On 4/26/12 4:47 PM, Lucas Adamski wrote:
> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code: Access to users name to personalize interaction.

Apps might want to get the phone number, the email address or stuff like
that. I don't think it should be limited to users name...

> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code: Address book
> Authorization model: Explicit
> Potential mitigations:
> * Let user configure what data is accessible (globally?)
>
> == Certified (vouched for by trusted 3rd party) ==
> Use cases for certified code: Built-in address book
> Authorization model: Implicit
> Potential mitigations:

What's the difference between "Address book" and "Built-in address book"?

--
Mounir

Mike Hanson

unread,
Apr 26, 2012, 1:07:01 PM4/26/12
to dev-w...@lists.mozilla.org
On Apr 26, 2012, at 7:47 AM, Lucas Adamski wrote:

> Brief purpose of API: Access to users contacts.
> General Use Cases:

More use case detail:

Communication Apps would use the address book to populate a UI element to initiate sends / conversations. This would include dialers (which need name, portrait, and phone number), SMS apps (same), voice/video-over-IP (name, portrait, and correlatable identifier (email/phone/?)), chat apps (name, portait, IM network identifier).

Media Apps might use the address book to tag data, or to initiate shares. For example:
* Name tagging in a photo app (possibly including facial recognition)
* Send this photo to… (need name and email, at least)

Social Apps would use the address book to find peers for data sharing or interaction. Use cases would include:

* Which of my friends are on this network already?
* Share this with people in my address book (either by pre-ACL'ing them on the server, or by sending out mail, SMS, whatever)
* Which of my friends are playing this game too?

Entertainment Apps might use the address book for purely local interactions, to enhance emotional engagement. For example Dr. Awesome [1] pulls names from your address book for your "patients".


You can often break these use cases up into "display", "correlation", and "contact" use cases.

* Display means that the app wants to provide a UI element that contains the name-and-face, or perhaps the organization (employer) of a contact, in order to provide a target for user interactions that will lead to additional steps. It could, in theory, be done in a way that was opaque to the app.

* Correlation means that the app wants to display, or store, remote content that is keyed on a property of the contact. It has serious privacy concerns, though for reasons I'll go into below, can be slightly less than contact.

* Contact means that the app wants to use a property of the contact to initiate a network interaction that will ultimately result in data flowing to, or information in a database being keyed on, that property. It has the strongest privacy concerns.

In the Labs Contacts prototype [2], I experimented with providing hashed identifiers to untrusted apps, to provide some privacy-protecting correlation capabilities. The way i wrote that part was, the app could call navigator.contacts.get( [ "hashedEmail" ]) and the user would receive a less detailed/worrisome privacy prompt. Now, as everyone knows, hashing the email is no guarantee of privacy - a rainbow table can easily reverse it. You could salt the hash with the domain, which would at least eliminate the universal rainbow table.


[1] http://drawesome.ngmoco.com/
[2] https://hg.mozilla.org/labs/people

> Inherent threats: Access to confidential information, destroy user's data, upload contacts to site. Denial of service by filling storage or obscuring real contacts in a ton of bogus contacts.
> Threat severity: high
>
> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code: Access to users name to personalize interaction.
> Authorization model for uninstalled web content: OS mediated (intents)
> Authorization model for installed web content: OS mediated (intents)
> Potential mitigations:
> * System address app provides contacts back to requesting app
>
> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code: Address book
> Authorization model: Explicit
> Potential mitigations:
> * Let user configure what data is accessible (globally?)
>
> == Certified (vouched for by trusted 3rd party) ==
> Use cases for certified code: Built-in address book
> Authorization model: Implicit
> Potential mitigations:
>
> Notes:
>
> _______________________________________________
> dev-webapps mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps

Paul Theriault

unread,
Jun 4, 2012, 12:46:45 AM6/4/12
to dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, Mozilla B2G mailing list
Final call for comment/changes to the permissions model for this API.
Please provide comment (to dev-w...@lists.mozilla.org only) by COB
Monday June 4.

I've tried to incorporate feedback so far, though note that this post is
really mainly about deciding which app types will be explicit, and which
will be implicit. Finer details will be in the API design.

I think this API should also have a similar model to device storage -
both relate to repositories of private information, and both would have
a significant impact if the data was deleted/overwritten/changed.

===========================
Name of API: Contacts API
Reference:https://wiki.mozilla.org/WebAPI/ContactsAPI

Brief purpose of API: Access to users contacts.
General Use Cases:

Inherent threats:
*Read/exfiltrate confidential information,
*Destroy user's contact data
*DoS via filling address book with bogus data

Threat severity: high

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: Mediated access limited contact
information
Authorization model for uninstalled web content: OS mediated (web
activities, or trusted UI)
Authorization model for installed web content: OS mediated (web
activities, or trusted UI)
Potential mitigations:
* App requests a contact via web activities or trusted UI
* API provides a local identifier instead of the actual contact information

== Trusted (authenticated by publisher) ==
Use cases for authenticated code: Create,read or edit contact information
Authorization model: Explicit
Potential mitigations:
* Let user configure what data is accessible (globally?)
* Have separate permissions read,create or update/delete? (assuming that
many apps only want read, and could use web activities to create a
contact if necessary?)

== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: Create,read or edit contact information
Authorization model: Implicit
Potential mitigations: None
Reply all
Reply to author
Forward
0 new messages