Privacy Interest Group Teleconference -- 15 Feb 2018

<christine> Agenda item 1 - Web Audio API

<christine> Specification URL: https://webaudio.github.io/web-audio-api/ GitHub repo: https://github.com/WebAudio/web-audio-api

<Chris> security and privacy appendix https://webaudio.github.io/web-audio-api/#Security-Privacy-Considerations

Thanks, Chris, for joining us to discuss Web Audio API

<Chris> control over native UI https://github.com/WebAudio/web-audio-api/issues/1487

<Chris> access to physical audio devices https://github.com/WebAudio/web-audio-api/issues/1486

There are two specs today -- Web Audio and updates to the DOM

AOB?

No additions to agenda so far

runnegar: Chris: can you provide overview of what spec does, any privacy issues you have identified

Chris: Web Audio API is way for you to set up delays, reverb, effects etc

You create effects -- can use in games, music apps, accessibility aid

There is a security/privacy appendix (link above)

There are some unresolved questions

Two specific privacy issues

1. Humans have cutoff on ability to hear at certain frequency -- could send signals that humans can't hear

<weiler> where is this issue documented in the spec?

Could allow signal that device could hear; could be used as tracking method which is undetectable

Tabs reveal audio (Firefox, Chrome) even if not audible..but this is not standard

Spec is curtailed to human range of hearing mainly for efficiency

Limited - not really ultrasonics

2. Could make sounds that talk to things like voice-operated assistants

Issue 1486

Could allow people to make systems that replicate system sounds -- could be security issue

Similar to fake popups (malware installers) - sound could make this seem more legit

Concern for fingerprinting? Sampling rates could be vector? Not in practice -- these are limited to standards

Same two sample rates -- not fine-grained

Could force all to use highest possible rate, but that's heavyweight for small risk

Possibility of DoS attacks: make something hard to compute which eats CPU

Additional issues from PING?

<Chris> https://webaudio.github.io/web-audio-api/#Security-Privacy-Considerations

weiler: where are the issues you just mentioned documented?

<Chris> https://github.com/WebAudio/web-audio-api/issues/1486

See link, reposted

<Chris> https://github.com/WebAudio/web-audio-api/issues/1487

<jnovak> https://audiofingerprint.openwpm.com

weiler: fingerprinting research (link?) - is that addressed?

jnovak: audio context fingerprinting (weiler mentioned) was something I noted also
... this tries to get access to properties of hardware
... there are some objects that expose notions of time (timestamps) - latency
... can someone use timing values to determine something like clock skew to fingerprint device?

chris: microphone is not part of Web Audio API but could be used
... latency varies (Windows, Mac); at platform level could differentiate
... timestamps are used for synchronization
... synch track (drum, melody)

<npdoty> operating system and user agent aren't typically hidden, but the list of fonts is a fingerprinting surface that's actively being addressed by browsers, so let's not assume those are identical

jnovak: timestamps to coordinate tracks: they are absolute, but could they be relative?
... this may not be effective mitigation though

chris: browsers are making timestamps less granular
... not sure if that affects audio directly or not

jnovak: if it does, what would effect be?

chris: Web Audio is not dealt with on *per sample* basic, but in block (rendering quantum)
... need to process and return control within 2.9 millisec
... if longer you get choppy result in audio

chaals: I agree with speaker capacity being obvious mitigation against ultrasound attacks

<npdoty> getOutputTimestamp text specifically notes that outputLatency should be used instead. is there a separate use for getOutputTimestamp, a reason that it's needed?

chaals: but two points I would expect to see are 1. very high-range speakers are a risk

2. Lots of people have hearing that's subset of audible range; this is potential fingerprinting vector

<npdoty> like, "click now" repeated in different audio frequencies?

(very rough vector), might not be mitigation for this but value of knowing this would allow targeting audio

chris: had members previously who wanted to do audiology testing via Web Audio
... via in-ear device; frequency sweep (hearing test) at low cost

chaals: this strikes me as something within range of capability - is in usual audible range

<npdoty> q

runnegar: part of the use case was accessibility, so I wondered about folks with hearing loss

chaals: mitigations? Is there a way to tell device to not output sound outside a specific range
... transpose sound into specific range is like mapping colors into visible range

chris: can use low-pass filter to attenuate; were you thinking of preference?
... if you indicate your hearing range, is this privacy issue?

chaals: low-pass filter is a simple approach, but using two different pairs of low- and high-pass filters allows simultaneously saying something is either black or white (depending on what the range is); being able to transpose audio range I think is feasible if ugly?

chris: this is basis of auto-tune

weiler: to what degree do you understand what we're asking for in terms of documenting?

chris: I did expect to hear about additional concerns on this call and then update docs

<npdoty> it would be useful to have an email followup, anyway

weiler: should they come back with new doc?

chris: we can add meta-tracking of issues

runnegar: thanks, we're happy to look at updated privacy considerations and PING can help you work through them

chris: thanks to PING for doing reviews - much appreciated

<jnovak> nick, we can’t hear you, don’t know if you can hear us

<npdoty> I was curious what info is revealed about attached hardware

<npdoty> is the number and configuration of speakers or other devices

chris: yes, there is something about sampling rate, but not very granular data
... doesn't include brand name, add'l capabilities &c. Web Audio needs to say "can you handle this sampling rate"

