<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 09/01/14 20:25, Bill Spitzak wrote: <blockquote cite="mid:52CEF796.7090704@gmail.com" type="cite">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. </blockquote> 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: <blockquote type="cite">The video capture API concerns me more. </blockquote> 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. <blockquote type="cite">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.</blockquote> 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 ... <div class="moz-cite-prefix">On 09/01/14 20:52, Martin Peres wrote: </div> <blockquote cite="mid:52CEFDFE.7050906@free.fr" type="cite">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. </blockquote> '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 ... <blockquote type="cite">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... </blockquote> 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. <blockquote type="cite">Clients should never be trusted. I trust the server because it is the one implementing the service, but that's it. </blockquote> 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. Maarten Baert </body> </html>