- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Tue, 29 Mar 2022 12:44:54 +0000
- To: public-webrtc-logs@w3.org
> That proves that implementations are possible that do not involve a weak reference back to the Element. I think this WG works off the idea that any implementation that is indistinguishable from a spec algorithm is a valid implementation. > Things are more patently safe when such references are not posted cross-process. Can you explain the specific threat vector you worry about? A "reference" can be an id or a key/string for the user agent to look something up later in a different context, a "tag" if you will. It doesn't need to mean a memory pointer. Even if it were implemented that way, it'd 'd be a pointer that would be unusable in other processes without some lookup mechanism invented by the user agent, since neither the element itself or its environment or any other information about it leaves or gets copied to any other process. The only thing that leaves the process is whatever we specify in the serialization steps, which will probably be some id or key. While it's good to give implementation advice where it matters¹, specs normally don't care about these details, and trusts user agents to be responsible. Specs typically care mostly about JS observable behaviors, like GC, i.e. the [3 properties I mentioned](https://github.com/w3c/mediacapture-region/pull/24#issuecomment-1081142141). My view is @youennf's PR satisfies these, and that the prose you've provided in response does not, but please illuminate me, so we don't keep tripping up over details like this. --- <sub>1. In WebRTC we use a [[[KeyingMaterialHandle]]](https://w3c.github.io/webrtc-pc/#dom-rtccertificate-getfingerprints) internal slot for the arguably much more sensitive information. If this is unsafe, this would be good to learn.</sub> -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-region/pull/24#issuecomment-1081826238 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 29 March 2022 12:44:57 UTC