A few days ago, I posted to Twitter a picture I took of a Google Glass unit running software that I had modified. I did this while in the Bay Area after picking it up from Google's headquarters in Mountain View. I was unable to provide many more details at the time, as I first was busy driving home, and then became caught up responding to a large amount of feedback caused by press surrounding my picture.

My motivation for posting that picture was, in my mind, fairly simple: I have a large audience of users who are interested in device customization, particularly stemming from the idea of modifying the code of popular consumer devices (such as the iPhone). Some developers I work with had posted the night before that I was looking at Glass, and my post was an update on what I had done.

The context for many reporters who saw what I posted was somewhat different, due to statements made by the Executive Chairman of Google the day before that Glass would be a relatively closed platform for developers. In contrast, engineers, developer advocates, and technical leads at Google have been trying to make it clear that Glass is designed to be an open platform. The result was difficult to navigate.

In this article, I describe what I did, why I did it the way that I did it, and how people who own their own Glass can do the same thing. In the process, I explain the mechanism behind a security exploit in Android 4.0 that had been disclosed last September (this is the bug I used to modify Glass, not fastboot). Finally, I take a look at some important considerations on the security of this device that I find quite concerning.

What is Google Glass?

Glass is a new first-party hardware product designed by Google. It is a head-mounted computer that sits on your face very similarly to a pair of glasses (resting on your ears and your nose). It has a camera, a display, a touchpad (along the right arm), a speaker, and a microphone. The display is projected into your right eye using a prism, and sound is played into your eardrum from above your ear via bone conduction.

While Glass looks very different from any other device, it runs an operating system that is now very common: Android. That said, it isn't quite the same as the Android that you see on phones and tablets: many of the higher-level applications are not present and have been replaced with the Glass UI (which is controlled by voice and gestures). (This is analogous to how the AppleTV runs a modified UI on top of iOS.)

Glass costs $1500, but is not yet generally available. Currently, Glass is only available to a limited number of "early adopters" as part of something they call the "Glass Explorer Program". The device currently being sold is the "Glass Explorer Edition"; one would expect that Google will learn from peoples' reactions to it and make modifications for the final units put into general release.

How did you get your hands on one?

Recently, Google ran a contest on Twitter where people were asked to post messages using the hashtag #ifihadglass that had a cool idea for what they could do if they were given a device (winners were not just given a device, though: they still had to pay $1500, which according to an article published by Android and Me, many did not realize). (Sadly, as described in a post on Forbes, not all entries were very pleasant.)

While my post on Twitter from a few days ago used the #ifihadglass hashtag (making a joke that "#ifihadglass I would jailbreak it and modify the software"), I had not ever actually entered this contest. I explain this, because at least a few people on Saturday thought that by posting that message (or by modifying the software on the device at all) I was violating the purpose and spirit of the competition.

Instead, at Google I/O 2012, Google was allowing any attendee to "pre-order" one. While they couldn't accept your money that far in advance (a restriction enforced by credit card companies), attendees of the conference who signed up would be given the opportunity to buy one (for $1500) whenever it first became available, something Google expected to happen sometime in the next year (before I/O 2013).

The one restriction was that you had to have a "business purpose", as they did not have the required FCC licenses in order to distribute the product to "consumers". They were not requiring you to use it for development, and I made it clear to them at the time that I did not intend to develop for the device normally. My business (SaurikIT) builds tools to modify software, and I'm always looking for more test devices.

Can developers write apps for it?

Yes: Google provides an official way to develop software for use with Glass (which they call "Glassware"): the "Mirror API". Unlike with other mobile devices (such as Android phones and tablets, or devices from Apple running iOS), software for Glass is not run on the device itself: instead, the developer is given access to a web-based API that allows them to integrate over the Internet with the user's Glass.

Further, Eric Schmidt, the Executive Chairman of Google, as reported on Thursday in a release by Reuters, stated in a talk at Harvard that Google was intending to have a closed software ecosystem for Glass, where Google will have to pre-approve all software offered to users by developers. "It's so new, we decided to be more cautious," Schmidt said. "It's always easier to open it up more in the future."

Looking back, two weeks ago Google released guidelines for developers of Glassware, which an article from the New York Times goes so far as to say "emulates Apple in restricting apps". "To begin, developers cannot sell ads in apps, collect user data for ads, share data with ad companies or distribute apps elsewhere. They cannot charge people to buy apps or virtual goods or services within them."

