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