942641 - Define permission model for Datastore API

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System, defect, P2)

Description

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Currently any app of any type can ask to register or access a datastore. I understand there is ongoing work to define the permission model aimed  (both in terms of creating and accessing stores, but also in terms of access to the API itself).  I couldn't find a bug so I am creating one to track progress.

Comment 1

[Gene Lian (I already quit Mozilla)]

Hi Ehsan, some projects/products are requesting to open Data Store API to privileged apps. As far as I know, before doing so, we need to work out a prompting mechanism, which needs UI/UX to be involved. Is there any existing resources (or bugs) already working on this?

Comment 2

[(no longer active)]

(In reply to Gene Lian [:gene] (needinfo? encouraged) from comment #1)
> Hi Ehsan, some projects/products are requesting to open Data Store API to
> privileged apps. As far as I know, before doing so, we need to work out a
> prompting mechanism, which needs UI/UX to be involved. Is there any existing
> resources (or bugs) already working on this?

CCed you on an email thread just now.

Comment 3

[Rob MacDonald [:robmac]]

Attachment: Draft Datastore UI Spec

Draft datastore spec for feedback. Settings location and format may change based on UX team comments.

Comment 4

[(no longer active)]

Sorry, I did my best to get to this today but couldn't...  It will be on top of my list for tomorrow.

Comment 5

[Ivan Tsay (:ITsay)]

Hi Peter,

Is this bug just to confirm the permission model (Looks to me Ehsan helps to review UX spec.)? Once the model is confirmed, all the implementation will be on the dependent bugs you added here? I've also talked to Candice about these dependent bugs since they are covered by Systems Front-end. 

webRTC team expects this one and its implementations to be happening in Firefox OS 2.0 time frame (land before June 6). The upcoming webRTC loop client privileged app need to base on this for the development.

Comment 6

[(no longer active)]

Thanks a lot Rob for preparing the spec, I like it overall.  I have some comments below.

One general issue that we need to figure out at some point is what we want to do with the names of the data store.  To restate some of the previous discussion we've had about this in email threads: the issue is that the application manifests contain the programmer facing names for data stores, and it's not clear if those are the best names for exposing to our users.  There is apparently a way to localize some of the manifest fields in Gaia but I'm not very familiar with it.  I think this is the largest issue in the current UX proposal, and it would be nice if we could figure out an answer soon.  Etienne, can you please provide us with some information on how the manifest filed localization story looks like these days?


Now, please let me go through the UX scenarios that we had previously discussed here: <https://etherpad.mozilla.org/DataStoreUX>:

UC1
During runtime, an application (e.g., Instagram) requests read and write access to the datastore with the description "Photos". The "Photos" datastore is published by the Gallery application. 
(Probably not valid UC.  DeviceStorage API used here.)

The current spec sufficiently addresses this, I believe (except for the data store name issue.)

UC2
User installs an application (e.g., Facebook) that creates new data stores with the descriptions "Facebook Friends",  "Facebook photos" and "Facebook Profile Info". The Facebook application requests read access to the datastore "Contacts". The "Contacts" datastore is published by the Contacts application. 
(Valid except photos.)

This use case really depends on the names of the data stores, I'm not sure if we can address this without having a way to show those names in the UI.

UC3
The user then installs an application, (e.g., "Whatsapp") that gives the user the option to use their Facebook information. When the user initiates this, the app requests access to all three data stores from the Facebook app ( "Facebook Friends",  "Facebook photos" and "Facebook Profile Info").
(Valid except photos.)

Same here.

UC4
The user installs an application (eg. Facebook) that creates a new read only data store with the same name as the existing Contact data store.  Once the Contacts app is launched subsequent to this, the Contacts app asks the user if they would like Contacts to read from the new data store as well.
Note that any application which accesses the contacts data store will be affected by the same issue -- it's not specific to the Contacts app.

This depends on having a way to represent the data store names in the UI of course.

UC5
User installs app A which creates a new datastore called "qwerty".  User installs app B which requests access to the "qwerty" datastore.  User needs to be made aware that "qwerty" is data from app A.

I think this is sufficiently addressed.

UC6
User installs app A which creates a new datastore called "notatka" (memos in Polish).  User installs app B which requests access to the "notatka" datastore.  Datastore name "notatka" does not have a localized version.  User needs to be made aware that "notatka" is data from app A.
Note: this is basically the same as UC5, but I wanted to call out the non-localization difference vs. another type of non-human readible datastore name.
Note: the other interesting case here is the situation where multiple apps have different human readable textual descriptions for the same data store.  Which one should be picked up?

This is blocked on resolving the names issue.

UC7
User installs app A which creates a new read-write data store, and then installs App B which tries to access the data store in read-write mode, but the user is not interested in giving app B write access to the data, and only wishes to grant read-only access.

The current spec doesn't really address this intentionally.  So do we think this is not a valid use case any more?

UC8
(Specific to Facebook for now) The Facebook app would like to grant access to its data stores only to the system apps, and not to other third party apps.  This may or may not mean that we wouldn't need to prompt for accesses to its data store.

I think we can ignore this for now.

UC9
User installs app A which tries to access the "contacts" data store.  The "contacts" data store is provided by several applications (such as Contacts, Gmail, Facebook, Twitter, Whatsapp, etc.)
Note: the intention here is to capture the requirement for our prompt to be gracefully extensible to the case where there are many apps providing a data store.

I think this is sufficiently addressed.

UC10
User decides to modify the data store accesses that they have granted or revoked previously (for example, if they click Yes/No by mistake, or change their mind later on.)
Note 1: this is probably an advanced use case.
Note 2: if the user revokes the access that they had already granted to a data store for a given app, should that just appear to the app as if the data in that data store is deleted?

This is sufficiently addressed by the settings UI in the spec, assuming that we don't want to differentiate between readonly and read-write.


Now please let me address some of the open questions in the spec:

* Does revoking datastore access require a dialog?
I think it does.  The settings UI does have a dialog for this purpose, did you mean something beyond that?

* Do we need to show read / write permissions in settings? Do users need to be able to allow/deny read/write permissions separately for each app??
I think this is really a UX call.  I can see cases for both going for a simpler UI, and also making it easy to differentiate between whether an application wants to access my contacts or whether it's requesting permission to change my contacts.  As an anecdote, I personally sometimes make these kinds of decisions based on whether the requested access is readonly or not, but I'm probably not a typical user.  :-)

