W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2010

Re: DAP API Exchange Control (was: RE: A comment on Security and Privacy Implications for Contact APIs)

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Fri, 19 Feb 2010 10:34:03 +0100
To: richard.tibbett@orange-ftgroup.com
Cc: public-device-apis@w3.org
Message-ID: <1266572043.3040.2705.camel@localhost>
Hi Richard,

A couple of comments on your analysis/proposal below.

Le jeudi 04 février 2010 à 15:48 +0100,
richard.tibbett@orange-ftgroup.com a écrit :
> 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

I think a likely problem with such an approach is that it makes each
"find" call very costly in terms of user experience (i.e. it will
require user interaction, which, even if non-modal, creates a disruption
in the workflow). I'm hoping to send today some thoughts on the fact
that this problem might actually be arising from the design of the API
itself rather than this specific proposal you're making.

> 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]
>  <---------------------------  

While this would indeed protect against abusive writing, it also creates
a fairly high risk that the user would be losing data (e.g. Alice hits
the "save" button in the app UI, feels that her data is now safe,
doesn't see the non-modal prompt of confirmation and closes her browser,
losing her data).

Both of these might be solvable through a clever UI, but I think it
would be worth investigating what kind of UI would indeed solve these.

Dom
Received on Friday, 19 February 2010 09:34:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:17 UTC