cananian

The somewhat oddly-technical (and often slightly-wrong) middle section of the Chrome OS presentation veered off at one point about filesystem partitions (!) and how having a read-only partition is a novel feature of their OS. Read-only partitions are one of the oldest security mechanisms — my boot floppy had the write-protect notch taped over back when I was booting DOS — and a near-universal feature of thin-client deployments (which Chrome OS certainly is). OLPC maintained a mostly-read-only root, but primarily to extend the lifetime of the flash disk (flash lifetime was not touched on in the Chrome OS presentation). Litl mounts a read-only root with a writable unionfs on top, which actually works much better in practice: improved maintainability because all the various Linux system daemons can still "do their thing" as they expect, but you can wipe the top partition whenever you like to return to a clean state (at litl we do this on every update). (If you haven't hacked the lower levels of a Linux distribution, you'd probably be surprised at how many system daemons assume they can write various places in the root partition, and you really don't want to maintain hacked versions of all of them.) Since ChromeOS gave an Ubuntu shout-out at one point, I strongly suspect the unionfs scheme is actually what they are doing as well — and, for that matter, what all the other Ubuntu Mobile downstreams are doing. Not new.

The emphasis on a read-only root partition is rather misleading from a security standpoint (as much of the middle portion of the presentation was). If you're not storing your files locally, it doesn't mean that you suddenly have no security concerns. It just means you have different security concerns. Cross-site scripting attacks give a malicious website access to your Google account through your web browser: these sorts of things are the malware for a WebOS. You have a different attack surface, but a vulnerability in your browser or flash plugin still gives access to private data. Mentioning that they encrypt the data on disk seems to be pure snake oil: your browser has access to the unencrypted data, and that's your most vulnerable surface anyway.

Overall, Chrome OS is a nice validation of some of the cloud-computing ideas we've been working on at litl, and it's always nice to see more legacy-free hardware (like the OLPC XO-1 and the litl webbook), but the presentation was oddly underwhelming. They're not really "reimagining the PC" — they're just removing all the applications on the PC except for Chrome. You still interact with "the PC" the same way you currently interact with Chrome. For reimagination, watch the videos at litl.

So, yesterday I posted a entry discussing how Google Wave actually implements the collaborative vision Sugar (and OLPC) were working towards. (It's a shame we didn't have better contacts with Google while I was at OLPC; Google was actually on OLPC's board, and beta-ing Waves would have been a very fruitful partnership.)

If you agree with the premise: what should the next steps in a Waves-ification of Sugar be? Eventually Google promises to release "the lion's share" of its source code, for both server and client, so getting the google server installed on the school server is one task — but not one which can be done immediately. Implementing Network Principles is another necessary precondition, in order to use Wave's DNS-based participant naming system ("SuzyQStudent@lima.peru.schoolserver.laptop.org" or whatever). That's something which can be done now. What else?

Eventually, when the source code drops, making the waves client work offline would be important, since Waves (and embedded gadgets) basically replace Write and Sugar's bulletin board. Waves edit XML trees, so porting existing activities to use XML-based file formats will go far in integrating them into a new Wave World Order. I haven't seen any demo of a waves-based drawing activity/gadget (tuxpaint is a favorite of most kids), so Waves Paint would be a fun project if you want to start playing with the Waves extension APIs.

More controversially, work on Waves-enabling a next-gen Journal could be interesting. As predicted by proponents of the Journal for some time, the "wave of the future" (so to speak) is filesystem-independent storage. Waves in Google's demo are titled and searched like email messages, not as "documents" in a filesystem hierarchy. However, we had repeated requests to unify Journal storage and traditional filesystems, for (a) better interoperability with existing systems, and (b) sneakernet collaboration. In my mind, this would mean exporting a waves-like view of an existing filesystem, as I proposed for the Journal, where directories are interpreted as slightly-special tag markers. One could imagine implementing a "Wave Server" based around this idea, in effect using the filesystem as the wave database. With the magic of Wave Federation, these "filesystem" waves can interoperate with other wave clients and servers. This standalone file-based server might also server as the basis for "one child under a tree" wave editing. (For that matter, a robust sneakernet implementation of the Wave Federation Protocol would also be very useful!)

Exciting times! Wave promises to bring OLPC/Sugar's vision of ubiquitous collaboration to life at long last. Google has the funding and development resources to tackle what is in effect a bottom-up reorganization of the software stack. OLPC/SugarLab's role is peripheral but vital: strongly lead the development of offline or "flakey connectivity" aspects of this technology so that it can be used everywhere from the solar-powered jungle to the dense urban cities, and to provide the educational software on top of the platform so that kids can *learn* as they collaborate and create.

Well, the "Google NDA" post has been at the top of this page for a while, and it looks like it's not exactly going to be tomorrow that I get to post about (a) the fact that I've gotten my thesis receipt and am totally done with this PhD (that will be next week), or (b) what exciting thing I'm going to do next (that's waiting on the results of the previously mentioned Google interview, among other things). When media talk about "balance" it usually just means that they've punted on the idea of discovering "truth" and are about to give falsehoods equal time. But that's not what we mean here, dear Reader! Notwithstanding my real gripes with their aggressive (and not obviously-enough optional) pre-employment NDA, here are some more Googly bits for "balance":

• Google Apps for your Domain is really great. If you've got a domain name sitting around underutilized, you can make the bits point to google, and google will then host page creation tools, email, and even calendaring for you. In my case I've let Google loose on ananian.com, to manage email for the domain behind the scenes. Addresses at ananian.com can get forwarded elsewhere or else my family members can use gmail on the ananian.com domain. I haven't really played around with the web page creation tools, yet, but it's gotta be better than what I'm putting up on that site at the moment (ie, nothing much!). It handles domain aliases (ananian.org, ananian.net), catch-all addresses, and SPF anti-spam measures, too. Groovy.
• The mobile version of Google maps is really nice, at least on my Treo. The other mobile Google services are more of a mixed bag: I'm still waiting for a nice mobile version of Google Calendar (the SMS gateway is better than nothing, but I get charged for SMS), and mobile Gmail 1.1.0 worked great on my Treo, before the latest 1.1.1 release crashed and burned, making it obvious that Google isn't actually reading their support forum. (Or is there some other place I'm supposed to report that "your 1.1.1 JAR file is corrupt"? A newsgroup is not a bug tracker!)
• OK, this isn't Google, but I just stumbled across Project Honeypot, which has some simple steps you can take to help nab email harvesters for spam.

Tomorrow I am going to interview over at Google. Before I do so, I need to sign an NDA which states, among other things, that I'm not allowed to tell anyone I'm interviewing over there, or indeed, to mention the name of Google at all. So I'm going to do all that now and get it out of my system, so I'm not tempted to violate the agreement after I've signed it. Since linking the entire NDA would likely violate Google's copyright on the document, I'll just quote sections of it below:

• The biggest flaw, to my mind, is the lack of any expiration date. Clause 8, "This Agreement shall remain in effect until such time as all Confidential Information of Google disclosed hereunder becomes publicly known and made generally available through no action or inaction of Participant." Since some of the information "disclosed hereunder" will only ever be known to me and Google (see next bullet), this means that the NDA lasts forever. Technology moves fast — certainly it must be possible to put some time limit on the information I might (inadvertently) receive. 3 years? 5 years? 10? 20?
• The definition of "Confidential Information" in section 2 includes, "the terms of any agreement and the discussions, negotiations, or proposals related to any agreement." So, according to the NDA, I can't even tell my mother (not an "employee, director, agent, or third party contractor", even if she signs a Google NDA herself) what salary or options are in any Google offer. I'd like to ask my friends at Google, say, what ballpark compensation I might expect, but under the terms of their NDAs they couldn't tell me either. Further, since it's highly unlikely that the terms of my offer become "publicly known ... through no action or inaction of Participant" this bullet combined with the previous makes the agreement eternal.
• I can never mention Google again in any public statement after I sign this NDA:

  4. Participant agrees not to do the following, except with the advanced review and written approval of Google: (a) issue or release any articles, advertising, publicity, or other matter relating to this Agreement (including the fact that a meeting or discussion has taken place between the parties) or mentioning or implying the name of Google."

  So, after I sign this NDA, I can't tell you that I've done so. (Luckily, I haven't signed it yet.) I have crossed out "mentioning or implying the name of Google" in my copy, as I simply cannot in good conscience promise never to "mention or imply the name of Google" in public (say, on this blog) ever again. What lawyer wrote this crap?
• The third clause of item 4, whose first clause is above, is:

  [4] (c) reverse engineer, disassemble, decompile, translate, or attempt to discover any prototypes, software, algorithms, or underlying ideas which embody Google's Confidential Information.

  As the NDA is very loosey-goosey about what, exactly, Google considers Confidential Information — nowhere in the NDA does is say that Confidential Information will be marked or identified in any way — this may effectively forbid me ever to take apart any of Google's software. US law allows me to (for example) reverse engineer for compatibility (what Ed Felten calls the Freedom to Tinker), and as a practicing computer scientist I'd rather not forfeit those rights for all time for all Google code. Time-limiting the NDA or clearly marking Confidential Information may have made this term less objectionable. One may also attempt to argue that "Confidential Information" is limited to stuff I directly observe or is presented to me — for example, if I'm told that there's some secret at the heart of Google Mail, I can't ever "view source" in my browser to try to discover what it is, but that I'm still free to view the source of (say) Google Calendar. I'd prefer that to be the case, but the language used in the NDA is:

  2. Google may disclose certain information under this Agreement it considers confidential and/or proprietary concerning Google's business and/or technology ("Confidential Information") including, but not limited to...

  Is the Confidential Information only that information which Google discloses, or is there a broad swath of Confidential Information owned by Google, some of which it may disclose, but all of which I'm forbidden to "attempt to discover"?
• Finally, item 5 provides that "If Confidential Information is required to be produced by law, court order, or other governmental demand... Participant must immediately notify Google of that obligation," regardless of the fact that disclosure of a National Security Letter is illegal. Not that this possibility is likely, but it is just one more term with which it could be impossible to comply.

I have signed NDAs with other companies which seemed entirely reasonable. The Google NDA, however, seems to fly directly in the face of Google's reported "Do No Evil" motto. What's more, after tomorrow I may be entirely unable to complain about it — and I expect that current Google employees are similarly contractually bound not to comment. But while I can, let me say: this stinks!

UPDATE: A quick google for "Google NDA" turned up several more complaints about the Google NDA, such as this one from Colin Percival. Valleywag reproduces the entire Google NDA, so you can read it in its entirety yourself. Further, I've written an amendment to the NDA which remedies its faults as I see them. If I can get Google to agree to at least term 2 of this amendment, then you'll hear about my experiences here tomorrow.

UPDATE x2: I crossed out some terms before I signed the NDA this morning. At the end of the interview (4 or so hours later) my recruiter returned to tell me that he'd talked to his supervisor and it turns out that I could have not signed it at all. (Thanks for checking, Jeff!) They'll still talk to you if you decline. In fact, when you arrive at Google they ask you to sign a different NDA (a much less evil one) in order to get a visitor's badge, and it turns out that you can decline that as well: your badge will have a big red "No NDA" label or some such on it, but no harm done. So, my advice to future interviewees: be brave! Just decline the NDAs, and ask your recruiter to check with their boss if that makes them nervous. It would probably be a good idea to warn your recruiter first if you plan to do this, so that the boss-checking won't throw off the schedule. It will be all right.