W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > October 2019

Re: [mediacapture-main] A privacy concern of "Media Capture and Streams" (#630)

From: Mu Lei via GitHub <sysbot+gh@w3.org>
Date: Wed, 23 Oct 2019 15:35:06 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-545503345-1571844905-sysbot+gh@w3.org>
> > May I ask why the clone can hang with the original object?
> 
> The code attempts to reproduce the language of the specification, and is probably not the only means available to achieve that output.

I understand your code attempts to reproduce the specification, and I have no question with how you write the code. My question is trying to figure out why the spec permits the other object to hook the object which has enabled MIC even temporarily. Usually, if a clone operation copied all the subtree of an object, then it's ought to be collected by GC. But it seems not here.

> Not sure what you mean. How and what exactly would a malicious script be hijacking?

If I understand it correctly, the first object which enabled MIC has been hanging by the cloned object. So that the first object can never be freed iff the cloned object is kept intended. In this situation, I think the MIC is still working, right?
Please correct me if I was wrong.

I'm not trying to be picky here, and I know the condition to hijack is extream.  :-)
My purpose is to confirm whether the second object (the cloned one) can be used to keep the first object (enabled MIC) working to listen.


-- 
GitHub Notification of comment by NalaGinrut
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/630#issuecomment-545503345 using your GitHub account
Received on Wednesday, 23 October 2019 15:35:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:29 UTC