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

This feedback isn't really very meaningful to me. Can you think of a
single meaningful adjustment that can or should be taken in response?
It sounds like any significant change would be to add some boilerplate
warning users that browser state could be steganographically included
in data, or included in the timing of intent invocations, or some
other undetectable side channel, and that users should therefore....
what, exactly?

Which of these privacy implications are not already present on any web
page a user visits? If the group wishes to help users and spec authors
understand the privacy implications of new technology, it needs to
find a way to present analysis in a differentiated way, not as an
enumeration of things we already know about the web.



On Fri, Sep 21, 2012 at 3:44 AM, Arthur Barstow <art.barstow@nokia.com> wrote:
> -------- 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.:
> 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'.
>
> * 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.
>
> cheers
> Fred
>
>
>
>
>

Received on Friday, 21 September 2012 14:02:14 UTC