Final call for comment/changes to the permissions model for this API.
Please provide comment (to dev-weba...@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
On Friday, 27 April 2012 03:07:01 UTC+10, Mike Hanson wrote:
> 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-weba...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-webapps
On 4/27/12 3:07 AM, Mike Hanson wrote:
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-weba...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps
_______________________________________________
dev-webapps mailing list
dev-weba...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
