- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Wed, 2 Nov 2016 08:31:14 +0000
- To: David Singer <singer@apple.com>, Joseph Lorenzo Hall <joe@cdt.org>, "craigs@otalliance.org" <craigs@otalliance.org>
- CC: "runnegar@isoc.org" <runnegar@isoc.org>, "tjwhalen@google.com" <tjwhalen@google.com>, "public-privacy@w3.org" <public-privacy@w3.org>, "webrtc-chairs@w3.org" <webrtc-chairs@w3.org>
Craig, David and Joseph, thanks for your input. We'll look into it. Stefan On 31/10/16 22:28, David Singer wrote: > I think these privacy considerations are woefully inadequate. > > I would encourage people to open up their preferences and look at what the system has available as output devices. In my case, on a Mac, it includes: > > * headphone port > * display audio > * an dozens of Apple TV devices, many of them with descriptive names (I am at work) > > Fingerprinting: a site can work out if I am at work or not by seeing whether I have a display connected. If the sites see the AppleTV devices, it can fingerprint me much more, and indeed can connect me with other devices that see the same or similar sets of outputs. Increasingly, projectors, TVs, and other devices have wireless capability to behave as an output device.. This is undiscussed. > > Beaconing: as you say, it might emit beacons if it thinks it’s on speakers. Indeed, if it has access to AirPlay, it might cycle through the set of devices and see which ones are audible to someone else, and connect me. This API came from the WebRTC group and to do RTC one needs microphone access, after all. > > Since the draft does not discuss the motivation for this API, it’s hard to see how to mitigate the problems. In general, I think APIs that think about “devices” rather than “functions” are problematic for security, for privacy, and maybe even for portability; it is the wrong mind-set. > > >> On Oct 31, 2016, at 13:30 , Joseph Lorenzo Hall <joe@cdt.org> wrote: >> >> (if an issue arises, happy to put them into github... staying here for >> the moment) >> >> Heya, I took a look at this spec and had a question about the example >> in the privacy considerations section: >> >> https://www.w3.org/TR/2016/WD-audio-output-20161014/#privacy-considerations >> >> There, is says, "Authorization is necessary because playing audio out >> of a non-default device may be unexpected behavior to the user, and >> may cause a nuisance. For example, suppose a user is in a library or >> other quiet public place where she is using a laptop with system audio >> directed to a USB headset. Her expectation is that the laptop’s audio >> is private and she will not disturb others. If any Web application can >> direct audio output through arbitrary output devices, a mischievous >> website may play loud audio out of the laptop’s external speakers >> without the user’s consent." >> >> The case I can think of at the moment (because it's happening on my >> system right now!) is Spotify... we'll pretend through a browser UA >> and not it's native app. Presumably, in typical use of a site like >> spotify.com to play audio, the user quickly (within a few days) gives >> permission (if needed) to spotify.com to output audio to external >> speakers and any headsets they may use. So, certainly spotify.com >> would be able to switch audio from one to the other (and from the >> spec, it sounds like if the USB headset is removed an becomes >> unavailalbe, the sinkId for the external speakers is likely to be >> chosen in a non-paused state)? >> >> It might make sense to have that example be a bit more robust... for >> example, you could describe the user listening to audio at foo.com on >> USB headset and another tab at bar.com wants to direct audio ouput to >> external speakers, perhaps to play an ultrasonic beacon code that >> humans can't hear? (e.g., trying to signal across origins in different >> tabs or something). >> >> Or maybe I have this wrong? best, Joe >> >> On Wed, Oct 19, 2016 at 9:24 AM, Stefan Håkansson LK >> <stefan.lk.hakansson@ericsson.com> wrote: >>> Dear Privacy Interest Group, >>> >>> The WebRTC Working Group and Device and Sensors Working Group are >>> working toward publishing their Audio Output Devices API to Candidate >>> Recommendation and are thus seeking review from a variety of groups on >>> the document: >>> https://www.w3.org/TR/2016/WD-audio-output-20161014/ >>> >>> We are particularly interested on feedback from the Privacy Interest >>> Group on the impact on privacy (and the proposed mitigations) to the new >>> ability to play sound on specific audio devices. >>> >>> We of course also welcome feedback on any other aspect of the >>> specification. >>> >>> We would appreciate to receive feedback before November 11. We hope to >>> transition request to Candidate Recommendation by the end of this year. >>> >>> If you have any comments, we prefer you submit them as Github issues: >>> https://github.com/w3c/mediacapture-output/issues >>> >>> Alternatively, you can send your comments by email to >>> public-mediacapture@w3.org. >>> >>> Thanks, >>> >>> For the WebRTC and DAS chairs, >>> Stefan Hakansson >>> >>> >> >> >> >> -- >> Joseph Lorenzo Hall >> Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] >> 1401 K ST NW STE 200, Washington DC 20005-3497 >> e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key >> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 >> >> Tech Prom, CDT's Annual Dinner, is April 20, 2017! https://cdt.org/annual-dinner >> > > David Singer > Manager, Software Standards, Apple Inc. > >
Received on Wednesday, 2 November 2016 08:33:49 UTC