- From: pes via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Jul 2019 19:06:48 +0000
- To: public-webrtc-logs@w3.org
> > I agree, it would be good to have a single "storage partitioning, double-keying" definition / spec, but until that exists, we need to deal with the state of standards as is. If future spec comes and makes specifying double-keying in this spec unnecessary, thats great and a perfect reason to revise this spec and remove it. > @Snyder Isn't it the opposite? Future partitioning of cookies and localStorage wouldn't make this unnecessary. Rather, it would seem like a prerequisite for the suggested mitigation to matter. We might be saying the same thing here, but my point is that "if double keying isn't standardized somewhere else" (as it currently isn't) then it needs to be specified here, even if that text ends up being made redundant by future work. > localStorage.fingerprint = Math.random().toString(36); Some browsers do, and more seem to plan to, take steps to make the above non harmful (again double keying, blocking storage in 3p frames, etc.). So that problem is (in some cases) being addressed by ongoing work. So my goal / concern in this issue is to make sure getUserMedia doesn't make that work more difficult / nullified. > If the lifetime is tied to cookies, and Brave enforces fixed life time of cookies, doesn't that mitigate it? Brave currently blocks 3p cookies. By the text of the standard, that would mean that getUserMedia is broken no? The broader concern is that I don't think cookie lifetime is the right the right lifetime to key off of, since vendors are getting increasingly "tricky" (for good) in managing cookie lifetimes, and not only clearing cookies when the user hits "clear cookies". Brave, for ex, blocks all 3p cookies. Brave and Safari treat the life times of different cookies in the same frame differently (e.g. cap lifetime of JS set cookies to 7 days) etc. In the latter case, would that mean that device Ids are cycled every 7 days? (and if cookie A is JS set on day one, and cookie B on day two, does that mean device Ids are reset on day 8 *and* 9?). 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) > Those are non-normative recommendations though, so the spec could perhaps be stronger normatively here. That seems like a terrific idea! I would be very happy to help in strengthening the normative, mandatory protections in the spec :) -- GitHub Notification of comment by snyderp Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/607#issuecomment-514760625 using your GitHub account
Received on Wednesday, 24 July 2019 19:06:50 UTC