Exploiting a Bug in Google's Glass
saurik.com
saurik.com
FWIW:
1. It wouldn't have taken days, it would have taken roughly the same time no matter when it happened, or whether it was requested privately or publicly.
In most cases, faster. Part of the time delay was that I needed to give the code.google.com oncall folks a heads up in case it caused them a massive amount of traffic (it's generally bad form to cause a DDOS to someone else's service without giving them a heads up), since that was not the original planned release mechanism, and historically, these releases generate a bunch of traffic.
2. The very small number of times (in the 7 years i've been there) these things have been screwed up, even privately, we have almost always given people source within hours, so i'm going to say it was more that I try to correct mistakes as quickly as possible.
The only case it didn't happen that quickly that i'm aware of was when someone in a beta program requested pre-release GPL source, which we, of course, gave them, but it took a day or two to actually pull it together.
When it comes to stuff like open source compliance, what you do when things go wrong matters as much as what you do when things go right.
You should always feel free to ask folks for source, and beat them over the head if they don't reply quickly.
Besides that, the general rule of thumb for the GPL is that if you give binaries outside the company, that's what matters, not whether it was only sold to a few people, labeled a beta, or whatever.
There were a few companies (this is about 13 years ago now) using GCC that tried to use NDA's to separately restrict GPL release of new architecture patches until some "public release date" for that architecture, and the FSF threatened suit. It got worked out, and eventually led to this seemingly random message to the GCC mailing list: http://gcc.gnu.org/ml/gcc/2001-07/msg01342.html
(This is also when the GPL FAQ was updated with the same answer)
(Who to email, which webpage I submit the request at, or whatever the official process is)
I'm asking here because what you said sounds great, but unfortunately Googling for "google gpl request" and the like didn't turn up anything.
I haven't heard that people have had difficulty getting source (because we try to be proactive about it), so I haven't set up an alternate method of contact specifically for it (and in most cases, i'd rather just fix whatever process is broken).
In the short term, the easiest way is to just email me at dannyb@
Longer term, maybe i'll create opensource-requests@ or something.
The only caveat i'll mention is that Motorola is run as a completely separate subsidiary, so I can't guarantee quick answers/solutions if you are having issues with Moto. Not that I can't help, but in practice, because the companies are run separately, it involves beating up people that don't work for me
Neat.
http://dl.acm.org/citation.cfm?id=1102169
"We present a novel attack taking as input a 10-minute sound recording of a user typing English text using a keyboard, and then recovering up to 96% of typed characters. There is no need for a labeled training recording. Moreover the recognizer bootstrapped this way can even recognize random text such as passwords."
I think this also works on dvorak, but it might be stumped by plover + custom dictionaries. Especially for short typing sessions. Although short sessions might be mitigated by recording from multiple locations... hm.
http://static.usenix.org/events/sec06/tech/shah/shah_html/jb...
"In particular, we show a practical Keyboard JitterBug that solves the data exfiltration problem for keystroke loggers by leaking captured passwords through small variations in the precise times at which keyboard events are delivered to the host. Whenever an interactive communication application (such as SSH, Telnet, instant messaging, etc) is running, a receiver monitoring the host's network traffic can recover the leaked data, even when the session or link is encrypted."
While I was super-eager to get Glass before, it really got me wondering if having camera and microphone in your glasses is such an great idea after all.
I agree with your statement that cameras will be accepted in the future, but I'm not sure it follows that it's a great idea.
On the other hand, I'm not even convinced cellphones and facebook are great ideas, so my life is probably not representative. (Now get off my lawn.)
Given that the kernel source was not made available until the next day, he could not have used oem unlock - even "if he wanted to."
So, it is possible, it just isn't practical, especially when an exploit happened to be so easy to come by. Once you then have a security exploit, you can then start to ask "what does this let me do that an unlocked bootloader does not", and the ramifications on Glass are, at least to me, interesting.
With an unlocked bootloader, you could boot something that then messed with the filesystem to drop "su" out in the bin (and this is what happens when you boot a recovery image to root an Android phone).
But in order to do that, you'd need kernel sources, so that you could have something that would properly boot on the device and mount the filesystem.
Additionally, my article documents the threat of this kind of security exploit on Glass, along with some issues with this specific device that make exploits of any kind more dangerous (the lack of a PIN being key), as well as looking at some scary examples of Glass-specific malware opportunities.