- From: Nick Doty via GitHub <sysbot+gh@w3.org>
- Date: Sat, 09 Mar 2019 22:43:51 +0000
- To: public-webrtc-logs@w3.org
Those are a very good set of documents to start from when working on security/privacy considerations. The `/TR/` version of the fingerprinting guidance is out of date, though, we are about to publish a new version and the editor's draft may be useful in terms of identifying different severity factors and mitigations: https://w3c.github.io/fingerprinting-guidance/ 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. -- GitHub Notification of comment by npdoty Please view or discuss this issue at https://github.com/w3c/mediacapture-record/pull/165#issuecomment-471229023 using your GitHub account
Received on Saturday, 9 March 2019 22:43:52 UTC