W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > July 2019

Re: [mediacapture-main] fixed, per origin, device ID creates tracking risk (#607)

From: pes via GitHub <sysbot+gh@w3.org>
Date: Tue, 09 Jul 2019 23:34:38 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-509848542-1562715277-sysbot+gh@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.  But in the meantime, it seems we agree that double-keying is necessary, no?

I take your point re #549, but unfortunately, if the sorry state of privacy on the web has shows anything, its that we can't rely on sites to protect user privacy; it needs to be baked into clients and standards.  So, the standard needs to protect the user from a site that would like to track, not just _allow_ a site to protect the user.

But either way, I'm not sure how #549 addresses what I imagine to be the typical scenario: two different sites have embedded the same origin that would like to track the user AND allow the user to use the microphone / web cam / etc.(example.org)

Under the current spec, all embedded example.org's would be able to track the user, even if the user only wanted to use the webcam on embedded instance.  Under a double key'ed solution that wouldn't be possible.

But, a bigger question: why do you need the keying at all: why not just use something other than unique device ids.  What would be _lost_ in the first suggest in the issue?  Worst case, the user would need to re-grant a permission when their media set up changes.  Seems reasonable? :)

-- 
GitHub Notification of comment by snyderp
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/607#issuecomment-509848542 using your GitHub account
Received on Tuesday, 9 July 2019 23:34:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:25 UTC