Exploring New Technologies

Last Monday I rejoined One Laptop Per Child as Director, New Technologies. My mandate is hardware and software for the XO-3, OLPC's upcoming ARM-based tablet computer for education in the developing world. The new machine should be lower cost, lower power, more indestructible, more powerful, and potentially more expandable than ever. There are about two million machines in the XO-1 family (XO-1, XO-1.5) in the hands of kids today. The XO-3 will build upon this impressive foundation to reach further into the poorest and least-connected regions of the world.

I will kick-off my work with a series of four week-long sprints between now and eduJAM Uruguay to investigate a number of possible directions for the educational software stack on the XO-3 tablet. On the XO-1—series machines OLPC ships Sugar, an impressive collection of educational software developed by Sugar Labs. How can we best keep the best of Sugar while yanking the UI forward into a touch-friendly tablet world?

  1. This week (April 4-8) I'll begin by working on a port of the GTK3 UI library to Android. The GTK3 library contains touch support missing from the GTK2 library on which Sugar is currently based. The end goal here would be a full port of the Python/GTK-based Sugar APIs, running on something like the Honeycomb Android OS. Our existing educational activities could be ported to the new APIs without too much difficulty, but we'd largely use the existing Android OS facilities instead of the parts of Sugar concerned with low-level system management. To clarify: this is a preliminary exploration—we haven't decided to base the tablet software on Android (or anything else) yet.
  2. The next week brings a new direction. During the week of April 11-15 I will start porting Python/GTK3 to Chrome or ChromeOS via the Google NativeClient plugin. This path would result in activities which more fully integrate with web technologies—even in disconnected regions of the world. On desktop machines, Sugar activities could be run inside the Chrome browser, while ChromeOS (or another embedded OS running chrome/webkit) would provide the system management functions on tablet machines like the XO-3. As with the Android port, this is an exploration, not a definite software direction.
  3. The week of April 18-22 I hope to focus on mesh networking. This has a somewhat checkered history in our deployments; I hope to identify the remaining roadblocks and map a way forward to make this a flagship feature of the XO-3 software.
  4. The week of April 25-29 is for the existing Python-based Sugar codebase. In order to continue moving forward, it needs to migrate to GTK3, gobject-introspection, and some other key enabling technologies. I believe it would also benefit from language-independent APIs and better modularization to allow a more incremental migration path.

The following week is Conozco Uruguay and the Uruguay EduJAM where I'll present my progress on these initial exploratory projects and discuss the path ahead with the wider OLPC and Sugar communities. Clearly, a week each is not enough time to finish any of these projects! But the focused effort should help to better identify the promise, roadblocks, and challenges in each of these paths, which then in turn will help us to plan the future.

Improving Hunt Software/Improving Google Docs

There's been a lot of discussion about publishing and sharing the software that Mystery Hunt teams use to collaborate to solve puzzles. This is mostly misguided, IMO: teams are very different, and they organically grow solutions to fit their unique processes. On the other hand, an increasing number of teams (including my team, Codex), are building their collaboration software on top of Google services, especially Google Docs and Spreadsheets. Rather than trying to collaborate on One True Hunt Team Software, I think it would be far more useful (for all teams) to lobby for improvements to Google's services. These raise the bar for everyone, and indirectly benefit many other people with collaborative processes.

So here's my list of improvements I'd like to see in Google services:

  1. Integrating Docs and Spreadsheet. If we had an initial "sheet" of the spreadsheet with editable formatted text (not spreadsheet cells) we could actually do away with the wiki we use for capturing free form thoughts and links related to a puzzle.
  2. Integrating Spreadsheet chat, Google Talk, and Jabber. We could just use the chat in the spreadsheet if it were open and accessible, instead of creating our own per-puzzle chat rooms.
  3. Making publish and "setAnonymous" access available via APIs that actually work. We need to use Google Doc Script to do the setAnonymousAccess call, which is not exported via the otherwise-more-complete GData APIs, and drive a headless Firefox 2 instance via Selenium to get the publish bits enabled for the spreadsheet. That's ridiculous.
  4. Providing a way for Google Doc Scripts on a spreadsheet to export data more easily. We can use a Google Form to create a spreadsheet for a puzzle, but no easy way to provide a link to that spreadsheet on the page that results after form submission, or redirect from there.
  5. IIRC Google Talk support for multi-user chat is still barely supported. It doesn't use the standard Jabber protocols, for one. If this were a better supported/more standard service, we wouldn't have to run our own Jabber server.
  6. And, of course, the "next generation" of all this would integrate audio and video into the chat as well. Video is probably more useful, as it communicates human emotional cues. Audio isn't easily archived or searchable, and doesn't work well in crowded rooms, so it is less useful to us. But it would be great if we could actually see some/many/most of the particants in ringhunters, maybe little live video icons next to their faces.

