public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Ricardo Ribalda <ribalda@chromium.org>
Cc: Gergo Koteles <soyer@irl.hu>, Hans de Goede <hansg@kernel.org>,
	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: Wed, 19 Nov 2025 13:19:55 +0900	[thread overview]
Message-ID: <20251119010156.GD23711@pendragon.ideasonboard.com> (raw)
In-Reply-To: <CANiDSCudzTj0QZMWNnE0gUPFh5heQWRC8z8NOmDHnVXCdqi96A@mail.gmail.com>

On Tue, Nov 18, 2025 at 10:25:42AM +0100, Ricardo Ribalda wrote:
> On Tue, 18 Nov 2025 at 09:48, Gergo Koteles wrote:
> > On Tue, 2025-11-18 at 07:21 +0100, Ricardo Ribalda wrote:
> > >
> > > Most users expect that the led is always on when the camera is active.
> > > I think the usecases where the led should not be turned on are spooky
> > > or very limited.
> >
> > Or do most users expect that if a piece of hardware has a setting, they
> > can set it without module parameters?
> 
> A piece of hardware that has a non-standard, undocumented setting.
> 
> Do you have a compelling use-case for turning off the privacy LED?

The use case that Logitech added this XU control to support is avoiding
the reflection of the privacy LED in users' glasses.

> > > Even if you use open-source software, when it parses user generated
> > > data, there is a risk for bugs. If there is a bug the only thing
> > > protecting the security of the camera is the membership of the video
> > > group which is a very low barrier.

In modern systems the answer to this would be pipewire and portals (or
similar solutions for vendor operating systems). We'll still need time
until the user won't have direct access to the video device nodes
though.

> > > And once you manage to change the
> > > LED behaviour will persist in other unrelated apps.

Maybe that's something we want to address, and make the control
per-file-handle ?

> > So this is about what if an attacker accessed my passwords, private
> > keys, OTP tokens, emails, pictures and then couldn't take a fresh
> > picture of me in the dark without an LED? I'm smart as hell and I use a
> > privacy tape anyway ;)
> 
> 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.
> 
> Gaining access to the video node does not automatically grant access
> to sensitive data like browser information; there are sandboxes in
> place for that. Also open source does not equate to secure or
> non-malicious code.
> 
> > I think freedom is worth more than this kind of fear.
> 
> No freedom is lost. This change simply increases the
> trustworthiness/reliability of your device.
> 
> On ChromeOS, I don't use a privacy tape, but that's because I know how
> the LED is wired :). I want to achieve a similar level of
> trust/reliability for everyone else.

I'd argue that a privacy tape is useful on those devices too. Far more
common than attack scenarios are cases when you unvoluntarily turn your
webcam on during a call. This is however beside the point.

> In other words, I want to know if someone has seen me without t-shirt,
> eating ice-cream and crying while I am re-watching Coco.

-- 
Regards,

Laurent Pinchart

  parent reply	other threads:[~2025-11-19  4:20 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
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 [this message]
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=20251119010156.GD23711@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hansg@kernel.org \
    --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