It is this context that must then be kept in mind when reading the numerous articles that hit the press on Friday regarding my demonstration of a Glass running modified software: if you were wondering why the press ran so far and so hard, turning it into what seemed like a major story, it is because just the day before it had come straight from the top of Google that Glass would not be an open platform.

Now, that said, Google generally likes open hardware, and it seems to me like Glass will not be an exception: at least the units currently being distributed as part of the early-access program have features (such as "Debug Mode") that demonstrate they are intended to be relatively-open devices. This was made clear by me to reporters I spoke with, and frankly the stories largely (but not entirely) got this right.

What is the "Debug Mode" feature?

So, when I picked up my unit, there were two "Glass Guides" who walked me through its use. At one point, they asked me to open Settings and select Bluetooth, so we could pair it with my iPhone. While there, I became curious about the "Device Information" menu, under which I found a setting "Debug Mode". The option had the Android logo next to it, and could be turned "on" and "off" (it was off).

I asked the primary guide what it did (specifically asking whether it would give me access to the device via adb, the Android Debugging tool), and she told me that she wasn't certain; I believe she said that she hadn't seen that option before (although I don't quite remember; she may have just not known what adb was). I turned the feature on (of course), which seemed to make her somewhat uncomfortable.

The second guide was slightly more technical, so when he returned a little later I asked him about the Debug Mode option. The reaction was interesting: he kind of looked at me, somewhat confused, and asked "wait, what version of the software does it report in Settings"? When I told him "XE4" he clarified "XE4, not XE3", which I verified. He had thought this feature had been removed from the production units.

After a quick explanation that he must have not paid enough attention to the release notes, he told me that with Debug Mode enabled you could use a three-finger tap on the control area to file a bug report with the Glass team (while doing so, he demonstrated the action, which had a humorous result of him accidentally sending a bug report himself, which he then seemed somewhat abashed about).

In fact, the Debug Mode option is the equivalent of the typical Android "Enable USB Debugging" option: it allows you to connect to the device over USB via adb. This tool allows you to manage the applications installed on the device, watch a detailed log of events occurring on the device, and get access to a shell (much like the Command Prompt on Windows, or even more closely, Terminal on Mac OS X).

Some people stated that adb allows one to get full access to the device, particularly due to a few articles that mentioned a command "adb reboot-bootloader". In fact, adb itself is fairly restricted. What that command does is reboot the unit; when it boots back up, it starts into a special mode known as "fastboot". (On most Android devices, this is accomplished by holding down some buttons during boot.)

What is fastboot (and "oem unlock")?

The first piece of software that runs on devices like this is the "bootloader", a fairly small piece of software stored directly inside the device that has the job of loading the operating system that will be used and starting it. The default bootloader for Android provided by Google is called "fastboot". Some devices provide their own alternative bootloader; some of those support fastboot as a second option.

When you boot in the fastboot mode, rather than continuing into the operating system, fastboot stops and makes itself available over USB. You can control the bootloader using a program provided by Google that is also called "fastboot". This allows low-level device access. (For people reading this from my iOS audience, it is reasonable to think of fastboot as the functional equivalent of "DFU mode".)

One of the commands available via fastboot is "oem", which allows manufacturers to provide custom commands; everything after "fastboot oem" is sent to the device without modification. By default, fastboot is "locked", and only a subset of the available commands can be used. Some devices provide oem commands that will unlock the bootloader (possibly requiring a password or other secret data).

The most common command to unlock the bootloader is simply "unlock". On most devices that provide this command, a menu will be displayed that explains that by unlocking the bootloader your warranty will be voided, and that it is disrecommended by the manufacturer. It also has a side effect: it will delete all of your personal data stored on the device (I mention this in more detail later, and explain why).

In order to enforce that your warranty has been voided (as well as to make it more clear to the user that something has changed), devices that have unlocked bootloaders will also generally display some kind of image making this clear as the device boots. I like to call this image the "unlock of shame". I am not certain whether Glass has such an image, but I would presume it to be similar to other devices.

Once the bootloader is unlocked, you can use it to get full access to the device, in particular using "fastboot flash" to install different or modified operating systems. In a way, having access to an unlocked bootloader is the be-all-and-end-all of power. The things I wanted to accomplish require access to the "root" (administrator) account on the device, and fastboot is powerful enough to make that happen.

However, I did not use fastboot; in fact, the bootloader on my device is still locked (and I would prefer not having to unlock it, for reasons more complex than "it would delete all of my data", which I also discuss in more detail later). Regardless, the truth of the matter is that while fastboot technically allows you to get root on Glass, as of Thursday night it was not an easy or viable option for various reasons.

Why didn't you just use fastboot?

In order to get much value out of fastboot, you need to have an operating system "image" you can ask it to either store for later use or immediately boot. This image is similar to a bootable CD that you might place in your computer: it is a self-contained operating system. In the case of Linux, this will be a "kernel" (which includes any required device drivers) and, embedded inside of it, a filesystem.

In order to make one of these, you need a kernel that is compatible with the device. By far the easiest way to get a working kernel is to just dump one from a working device. However, fastboot actually doesn't provide this as a feature: you have to do it after the device has already booted, and this requires you to already have root access. In essence, this is a catch-22 situation: we need root to get root.

Sometimes the manufacturer of a device provides a set of "stock images" (which is really convenient if you accidentally mess up your device: you can then easily restore it to a pristine from-the-manufacturer state via fastboot). This isn't common enough, but Google normally does release stock images for all of their Google-branded devices; they have not, however, done it for Glass. They may very well do so later on.

The other option is to construct our own kernel: Linux is open source, so anyone can, without that much difficulty, compile their own from scratch. However, you need to know what kinds of hardware components (both obvious things such as the kind of CPU, as well as subtle things like the model of the network card) the device is built out of, along with any other hardware-specific configuration information.

What kept you from building a kernel?

The easiest way to get this required information is to ask your device to provide it for you: Linux provides a way for the full configuration to be included in an easy-to-find manner (a virtual file, /proc/config.gz). Google, however, disabled this feature on Glass, so the fact that we have access to the device via adb is unhelpful for this purpose. Alternatively, one can get this information from the manufacturer.

It is actually a requirement that the manufacturer of a device using the Linux kernel provide this information (along with the full source code for the kernel, as modifications may have been made), but Google had not yet done this as of Friday morning (when I posted the picture of a modified Glass). It was not posted until Saturday (after which point many people didn't realize the delay).

This is actually quite common, and honestly I do not begrudge them at all for the delay: Apple is much worse about compliance, and only in a couple cases have I ever felt the need to complain. In this case, according to someone from Google in charge of "open source compliance": "The GPL source should have been posted already (13 days ago, in fact), but it looks like the person who was to do it went on vacation first."

Of course, we could always attempt to guess-and-check our way to a compatible kernel, but this is hard and somewhat risky. I asked Koushik Dutta, the developer of ClockworkMod (a very popular recovery image used on rooted Android devices) if he had any tips on how to proceed in this situation; he said he "definitely wouldn't want to try to hack and slash at putting a kernel together for some random device".

Many people were rather confused by this (including a technical lead at Google who wrote "we intentionally left the device unlocked so you guys could hack it and do crazy fun shit with it. I mean, FFS, you paid $1500 for it... go to town on it"): the source code is supposed to be available, and so an unlocked bootloader should be sufficient. In this situation, however, it simply wasn't practical to use this to get root.

How did you actually get root access?

At this point, I could have simply complained to Google in order to obtain the source code for the kernel. However, I expected that would take days (Google actually ended up posting the code within hours on Saturday, but that was under rather large public pressure), and had no guarantee of even being successful (I am not certain the GPL applies to restricted releases; Glass isn't really publicly available yet; IANAL <- edit: a "Licensing & Compliance Manager" from the FSF reached out to me to clarify that "yes, the terms of the GNU GPL still apply").

To be very explicit: I was not bothered by this, nor did I complain about it on Twitter; if anything, I found it to be an interesting challenge. I like hacking on devices, and despite having an unlockable bootloader, it turns out that Glass posed a challenge to get the access required to modify its software. (Besides, as described in more detail later, I generally prefer to not unlock my bootloader.)

So, I decided I'd look to see if any known exploits would work on the device: Android devices tend to not get updates very quickly and often come from the manufacturer running an old version of the operating system. This has allowed many devices that might otherwise be locked down to get hacked: universal exploits that work on every device running particular versions of Android have been surprisingly common.

Last August, I actually had implemented an exploit for Android (mempodroid, using the mempodipper exploit described by Jason A. Donenfeld, attacking a bug discovered by Jüri Aedla). Sadly, it was fixed in Android 4.0.3 (Glass runs 4.0.4). Thankfully, a Google search for "Android 4.0 root" turned up an article published by The Next Web from September about an exploit that affected all versions of Android 4.0.x.

This exploit, which doesn't have a name (and so will be referred to indirectly), was developed by a hacker named Bin4ry. It isn't clear that it is "his exploit", though: he credits the idea to "Goroh_kun and tkymgr". It is Bin4ry's implementation, however, which I downloaded and analyzed: I needed to figure out how this exploit worked, to see if it would work on Glass, and if not to adapt it until it would.

How does this exploit work?

The way it works is, humorously to me, somewhat similar to one of the first stages of the evasi0n exploit used to jailbreak iOS 6: it involves something called a "symlink traversal" that can be triggered while restoring a backup to the device. In the case of evasi0n, you constructed, modified, and restored multiple backups, one to setup the symlink, and the second to do the traversal: here, we rely on a "race condition".

So, on Android, you can use adb to take a backup of the personal data associated with any installed package, and then later restore that data. When you restore the data, it first deletes all of the personal data that is already there, and then it extracts the data that is stored in the backup. The backup itself is a compressed "tar" file (conceptually similar to a zip file, for people who haven't heard of tar).

To explain, a "symlink" (short for "symbolic link") is a special kind of file that isn't really a file at all: it is like a sign post that tells the computer to go use a different file instead. If you have a directory or folder that is a symlink to a different one, when you go into that folder you will end up in the one that it refers to. If the backup is then extracted on top of a symlink, the files will end up in the wrong place.

We can't place this symlink ahead of time, because the first step is to delete the old data. We also can't place it into the backup itself (as is done with evasi0n) because even though that is possible in a tar file, the restore system on Android doesn't know what to do when it finds that special kind of file in the backup data. We thereby need to drop the symlink while the restore process is taking place.

We call this a "race condition", because we now have two activities that are racing to the same place, and depending on which one gets there first (the restore process, or our attempt to place the symlink), we may get either intended or problematic behavior. To make the timing more deterministic (ensuring we always win), we make the backup "very large", slowing down the process of the restore, giving us more time.

The file we try to overwrite with our backup is /data/local.prop, which is stored on a part of the device that can be modified, but only if you are root. Inside this file, the goal is to place "ro.kernel.qemu=1", which will make the operating system believe that it is running not on real hardware, but instead on the emulator shipped by Google for developers to test their apps more easily (a program called "qemu").

To make this work, we need to find a package that both allows its data to be restored from a backup (packages can opt out) as well as is owned by root (so that the backup is extracted as root, which is required in order to write to /data/local.prop). On most Android devices, the Settings application fits the bill. On Glass, there is no Settings, but we got lucky: the Glass Logging service satisfies both criteria.

How can I use this exploit myself?

This exploit is simple enough that you can pull it off with just a couple files, and without any specialized tooling. In order to proceed, you need only have the Android SDK (which comes with a copy of the adb utility) installed on your computer, and two files from me: exploit.ab (the exploit payload for use with adb restore) and su.

As this process involves doing a restore of the personal data stored for the Glass Logging service, we must first do a backup of any data that we already have stored for it (as it will be deleted). We do this using adb's backup command, to which we will pass the name of a file to store the backed up data and the name of the package which we want to back up. In this case, that is "com.google.glass.logging".

$ adb backup -f backup.ab com.google.glass.logging

When we run this command, Glass will show a dialog (through the prism, so make certain you are wearing your device) verifying that we want to make this backup and asking if we would like the backup to be password protected. In this case, you should just use your Glass's touchpad to scroll to "Back up my data", and select it (by tapping). The command on your computer will then complete.

Our next step is to set up the race condition. As part of this exploit payload, a folder will be created in the data area for the Glass Logging service in which anyone, even the otherwise-restricted adb shell, will be able to create new files. We will run a command in the adb shell that will attempt to create the symlink, repeating over and over until it succeeds as the folder is created.

$ adb shell "while ! ln -s /data/local.prop \ /data/data/com.google.glass.logging/a/file99 \ 2>/dev/null; do :; done"

While that is running (so leave that alone and open a new window) we now need to start the restore process of our modified backup payload. We do this using adb restore. This command (which will exit immediately) will cause another dialog to appear on the display of Glass, so make certain you are still wearing your unit: you will need to scroll to and select the "Restore my data" option.

$ adb restore exploit.ab

After a few seconds, the previous command (the one attempting to place the symlink) should have completed. (As the timing on this is fairly deterministic, we can feel rather confident that it "worked", but if you want to make certain before proceeding, you should verify that /data/local.prop has now been placed on your device. If not, delete /data/data/com.google.glass.logging/a and try again.)

Before we proceed, we should restore the backup we had made of the previous contents of the Glass Logging daemon. This not only cleans up any mess we left (such as the 50MB of backed up files that we extracted as part of the restore), but also will put back the previous (potentially important) personal data for this system service. You will again need to approve this from the device.

$ adb restore backup.ab

At this point you should reboot your Glass. When it comes back up, there may be some errors displayed regarding the Bluetooth system having crashed or otherwise failed: this is because the emulator (which Glass now believes itself to be running inside of) does not support these features. We thereby need to copy our su binary to the device, make it privileged, undo our hack, and reboot.

$ adb reboot $ adb shell "mount -o remount,rw /system" $ adb push su /system/xbin $ adb shell "chmod 6755 /system/xbin/su" $ adb shell "rm /data/local.prop" $ adb reboot

Now, when your device reboots, you should no longer get any errors. Your adb shell will also now be restricted as it was before, as the device no longer has our modified properties file. However, as we have installed "su" and marked it with the right privileges, you will be able to get root access whenever you need via adb. You can now install more complex su utilities, and have some fun.

Should I now go unlock my bootloader?

This is up to you; many people would say "sure, that's what it is there for", but my recommendation is actually to avoid unlocking your bootloader unless you are left with no easy alternatives. You certainly do not need to unlock your bootloader right now: you already have root access. You can always unlock the bootloader if you ever decide you need or want to: you don't have to make this decision right now.

As mentioned earlier, in the process it is going to delete all of the data on your device, which might be irritating (you will lose your timeline, and have to reconfigure everything). The device also displays its status (locked, unlocked, or on some devices "re-locked"), allowing the manufacturer to easily deny warranty service to your device. Finally, I'm going to argue you will want to re-lock it anyway.

The process of re-locking your device is similar to unlocking it: "fastboot oem lock", and the device is immediately "re-locked". On some devices (not the Nexus 4 I tested), this state is separate from "locked", allowing the manufacturer to know it was previously unlocked. With a re-locked bootloader, you can keep running your modified software, but you cannot use fastboot to modify it again without re-unlocking.

The reason you would want to do this is that while your device has an unlocked bootloader, you have no way to be confident that your operating system hasn't been modified by someone while outside of your control. This is because anyone can, after booting your bootloader-unlocked Android device into fastboot, boot or flash any custom image they want. It doesn't matter how secure the operating system is: fastboot is accessible.

You might think you would notice if someone installed a different version of Android to your device, but the attacker needs only modify your existing software: they can access the device's filesystem and install a slightly modified version of any of the software that you might use. On many Android devices there are security mechanisms to guard your private data, but the system software is left unencrypted and can be modified.

Why do you consider that a problem?

This means that if you leave your device in someone else's hands, and it has an unlocked bootloader, with just a minute alone they can access anything you have stored on it. While on most Android devices there is a PIN code that protects your personal data (encrypting it, as of Android 4.0), it doesn't take long to programmatically try every possible PIN code (on iOS, the four-digit code takes ten minutes to crack).

That said, getting ten minutes alone with your device might be more difficult than getting just a minute. Sadly, they don't actually need all that time: all they need to do is modify your device to automatically upload all of your contacts to a server the next time you pick it up and start using it. They can even leave software that allows them to remotely access it at any time, getting your location or even taking pictures.

(One way of looking at this, for readers that have a background in iOS attacks, is that unlocking your bootloader using "fastboot oem unlock" can be thought of as opening up an exploitable bug in your bootrom; the things you can do to a device that has had its bootloader unlocked are comparable to the things you can do to an iOS device susceptible to the limera1n bootrom exploit, such as an iPhone 4.)

The way you are normally protected from this is that, in order to use fastboot to steal your data, the bootloader must be unlocked, and the process of unlocking the bootloader deletes all of your data. (So, if you were wondering earlier why that feature requires you to delete all of your data, this is why: it is to protect you from malicious people unlocking your device, booting a custom image, and brute-forcing your PIN.)

The result is that when you get your device back (which might be as simple as returning from the bathroom after leaving it on the table at dinner), it will be painfully obvious it has been modified: all your data will be gone, and when you boot the device it will show the "unlock of shame". It kind of sucks that it is so easy for someone to so easily delete your data and void your warranty over USB, but at least you noticed.

OK, and if I don't do that, I'm safe?

Sadly, due to the way Glass is currently designed, it is particularly susceptible to the kinds of security issues that tend to plague Android devices. The one saving grace of Android's track record on security is that most of the bugs people find in it cannot be exploited while the device is PIN-code locked. Google's Glass, however, does not have any kind of PIN mechanism: when you turn it on, it is immediately usable.

Even if you wear Glass constantly, you are unlikely to either sleep or shower while wearing it; most people, of course, probably will not wear it constantly: it is likely to be left alone for long periods of time. If you leave it somewhere where someone else can get it, it is easy to put the device into Debug Mode using the Settings panel and then use adb access to launch into a security exploit to get root.

The person doing this does not even need to be left alone with the device: it would not be difficult to use another Android device in your pocket to launch the attack (rather than a full computer). A USB "On-The-Go" cable could connect from your pocket under your shirt to your right sleeve. With only some momentary sleight-of-hand, one could "try on" your Glass, and install malicious software in the process.

You might think that security exploits are rare, but most versions of Android have been subject to these kinds of attacks; again, these are often seen to be somewhat low-priority because most require the device's PIN code to be entered (manually by hand, not via computer, so cracking the code is not an option). In fact, as we have seen, Glass even managed to ship with a security bug in it that was known eight months ago.

What can someone do via my Glass?

Once the attacker has root on your Glass, they have much more power than if they had access to your phone or even your computer: they have control over a camera and a microphone that are attached to your head. A bugged Glass doesn't just watch your every move: it watches everything you are looking at (intentionally or furtively) and hears everything you do. The only thing it doesn't know are your thoughts.

The obvious problem, of course, is that you might be using it in fairly private situations. Yesterday, Robert Scoble demonstrated on his Google+ feed that it survived being in the shower with him. Thankfully (for him, and possibly for us), this extreme dedication to around-the-clock usage of Glass also protects him from malicious attacks: good luck getting even a minute alone with his hardware ;P.

However, a more subtle issue is that, in a way, it also hacks into every device you interact with. It knows all your passwords, for example, as it can watch you type them. It even manages to monitor your usage of otherwise safe, old-fashioned technology: it watches you enter door codes, it takes pictures of your keys, and it records what you write using a pen and paper. Nothing is safe once your Glass has been hacked.

What should Google do about this?

For starters, they should have some kind of protection on your Glass that activates when you take it off. If the detector along the inside of the device is a camera (I am not certain whether it is a camera or a light sensor), it might be possible to use some kind of eye-based biometric. Another option is a voiceprint. Otherwise, a simple PIN code would suffice: the user could enter it using the touchpad when they put it on.

Secondly, they should provide some way for the user to feel confident in a given situation that the device could not possibly be recording: a really great suggestion that a friend of mine had is that the camera could have a little sliding plastic shield. (This also addresses the privacy concerns many have about a future where large numbers of people have Glass: this makes it clear "I'm not recording right now".)

Finally, they should be a little more careful while discussing these issues with the community. In response to one of the articles written about my post, a Google engineer (who claims to have not read the article and was making a "joke" based only on the title) stated "This is not rooting. Nothing is rooted. There is no root here! This is 'fastboot oem unlock'.", which accidentally derailed the conversation.

As an example, in an article published by Ars Technica, the situation had gotten so confused by such statements from Google employees (which included comments like "Yes, Glass is hackable. Duh.") that Ars ended up reporting that "there's been some debate over whether developers actually gained root access to the devices or simply took advantage of a 'fastboot OEM unlock' that Google itself provided".

As long as engineers, advocates, and officers from Google make statements like these without carefully looking into the facts first, it will not be possible to have any kind of reasonable and informed discussion about this system. The doors that Google is attempting to open with Glass are simply too large, and the effects too wide-reaching, for these kinds of off-the-cuff statements to be allowed to dominate the discussion.

Copyright © 2008–2022 — Jay Freeman (saurik)