On Wed, 2013-08-14 at 21:53 +0200, David Henningsson wrote:
> On 08/14/2013 04:57 PM, Matthew Garrett wrote:
> > On Wed, 2013-08-14 at 11:27 +0200, David Henningsson wrote:
> >
> >> The privacy issue is interesting, but I don't see a practical way of
> >> implementing things that would protect us against compromised userspaces.
> >
> > That's pretty easy - just tie the LED control to the HDA device in-kernel.
> >
>
> Well, my point was that the compromised userspace could still record
> from other possibly connected microphones (such as USB or bluetooth
> headsets).
Ok, true. It'd need to be at a higher level than HDA to make this
consistent. But in theory, this is something that could be tied to the
full set of input sources.
> But I guess one compromise could be to refuse userspace turn the mic
> mute LED on, if the internal mic is unmuted.
> Userspace would still be able to turn the mic mute LED off, to indicate
> that recording can happen from other sources. It will be slightly more
> complex for userspace though.
Like I said, I don't think there's any reason for this to be in
userspace. If it's only going to represent the internal device, that's
trivial. If it's going to represent the global state of audio devices,
that's more complicated but doable. The only policy aspect is "What if I
want it to track the state of the currently selected audio device",
which just doesn't seem like a useful thing for it to do.
--
Matthew Garrett <matthew.garrett@xxxxxxxxxx>
��.n��������+%������w��{.n������_���v��z����n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
