Agreed . However , most systems are not development systems . So it ' s appropriate that it is turned on by default . Fedora 24 seems to have it turned off , but I am nevertheless unable to access e . g . devpidmem because of SELinux . No one argued that Wayland wasn ' t fine for people who use their computer as a Phone OS though . The point is Wayland is being billed as a serious replacement for X in totality . But how do you know that ? Because that ' s what you suggested , a prompt like that , I argued that such a prompt would quickly become extremely annoying . As I said before , you can make your own compositor that allows any application to grab the screen without any notification at all . Yes , but then you go outside of the Wayland protocol . You can always fix holes in a protocol by providing extensions to it . But a protocol repraesents a standardized conduit of communication . If it ' s not standardized it serves no purpose . If GNOME , KDE , Sway , Enlightenment and Orbital all have their own different ways of doing it then no one is going to use that . No one wants to develop software with so many codepaths having special support for each compositor . Sure , but it ' s still an efficient exploit mitigation technique . Address space randomization also does not prevent all exploits , but it ' s still sensible to do . Security is a process . You don ' t skip it just because it ' s impossible to prevent every exploit every time . You ' re confusing horizontal with vertical security , or rather comparing them . ASLR is a form of vertical security . It creates another layer , another wall the attacker has to go through that is locked the attacker needs to somehow find a way to open and break the lock . In order to gain access the attacker has to go through all the doors . What we discuss here is horizontal , the doors are not after each other but next to each other . The attacker needs to only go through one door , it doesn ' t matter which of them , to gain access , what ' s more , the doors are wide open , there is no need to break any lock . They are documented APIs . Closing of a door when there ' s an open door next to it that leads to the same place doesn ' t do much . That ' s why horizontal security works differently . In the vertical case every new door you add makes the system more secure . With horizontal , every door you close off just adds securitybyobscurity in the hope that the attacker doesn ' t know about the other doors . Only once you ' ve closed them all do you actually increase the security against a knowledgeable attacker . What I suggest is one option . Unlike you , I believe it ' s up to the users to decide how much security they want . There ' s no one size fits all . With Wayland you can have everything from no security to hardcore security . With X you can have bad security . No , it ' s in reverse . With Wayland you have one choice , with X you have multiple . You know the X server can run in the SECURITY mode right where it doesn ' t do this anymore as well as that you can use nested sandboxes ? This is available right now and you can install it on any distribution . Install Firejail and check its X 11 sandboxing This all goes via standardized protocols , applications that run inside those sandboxes do not need to support compositorspecific APIs . With Wayland you currently have one level , and one level only . OK , bad phrasing . Wayland does not give you options . Wayland gives the compositor options , which then gives you options . Nope , it doesn ' t give the compositor options at all . A compositor is free to go outside the Wayland protocol just as an X server is free to go outside of the X protocol to provide extra functionality . But this is what it is , a nonstandard extension that is not standardized in any way .