- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Thu, 05 Nov 2020 23:52:38 +0000
- To: public-webrtc-logs@w3.org
_(Going over old issues...)_ > 1. MediaStreamTrack objects are only readable by the origin that requested them I don't see any such general principle. Tracks that are _**not tainted**_ are effectively readable from any origin, since they may be transmitted over a peer connection (MediaStreamTrack isn't transferable, so we don't have to worry about postMessage, but if we were to add that, I think the same principle would apply). The only source of tainted tracks atm appears to be `element.captureStream` which in some implementations (Firefox) emits tainted tracks when the element source is cross-origin content, although web compat here appears to have gone to shreds. See https://github.com/w3c/mediacapture-fromelement/issues/83 and https://github.com/w3c/mediacapture-fromelement/issues/21. For some reason `canvas.captureStream` chose to fail rather than emits tainted tracks. IOW there's effectively no origin concept for camera, microphone, screen-sharing or web-audio tracks. There might be some benefit from a central definition for the concept of a **tainted** track, since every sink in the MediaStreamTrack [model ofsources and sinks](https://docs.google.com/presentation/d/10myL8D_a3oQghAH1RO522x00KO4qmGi9ZQyXQD70Xto#slide=id.ga38008d958_3_120) is going to have to deal with it (I've already filed https://github.com/w3c/mediacapture-image/issues/272). -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/529#issuecomment-722711285 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 5 November 2020 23:52:42 UTC