Any further suggestions from other teams?

Adopting an IFRAME

Warning: heavy geek content.

Google recently rolled out a new Gmail feature: if you pop open a new little compose or chat window, and then close your main window, the small child window doesn't go away.

This is a pretty esoteric little tweak, but the underlying functionality is quite profound: in order to make this feature work, the entire document context (all the JavaScript responsible for running Gmail's UI) needs to get teleported from the main window out into the child window. For speed and memory reasons, you don't want to run a copy of the main code in the child window — no, you want to wait until just before you close the main window and then instantly teleport the guts of the main window over to the child. How's Google doing that?

In the browser model, separate windows are usually separate security contexts, safely sandboxed from each other. So this magic teleportation trick is also creating a wormhole between the different security domains. My curiosity was piqued, but Google (both blog and search engine) was strangely silent on how their new trick was pulled off.

Here's the story I eventually discovered. Google had long been thinking about a way to make this feature work. Their initial proposal was something called GlobalScript (or sometimes, "SharedScript"). This proposal met resistance and a new simpler solution was found: the "Magic IFRAME".

The guts are hidden inside bug 32848 in webkit's bug tracker. You put all of your application's good stuff inside an <iframe> element — we've guessed that already. You pass your child window a copy of that IFRAME, something like:

function doSomethingCoolThatNeedsANewWindow() {
     var childWin = window.open(...);
     childWin.onload = function() {

Now, the crux: when your main window is about to close, you just adoptNode the shared <iframe>:

// adoptNode in this case does removeChild() internally
// but does not unload the content

Voila! This used to completely unload and reload the iframe, erasing the existing application context, but with this one small hack Chrome (and now Safari, too) suppresses the reload and allows the untouched <iframe> context to teleport over to the child.

This doesn't work on Mozilla yet. And it's a pretty ugly hack, tweaking the behavior in just this one narrow case. (And Mozilla is a little bit cranky about adoptNode() being used without an prior importNode().) But this hack also allows work-arounds for two other long-standing iframe-reparenting "bugs". It suggests that <iframe> is now the <module> tag Crockford wanted, especially now that the <iframe> can be sandboxed in various ways as well. By putting each piece inside an <iframe> you can now build a robust module system for browser JavaScript.

Chrome OS, litl, and OLPC
Well, Google just announced Chrome OS, to be available next Christmas. Some parts of it are very similar to what you can already put under the tree this Christmas from litl (actually, you can buy one right now) — and other parts are familiar from my time at OLPC. For example, the legacy-free BIOS and signed bootloader are what OLPC shipped two years ago on the XO-1. The XO-1 was not an "always connected" device, though — in fact the opposite: it assumed connectivity was infrequent and low-bandwidth. At OLPC, the signed code scheme was part of an theft-deterrence system, crucial for OLPC's target third-world deployments. It wasn't very popular among our first-world users, and I'm not actually sure why Google implemented it for Chrome OS. Phone company lock-in (due to largely misplaced concerns about maintaining the integrity of their networks) are why phone apps are locked down with signature schemes; this isn't necessary (and verges on Evil) for what's intended as a general-purpose computing device.

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.

Sugar waves: time to get started!
While I was abroad, it seems that Google released their wave server/federation code. So you can now get started tackling some of the projects I outlined in my previous post on Waves and Sugar: getting a basic federation server running on the school server and/or writing a server running locally on the XO which exports the content of the Journal/filesystem for collaboration. I'm hoping someone other than me thinks this is an exciting idea, and runs with it!

Google Wave and Sugar: what's next?

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.

Fun things to do with your domain

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.
Tags: ,

Google's Evil NDA

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.

Tags: , ,