- From: Dominique Hazael-Massieux via GitHub <sysbot+gh@w3.org>
- Date: Fri, 20 Mar 2020 06:56:46 +0000
- To: public-webrtc@w3.org
dontcallmedom has just created a new issue for https://github.com/w3c/mediacapture-record: == Improvements to Privacy & Security Considerations == Availability (https://w3c.github.io/fingerprinting-guidance/#identifying-fingerprinting-surface-and-evaluating-severity) is a factor that might be worth considering in this section of the specification: can any embedded iframe or third-party JavaScript use these features without user interaction? (In #142 I explicitly described this as drive-by available fingerprinting surface, but I'm not sure if that's still the case.) There are a few mitigations described at the end of the new section that use "should" language, but I'm not clear on whether that's intended to be normative or not. (It seems likely that it's not.) Are there any normative mitigations that could be described, so that sites can understand that the same protections apply in all user agents? I wasn't clear on what the suggested mitigations were for "default values". Could you explain that further? The first example, which immediately follows the privacy and security considerations section, is an example that explicitly shows how to enumerate the UA's supported types, which seems like an explicitly bad practice and isn't showing an example driven by functionality. Limiting the number of type supported checks might be a good mitigation to recommend to those UAs that are going to support a diversity of types. _Originally posted by @npdoty in https://github.com/w3c/mediacapture-record/pull/165#issuecomment-471229023_ Please view or discuss this issue at https://github.com/w3c/mediacapture-record/issues/196 using your GitHub account
Received on Friday, 20 March 2020 06:56:48 UTC