search

w3c / mediacapture-fromelement

API to create a MediaStream from Media Element
https://w3c.github.io/mediacapture-fromelement
Other
21 stars 15 forks source link

Deny captureStream for cross-origin media by default #70

Closed shhnjk closed 6 years ago

shhnjk commented 6 years ago

Per spec, it is allowed to captureStream() cross-origin media contents. But I don't see much benefit from it. Instead, there are many risks. Media related APIs are growing and it's complicated for browsers to allow captureStream of cross-origin media yet deny leaking information. Stream can be passed from video <-> canvas, or to WebRTC peer, etc.

Chrome denies to captureStream for cross-origin media contents today. Where Firefox allows it. I think we should stick to Chrome's behavior and change the spec.

Test https://test.shhnjk.com/whycapture.html

shhnjk commented 6 years ago

CC: @mikewest @annevk @dveditz

annevk commented 6 years ago

As long as the <canvas> is tainted how is this different from drawImage() doing a similar thing?

shhnjk commented 6 years ago

This is media stream, so there's no requirement of canvas. It is similar to drawImage, but the spec doesn't have nice concept like "origin-clean flag". So any new media API that can retrieve data from stream (or streamTrack, and more) could potentially leak the data.

shhnjk commented 6 years ago

So in that sense, I don't have much problem with HTMLCanvasElement.captureStream() because UA can check "origin clean flag" of canvas. But I'm worried about HTMLMediaElement.captureStream().

guest271314 commented 6 years ago

What are the risks with capturing cross-origin media content?

shhnjk commented 6 years ago

Potential of stealing cross-origin media file. But seems like there are more APIs that has ability to do it. So closing the issue.