search

w3cping / tracking-issues

Repo to track PING initiated issues on other standards documents.
https://w3c.github.io/horizontal-issue-tracker/?repo=w3cping/tracking-issues
12 stars 2 forks source link

WebAudio API: re-review requested #13

Open svgeesus opened 4 years ago

svgeesus commented 4 years ago

Audio WG requests privacy re-review of the Web Audio API. This specification has already had a round of Privacy review; however we are readying an updated CR, and would like to be sure that the changes since the 18 September 2018 CR do not introduce any new privacy concerns.

The changes are primarily clarifications and bugfixes; no new features have been added since the previous CR.

The Security and Privacy Considerations from the last review remains available.

We are happy to visit you in in Yoh, 3F for a brief meeting at TPAC, if any issues are noticed (we are in Kashi, 1F). Alternatively, if you agree that the changes are all minor and don't introduce any new privacy issues, please feel free to close this issue so we can reference it in our CR transition request.

Many thanks!

NalaGinrut commented 4 years ago

hi @svgeesus! I'm one of IE in PING. I'd like to ask a few questions:

This will require asking the user for permission in an appropriate way, probably via the getUserMedia() API.

Is it possible to add API to just give an oneshot session-based permission for accessing MIC? Or maybe it's already included? I haven't learned the current WebAudio further. What I'm concerning here is that once the permission was given, will it be withdrawn locally when I drop the session? I think the server can do it properly, but if the local client still keeps the permission to access the MIC by certain ID of the origin site, it seems possible to be hijacked to monitor users' privacy secretly. Sometimes we just need oneshot permission without trusting some sites forever.

No. AudioWorklet does not persist across browsing sessions.

This seems related to what I proposed, but I'm not sure if it's what I thought.

Thanks!

svgeesus commented 4 years ago

Hi @NalaGinrut

Is it possible to add API to just give an oneshot session-based permission for accessing MIC? Or maybe it's already included? I haven't learned the current WebAudio further. What I'm concerning here is that once the permission was given, will it be withdrawn locally when I drop the session? I think the server can do it properly, but if the local client still keeps the permission to access the MIC by certain ID of the origin site, it seems possible to be hijacked to monitor users' privacy secretly. Sometimes we just need oneshot permission without trusting some sites forever.

Good points, but those should be raised on Media Capture and Streams because getUserMedia is part of that spec, not Web Audio API. Their issues list is on GitHub so I suggest you raise that issue with them.

No. AudioWorklet does not persist across browsing sessions.

This seems related to what I proposed, but I'm not sure if it's what I thought.

Worklet data does not persist between sessions, even if permission is granted.

samuelweiler commented 4 years ago

PING's practice is to file the substance of issues in WG's own repos (assuming they're using GH) and just put links here for tracking purposes.

I made my review comments here: https://github.com/WebAudio/web-audio-api/issues/2061#issuecomment-552951822

I suggested reopening: https://github.com/WebAudio/web-audio-api/issues/1457#issuecomment-552943389

svgeesus helpfully provided a link to previously-raised privacy issues, mostly filed by Jason: https://github.com/WebAudio/web-audio-api/issues?q=is%3Aissue+is%3Aclosed+privacy+ label%3APrivacy

NalaGinrut commented 4 years ago

May I ask why the standard spec is trying to help the browsers to acquire information to generate the fingerprint? Is there any W3C description for the necessity? Thanks!

samuelweiler commented 4 years ago

Should we review the already-closed issues filed by Jason, Nick, et. al.?