- From: Chaals Nevile <chaals@yandex.ru>
- Date: Fri, 25 May 2018 09:42:06 +0200
- To: public-privacy@w3.org
- Message-ID: <op.zjj7ogdcnd6f5a@ordhord.home>
On Fri, 25 May 2018 01:11:26 +0200, Nick Doty <npdoty@ischool.berkeley.edu> wrote: > A few notes on other changes in HTML5.3 that have some privacy > significance. Nothing major here, and I think <a ping=""> should be the > focus, but >I'd also welcome any feedback on these notes. Am I > interpreting these pieces correctly? Any changes we should recommend? > > Thanks, > Nick > > ## `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. > > Is this intended to parse as "implementors should note *that* the > requirements on user agents have security and privacy implications"? Yes. Feel free to file an issue on this yourself and I will fix it. > 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? From an HTML perspective, we just include the hook so people can see it and be referred to the relevant spec. I added the note because there are privacy implications in implementing that spec. >> The capture attribute requests a specific microphone or camera for the >> media capture mechanism, for example the user-facing and outward facing >> >cameras on smartphones. It has one of the two values user or >> envorinment. > > "environment" is misspelled in this note. Yep. That got fixed yesterday... > > ## `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. Yeah, and we don't define it ourselves for HTML... > > ## 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? We believe so. I also expect an editorial update on that section next week to make it clearer. > ## open privacy issues > > There are a couple open issues on the privacy implications of audio. Are > these scheduled for a later milestone? > > https://github.com/w3c/html/labels/privacy Yeah, they should be dealt with in the next milestone. As another note, I think it would be worth pointing out that there are privacy implications scattered through the document, but there is no place that gathers them all, and it would be very helpful if there were. cheers Chaals > > >> On May 24, 2018, at 3:21 PM, Nick Doty <npdoty@ischool.berkeley.edu> >> wrote: >> >> Hi Privacy-interested colleagues, >> >> We talked briefly about the HTML 5.3 spec at our call this month and >> the prospect of providing privacy review or feedback by the >>requested >> deadline of May 25th (GDPR Day! tomorrow!). I'm trying to work through >> the changes that seem most relevant to privacy. >> >> While I'm working on that, I have written up some comments on the a >> ping attribute which has resurfaced in this draft. Comments are >> >>included below -- I would welcome any feedback before we share >> directly with the HTML WG. I can just provide comments on an >> >>individual basis since we're very close to the deadline and I don't >> expect to be able to gather the consensus of everyone who might >> >>participate in this Interest Group, but I still wanted to have a >> chance to get your review if you happen to have additional ideas. >> >> Cheers, >> Nick >> >> --- >> >> 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 >> 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. >> >>> On Apr 26, 2018, at 5:31 AM, Léonie Watson <tink@tink.uk> wrote: >>> >>> Hello Privacy, >>> >>> We would welcome your review of HTML5.3 [1]. >>> >>> To help make your review easier, we have produced a changelog that >>> contains all substantive changes made since >>>HTML5.2 [2]. Please >>> also note that there are features marked "at risk", documented in the >>> Status. >>> >>> If there are any issues arising from your review, please file them on >>> the HTML Github repo [3], and apply the "wide >>>review" and "privacy" >>> labels to each issue. This will help us track your issues and ensure >>> we respond accordingly. >>> >>> We would appreciate your feedback no later than Friday 25th May 2018. >>> Thank you. >>> >>> Léonie on behalf of the HTML Editors and WebPlat Chairs. >>> [1] https://www.w3.org/TR/html53/ >>> [2] https://www.w3.org/TR/html53/changes.html#changes >>> [3] https://github.com/w3c/html/issues/new/ >>> >>> --@LeonieWatson @tink@toot.cafe Carpe diem >>> >> > -- Chaals: Charles (McCathie) Nevile find more at https://yandex.com Using Opera's long-abandoned mail client: http://www.opera.com/mail/ Is there really still nothing better?
Received on Friday, 25 May 2018 07:42:40 UTC