* Is there a limit to how many times an app can prompt for access to a datastore?
No, the app can issue the request an arbitrary number of times.

* Should we re-organize other aspects of permissions at the same time? For example, how users access geolocation, camera, photos, etc?
This is a UX decision, I'm the wrong person to advise anything here. :-)

* Is it possible for the requesting app must know whether access to a datastore was denied and be able to adjust its UI accordingly? In some cases this may involve an “upsell” screen or a list of benefits.
The API will notify the application if the request for access to the data store failed because of some reason, but doesn't provide more information about the reason.  The reason could be either the data store itself not existing on the system, or the user rejecting the request.  This lack of distinction is by design, we generally don't deliver the specific reason why a request for something like this failed to the web application.

* Is the confirmation dialog necessary? Or does the wording in the App Permissions screen suffice?
The former is a UX question.  On the latter question, one thing worth noting is that the way that the API is designed, we can't forcefully remove some of the data that the application might have cached from what it has received from the data store.  Well behaving applications however are assumed to handle the notification that we send them properly by clearing any possible cached version that they might have lying around.  So perhaps we need to make the wording of the prompt a bit more precise.

I think this is moving in the right direction and we're really close to a final version of the spec.  Please let me know what you think about the above, or about any questions that you might have.

Thanks!

Comment 7

[Jose Manuel Cantera]

are we considering that there can be datastores that by definition will only be available for certified content? 

For instance, the FB datastore can contain email addresses or telephone numbers that we are not allowed to share with other apps and as a result none privileged app will be able to get access to that datastore.

Comment 8

