Google glass is an interesting idea that conflicts with basic tenants of psychology. Facial recognition and attractiveness are critical to how we interact with others. This drive is so powerful that glasses used to correct vision are replaced by lenses that touch your eye, or aren't worn at all.
People would rather have plastic TOUCH their eye with somewhat rigid gas permeable lenses than mar their facial appearance with glasses. My eye flinches when I move my finger towards it and I still jammed contacts in there for years. The association of our facial appearance with our social identity is so powerful that we readily choose it over vision or comfort and pay more to do so.
Google glasses sound awesome, but the psychology against shit like this is powerful. I'm glad they're spending the money on it, but without some serious money invested in overcoming these psychological hurdles they won't go far.
It does exist but it is smaller than 350k in the post.
He might be not bad at managing money but almost everyone who starts earning more starts spending more. This is not bad money management, this is human nature.
Another effect is cost-of-living changes when moving from college town to real life. If a graduate earns 100k, it is probably not in a low-cost area. Taxes on this income are also higher than on a PhD income.
timing attacks don't necessarily need access to the actual machine to work. his point is valid because a side channel timing attack may arise from the differences in time it takes to receive a response from the server. there are remote timing attacks that take advantages in the differences in execution time between paths in the code. this means anyone observing message traffic may be able to execute a side channel attack, instead of just people with access to the hypothetical backdoors you mention.
you are saying not safe as if the term has a standard meaning across all contexts. anything can be cracked - the question is whether the time it takes to crack a computer is worth it compared to the data stored on the computer. in almost any case you actually need cryptography and it's not just a nice to have (aka credit cards, personal information) it's not worth using anything but native code.
As someone that has spent the better part of the last 18 months getting animations as smooth as possible in Javascript, I will happily buy a beer for anyone trying to execute a time-based side-channel attack against Javascript. You'll need the beer to cry into when the garbage collector craps all over your assumptions of constant durations for code path execution...
Exactly - interpreted code is harder to do timing attacks against because interpreters add a lot of timing "noise", while native code is much more consistent re: time taken to execute a specific routine.
a timing attack doesn't require constant duration for execution paths in the code. even with the noise in server communications remote timing attacks are often feasible - the noise filters out when you up the number of measurements or use the statistical techniques most modern side channel attacks rely on.
remote timing attacks contain noise by default, as they rely on server communications passed across a network with latency instead of examining the hardware directly to determine execution time. if you compare the network latency to the cache timing you'll find the noise is actually pretty fucking substantial.
a timing attack relies on a average difference in execution time between two paths of code. certain noise isn't going to protect you - for example, if everything on average takes 200ms longer, the average difference in execution time is still there.
I'm not saying timing attacks against interpreted code are impossible. I'm just saying they are easier to execute against native code, and thus have nothing to do with JS crypto being less secure than native crypto.
no serious person writes native code that vulnerable to timing attacks. if native crypto code has a measurable difference in execution time for different code paths that usually results in huge security advisories, patches, and it's against openssl a published paper. if the native code is written with constant time taken for all execution paths then by definition a timing attack is not possible. even if they are very close in execution time the timing attack is much more difficult, if not impossible.
timing attacks are only easier against native code written by people who don't know what they're doing, which means they made different execution paths take variable amounts of time, didn't examine the generated assembly by a hardware expert, and didn't bother to mask the crypto operations with proper noise generated using a cryptographically secure prng.
> timing attacks don't necessarily need access to the actual machine to work. his point is valid because a timing attack may arise from the differences in time it takes to receive a response from the server.
That point of yours actually points to a potential vulnerability in server-side (possibly native-code) encryption, not client-side encryption, which we discuss here.
I completely agree with you that anything can be cracked, and JS crypto more so than _some_ native-code cryptosystems. My point is that using JS crypto for some non-critical applications (e.g. as an alternative to corporate IM/email) can be useful and convenient.
>That point of yours actually points to a potential vulnerability in server-side (possibly native-code) encryption, not client-side encryption, which we discuss here.
...it also relates to the time it takes to generate a response from the client, server was just a specific example. side channel attacks are extremely flexible. the only reasonably secure crypto code is code that executes in the same amount of time no matter the execution path.
lastly, if you're using protocols to prevent mitm attacks, you've already reached a level of sophistication where you may as well just throw javascript crypto out and use a real crypto package. if you're not using those protocols the information is basically free and you shouldn't add any crypto because that might mistakenly convince people that they're secure.
a timing or voltage dependence on the key used for the encryption/decryption is often exploited by side channel attacks. this dependence can be used in some sophisticated attacks to reduce the key space dramatically. c and asm/microcode are close enough to the hardware that the operations let you analyze potential side channel leakage. for instance, if i look at the generated assembly it's possible to reason if the time/voltage used by the decryption operation is a function of the key used in the decryption.
when a virtual machine is introduced the just in time compilation itself may introduce these dependencies between timing/voltage and the key used in decryption even if the source code does not appear to. however, unlike in c, you can't just go examine the compiled assembly to ensure a timing attack wasn't added by the compiler. the actual native code becomes a function of the virtual machine installed.
i have no idea why you're being downvoted. auto and avionics companies go through hell to test this stuff at a level that involves the hardware and how it integrates with the software. this just doesn't happen in most software companies.
this is much more than a software problem. i've heard of people verifying opcode behavior on avionics processors to determine the correct implementation of the hardware - when your software relies on it it's fair game.
i don't doubt that google could do this if they made it a priority. but it's a huge issue that encompasses more than a "software algorithm." if the collisions sensors degrade over time doesn't matter if the software works.
my father worked full time while receiving his phd in the professional field he was employed in. he has had a very successful academic career. his dissertation was no joke and he has advanced much further than others from more prestigious universities.
i don't understand this mindset and the fact it exists is why i would never go back for a phd (pure math phd drop out). this is why so much research ends up being inapplicable garbage that doesn't advance a profession so much as hit the current vogue in academics. half the shit i saw pushed the current boundaries of human knowledge further away from anything applicable, interesting, or worth spending 6 years of your life on.
Good research takes time and intense focus. I.e., you want to be able to have a total focus when your mind is fresh. That is not going to be doable after you've already worked your 8-9 day (maybe if you're in the 1% of humans who can do that, but I'm talking about the common case). This is going to get worse in the case of having a family.
I'm not going to comment on your father, since I don't know him, don't know his research, and don't know his field. :-) But I know that I've been... less impressed... with part-time PhD research than with full-time PhD research. There are ways to manipulate your situation into a less conflicting one, that is true, but that depends on the employer and the university.
> pushed the current boundaries of human knowledge further away from anything applicable, interesting, or worth spending 6 years of your life on.
That's just your opinion, ne? Why should academics do anything that is applicable? Isn't it industry's role to take this research and channel it into something practical (or ignore it if its not)? A surprising amount of effort has been expended over the years in software that have been avoided by some basic attention to the research literature.
But that leads us down an entirely different discussion, one I don't think is really resolvable here and now.
