- From: pes via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Jul 2019 23:09:08 +0000
- To: public-webrtc-logs@w3.org
> I'm saying the opposite: if double keying of both cookies and localStorage isn't standardized—which I doubt will ever happen, as it would break lots of stuff—then double-keying deviceIds seems futile. This is already underway in some vendors, and some deployments. Whether or not it makes it way up into a full recommendation (🤞) , it would be good to make sure this standard doesn't make that work _more_ difficult. E.g. double keying deviceIds will help on those platforms / configurations today, and will help everywhere if / when double keying goes "general". > My take on mediacapture's "treat ... deviceId as ... cookies ... are treated." … Sorry but i'm not following here. The point is that (to take Safari for example), there is no single point when "cookies are cleared". For example, one currently deployed cookie management system is to reduce the the lifetime of individual cookies, explicitly so the user never has to explicitly clear cookies. Tying device id to cookie lifetime is not clear, and maybe impossible, in these cases. Consider the following: 1) 3p frame A sets cookie B is set on day 1. Lifetime is capped by client set to 7 days 2) 3p frame reads devices Ids on day 2 3) 3p frame A sets cookie C on day 3. Lifetime is capped by client to 7 days 4) 3p frame reads device ids on day 4 What is the the state of the device Ids on day 7, 8 and 14? > @snyderp All the above could be bypassed by just not using any long term unique Ids in the scheme at all right? Whats lost by the proposal in the the issue? (im sure something better could be devised, but at least as an improvement) Can you clarify if there is a functionality _loss_ by one of the more privacy preserving alternatives? It seems like there are clear privacy wins, so it'd be useful to get a sense of the trade offs -- GitHub Notification of comment by snyderp Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/607#issuecomment-514831922 using your GitHub account
Received on Wednesday, 24 July 2019 23:09:10 UTC