Re: Review of 'Web Intenets' wrt covert sharing of UA state.

Some comments inline.

regards, Frederick

Frederick Hirsch
Nokia



On Sep 21, 2012, at 2:14 AM, ext Fred Andrews wrote:

Some points noted for the 'Web Intents' spec.:
http://www.w3.org/TR/2012/WD-web-intents-20120626/

* The introduction claims that 'They all exist purely client-side,
...', however the proposal also mentions cloud storage which is hardly
'client-side'.  Further the proposal has no mechanisms for ensuring
that data remains 'purely client-side'.


Perhaps this edit would help:

Replace: "They exist purely client-side, mediated through the User Agent, allowing the user a great degree of control over the security and privacy of the exchanged data." with:

"User selection of a service via web intents usually occurs at the user agent, including any use of history of previous choices. Thus the user has control over the selected service, which is responsible for privacy and security of the data shared with it. (Explicit intents are chosen by the client web application.)

Your point is well-taken that issues of secondary use, data retention, and security at the service is the responsibility of the service.

* The shared 'data' is so broad that the UA has little chance to
understand it and present it to the user for validation before
sharing.  For example, when the data is text, HTML, or an image it
should be presentable by the UA.  This would still not eliminate the
possibility of JS encoding covert information in the shared data, but
would reduce the chance of completely inappropriate data being sent.
Perhaps the range of data types should be restricted to those that a
typical UA can present for confirmation.

I think the idea is that the user has control over the choice of service provider to select for the client web page to use.

One of the themes that has come out on the list is that the user is expected to 'trust' the client web page, and has done so by navigating to  it.

Thus there is no requirement to examine or approve of the actual data transferred. The choice is whether or not to trust the service.

(I have a question about 'explicit intents' as this removes the user choice though the reasoning also is that the user  'trusts' the client web site.)


* This proposal runs the risk of blurring the distinction between
local applications and open web apps and cloud services.

This is the intention, to make it transparent to the client web application whether the data/service is local or from the web, leaving that choice to the user.

Local
applications without network access are inherently less of a risk of
covertly sharing UA state.  Web applications run in the UA with access
to back channels are open to covertly sharing the data.

do you mean the service (chosen by the user via web intent)  or the client web application? Regardless, user trust is needed in both or there are many risks.

  Cloud
services inherently share the date externally.  Each of these cases
are quite distinct and they should not all be bundled into the same
service selection and have the same privacy policy considerations.

* Web apps that are downloaded and then run in a sandbox without
access to back channels would be the obvious candidate to implement
many of these services, such as the example of image editing included
in the proposal.  This key opportunity to keep data client-side and secure
is not developed in the proposal.

What do you mean by back channel here, the use of a web intent mechanism to integrate a service?


* The proposal does not deal with sanitizing the returned results, but
this would be a critical need for may uses.  Perhaps defining specific
return data types for intents would help.


Isn't data validation application dependent?

* The 'privacy considerations' fail to note that the user also needs
to trust the page that creates the Intent and fills the data, and it
fails to note that the Intent object could be used to covertly share
UA state.

We probably could improve the privacy considerations section so specific wording proposals would be helpful, I expect.


cheers
Fred


Thanks.