W3C home > Mailing lists > Public > public-web-intents@w3.org > September 2012

Fwd: Fred Andrew's Review of 'Web Intenets' wrt covert sharing of UA state.

From: Arthur Barstow <art.barstow@nokia.com>
Date: Fri, 21 Sep 2012 06:44:22 -0400
Message-ID: <505C4506.1070602@nokia.com>
To: WebIntents <public-web-intents@w3.org>
CC: Fred Andrews <fredandw@live.com>
-------- Original Message --------
Subject: 	Review of 'Web Intenets' wrt covert sharing of UA state.
Resent-Date: 	Fri, 21 Sep 2012 06:15:21 +0000
Resent-From: 	<public-privacy@w3.org>
Date: 	Fri, 21 Sep 2012 06:14:53 +0000
From: 	ext Fred Andrews <fredandw@live.com>
To: 	public-privacy@w3.org <public-privacy@w3.org>

Some points noted for the 'Web Intents' spec.:

* 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'.

* 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.

* This proposal runs the risk of blurring the distinction between
local applications and open web apps and cloud services.  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.  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.

* 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.

* 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.

Received on Friday, 21 September 2012 10:44:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:47 UTC