While using Firefox may reduce the number of browser holes that can be exploited (or at least shift them around, particularly when you factor in extensions), it's still easy to get trashed.
Attackers are finding that it's easier to attack apps that are used with common file formats (Word doc, Excel spreadsheet, PDF, video, etc.) than to try to compromise the browser. Combine that with new morphing-code toolkits and pretty much anybody who wants to can create stuff that gets past any signature- or behavior-based defenses.
That's why virtualization is starting to be talked about in the mainstream (Gartner, press, etc.) as an alternative to the nonsensical choice of (a) "don't open anything, anywhere" and (b) "hope-as-a-strategy" (hope that you don't hit anything).
In fact, isolating browsers (and other Internet entry-point applications such as Email, IM, etc.) within virtualized environments is already happening. There are a growing number of products and freeware under Windows, including: GreenBorder, VMware's Browser Appliance, Sandboxie, among others.
The trick is to find the right balance of security and usability to meet your needs. The biggest complexity is often in the latter rather than the former. Making the isolation solid while still allowing useful content to run safely requires interesting amounts of virtualization as well as integration into the desktop to make it easy to use. Particularly when you add things like:
saving downloaded files that automatically launch within the isolated environment,
switching between content that should be isolated and that which should run normally outside the isolated environment, and
prevention of access to files or networks that Internet content shouldn't ever be allowed to touch.
Visiting any unknown page on the Internet or opening any unknown attachment in email without some form of isolation is just begging for people to slap you.
Or run a Desktop DMZ that isolates the browser (and any helper apps) from the desktop and prevents any exploits from being able to read files, key strokes, etc.
Note, Desktop DMZs are *not* personal firewalls, but a new form of security. There are several out there for Windows.
Kind of a stretch to suggest that the protocol supports restarting. If you restart, all applications would have to reconnect and recreate all resources (Windows, pixmaps, fonts, etc.). In doing so, they would almost assuredly end up with different resource ids.
In theory the application programming libraries (either Xlib, the protocol binding, or various toolkits that sit on top of it) could have been written to provide a level of indirection that would allow such recreation to be done under the covers (exposing it to applications would most likely be a recipe for not getting handled properly). But, that would have been a lot of overhead and complexity. At the time, it was perceived as overkill, although today's systems now are beefy enough to warrant it.
> Or you could just install Firefox, with the foxie plugin, > and get completely secure browsing for all sites
Well, not really. While the number of exploits that are targeted at Firefox is small, it is non-zero and growing.
More ominously, however, are threats that target other applications used with content downloaded through the browser. How often do you update your office suite? WinZip? PDF Reader? etc. Even Symantec in one of their recent reports said that that threats are shifting from being broad-based to being targeted at specific applications, increasingly within specific organizations (to fly under the rader of signature-writers).
In short, while the browser has historically been the attack point, it's now just becoming another stage in the pipe into the enterprise.
Right line of thought (anybody who says they can absolutely detect all forms of unknown/morphing threats is jerking your chain), but go further.
> creates a VM sandbox that would then allow the a program to run to see what it would do, and if determind to work normally
Actually, the newest generations of security products go significantly beyond this. You *really* don't want to rely on "trying" out content and guessing whether or not it'll eventually do something bad: that's just asking trouble from threats that "sleep" for a while and then unleash trouble later.
Instead, newer systems create isolated subsystems in which the relevant portions of the browser, email and any viewers or applications that touch Internet content run. Such subsystems intercept all attempts to access system resources from anything running inside. That way, if anything does manage to punch a hole through the browser, email client, or viewer apps, all it can do is swim around in the isolation environment. Most solutions make it trivial to then flush out any remnants of Internet activity at logout.
Examples include BSD jail, Solaris Zones (and even Trusted Solaris), and GreenBorder (a product for Windows).
Some of the key differences between this approach and simple detect-block schemes are:
no restrictions on what content can be used = no user complaints/blaming IT
no signatures = no updates = no hassles
no having to distinguish "good" from "bad" = no false positives or false negatives
no vulnerability to unknown/new/morphing attacks
Ultimately, these solutions trace their conceptual lineage to the Compartmentalized-Mode Workstation (CMW) effort that was part of the "Orange" book series of multi-level security standards back in the 90s.
> Isn't there a way to do it without being intrusive on the user?
Yes.
GreenBorder automatically runs Internet content (including all associated apps/viewers/etc.) received via IE and Outlook in a reduced-privilege subsystem that also filters and virtualizes access to system resources (files, registry, OS objects, processes, threads, windows, address book, etc.). Never asks the user anything.
Disclaimer: I'm biased.
It's more that the 5100 had two personalities. By flipping a switch, you could boot into APL or into BASIC.
It was a fun machine to play with. If you wanted to write any program (read: game) of any size, you had to jump through hoops. In APL, you'd load a file from cart tape into a character array and then (several minutes later:) eval it.
Sounds like they're finally catching on to Multics-type security from back in the 80s
It's more along the lines of the Multi-Level Security (MLS) and Compartmentalized Mode Workstation (CMW) specs of the early 90s, popularly known as the DoD's "Orange Book". Digital also had an implementation, as did a third party called Argus. The hacks in the X Server to enforce separation of security levels and ensure no leakage of information (explicit or covert) across those levels were pretty "interesting."
Good technology marketers often start out as as engineers who find they have a passion for evangelizing their creations. Similarly, the best technologists make the biggest impact on the world often because they are able to get people to immediately understand the value of what they create.
The "field of dreams" approach usually ends up giving you a pile of dirt covered with weeds.
Nit: X11 is shorthand for "Version 11 of the X Window System protocol," which was released in September 1987 (X10 had been in use from late 85 until then). The Rx originally indicated the X Consortium's release of the X software (X11R2 was the Consortium's first release in February 1988; R3 was October of 1988).
I don't know the historic reasons for why X was designed [with clients separated from servers]
The network-transparency was designed in from the start due to a confluence of needs. Bob Scheifler of the Argus Group in the MIT Lab for Computer Science wanted to have a system for developing and debugging networked systems. MIT Project Athena (from which X, Kerberos, Zephyr, Hesiod and various other systems sprang) was looking at how to create a common environment across a variety of types of workstations donated by Digital and IBM; allowing applications to run large computers on the network and display on different flavors of workstations was a way to keep people's sanity.
So, Bob took a copy of a Unix port of the "W" window system (written for the V kernel) that Chris Kent had done with Paul Asente at Stanford, changed it from be synchronous to asynchronous, and dubbed it "X" (from then on, we teased him that we'd never let him name anything again:-).
The early version of the X protocol (up through X10) were focused on fixing various things that came up as the system was ported to different architectures. Initially, the design center was referred to as "3M": 1 megapixel, 1 MIPS, and 1 megabyte.
The X server was quickly ported to a variety of workstations, to DOS, and to terminals. At the time, it was one of the few places where warring companies came together to bring a little bit of unity.
That type of clause is not uncommon. It is sometimes used as a justification for giving one side or the other the right to ask for an immediate injunction rather than having to wait for a lawsuit to eventually be tried and concluded.
Not to be too pedantic, but there *was* (past tense) an MIT X Consortium from 1988 through the mid 90s. However, the X Consortium moved out of MIT and became an independent organization. After an abortive attempt to have it run by somebody else, Bob Scheifler (the original lead architect on all versions of the X protocol, 1 through 11 and a true leader of the X community for many years) stepped back in and run the independent organization for several more years.
Eventually, the X Consortium faded away and transfered control of the standards into The Open Group, under whose auspices x.org now operates.
As mentioned, various implementations of the X standard, particularly XFree86, came to overshadow the standards organization. Now, the xwin.org effort looks like it will be taking up the mantle.
Jim Fulton X Consortium staff member many, many years ago
Re:I'll have to see the bandwidth tests first.
on
A Sound Server For X
·
· Score: 1
Actually, you could watch video (with sound, using NAS:-) from an NT box connecting to an X display long before ICA ever had audio, or the (relatively) recent optimizations for turning off compression over LANs. All you needed was WinCenter, a package NCD developed to layer on top of Citrix's Multi-Win NT kernel (this was pre-Terminal Server).
It blew the pants off of every other NT remoting solution and led to a competition that ultimately made all of the products better. ICA got faster on LANs, WinCenter added an extension that got bandwidth consumption down to almost ICA-like levels (the NT remoting traffic had very specific patterns that could be optimized more easily than was the case for general X traffic in LBX).
WinCenter even did some rudimentary synchronization of NAS audio with X graphics. And, it supported audio input as well as output. And MIDI (Keith got inspired one weekend:-).
When we designed NAS, we intended it to be a (relatively) simple, but flexible, framework that allowed components to be wired together in many different ways and new things added as they were needed. Bonus points go to anybody who recognizes certain similarities (good or bad:-) between it and the X Image Extension...
However, during NAS's early life, some of the more interesting multimedia-enabling technologies such as RTP, XSYNC, and others weren't widely available. So, we had to move on before we could add things like non-TCP streaming audio (essentially extension device objects that would send/receive over a separate datagram socket instead of the TCP-based control socket) and integration with the X Synchronization extension or other video playback technologies.
AudioFile had better support for managing time, but it lacked a lot of flexibility and automatic conversion that NAS provided.
In the end, some cool things were done with both NAS and AudioFile, but in reality they both were missing key design elements that really need to be there. Without a strong organization pushing them forward, they weren't going to be practical in the long run.
Leon has historically done interesting stuff, so I would feel pretty confident that his team did their homework.
Jim Fulton
former NAS protocol weanie, a looooong time ago
Remember that when X was first invented, your average Unix workstation was less powerful than today's PDAs (permanent storage and display size aside).
It was even somewhat before the wide-spread availability of UNIX workstations....
At MIT, within Project Athena and the Lab for Computer Science (remember, this was 1984, pre-X11 and pre-X Consortium days), the target platform was referred to as a "3M" machine:
1 megapixel display
1 MIPS processor
1 MB of memory
The original X server was written for the Digital VS100, an intelligent (for the time) graphics display. Believe it or not, a single VAX 11/750 had several VS100s connected via fiber-optic cables. Imagine time-sharing on your PDA.:)
For what little it's worth, I wrote the pedantic section of the man page you are quoting. While we were trying to drive a little bit of brand recognition, in the 14 years since I have pulled the stick out of my butt and gotten over it. I suggest others do the same.
As is pointed out further below, the initial design point for X11 was initially local area networks. For remote access, where bandwidth is highly constrained and more importantly latency is significantly higher, a compressing and caching proxy called Low-Bandwidth X (LBX) was designed (okay, it escaped before we could give it a catchier name:-).
Early on, the most common X applications used relatively crude UIs. These were still bandwidth-sensitive (the initial design focus as 14.4kb modems and moved up to 56kb later in the cycle), but less so than you see today. As is pointed out in other postings, the more modern, professional (and usable IMHO) UIs do more round-trip requests to the X server. Which, of course, makes them much more sensitive to the latency introduced by the communications channel.
One of the main differences between LBX and its predecessors such as XRemote is that LBX attempted to do some amount of X-knowledgable caching. The hope was to find ways of reducing or eliminating some of the round trips.
So, in short, for those who are using X over remote links, you might try using LBX to see if that helps (particularly if you are running multiple applications). I'd also suggest using SSH as well if you going over a public link.
We find that TWM is made by committee, and according to a client communications manual.
No, it wasn't made by committee. Like much open source software, it was the result of serial efforts by several people, all of whom contributed to make it better.
The Inter-Client Communications Conventions Manual (ICCCM) was the specification of the protocol used between applications and window managers. It controlled how applications requested placement on the screen and other functions. At the time it was adopted by the X Consortium as a standard, there weren't any window managers that implemented it.
We looked at trying to retrofit UWM to be compliant, but it was simply too primitive and really had a pretty crappy UI. TWM offered a much better foundation, so we asked Tom (nicely) if we could use it. He was gracious enough to say "yes" and the rest is (blurry) history.
Also all those funny
key combinations where (sic) to stop RSI
problems.
Nope. RSI didn't become an issue until well after uwm was written.
They were a hold-over from the early window management functions that were implemented in X6-X10. And those were motivated, in large part, by a need to avoid key sequences used by applications (including Emacs and Ted which were among the more commonly-used editors at MIT at the time).
The keyboard model in X10 and prior versions of the protocol was modeled on the DEC LK201 keyboard that was used on the VS100 and various MicroVaxen. It had a Meta key, but lacked keys present on many other keyboards in use at the time (remember, this was before all keyboards looked like they came from off a PC).
It's interesting how they renamed it from Tom's Window Manager to Tab Window Manager.
We renamed it from "Tom's..." to "Tab..." primarily because Keith Packard and I had reworked it (read: hacked) enough that we thought Tom shouldn't be blamed for our egregious actions. Being crammed together in a tiny office yielded some weird code at times.:-)
The details are getting foggy (it was upwards of 12 years ago, afterall), but I believe I hacked in a bunch of the ICCCM compliance and various usability (mis)features, then Keith added the SHAPEd windows support. I can't remember which of us then did the tabbed titlebars, so I'll say that he probably should get the credit (although he always ran with titlebars turned off for his xeyes and oclock).
There weren't really ten full releases prior to X11R1, however there were 10 incompatible revs of the protocol. Most of the early versions were primarily used within MIT (Athena and LCS) and friendly commercial R&D labs. Here's some of the pre-history based on cryptic notes and blurry memory:
X1 - summer 1984 - the first version, based on a substantial rearchitecting of the UNIX port of the W Window System (originally developed for the V Kernel).
X3 - fall 1984 - used internally at MIT as the initial basis of various plotting packages for coursework.
X6 - spring 1985 - first version licensed by MIT to various companies (including Cognition, MASSCOMP, and Digital) for use in commercial products. It cost $100 and if you wanted you could stop off at the (very small) licensing office to pick up your own magtape.
X8/X9 - fall 1985 - added color (X8 lasted all of about a week; X9 was quickly released to fix a protocol alignment problem that impacted ports on the IBM PC/RT). Many organizations began developing ports (including a version to the Lexidata 9000 display card for VAXen that was used at the Autofact tradeshow in late 1985 to show a prototype of the first 3rd party application: a mechanical engineering design system).
X.V10R1 - spring 1986 - first version released by MIT that did not require signing a license agreement. Also the first version to have a DOS Xserver developed.
X.V10R[234] - fall 1986 & spring 1987 - an explosion of ports done on a variety of platforms.
X.V11R1 - Sep 15, 1987 - major overall done in collaboration with folks from Digital, Sun, IBM, and other companies. Formed the basis of core protocol used today. Companies and organizations releasing X-based products used this release as a starting port for incorporating into their own distributions.
X.V11R2 - March 1, 1988 - first version released under the auspices of the newly-formed MIT X Consortium.
The MIT X Consortium continued to put out releases of X11 for a number of years. Then in the mid-90s, it was spun off into a separate not-for-profit organization (simple the X Consortium). As has been noted, that eventually folded into various organizations that became X.ORG.
The rest is history.:)
Jim Fulton
Slashdot Mirror
While using Firefox may reduce the number of browser holes that can be exploited (or at least shift them around, particularly when you factor in extensions), it's still easy to get trashed.
Attackers are finding that it's easier to attack apps that are used with common file formats (Word doc, Excel spreadsheet, PDF, video, etc.) than to try to compromise the browser. Combine that with new morphing-code toolkits and pretty much anybody who wants to can create stuff that gets past any signature- or behavior-based defenses.
That's why virtualization is starting to be talked about in the mainstream (Gartner, press, etc.) as an alternative to the nonsensical choice of (a) "don't open anything, anywhere" and (b) "hope-as-a-strategy" (hope that you don't hit anything).
Or get out of the 90s and run Desktop DMZ software so that you can go ahead and open every f*g email without ever worrying about it.
In fact, isolating browsers (and other Internet entry-point applications such as Email, IM, etc.) within virtualized environments is already happening. There are a growing number of products and freeware under Windows, including: GreenBorder, VMware's Browser Appliance, Sandboxie, among others.
The trick is to find the right balance of security and usability to meet your needs. The biggest complexity is often in the latter rather than the former. Making the isolation solid while still allowing useful content to run safely requires interesting amounts of virtualization as well as integration into the desktop to make it easy to use. Particularly when you add things like:
Visiting any unknown page on the Internet or opening any unknown attachment in email without some form of isolation is just begging for people to slap you.
Disclaimer: I work for GreenBorder.
Or run a Desktop DMZ that isolates the browser (and any helper apps) from the desktop and prevents any exploits from being able to read files, key strokes, etc.
Note, Desktop DMZs are *not* personal firewalls, but a new form of security. There are several out there for Windows.
Kind of a stretch to suggest that the protocol supports restarting. If you restart, all applications would have to reconnect and recreate all resources (Windows, pixmaps, fonts, etc.). In doing so, they would almost assuredly end up with different resource ids.
In theory the application programming libraries (either Xlib, the protocol binding, or various toolkits that sit on top of it) could have been written to provide a level of indirection that would allow such recreation to be done under the covers (exposing it to applications would most likely be a recipe for not getting handled properly). But, that would have been a lot of overhead and complexity. At the time, it was perceived as overkill, although today's systems now are beefy enough to warrant it.
> Or you could just install Firefox, with the foxie plugin,
> and get completely secure browsing for all sites
Well, not really. While the number of exploits that are targeted at Firefox is small, it is non-zero and growing.
More ominously, however, are threats that target other applications used with content downloaded through the browser. How often do you update your office suite? WinZip? PDF Reader? etc. Even Symantec in one of their recent reports said that that threats are shifting from being broad-based to being targeted at specific applications, increasingly within specific organizations (to fly under the rader of signature-writers).
In short, while the browser has historically been the attack point, it's now just becoming another stage in the pipe into the enterprise.
Go read the press reports again. Zotob spread through a number of vectors, including downloads. It used the PnP as just one mechanism.
> creates a VM sandbox that would then allow the a program to run to see what it would do, and if determind to work normally
Actually, the newest generations of security products go significantly beyond this. You *really* don't want to rely on "trying" out content and guessing whether or not it'll eventually do something bad: that's just asking trouble from threats that "sleep" for a while and then unleash trouble later.
Instead, newer systems create isolated subsystems in which the relevant portions of the browser, email and any viewers or applications that touch Internet content run. Such subsystems intercept all attempts to access system resources from anything running inside. That way, if anything does manage to punch a hole through the browser, email client, or viewer apps, all it can do is swim around in the isolation environment. Most solutions make it trivial to then flush out any remnants of Internet activity at logout.
Examples include BSD jail, Solaris Zones (and even Trusted Solaris), and GreenBorder (a product for Windows).
Some of the key differences between this approach and simple detect-block schemes are:
Ultimately, these solutions trace their conceptual lineage to the Compartmentalized-Mode Workstation (CMW) effort that was part of the "Orange" book series of multi-level security standards back in the 90s.
Caveat: I work for GreenBorder.
Yes.
GreenBorder automatically runs Internet content (including all associated apps/viewers/etc.) received via IE and Outlook in a reduced-privilege subsystem that also filters and virtualizes access to system resources (files, registry, OS objects, processes, threads, windows, address book, etc.). Never asks the user anything.
Disclaimer: I'm biased.
It's more that the 5100 had two personalities. By flipping a switch, you could boot into APL or into BASIC.
:) eval it.
It was a fun machine to play with. If you wanted to write any program (read: game) of any size, you had to jump through hoops. In APL, you'd load a file from cart tape into a character array and then (several minutes later
Only for poor marketers and poor technologists.
Good technology marketers often start out as as engineers who find they have a passion for evangelizing their creations. Similarly, the best technologists make the biggest impact on the world often because they are able to get people to immediately understand the value of what they create.
The "field of dreams" approach usually ends up giving you a pile of dirt covered with weeds.
So, Bob took a copy of a Unix port of the "W" window system (written for the V kernel) that Chris Kent had done with Paul Asente at Stanford, changed it from be synchronous to asynchronous, and dubbed it "X" (from then on, we teased him that we'd never let him name anything again :-).
The early version of the X protocol (up through X10) were focused on fixing various things that came up as the system was ported to different architectures. Initially, the design center was referred to as "3M": 1 megapixel, 1 MIPS, and 1 megabyte.
The X server was quickly ported to a variety of workstations, to DOS, and to terminals. At the time, it was one of the few places where warring companies came together to bring a little bit of unity.
That type of clause is not uncommon. It is sometimes used as a justification for giving one side or the other the right to ask for an immediate injunction rather than having to wait for a lawsuit to eventually be tried and concluded.
Not to be too pedantic, but there *was* (past tense) an MIT X Consortium from 1988 through the mid 90s. However, the X Consortium moved out of MIT and became an independent organization. After an abortive attempt to have it run by somebody else, Bob Scheifler (the original lead architect on all versions of the X protocol, 1 through 11 and a true leader of the X community for many years) stepped back in and run the independent organization for several more years.
Eventually, the X Consortium faded away and transfered control of the standards into The Open Group, under whose auspices x.org now operates.
As mentioned, various implementations of the X standard, particularly XFree86, came to overshadow the standards organization. Now, the xwin.org effort looks like it will be taking up the mantle.
Jim Fulton
X Consortium staff member many, many years ago
It blew the pants off of every other NT remoting solution and led to a competition that ultimately made all of the products better. ICA got faster on LANs, WinCenter added an extension that got bandwidth consumption down to almost ICA-like levels (the NT remoting traffic had very specific patterns that could be optimized more easily than was the case for general X traffic in LBX).
WinCenter even did some rudimentary synchronization of NAS audio with X graphics. And, it supported audio input as well as output. And MIDI (Keith got inspired one weekend :-).
However, during NAS's early life, some of the more interesting multimedia-enabling technologies such as RTP, XSYNC, and others weren't widely available. So, we had to move on before we could add things like non-TCP streaming audio (essentially extension device objects that would send/receive over a separate datagram socket instead of the TCP-based control socket) and integration with the X Synchronization extension or other video playback technologies.
AudioFile had better support for managing time, but it lacked a lot of flexibility and automatic conversion that NAS provided.
In the end, some cool things were done with both NAS and AudioFile, but in reality they both were missing key design elements that really need to be there. Without a strong organization pushing them forward, they weren't going to be practical in the long run.
Leon has historically done interesting stuff, so I would feel pretty confident that his team did their homework.
Jim Fulton
former NAS protocol weanie, a looooong time ago
It was even somewhat before the wide-spread availability of UNIX workstations....
At MIT, within Project Athena and the Lab for Computer Science (remember, this was 1984, pre-X11 and pre-X Consortium days), the target platform was referred to as a "3M" machine:
The original X server was written for the Digital VS100, an intelligent (for the time) graphics display. Believe it or not, a single VAX 11/750 had several VS100s connected via fiber-optic cables. Imagine time-sharing on your PDA. :)
Jim Fulton
Give it a rest.
For what little it's worth, I wrote the pedantic section of the man page you are quoting. While we were trying to drive a little bit of brand recognition, in the 14 years since I have pulled the stick out of my butt and gotten over it. I suggest others do the same.
As is pointed out further below, the initial design point for X11 was initially local area networks. For remote access, where bandwidth is highly constrained and more importantly latency is significantly higher, a compressing and caching proxy called Low-Bandwidth X (LBX) was designed (okay, it escaped before we could give it a catchier name :-).
Early on, the most common X applications used relatively crude UIs. These were still bandwidth-sensitive (the initial design focus as 14.4kb modems and moved up to 56kb later in the cycle), but less so than you see today. As is pointed out in other postings, the more modern, professional (and usable IMHO) UIs do more round-trip requests to the X server. Which, of course, makes them much more sensitive to the latency introduced by the communications channel.
One of the main differences between LBX and its predecessors such as XRemote is that LBX attempted to do some amount of X-knowledgable caching. The hope was to find ways of reducing or eliminating some of the round trips.
So, in short, for those who are using X over remote links, you might try using LBX to see if that helps (particularly if you are running multiple applications). I'd also suggest using SSH as well if you going over a public link.
Jim Fulton
former Xhead
No, it wasn't made by committee. Like much open source software, it was the result of serial efforts by several people, all of whom contributed to make it better.
The Inter-Client Communications Conventions Manual (ICCCM) was the specification of the protocol used between applications and window managers. It controlled how applications requested placement on the screen and other functions. At the time it was adopted by the X Consortium as a standard, there weren't any window managers that implemented it.
We looked at trying to retrofit UWM to be compliant, but it was simply too primitive and really had a pretty crappy UI. TWM offered a much better foundation, so we asked Tom (nicely) if we could use it. He was gracious enough to say "yes" and the rest is (blurry) history.
Jim Fulton
Nope. RSI didn't become an issue until well after uwm was written.
They were a hold-over from the early window management functions that were implemented in X6-X10. And those were motivated, in large part, by a need to avoid key sequences used by applications (including Emacs and Ted which were among the more commonly-used editors at MIT at the time).
The keyboard model in X10 and prior versions of the protocol was modeled on the DEC LK201 keyboard that was used on the VS100 and various MicroVaxen. It had a Meta key, but lacked keys present on many other keyboards in use at the time (remember, this was before all keyboards looked like they came from off a PC).
Jim Fulton
We renamed it from "Tom's..." to "Tab..." primarily because Keith Packard and I had reworked it (read: hacked) enough that we thought Tom shouldn't be blamed for our egregious actions. Being crammed together in a tiny office yielded some weird code at times. :-)
The details are getting foggy (it was upwards of 12 years ago, afterall), but I believe I hacked in a bunch of the ICCCM compliance and various usability (mis)features, then Keith added the SHAPEd windows support. I can't remember which of us then did the tabbed titlebars, so I'll say that he probably should get the credit (although he always ran with titlebars turned off for his xeyes and oclock).
Jim Fulton
There weren't really ten full releases prior to X11R1, however there were 10 incompatible revs of the protocol. Most of the early versions were primarily used within MIT (Athena and LCS) and friendly commercial R&D labs. Here's some of the pre-history based on cryptic notes and blurry memory: X1 - summer 1984 - the first version, based on a substantial rearchitecting of the UNIX port of the W Window System (originally developed for the V Kernel). X3 - fall 1984 - used internally at MIT as the initial basis of various plotting packages for coursework. X6 - spring 1985 - first version licensed by MIT to various companies (including Cognition, MASSCOMP, and Digital) for use in commercial products. It cost $100 and if you wanted you could stop off at the (very small) licensing office to pick up your own magtape. X8/X9 - fall 1985 - added color (X8 lasted all of about a week; X9 was quickly released to fix a protocol alignment problem that impacted ports on the IBM PC/RT). Many organizations began developing ports (including a version to the Lexidata 9000 display card for VAXen that was used at the Autofact tradeshow in late 1985 to show a prototype of the first 3rd party application: a mechanical engineering design system). X.V10R1 - spring 1986 - first version released by MIT that did not require signing a license agreement. Also the first version to have a DOS Xserver developed. X.V10R[234] - fall 1986 & spring 1987 - an explosion of ports done on a variety of platforms. X.V11R1 - Sep 15, 1987 - major overall done in collaboration with folks from Digital, Sun, IBM, and other companies. Formed the basis of core protocol used today. Companies and organizations releasing X-based products used this release as a starting port for incorporating into their own distributions. X.V11R2 - March 1, 1988 - first version released under the auspices of the newly-formed MIT X Consortium. The MIT X Consortium continued to put out releases of X11 for a number of years. Then in the mid-90s, it was spun off into a separate not-for-profit organization (simple the X Consortium). As has been noted, that eventually folded into various organizations that became X.ORG. The rest is history. :)
Jim Fulton