Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Privacy evaluation #19

Closed
youennf opened this issue May 4, 2020 · 5 comments
Closed

Privacy evaluation #19

youennf opened this issue May 4, 2020 · 5 comments

Comments

@youennf
Copy link
Collaborator

youennf commented May 4, 2020

This is a general issue about evaluating the privacy risks this new API can bring to existing infrastructure and adding a privacy section to the proposal.

This API may provide access to encoder/decoder states otherwise not available to applications, for instance timing information. It would be good to investigate this potential issue and the potential mitigations.
For instance, a fully native pipeline probably does not bring much fingerprinting, or makes it more easy to add mitigations. Limiting what JS can do/observe is a potential mitigation.

@alvestrand
Copy link
Contributor

For non-timing information, the API will provide exactly the same information to JS as that passed across the network in an unprocessed stream - so that's nothing new.
Timing information is trickier to evaluate (as usual).

@youennf
Copy link
Collaborator Author

youennf commented May 7, 2020

For non-timing information, the API will provide exactly the same information to JS as that passed across the network in an unprocessed stream - so that's nothing new.

This API might make it much cheaper and faster to harvest the fingerprinting information.
Having to setup a separate network node, doing negotiation, sending packets and so on is costly to operate, is potentially harming the user's bandwidth and is potentially slow to get results.

It would be interesting to study what this API would leak compared to what a pair of local loop peer connections is leaking.

Timing information is trickier to evaluate (as usual).

Agreed this is the one to be evaluated with greatest care.

@alvestrand
Copy link
Contributor

I started on a privacy section in #22 - please comment!
Note that you won't get this API without setting up a connection, doing negotation and sending packets and so on - you can do all this locally, of course.

@alvestrand
Copy link
Contributor

Since #22 is merged, and there are no more comments, I'm closing this.

@youennf
Copy link
Collaborator Author

youennf commented Mar 25, 2021

I am not sure we should close it yet.
Spec currently says: "The API will allow access to some aspects of timing information that are otherwise unavailable, which allows some fingerprinting surface."
We should either explain why this is ok or provide guidelines on how to mitigate this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants