- From: pes via GitHub <sysbot+gh@w3.org>
- Date: Mon, 20 Apr 2020 22:40:19 +0000
- To: public-webrtc-logs@w3.org
In general, I understand the points that are being made that a UUID based identifier isn't in all (many) cases a tracking vector on its own (we might disagree, but I understand the argument). What I'm not getting is any positive argument in favor of a UUID. If we can agree that UUIDs are (at best) a privacy risk that needs to be mediated through other means, why use them? At best its a foot gun… @jan-ivar I take your point, and yes, using (say) just increasing ints would be its own privacy risk (still, way better than a UUID, but yes, not perfect to be sure). That was a straw proposal thats hung around since our conversations before TPAC, so I apologize for it. Here is a slightly less straw suggestion: 1. device ids are integers, chosen at random from the range [0,255], w/o replacement 2. if needed for web compat reasons, device IDs can be packed into the same of UUIDs (eg. 25500000-0000-0000-0000-000000000000) 3. device ids are in all other ways treated as the started currently describes (dual key'ed on platforms that support it, reset on storage clear events, etc). @guest271314 i dont think i fully understand your question, but the claim is that (i) having UUIDs when needed is a bad practice in general (ii) browsers do increasingly sophsiticated and clever things to maintain and minimize storage for users (for privacy, among other reasons), and the idea of a single "clear storage" event increasingly doesn't exist, and (iii) its important to not let one of these device IDs be the key used to rejoin sessions when cookies or other identifiers have been cleared. -- GitHub Notification of comment by pes10k Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/682#issuecomment-616849087 using your GitHub account
Received on Monday, 20 April 2020 22:40:21 UTC