[Etienne Segonzac (:etienne)]

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #6)
> Thanks a lot Rob for preparing the spec, I like it overall.  I have some
> comments below.
> 
> One general issue that we need to figure out at some point is what we want
> to do with the names of the data store.  To restate some of the previous
> discussion we've had about this in email threads: the issue is that the
> application manifests contain the programmer facing names for data stores,
> and it's not clear if those are the best names for exposing to our users. 
> There is apparently a way to localize some of the manifest fields in Gaia
> but I'm not very familiar with it.  I think this is the largest issue in the
> current UX proposal, and it would be nice if we could figure out an answer
> soon.  Etienne, can you please provide us with some information on how the
> manifest filed localization story looks like these days?
> 

We have a ManifestHelper [1] living in gecko and something similar in gaia.
Looks like we can arbitrarily localize anything in the manifest but the keys have to stay the same. So we can either localize and display only the "description" field or add a "public-name" field.

It will look like:
```
  [...]
  "datastores-owned": {
    "awesome": {
      "description": "A data store of awesome stuffs"
    }
  }

  "locales": {
    [...]
    "fr": {
      "datastores-owned": {
        "awesome": {
          "description": "Un partage de données vraiment géniales"
        }
      }
    },

```

[1] http://dxr.mozilla.org/mozilla-central/source/dom/apps/src/AppsUtils.jsm#603-607

Comment 9

[(no longer active)]

(In reply to comment #7)
> are we considering that there can be datastores that by definition will only be
> available for certified content? 
> 
> For instance, the FB datastore can contain email addresses or telephone numbers
> that we are not allowed to share with other apps and as a result none
> privileged app will be able to get access to that datastore.

That's a good point.  Does anyone know more about the use cases here?  I do have an impression but nothing very concrete.  If you cannot share detailed information on the public bug, please feel free to send me an email.  Thanks!

Comment 11

[Candice Serran (:cserran)]

Ted,

I reassigned this bug which is a dup of 945797. Using this as tracking meta since it has the attached UX spec

Comment 12

[Rob MacDonald [:robmac]]

Attachment: Draft Datastore UI Spec (datastore-140509a-DRAFT.pdf)

Updated to include read only and read/write cases.

Comment 13

[Maria Angeles Oteo (:oteo)]

Removing the dependency with 1.0 loop mobile client (corresponding to 2.0 FxOS version) as it was agreed with Vivien that contacts is going to check if Loop is installed via mozApps.

Comment 14

[Gregor Wagner [:gwagner]]

Rob, Ehsan, what's the current status here? Do we have consensus on how this should work? Is the datastore API stable enough to expose it?

Comment 15

[(no longer active)]

(In reply to Gregor Wagner [:gwagner] from comment #14)
> Rob, Ehsan, what's the current status here? Do we have consensus on how this
> should work? Is the datastore API stable enough to expose it?

I don't think that the security dialogs themselves are going to be affected by changes in the API, but the API has not yet changed since the last time that we talked about it, so it's not ready to be exposed to third party apps yet.  That said, I think the work on the security dialogs can happen now, but it won't have a high priority because these prompts will not affect certified apps which are the current target of the API.

Comment 16

[Francisco Jordano [:arcturus] [:francisco]]

Hi folks,

could we have into account while defining this security model things like:
- Apps defining DataStores accessible just by certified apps
- Apps defining DataStores accessible by specific origin + manifest

I think those options will make DataStore a really solid candidate for 3rd party apps to feel safe to use it to share with system apps or other apps from the same manufacturer.

Cheers!
F.

Comment 17

[Rob MacDonald [:robmac]]

(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #15)
> (In reply to Gregor Wagner [:gwagner] from comment #14)
> > Rob, Ehsan, what's the current status here? Do we have consensus on how this
> > should work? Is the datastore API stable enough to expose it?
> 
> I don't think that the security dialogs themselves are going to be affected
> by changes in the API, but the API has not yet changed since the last time
> that we talked about it, so it's not ready to be exposed to third party apps
> yet.  That said, I think the work on the security dialogs can happen now,
> but it won't have a high priority because these prompts will not affect
> certified apps which are the current target of the API.

Hi Gregor - The UX spec is ready. There are open issues but these are mainly surrounding potential enhancements for future releases. - Rob

Comment 18

[BMO Automation]

Firefox OS is not being worked on