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

> 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. ()

The user may have some control over the privacy and security of their data for some services, so could I suggest:

"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 - although explicit intents are chosen by the client web application.  The user has no control over the data shared by the client web application, and when sharing with another web application service the user has no control over the privacy or security of the data."

I would like to see another category of web app that runs locally and does not have the capability to send information to the Internet.  This could suit image editors etc, and would give users control of the privacy and security of the data.  I understand this is outside the scope of the Web Intents group but Web Intents could work very well with such a model.

Might it be possible to say something a little more positive when Web Intents is combined with specific Intent definitions such as a 'share' intent?
In this case the data might be defined adequately that the UA could present it to the user to vet before sending?  If this were the case then could the following be added:

"When combined with a definition of a specific Intent the user agent MAY present the data to the user to verify before sharing and MUST check that the data fits the defined intent and includes no data beyond the definition."

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

Trust with verification is a commonly accepted practice.  Some web service providers may be able to dictate terms 'out way or the highway', but a lot of other providers may want to offer a better service to customers to attract them and I do not see any reason that Web Intents should be on the assumption that selecting a service implies trust without verification.

> (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 also raises the question of the interaction with CSP?
Would an explicit intent be considered a connection?

Would the Intent service URL in general be subject the CSP?

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

While it is good that the user has this choice, blurring the risks associated with different classes of services is not good for 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.




...


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

For example XHR, but more generally any channel that could leak information. 


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

Yes, but it would have been helpful if the return data types were known and were checked.  For example returning a integer code rather than a general HTML string, or being able to define the result as being an image and having the UA check this.  If there were some basic data types and checks then authors could at least try to use them.



cheers
Fred