545063 - Weave Developer API: Add finer-grained access control to synced data.

Status: RESOLVED WONTFIX

(Cloud Services Graveyard :: Server: Sync, enhancement)

Description

[Doug]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_2; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.49 Safari/532.5
Build Identifier: 

I'm filing this as a bug, but it's more commentary on a general deficiency with the published 1.0 weave API.

The problem is that data synced to weave by any client is universally available to all clients with full read / write / delete permissions.

Example of why this is an issue:
Lets say extension A automatically adds a bookmark to itself, and removes bookmarks to competing extensions B, C. Extension B, C do the same thing; now we a have a case where silently in the background A, B and C are constantly checking, altering and resyncing bookmark data; but nothing is visible to the end user (except perhaps, everything seems rather slow). 

...and now, a few possible solution that spring to mind:

Solution 1:
As per Facebook applications, each client registers and receives an application key. Synced data is associated with the parent application when a put operation is done; delete / modify operations can only be performed if the request is signed by the secret-key of the parent application. 

API wise that means basically a duplicate of the User api for extensions, and a slight modification of the sync api to support signed requests.

Solution 2:
All modification / delete actions need to be confirmed specifically by the end user (including possibly a 'always trust this extension' option).

Solution 3:
Android style per client permission levels; specify User API, Sync API (read), Sync API (append), Sync API (full) as separate client permission levels for clients; when installing an extension, running a client end user is informed of the permission levels requested by the application and applications are restricted to actions permissible by their permission level.

This would still require an Extensions API, but removes the need for per-node-permission data to be stored; probably a good thing. All the existing API's would have to be changed to support request-signed-by-extension.


Reproducible: Always

Comment 1

[Mike Connor [:mconnor]]

FWIW, the example doesn't actually rely on the Sync API, as Sync only syncs what the local datastore has in play.  Firefox's current security model doesn't restrict add-ons from writing/editing the bookmark store, and it has nothing to do with the server API, as the extensions aren't modifying the server API.

At this time, we do not plan to do anything like a ACL-style permission/capability model, and we would actually like to simplify the crypto model further (more client than server).  If we do a sharing model, it will be via a separate set of APIs.