- From: <richard.tibbett@orange-ftgroup.com>
- Date: Thu, 4 Feb 2010 15:48:21 +0100
- To: <public-device-apis@w3.org>
Hi,
This email is a brain dump on the subject of Security and Privacy in DAP
and a proposal for shifting from an implied 'access control'
authentication model to an 'exchange control' authentication model. I am
speaking as an individual in this email.
This email introduces an 'exchange control' model in deliberately
abstract terms. I tabled this approach in a previous email [1] and I'm
moving that concept forward.
By way of background, my primary concern with integrating privacy
controls in to Device APIs, on top of Security controls, is the
perceived effect that it would have on the user experience. This
'double' interaction required from a user to initially authorise access
to the API and then to tweak the privacy controls for the actual data
being exchanged had/has complicated and unforeseen user experience
implications.
Another issue, and the grounds for Privacy mechanism dismissal from the
Geolocation specification is that web sites can/will lie or mislead the
user just to get at sensitive information [2]. The privacy controls
originally proposed to the Geolocaton API had significant trust issues
[3] [4].
Rather than providing access control, where permission needs to be
granted for access to an API method in the first place, exchange control
requires user permission (let's call this the 'exchange control
authorisation':):
* after an API method has been invoked by a Web Application;
* after the API method has returned a tentative (uncommited) response
from the Device via a secure and trusted broker (i.e. the Browser);
* before the API method has been committed on the Device; and,
* before the response has been returned to the requesting application.
The diagram below summarises the concept of exchange control for HTTP
GET requests (or equivalent):
Web App User Agent (Broker) Device
------- ------------------- ------
1. GET contacts.find(...)
--------------------------->
2. Find Contacts
-------------------------->
3. [Contact Data]
<-------------------------
4. User Authorisation/Review
-----
|
|
<----
5. [Contact Data]
<---------------------------
1. A HTTP GET API method is invoked by a Web App (e.g. find, retrieve
data)
2. Broker executes the method against the Device
3. Device returns the response from the method to the Broker
4. Broker provides user authorisation interface with the potential for
the user to review the method response data that will be sent to the
requesting Web App. User may have the ability to edit/remove data
fragments from the response as part of the UI.
5. Response data is returned from the Broker to the requesting Web App
The diagram below summarises the concept of exchange control for HTTP
POST, PUT, DELETE requests (or equivalent):
Web App User Agent (Broker) Device
------- ------------------- ------
1. POST contact.save(...)
--------------------------->
2. Save Contact (Tentative)
------------------------->
3. [Contact Data]
<-------------------------
4. User Authorisation/Review
-----
|
|
<----
5. Save Contact [Commit]
------------------------->
6. [Contact Data]
<-------------------------
7. [Contact Data]
<---------------------------
1. A HTTP POST/PUT/DELETE API method is invoked by a Web App (e.g. save,
remove, edit/update)
2. Broker executes the method against the Device but does not commit the
action (method is executed tentatively)
3. Device returns the tentative response from the method to the Broker
4. Broker provides user authorisation interface with the potential for
the user to review the method response data that will be committed to
the Device and subsequently sent to the requesting Web App. User may
have the ability to edit/remove data fragments from the response data as
part of the UI.
5. Broker executes the method against the Device with the User Reviewed
Response data. The Device stores the response data (method is committed)
6. Device returns the committed response from the method to the Broker
5. Response data is returned from the Broker to the requesting Web App
We shouldn't need to be overly prescriptive on the User Interface
required in Step 4. This could be implemented in a number of ways -
according to existing implementations (Geolocation in FF3.5 is fine but
could be extended to provide more privacy control via the exchange
control model). The choice of UI should be at an implementors
discretion:
- A non-modal prompt equivalent to the access control non-modal prompt
(e.g. "This application would like to find your Contacts? [Allow]
[Deny]")
- A non-modal prompt with additional controls over the access control
prompt (e.g. Same prompt as above but with a '[Review]' button to enable
the user to edit/remove data fragments from individual requests before
committing to the Device/returning to a requesting web app.
- A trust based interface for session/permanent settings to be stored
(e.g. 'I trust this web application with my data' - in which case data
review is implicitly authorised by the broker for subsequent requests -
this would be an entirely separate discussion at a later date)
- An alternative trust based interface away from prompting
- A pre-arranged trust relationship between the broker and the user
(e.g. A policy)
Exchange control may optionally take input from a requesting web
application detailing what subset of contact attributes it would like to
access (e.g. I (the web application) want contact.name and
contact.phones only that match my requested filter X). This would
translate in to a subset of data being returned to be authorised by the
user at the moment of 'exchange control authorisation' (defined in a
previous paragraph) that can be reviewed and tweaked before return to
the web app. This does not mean that a requesting web application has
any input in to the authorisation process other than to request the
specific data subsets it requires i.e. it doesn't have the ability to
add a note to the exchange control authorisation process because this is
irrelevant as a site can lie about the intended usage of your data: [3]
[4].
The net result of this is to shift permission to an intermediate
non-commital point (rather than an up-front commital point) in order to
combine both Security and Privacy opt-in permissions from the user
(Security opt-in can be implicitly derived from the Privacy opt-in in an
exchange model for instance).
Perhaps others are able to input to this concept of exchange control.
Obviously there are wide-reaching security and privacy implications that
will need further exploration.
I look forward to your feedback.
Kind Regards,
Richard
[1] http://lists.w3.org/Archives/Public/www-tag/2010Jan/0111.html
[2] http://www.w3.org/2008/geolocation/track/issues/10
[3]
http://lists.w3.org/Archives/Public/public-geolocation/2009Mar/0136.html
[4]
http://lists.w3.org/Archives/Public/public-geolocation/2009Mar/0139.html
*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************
Received on Thursday, 4 February 2010 14:48:55 UTC