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
Comments
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. It would be interesting to study what this API would leak compared to what a pair of local loop peer connections is leaking.
Agreed this is the one to be evaluated with greatest care. |
I started on a privacy section in #22 - please comment! |
Since #22 is merged, and there are no more comments, I'm closing this. |
I am not sure we should close it yet. |
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.
The text was updated successfully, but these errors were encountered: