Preventing 3rd Party Webcam Software / Only Allowing Native Camera(s)

88 views
Skip to first unread message

Rao M

unread,
Oct 31, 2019, 4:51:32 PM10/31/19
to discuss-webrtc
Hello,

I have searched far and wide for the answer to this and am surprised that there aren't more people talking about this.

There doesn't appear to be a way to ensure that the stream/track that is selected is a native camera or a stream provided by something like ManyCam (https://manycam.com/?__c=1) or AlterCam.  The use case for this is secure apps that, for security reasons, want to ensure that the video/images/data coming through the stream comes from a "legitmate" (native camera) source rather than a source that can really be anything.

Thank you

Rao

Justin Uberti

unread,
Oct 31, 2019, 7:15:39 PM10/31/19
to discuss-webrtc
This is a next to impossible problem to solve when the user has full control over the endpoint and can install arbitrary software, including software that patches the OS. What's the specific issue you are trying to address?

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8b9f18e3-a0cf-463b-902f-3fda9aee1548%40googlegroups.com.

Alexandre GOUAILLARD

unread,
Nov 1, 2019, 6:09:30 PM11/1/19
to discuss...@googlegroups.com
1. if the OS layer presents it to you as a native cam (through a legitimate device driver), how do yo then differentiate?
2. If you re on macOS, and you depend on such "fake" device to get what you want, like system audio, how do you differentiate between the fake device you want and those you don't?

Those bring you into white listing / black listing, and cause all kind of signature problems. Let's say today you can recognise many cam with 100% accuracy, will it still be the case after an update?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOJ7v-2c69CKCi1E8_SPkxM4L4emJu9J7x_BgfVFn7%2BPuGg_vg%40mail.gmail.com.


--
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------

Rao M

unread,
Nov 4, 2019, 9:26:54 PM11/4/19
to discuss-webrtc
@Justin, you're asking for a use case?

Alexandre more or less touches on this, but there are quite many reasons why you might want to ensure that the device/stream that you are acquiring from getUserMedia is from a legitimate or built-in capture device rather than a fake device.

Use cases:
1.   In general, ensuring the person on the other end of the camera and not a replay video
2.   #1 but ensuring the person on the other end of  the line isn't a fake face being overridden in realtime a la "deep fakes"
3.   Preventing fake cam programs from purporting to be real ones -- i.e.  some sort of solution to this cat and mouse game -- https://www.youtube.com/watch?v=qPjpE20xov4
4.   Live webcam interviews / verification where you want to be sure the feed on the other end is coming from a real camera
5.   Wanting to ensure my security/monitoring camera that uses webrtc to broadcast can't be overridden.
6.   ...etc

Am I correct in paraphrasing your response as "this is next to impossible because anything is possible when a user has root privs on their device and they can change anything in client side code, given enough motivation and know-how" ?

@Justin, I agree, in spirit, to the above.  I see that you are a founder/tech lead so I am interested in your insight/perspective on the matter of the argument that "a sufficiently skilled attacker/programmer can hack the client to do anything they want" vs. protecting users and app ecosystems from fraud and exploits derived via the indistinguishability of native cam feeds and "fake" cam feeds.

Some ideas (if we were trying to brainstorm how this could be fixed...):
- Forgive my naivety on this front, but aren't there deeper OS-level properties/APIs that we can get at to better understand that a stream is tied to an actual piece of hardware?
- A registry and validation of hardware cams.
- Otherwise requiring some sort of deeper level of opt-in to be able to serve or "lock down" a hardware camera's signature.
- exposing more information about the video source, thus making it require more effort to spoof a real camera (i.e. currently the only thing webdevs can use is the "label" property and blacklisting/whitelisting

Thanks

Rao


On Friday, November 1, 2019 at 3:09:30 PM UTC-7, Alexandre GOUAILLARD wrote:
1. if the OS layer presents it to you as a native cam (through a legitimate device driver), how do yo then differentiate?
2. If you re on macOS, and you depend on such "fake" device to get what you want, like system audio, how do you differentiate between the fake device you want and those you don't?

Those bring you into white listing / black listing, and cause all kind of signature problems. Let's say today you can recognise many cam with 100% accuracy, will it still be the case after an update?

On Fri, Nov 1, 2019 at 12:15 AM 'Justin Uberti' via discuss-webrtc <discuss...@googlegroups.com> wrote:
This is a next to impossible problem to solve when the user has full control over the endpoint and can install arbitrary software, including software that patches the OS. What's the specific issue you are trying to address?

On Thu, Oct 31, 2019 at 1:51 PM Rao M <rao.m...@gmail.com> wrote:
Hello,

I have searched far and wide for the answer to this and am surprised that there aren't more people talking about this.

There doesn't appear to be a way to ensure that the stream/track that is selected is a native camera or a stream provided by something like ManyCam (https://manycam.com/?__c=1) or AlterCam.  The use case for this is secure apps that, for security reasons, want to ensure that the video/images/data coming through the stream comes from a "legitmate" (native camera) source rather than a source that can really be anything.

Thank you

Rao

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

Webstream

unread,
Nov 7, 2019, 6:03:49 PM11/7/19
to discuss-webrtc
What about Hardware Capture Devices that you could plug any video source into?

I feel like this falls under the same security hole category as "How Can I Stop People From Recording the Screen".

Reply all
Reply to author
Forward
0 new messages