<npdoty> AudioContext seems to include numbers of inputs and outputs

chris: WebRTC has been handling this, but not with a lot of details
... we don't have access to this data in any event

runnegar: Again, thanks, Chris and the WG. Looking forward to seeing updated doc.

chris: if someone does minutes to circulate, please add me!

runnegar: other privacy request we received was DOM 4.1

<christine> W3C DOM 4.1- https://www.w3.org/TR/dom41/

<christine> https://github.com/w3c/dom/blob/dom4.1/security-privacy-questionnaire.md

runnegar: asked for a discussion rep but didn't get one for this call
... is anyone familiar with this work and what they are trying to achieve?

chaals: I am co-chair of the WG
... DOM core basically covers central functions of DOM

Added a few pieces like shadow DOM for a document

Have not followed this work very closely in detail, not certain that it *doesn't* have anything user-facing

But anything that might touch users (outside of shadow DOM) is outside the scope of users

Not much you can read into it about user aside from what document

runnegar: question mark about "add event listener"

chaals: the event listener is basic way that apps find out what is going on inside system

if you have something like Audio API that fires notifications, event listener will be used to discover this

but this is low-level piece

runnegar: sounds like, given this is core/low-level pieces of DOM, may not be any specific privacy considerations

But there is a question about whether or not to have a priv considerations section

<weiler> +1 should have one.

I think it's a good idea to have a section, if at least to say that it was considered and reviewed and found to be fine

And not simply ignored

<npdoty> isTrusted property on events, for example; it's clear that security is being considered, at least implicitly

chaals: I would suggest we add a note in that section to say we didn't uncover any issues in a cursory review

runnegar: we want to be clear & honest - but is there anyone who *could* do a deep-dive review on DOM issues?

chaals: hard to find someone with expertise in both domains

berjon?

Could approach him to see if he is willing & able

runnegar: this design is not a major change to existing spec, which helps

chaals: really just shadow DOM and even that's not entirely new

runnegar: we have a plan - any questions?
... any web privacy-related issues (in general) anyone wants to chat about?

<npdoty> I have MediaCapabilities to add to our review list: https://wicg.github.io/media-capabilities/

chaals: I'd like to talk about the unreadability of privacy policies and how that means that in practice they are polite fictions irrelevnt to reality.

runnegar: recently saw website where you can use a bot to help read policy and spit back answer

<npdoty> we have some experience with trying to standardize machine-readable privacy policies, which didn't see the level of adoption that we would have liked (P3P)

chaals: I noticed information in a privacy policy recently and it took a long time of reading to discover important information
... policies are being used to carry out duties for which they are unsuitable (legalese)
... nobody is going to read all that info -- is unreasonable
... are there any good policies as example?

<npdoty> could you describe a very specific use case of information that should be more readily fetched/interpreted?

<weiler> I wonder if this analogy is really a good one. One's medical proxy and advance directive is only used for a short time, also. Does that mean it should take only moments to consider and create?

jnovak: assumption is that priv policies are designed to inform users what companies are doing

<npdoty> I suspect that sites aren't actually using privacy policies as documents for readers to understand prior to using a service

<christine> i found it - https://pribot.org/

<npdoty> +1 to jnovak

<weiler> (only used briefly in many unfortunate cases, anyway)

jnovak: or is it about enforcement actions instead?

<chaals> [example: Policies *often* state that a service is not authorised for use by someone under e.g. 14 years old - and responsibility for enforcing that is left to the user]

chaals: enforceability -- not our role to say what the requirements are (legal sphere)

<npdoty> we could imagine standardizing a description of age-requirements for sites so that users could more quickly determine it, but I don't think either the sites or the users actually want that

chaals: but technical implementation of that makes it easier or harder to interact with system

(COPPA is kid law for US privacy)

jnovak: not suggesting we take on enforcement role - more like breaking up policy into different pieces

that address different needs

chaals: we can provide technical solutions, but mostly arguing: there are practical problems with practical solutions

that are not technical

chaals: if there are common requirements that are harder to find, then clarifying *those* would be progress

<npdoty> chaals, you're saying it's within our scope to evaluate and describe which sites are being unclear about privacy requirements in their online privacy policies?

runnegar: yes, I think there is some scope for PING to improve privacy on the web beyond just tech specs

bearing in mind that we're grounded in that domain

but if there are ways that we can make a practical diff to web privacy, we should do that

this will take more thought

chaals: we are grounded in practical reality - can only ask for so much to be done

parallels to accessibility concerns

requirement to handle this issue if you want something to work

runnegar: I find myself asking "have things changed enough that we can make a difference"?
... is there a *particular* problem we can tackle and improve?
... I challenge all of us to think about something we can practically tackle
... move by Chrome & FF to call http (not https) sites -- mixed content? -- as "not secure"

<npdoty> I think it's not so much "call out", but to change the security indicators to say "not secure" for sites loaded over HTTP

barry: I believe there is already warning about mixed content

jnovak: yes, it's changing security indicators

https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html

runnegar: next call?

Aim for March 8th

ICANN March 10-15 also

<weiler> gathering at IETF week of march 19-23

- DRAFT -

Privacy Interest Group Teleconference

15 Feb 2018

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output