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

Thank you for following up.

Your answer was anticipated as I understand your concerns.  It is hard to
make a case for new specs to address the matter of the covert sharing of
UA state when there is no infrastructure in current JS based web standards
to protect against this.

Note that it is not such an issue with JS disabled, and currently social sharing
buttons generally work in such a context.

The Web Intents proposal has some features to like - being able to share client
side data via intents and allowing user choice of service.

I am working to address the issue of covert sharing of UA state and
perhaps when there is infrastructure on hand it will be possible to make a
better case for other specs to also consider the issue.

cheers
Fred

> Date: Fri, 21 Sep 2012 07:01:46 -0700
> Subject: Re: Fred Andrew's Review of 'Web Intenets' wrt covert sharing of UA state.
> From: gbillock@google.com
> To: art.barstow@nokia.com
> CC: public-web-intents@w3.org; fredandw@live.com
> 
> 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
> >
> >
> >
> >
> >