Authorized clients

[Martin Peres]

On 09/01/2014 23:33, Maarten Baert wrote:
> On 09/01/14 20:25, Bill Spitzak wrote:
>> Screenshot applications I have seen are triggered by a key, yes, but 
>> all of them then show the initial screenshot to the user and then 
>> allow the user to change parameters and make a second screenshot. I 
>> suppose restricting the ui so that the user must hit the same key to 
>> trigger a second screenshot may work, but I am very worried about any 
>> scheme that forces ui decisions on clients.
> I fully agree with this. Usable and intuitive UI design is hard enough 
> already without artificial limitations and requirements coming from 
> the compositor ;).
>
> Martin Peres wrote:
>> The video capture API concerns me more.
> I realize that many people will never use it, so I think it's okay to 
> have it disabled by default and require that the user explicitly 
> enables it (once!). But just because something /can/ be abused doesn't 
> mean it should be banned completely.

The feature is useful and needed, I'm not arguing with that. I don't 
like the idea of configuration because how do you make sure the 
configuration was set by the user and changed by a malicious app?

Actually, I don't think this is needed. For video capture, the 
authentication could be white-list based and the application run using a 
hot-key. Do you think it is usable-enough? I certainly think this 
secure-enough for me as long as the compositor gives me an indication 
when the application stops recording that it indeed stopped and won't be 
able to start it again unless I want it to.

>
>> However, I don't like the idea of having to audit the policy on every 
>> wayland computer I will be on especially since I'm pretty sure some 
>> devs won't mind if their application is a privacy killer.
> Uhm, you have to do that anyway. If you are using someone elses 
> computer, you have already given up your security. This person may 
> have recompiled his Wayland compositor. He may have added code to the 
> Wayland compositor that captures every keystroke and emails it to him. 
> He could even have installed a hardware keylogger in the keyboard 
> you're going to use. If you don't trust the owner of a computer, you 
> shouldn't use it for anything important, it's that simple.
>
> You can't seriously expect every single Wayland user in the world to 
> comply with your security requirements just in case you may have to 
> use their computer once, right? Because that's effectively what you 
> are doing if you ban every possible protocol that could potentially be 
> abused ...

Yes, that was pretty stupid of me but the point remains, if you 
administrate multiple computers and some have video_capture/screenshot 
apps and some don't. You would need to remember which ones are which in 
order to know if you are safe or not?

Can you guarantee apps will all require user input in order to operate? 
No offence, but I think you only think about your application.

>
> On 09/01/14 20:52, Martin Peres wrote:
>> Yes, X11-style screenshot apps won't work but this is for a good 
>> reason, isn't it? And as far as I know, most users on Windows do not 
>> use any application for screenshots, they just press "print screen" 
>> and paste that in paint/whatever.
> 'Most users' is not good enough. A core system component like Wayland 
> should aim to support the needs of as many users as possible, not just 
> 'most users' ;). If you compare Windows and Linux, Linux is clearly 
> good enough (or better) for 'most tasks'. And look where that got us ...
I doubt the reason why Linux isn't used on every desktop is clearly not 
a technical reason. I'm sure you know that too, so please focus.
>
>> With my proposed solution, the app would only be used to edit the 
>> screenshot (crop, resize). Different hot keys would be used depending 
>> on if you want to grab a window, a screen or all the screens. Is that 
>> that difficult onto users? Any other solution will result in lost 
>> confidentiality and, please, let wayland compositors be the only ones 
>> that cannot be spied on easily!
>> [...]
>> Users do not think them as being different because that's what they 
>> learnt. Should we keep on doing the same mistakes and carry than 
>> legacy thinking? Should we loose confidentiality just for the fringe 
>> amount of users who want a common GUI for screenshooters across all 
>> wayland compositors? You know my answer...
> Your requirements are too strict for many users. And whether you like 
> it or not, the result will be that users disable these security 
> features if they stop them from doing something. If Wayland lacks the 
> ability to disable security features, some user will add them. If the 
> patches are rejected upstream, there will be downstream patches or 
> Wayland forks that do! I'm not saying that this is a good thing, I'm 
> saying that it is unavoidable. This is an open-source project, it is 
> impossible to ban a feature that users want.

If users want no security, they can use X11, with DRI3, it should be 
pretty nice and should be comparable to wayland. If they want some, they 
need to agree that they'll have to do things differently from X11. 
That's a fact.


>
>> Clients should never be trusted. I trust the server because it is the 
>> one implementing the service, but that's it. 
> You have to trust some clients. You can't do online banking without 
> trusting the browser. You can't use PGP without trusting the gnupg 
> binary (or some equivalent). The 'clients should not be trusted' model 
> is just not realistic.
>
> And yes, your trust in the browser is totally misplaced because it is 
> trivial to compromise it. That's why I said that we need SELinux or 
> cgroups to create some sandboxing mechanism, before we can even start 
> to think about details like screenshots.

No, we need to design the protocol well. Otherwise, 10 years from now, a 
new wayland will be needed because too many apps are depending on stupid 
ideas people had 10 years ago because security wasn't a concern.

Anyway, you keep talking about other process than the compositor. Look 
at the name of ML, we don't care about them. If they are unsecure, too 
bad for them. We want to export a service, we need to make sure it is 
not abused. That's it, as simple as that. Please focus.