Re: Request Privacy review of HTML5.3

Thanks Nick. Your review and comments are really helpful.

I've filed them as issues as follows:

Privacy concerns with the ping attribute:
https://github.com/w3c/html/issues/1456
https://github.com/whatwg/html/issues/3718

Privacy concern with the capture attribute:
https://github.com/w3c/html/issues/1457/

More granularity for `allowusermedia`?
https://github.com/w3c/html/issues/1458/

I added your comment on the autofill warning to the original issue:
https://github.com/w3c/html/issues/1285

We'll continue discussion of these issues there. If you have a Github 
account, I can mention you on each issue so you'll automatically receive 
updates if you'd like?

We're glad the changelog proved useful. With regard to your comments 
about the spec as a whole, I agree that a more robust privacy/security 
section would be a good thing.

The TAG is undertaking a review of HTML in its entirety (somewhat of an 
enormous task), and I'm sure we'll see this and other similar 
recommendations coming out of that review in due course.

Once again, thank you for taking time to help us with this review.


On 28/05/2018 22:07, Nick Doty wrote:
> Hi Léonie and HTML folks,
> 
> We've discussed privacy in the HTML spec on a few occasions, and tried 
> to read over the relevant changes in 5.3 with a privacy eye for your 
> wide review process. I've identified issues and written up comments and 
> questions here, with help from some colleagues.
> 
> Rather than a formal Interest Group consensus, these are issues 
> identified by myself and a couple other individuals, although on the 
> ping attribute in particular there seem to be shared concerns.
> 
> Hope this helps,
> Nick
> 
> ## a ping attribute
> 
> Via https://github.com/w3c/html/issues/369 it looks like the ping 
> attribute has re-appeared.
> 
> When this was discussed in the past, I believe privacy concerns were 
> specifically cited as a reason not to include this in the updated HTML5 
> spec, but it seems to have gone ahead on this draft, based on increased 
> implementation experience.
> 
> When it was discussed with the Privacy Interest Group in April 2017, a 
> specific comment was noted:
>> Note that if we have a requirement that user agents clarify to 
>> the user that the link will ping other sites, we need to test whether 
>> that happens in real implementations.
> That concern stands.
> 
> Here is the relevant text from the spec (present in both WHATWG HTML and 
> HTML 5.3 WD):
>> user agents should make it clear to the user that following the 
>> hyperlink will also cause secondary requests to be sent in the background.
> Has anyone tested the real implementations to verify that user agents 
> clarify to the user that the link will also cause secondary requests to 
> be sent in the background? In my quick checks on current versions of 
> Chrome and Safari on Mac OS clicking on links from a google.com 
> <http://google.com/> search results page, I couldn't determine that 
> secondary requests were being sent in the background short of opening 
> the network inspector and observing HTTP POST requests. I trust that we 
> don't believe that is "clear to the user". (The spec includes an example 
> suggesting use of a tooltip; I'm not sure that's very clear either, but 
> I haven't seen that in existing implementations anyway.) Do others have 
> tests/screenshots/etc. documenting implementations that fulfill this 
> requirement?
> 
> Indeed, the question of implementing the clarity requirement was raised 
> in 2007, with the suggestion that if sufficient UI wasn't being 
> implemented within a year, then the feature should be revisited:
> https://lists.w3.org/Archives/Public/public-html/2007Nov/0055.html
> 
> If there haven't been compliant implementations developed in the past 10 
> or 11 years, then I question whether there is sufficient implementation 
> experience or whether implementers believe that feasible UI is possible 
> to meet that requirement.
> 
> I believe there are good motivations for the ping attribute feature in a 
> way that could help user privacy. However, I think we need to be 
> cautious about a feature where the privacy UI hasn't been developed for 
> this long. Indeed, this might be a step backward in transparency for end 
> users, who in some cases now can no longer use the status bar to observe 
> that they're being redirected through a tracking link, and might 
> conclude that tracking isn't happening, that they're navigating to a 
> site by clicking a link without any background communications. In 
> neither browser I tested could I find a setting to disable sending these 
> background requests, as was proposed as an advantage of the feature.
> 
> If implementers believe that the clarity requirement is actually 
> unnecessary and that it's still better for user privacy, that would be a 
> separate question to discuss. That approach might better match the 
> reality of implementations, but I'm not sure what the privacy advantage 
> is if users have neither awareness nor control of background tracking 
> requests.
> 
> ## `capture` attribute
> 
> There are some nice privacy advantages to using this model of 
> user-directed input for camera access and it's nice to see that 
> reflected in the HTML spec.
> 
>  > The capture attribute is defined in 
> the [html-media-capture] specification. Implementors should note the 
> requirements on user agents defined in that specification have security 
> and privacy implications.
> 
> The grammar is a little ambiguous here, but it sounds like this is 
> intended to parse as "implementors should note *that* the requirements 
> on user agents have security and privacy implications".
> 
> The Media Capture spec's Security and privacy considerations section is 
> non-normative; it explicitly doesn't add those as normative requirements 
> on the UA. Perhaps it should; the advice about stripping invisible, 
> sensitive metadata (the example is EXIF data, which might include 
> geolocation) seems especially important.
> 
> There are privacy implications to other requirements in that spec. For 
> example, the UA is forbidden from saving captured media to storage, 
> which seems like a privacy advantage, although I could imagine some 
> abuse or violation of user preferences from that requirement.
> 
> Is this just a general reminder to implementers that they should 
> consider security and privacy when implementing this other 
> specification? Could we provide something more substantive or is the 
> group just looking to hint at unspecified privacy implications?
> 
> ## `allowusermedia` attribute
> 
> Provides a way for a site to explicitly provide permission for an 
> embedded frame to use the getUserMedia API. Cool.
> 
> Shivan has pointed out that this attribute could be more granular, and 
> that ongoing work in Feature Policy would provide a more specific 
> delegation of permission. For example, a site might want to indicate 
> that the embedded iframe should be able to access the camera, but not 
> the user's microphone.
> 
> That kind of granularity might be a goal for future work, and 
> development/adoption of Feature Policy might have implications for 
> changes to the HTML spec, but doesn't need to be a blocker at the moment.
> 
> ## some security fixes
> 
> https://github.com/w3c/html/issues/1285
> 
> The warning on the autofill attribute seems particularly important. Do 
> we know whether UAs have implemented mitigations for this threat? Are 
> there mitigations that should be included in future versions of the spec?
> 
> ## open privacy issues
> 
> There are a couple open issues on the privacy implications of audio. We 
> understand these to be scheduled for subsequent milestones.
> 
> https://github.com/w3c/html/labels/privacy
> 
> ## privacy and security considerations section
> 
> Having a description of the changes in 5.3 made it feasible to review 
> those changes in particular for privacy and security implications. Many 
> thanks for keeping those clear and detailed change logs!
> 
> But we might also benefit from reviewing the entire spec and documenting 
> the privacy and security considerations in a consolidated location. 
> Currently there is a section on "Privacy concerns" which discusses 
> fingerprinting, but it does not make reference to any other privacy 
> threats (for example, tracking of user activity, revealing data from the 
> user's device, history sniffing). There are also substantial security 
> concepts discussed throughout (same-origin restrictions, sandboxing, 
> etc.) that are not collected in a Security considerations section.
> 
> The text on fingerprinting was the original source of the 
> "fingerprinting vector" icon for marking features with some 
> fingerprintability. Is that still being regularly used and updated? It 
> is difficult to find a list of all the references to that icon, which 
> would be a handy tool for reviewers or implementors interested in that 
> topic. (Via curl and grep, I see 12 instances, mostly around plugins and 
> cookies.)
> 
> I think users and implementors would benefit if we had a more 
> comprehensive and coherent collection of privacy and security 
> considerations in a single section of the document. (Chaals pointed this 
> out as well.)

-- 
@LeonieWatson @tink@toot.cafe Carpe diem

Received on Tuesday, 29 May 2018 08:44:01 UTC