From: Hans de Goede <hansg@kernel.org>
To: Gergo Koteles <soyer@irl.hu>, Ricardo Ribalda <ribalda@chromium.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org
Subject: Re: [PATCH 4/4] media: uvcvideo: Introduce allow_privacy_override
Date: Tue, 18 Nov 2025 15:26:07 +0100 [thread overview]
Message-ID: <381cf376-72b0-4a5f-a99e-524f6d83a2d0@kernel.org> (raw)
In-Reply-To: <b55a513fb25c47411ab7289f3812187e3f67da43.camel@irl.hu>
Hi George,
On 18-Nov-25 12:14 PM, Gergo Koteles wrote:
..
>> Do you have a compelling use-case for turning off the privacy LED?
>>
>
> As a pet camera, it is useful to be able to turn off the LED.
> In some cases, it can also eliminate unwanted reflections.
> Some cameras may have blue LED, and if someone hates blue LEDs..
And almost all cameras already do not allow manually overriding the LED
turning on while streaming. There is a very low-tech solution for this,
put some black isolation tape over the LED :)
>> My core goal is simple: if the camera is in use, the privacy LED must
>> be ON. If the LED is ON unexpectedly, it serves as a clear indication
>> that something unusual is happening.
...
>> No freedom is lost. This change simply increases the
>> trustworthiness/reliability of your device.
>
> It will decrease to the extent that fewer people will know that such an
> option exists because they will not read the description of the
> module's parameters.
People currently already will not know that the option exists.
Seeing the current LED controls on Logitech cams requires 2 manual steps:
1. Install uvcdynctrl which maps the custom GUIDs to the LED controls
Note distros do not install this be default
2. Use either a GUI v4l2-control app like qv4l2ucp or gtk-v4l, or
v4l-ctrl -l to list controls and then change the setting.
So there already is close to 0 discoverability for this Logitech
only feature.
For the new MIPI cameras on laptops we have deliberately made it
impossible to disable the privacy LED while streaming even though
it is often controlled by a separate GPIO because of privacy reasons.
For the same privacy reasons I fully agree with Ricardo that this should
be behind a module option. Which replaces step 1. with creating
a /etc/modprobe.d/uvc.conf file, so just about as much work.
> And it's not possible to be sure that there isn't another undocumented
> option in the firmware to turn it off the LED.
>
> A physical switch would be the best for this control, but that's not an
> option :(
Sure but remember perfect is the enemy of good. Having a v4l2-ctrl to
force the LED to always be off will make it a lot easier for an attacker
to use the camera without the LED turning on. Security is all about
layers / defense in depth and the module option is a nice and simple
way to make things harder for pervert spyware.
Regards,
Hans
next prev parent reply other threads:[~2025-11-18 14:26 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-17 20:14 [PATCH 0/4] media: uvcvideo: Map known XU controls Ricardo Ribalda
2025-11-17 20:14 ` [PATCH 1/4] media: uvcvideo: Remove nodrop parameter Ricardo Ribalda
2025-11-19 4:20 ` Laurent Pinchart
2025-11-17 20:14 ` [PATCH 2/4] media: uvcvideo: Import standard controls from uvcdynctrl Ricardo Ribalda
2025-11-19 4:21 ` Laurent Pinchart
2025-11-17 20:14 ` [PATCH 3/4] media: uvcvideo: Announce deprecation intentions for UVCIOC_CTRL_MAP Ricardo Ribalda
2025-11-19 4:21 ` Laurent Pinchart
2025-11-17 20:14 ` [PATCH 4/4] media: uvcvideo: Introduce allow_privacy_override Ricardo Ribalda
2025-11-17 21:10 ` Gergo Koteles
2025-11-18 6:21 ` Ricardo Ribalda
2025-11-18 8:48 ` Gergo Koteles
2025-11-18 9:25 ` Ricardo Ribalda
2025-11-18 11:14 ` Gergo Koteles
2025-11-18 14:26 ` Hans de Goede [this message]
2025-11-18 15:36 ` Gergo Koteles
2025-11-18 18:30 ` Ricardo Ribalda
2025-11-19 21:34 ` Gergo Koteles
2025-11-19 4:19 ` Laurent Pinchart
2025-11-18 11:14 ` Greg Kroah-Hartman
2025-11-18 14:09 ` Mauro Carvalho Chehab
2025-11-18 16:01 ` Michal Pecio
2025-11-18 18:28 ` Ricardo Ribalda
2025-11-19 4:19 ` Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=381cf376-72b0-4a5f-a99e-524f6d83a2d0@kernel.org \
--to=hansg@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=ribalda@chromium.org \
--cc=soyer@irl.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox