41–45 of 45 posts
I find this hard to believe. I can certainly believe that American crypto laws resulted in a lot of unencrypted protocols, but there’s more to security than just crypto. What about things like rlogin? A lot of older stuff (and newer stuff, for that matter) assumes that the other side is trustworthy, which is a separate concern from encryption.
> We asked MIT whether we could incorporate Kerberos (and other encryption) into the X Window System. According to the advice at the time (and MIT’s lawyers were expert in export control, and later involved in PGP), if we had even incorporated strong crypto for authentication into our sources, this would have put the distribution under export control, and that that would have defeated X’s easy distribution. Fascinati…
Did they really have to include strong crypto? Most secure protocols negotiate a cipher suite. They just had to add the ability to do so, and maybe some placeholder algorithm using the maximum allowed strength at the time.
I find this hard to believe. I can certainly believe that American crypto laws resulted in a lot of unencrypted protocols, but there’s more to security than just crypto. What about things like rlogin? A lot of older stuff (and newer stuff, for that matter) assumes that the other side is trustworthy, which is a separate concern from encryption.
What about rlogin? Isn't the major security vulnerability with it the lack of encryption?
So uh, why did you design X in such a manner that any client could sniff any other client's events and windows by default, and only later add a (quite inadequate) SECURITY extension? This is what we mean when we say that the security model of X is obsolete, and an afterthought besides. The threat model was completely different back then: every griefer, troll, thief, and state actor didn't have a pipe straight into yo…
Because all programs were running under the same user account, so there was no use trying to build a security boundary between them in the X server. Wanting to run mutually distrustful sandboxed apps side by side was not a popular use case back then.
These days network transparency is a) irrelevant for most use cases and b) much better implemented with newer protocols like RDP and PCoIP. That's why it was removed from Wayland.
Earlier quoted context omitted.
I wonder if there will be a successor to Wayland and X11 that learns from the mistakes of both? Can't always make wise improvements if you don't first make awful mistakes that weren't properly considered in practice.
> I wonder if there will be a successor to Wayland and X11 that learns from the mistakes of both? Ubuntu wanted to do this with Mir. The rest is history...
It took the X11 devs, many of whom were also involved in Mesa and Linux graphics development, literally years just to get all of the necessary plumbing in place in order to replace what X11 was previously doing.
These developments help not only X11 or Wayland, but make the development of a newer, superior protocol to X11 and Wayland much easier, because the hard yards have been done for them.
It also makes it easier for those who might want to transition from Wayland to a hypothetical superior protocol.