Re: app: URI - Request for review of privacy aspects

Hi Bjoern, All,  

On Monday, May 20, 2013 at 7:16 PM, Bjoern Hoehrmann wrote:

> * Marcos Caceres wrote:
> > The Systems Application Working Group would appreciate if PING could  
> > review the Privacy and Security considerations section of the app://
> > URI specification (or the spec in general - it's a very small spec,  
> > promise!):  
>  
>  
> The "Privacy and Security Considerations" section can't really be under-
> stood without understanding the motivation and application of the scheme
> but the section fails to provide any overview, and overall the document
> does not explain this very well either.

hmm… you are the first person to say that the intent is not clear. Basically file:// sucks, so we made app:// and gave it HTTP semantics to work with HTML5 stuff.  

I can try to add a few more examples or if you have any suggestions as to how to make the intent more obvious, I'm all ears (can even add the above if you think it will help).  
> The section would have to explain why such globally unique identifiers
> are asssigned at all, and why applications are given access to them.

I agree it would be nicer if the UUID went away altogether. The problem is that HTML5 wants an origin to be "either opaque identifiers or tuples consisting of a scheme component, a host component, a port component, and optionally extra data."
> It
> is not obvious that this is actually necessary.  

It appears to be unless we want to redefine HTML5 origin… that would probably mean changing a lot of infrastructure in browsers, but I don't know definitively.   
> It is also unclear how
> the remedies could be effective. If, for instance, the identifier is re-
> generated on every launch, that would not help if applications have any
> way to persist data, since then they could store the first identifier;
> in fact, if applications can persist data then they could just create an
> identifier of their own and use that, so it's unclear why this is an
> issue. Clearing "private data", similarily, would have to purge any and
> all persisted data in order to ensure the identifier is not kept by the
> application, but you do not really want to do that most of the time, as
> that would destroy your configuration data, highscores, savegames, draft
> documents, or whatever else may be stored by an application.

Right. Which could be duplicated on the server anyway.   
> I think the System Applications Working Group needs to put in a bit more
> of an effort before the Privacy Interest Group can give good feedback on
> this document.

Not sure what else to add, TBH. I can remove the privacy section or at least make mention that the ID can be used for tracking but mention that there is no way around that (because of the things you mentioned above, like being able to localStore.user_ID = Math.random() ).  

Technically, the spec is done and ready for LC so now would be a good time to provide this feedback. The only outstanding issues are to get review from this WG and uri@w3.org.  

--  
Marcos Caceres

Received on Monday, 20 May 2013 18:51:50 UTC