This appears to require Javascript. Thank you, noscript.
It doesn't, really. This proof of concept is implemented using Javascript, because it's easier, but the basic concept doesn't require Javascript to work.
Hollywood probably represents a huge net trade surplus to the American economy: lots of people who aren't Americans spend part of their disposable income on American movies, American music and so on.
Well, a small net trade surplus. In spite of the large amount of attention we give the entertainment industry -- because it's entertainment! -- if you look at the numbers and start comparing it to other industries it's not really very big. What Hollywood definitely does have is political and popular influence way out of proportion with its actual effect on the economy.
I think the Android Enterprise management is pretty solid. Google uses it to manage a fairly large fleet of Android phones and tablets itself. I don't have any direct experience with it though, so take this comment with plenty of salt.
Maybe. I'm not sure Google's track record is as dismal as you paint it, but what is very clear is that what Google is really good at is massive-scale infrastructure, and at that they're almost unequalled, so perhaps you're measuring by the wrong yardstick.
Also, Google has (recently? I'm not sure) started hiring older engineers. I joined Google in February and I'm 42. My team of about 30 engineers ranges from just-out-of-school youngsters to a couple of guys I'm pretty sure are in their 60s (I haven't asked), and the median age is probably around 40. They're all really sharp; some of the "oldsters" in particular are retreads from the likes of Bell Labs and Xerox PARC. Seriously talented people with a tremendous wealth of experience.
Anyway, I see Google as one of the companies right now who is actively recruiting and hiring older programmers for their experience. If your theory is right, perhaps that will change Google's effectiveness with new products. Dunno.
In any case, if there are any older programmers with quick minds, solid CS fundamentals and great architecture, design and implementation skills, drop me a line. I'd love to collect some more referral bonuses, and you'd love working for Google. Degrees don't matter, but the ability to think and solve problems on your feet does.
Right, which is why in this case I think there needs to be a requirement of an intent to commit fraud, misuse obtained data, etc. Or, perhaps better, there should be an exemption for individuals who demonstrably have no intent to act in bad faith, and who expeditiously report any weaknesses they find. This would probably be more of an affirmative defense, requiring the actor to be able to demonstrate good faith, so there would still be a risk of prosecution, but it would provide some protection for researchers and those who accidentally stumble onto something, and would facilitate reporting.
That doesn't really answer the question. Software can have many bugs around minor issues without actually being unusable. Stuff like "bookmarks bar flickers on mouseover". What is it that makes bookmarks actually not usable for you?
Agreed. That is a real problem with the way our legal system approaches these issues. Malicious intent really should be a required component of the crime.
I hope this is a whoosh moment, but mens rea does exist.
As I understand it, for this crime the prosecutor has to prove that you intended to access the system. But that's different from proving that you had malicious intent in doing so.
So now you're looking at someones account on, let's guess here, Square*... and you KNOW this has to be fixed, it's way too dangerous, but pushing the issue with the company (or elsewhere) could land you in prison.
Agreed. That is a real problem with the way our legal system approaches these issues. Malicious intent really should be a required component of the crime.
The question was actually about whether they could track his IP from when he tested his hack, not when he sent his e-mail. But, sure... public internet access, open Wifi, Tor network, whatever, there are tons of ways to avoid connecting from an IP that's tied to you, if you think about it ahead of time.
A fully open system is more easily audited. A more easily audited system is harder to hide garbage code in.
Read the paper. All the code that was examined to find these issues was Dalvik bytecode, which is very easy to analyze and audit. In this case it was probably easier to audit at that level than to audit the source.
What's the problem with bookmarks in Chrome? I have to admit that I don't really use bookmarks (that's what search engines are for), but on the rare occasion when I do use them they seem just fine. How are they broken?
Why do you need to go from version 9 to version 10 in order to fix a memory leak?
Because otherwise the developers end up having to fix the memory leak twice, once in the released version and once in the in-development version. And, inevitably, it happens sometimes that only one of those two fixes gets done, which leads to either a long wait for a fix or, even worse, a fix that regresses when the new version is released.
It's much more manageable to make all but the most critical changes in the dev version, and then release it quickly.
The one weakness happens when the MITM is between the SSL server and its only connection to the Internet, but the Perspectives developers appear to operate under the assumption what the whitepaper calls an "Lserver attack" won't happen often.
That attack can be recognized by the server being attacked pretty easily. All it has to do is to request its own cert from some notaries periodically, and compare what comes back to what should come back. The attacker could block these requests, but couldn't spoof them, so the site should shut itself down if the notaries begin returning the wrong cert or if too many of them are unreachable. This reduces the MITM attack to a DOS, and any attacker capable of intercepting and modifying a host's traffic can DOS it easily anyway.
You should look into Scantegrity, developed by security researchers David Chaum and Ron Rivest (the latter is the 'R' in RSA).
It is an automated, scanner-based voting system which is more secure than pencil and paper systems, precisely because it's more auditable. It actually enables each voter to verify that his or her ballot was counted correctly in the final tally -- but without giving the voter the ability to prove who they voted for to anyone else, to eliminate issues of vote coercion. The system also allows auditors (which can be anyone who is interested) to verify that no additional ballots were added to the system, and that the ballots were tallied correctly. Manual recounts can also be performed if someone doesn't trust the mathematical proofs of correctness (though the manual recounts are more likely to introduce errors than to correct them).
Technology actually can improve over the traditional ballot.
What does it say when I trust a bunch of random coders on the internet to give me a better performing, more secure, and overall more pleasing experience with my smartphone than the company that created it.
Except that the phones from the company that created the OS, Google, didn't have any security issues. CM is cool, but it's less secure than a standard Google build, not more. Although it probably is more secure than Android as delivered by the carriers.
You say this, like something complex is doomed to be incomprehensible to do correctly.
A claim which is particularly interesting in light of the fact that the Google phones had no significant flaws (at least under this analysis). Does it really surprise anyone that all of the crapware loaded by the carriers causes problems?
if they already suck at security, you think they're going to be able to do that?
lols x pi
Tracking down an IP address is much, much easier than implementing good security. Yes, it's entirely possible that they could track him down from their logs, even if they suck at security.
He's already violated several conditions of the Computer Fraud and Abuse act: conspiracy to access a computer without permission, accessing a computer without permission, including financial records
Maybe. He didn't say he *had* accessed the secure user accounts, just that he had discovered how. Granted that it's usually hard to know if your attack works without testing it, but it is possible to recognize an easily-exploited weakness.
Building a proof of concept doesn't necessarily require accessing the data, either. He could build the proof of concept, test it against his own system, and then send it to them (or perhaps even publish it) without having broken any laws.
You're either stupid, or a troll. After my extensive explanation of the meaning of baud, and it's relationship with bit rate, and how the two applied to different generations of modems, you persist in your error. Same with the rest. I'm done.
A friend from church mentioned to me a while ago that Zynga had been trying to recruit his son, a 16 year-old junior in high school.
Your friend is full of shit. There are so many coders/developers/producers out there with experience looking for jobs at any salary, and Zynga is so inundated with resumes, that they can't parse through them all. I have one friend who quit Zynga over the stock option fiasco, and several others trying to get in. I guarantee that they are not scouting out high schools for talent.
Think what you will. I do know his son was pissed at him for refusing to let him take the job. So if my friend was lying, his son was in on it -- and neither of them really have any reason to lie about this.
Also, there may be a lot of experienced people out there looking for jobs, but experience isn't the same as ability. My experience (having been out looking for a job as recently as last year, before Google hired me), is that if you're talented you'll have your pick of options. I'm no rock star, and I had a half-dozen good offers to choose from. Take a really smart kid like my friend's son, and it doesn't surprise me at all that he's being scouted by companies who are less than ethical.
For example, communication protocols (like this one) are specified in powers-of-10 units because they're based on measuring wireless frequencies, which are measured in powers-of-10 hertz -- in this case, I'm sure that 1.5 Gbps means 1.5E9 bits per second. A 14.4 kbps modem transmitted 14,400 bits per second. A T-1 line transmits 1.54 Mbps, meaning 1,540,000 bits per second -- and note that framing and other overhead bits mean that you can't just divide by 8 to get bytes per second.
You, like many modem vendors who labelled their products at X kbps, instead of X k, are just wrong.
This is really funny, because you're "correcting" my correct terminology with incorrect terminology.
You're confusing BAUD with BITS.
A 56k modem is 56,000 BAUD.
Nope. As a communications and networking geek who lived through much of this history and has spent a fair amount of time fiddling with modulation and coding algorithms, allow me to explain:
Baud rate is a measurement of the number of symbols per second transmitted across a communication line. The earliest modems encoded only one bit per symbol, so for those modems baud rate and bit rate were identical. Even as early as 1200 and 2400 bps modems, however, this ceased to be true. 1200 bps (v.22 and v.22bis) was actually 600 baud with two bits per symbol. These modems were almost universally called "1200 baud" and "2400 baud", but they weren't. It was common during the time period those modems were widespread for geeks like me to correct those who said "2400 baud", but the corrections never really stuck, only the "baud is not bits" idea did, in the confused form you hold in your head.
This continued with 4800 and 9600 bps (v.32) modems, which were actually 2400 baud with two or four bits per symbol, but people continued incorrectly calling them 4800 baud and 9600 baud. 56k modems were essentially 8000 baud, with 7 bits per symbol. Well, sort of. More precisely, they're 8000 8-bit samples per second, with one bit of each sample as a parity bit. The distinction between "symbol" and "sample" is subtle, but enough that you really can't define a baud rate at all for 56k modems.
And yes, floppies were a cluster fuck. All of storage was, because they all wanted to advertise more space. 1 KB was 1024 bytes, and everyone knew it. But a MB was something new to a lot of people, so they thought they could get away with calling 1000 KB 1 MB.
Also incorrect. The earliest hard disk storage was the IBM 305 RAMDAC, released in 1956. It held five million 8-bit characters (six data bits, one parity bit, one space bit) on 50 platters of 100,000 characters each. MB meant one million bytes, and the base 10 unit trend continued for a long time, even on floppies. For example, the first floppy ever was an 80 KB 8" disk (read-only), which had an actual capacity of 81,664 bytes (32 tracks, 8 sectors per track, 319 bytes per sector). Later floppies shifted to power-of-2 sector sizes (as did hard drives), but power-of-10 capacity measurements were already firmly established by then.
Many of the early storage devices weren't actually specced in a number of bytes, anyway, they were specced to tracks, sectors, etc. which marketing goons confused/abused, take your pick.
This is a complete red herring. All disk-based storage (even today) is necessarily fundamentally defined by platters, heads, tracks (or cylinders) and sectors, but to argue that it would have been somehow more useful or accurate to advertise those numbers is just ridiculous. Nobody other than people writing low-level disk manipulation tools cares about that, and nobody wants to have to multiply five numbers (platter count, head count, track count, sector count and sector size) just to figure out how much a disk will hold. "Marketing goons" would have to have been truly stupid to advertise such numbers.
Slashdot Mirror
This appears to require Javascript. Thank you, noscript.
It doesn't, really. This proof of concept is implemented using Javascript, because it's easier, but the basic concept doesn't require Javascript to work.
nor is there any reason for Google to care about academic needs.
Sure there is: If they don't meet the need, they'll lose the customers to someone/something else who does.
when the majority of the people is found to be infringing some law, that law was likely to be biased against the general interest.
This!
If the majority of the population breaks a law regularly, it's the law that's wrong.
Hollywood probably represents a huge net trade surplus to the American economy: lots of people who aren't Americans spend part of their disposable income on American movies, American music and so on.
Well, a small net trade surplus. In spite of the large amount of attention we give the entertainment industry -- because it's entertainment! -- if you look at the numbers and start comparing it to other industries it's not really very big. What Hollywood definitely does have is political and popular influence way out of proportion with its actual effect on the economy.
I think the Android Enterprise management is pretty solid. Google uses it to manage a fairly large fleet of Android phones and tablets itself. I don't have any direct experience with it though, so take this comment with plenty of salt.
Maybe. I'm not sure Google's track record is as dismal as you paint it, but what is very clear is that what Google is really good at is massive-scale infrastructure, and at that they're almost unequalled, so perhaps you're measuring by the wrong yardstick.
Also, Google has (recently? I'm not sure) started hiring older engineers. I joined Google in February and I'm 42. My team of about 30 engineers ranges from just-out-of-school youngsters to a couple of guys I'm pretty sure are in their 60s (I haven't asked), and the median age is probably around 40. They're all really sharp; some of the "oldsters" in particular are retreads from the likes of Bell Labs and Xerox PARC. Seriously talented people with a tremendous wealth of experience.
Anyway, I see Google as one of the companies right now who is actively recruiting and hiring older programmers for their experience. If your theory is right, perhaps that will change Google's effectiveness with new products. Dunno.
In any case, if there are any older programmers with quick minds, solid CS fundamentals and great architecture, design and implementation skills, drop me a line. I'd love to collect some more referral bonuses, and you'd love working for Google. Degrees don't matter, but the ability to think and solve problems on your feet does.
Right, which is why in this case I think there needs to be a requirement of an intent to commit fraud, misuse obtained data, etc. Or, perhaps better, there should be an exemption for individuals who demonstrably have no intent to act in bad faith, and who expeditiously report any weaknesses they find. This would probably be more of an affirmative defense, requiring the actor to be able to demonstrate good faith, so there would still be a risk of prosecution, but it would provide some protection for researchers and those who accidentally stumble onto something, and would facilitate reporting.
Obviously not all 1,035 open issues matching "bookmarks" are exclusively bookmarks bugs... but you'll see a good handful of them here: http://code.google.com/p/chromium/issues/list?can=2&q=bookmarks
That doesn't really answer the question. Software can have many bugs around minor issues without actually being unusable. Stuff like "bookmarks bar flickers on mouseover". What is it that makes bookmarks actually not usable for you?
Agreed. That is a real problem with the way our legal system approaches these issues. Malicious intent really should be a required component of the crime.
I hope this is a whoosh moment, but mens rea does exist.
As I understand it, for this crime the prosecutor has to prove that you intended to access the system. But that's different from proving that you had malicious intent in doing so.
So now you're looking at someones account on, let's guess here, Square*... and you KNOW this has to be fixed, it's way too dangerous, but pushing the issue with the company (or elsewhere) could land you in prison.
Agreed. That is a real problem with the way our legal system approaches these issues. Malicious intent really should be a required component of the crime.
The question was actually about whether they could track his IP from when he tested his hack, not when he sent his e-mail. But, sure... public internet access, open Wifi, Tor network, whatever, there are tons of ways to avoid connecting from an IP that's tied to you, if you think about it ahead of time.
On the contrary.
A fully open system is more easily audited. A more easily audited system is harder to hide garbage code in.
Read the paper. All the code that was examined to find these issues was Dalvik bytecode, which is very easy to analyze and audit. In this case it was probably easier to audit at that level than to audit the source.
What's the problem with bookmarks in Chrome? I have to admit that I don't really use bookmarks (that's what search engines are for), but on the rare occasion when I do use them they seem just fine. How are they broken?
Why do you need to go from version 9 to version 10 in order to fix a memory leak?
Because otherwise the developers end up having to fix the memory leak twice, once in the released version and once in the in-development version. And, inevitably, it happens sometimes that only one of those two fixes gets done, which leads to either a long wait for a fix or, even worse, a fix that regresses when the new version is released.
It's much more manageable to make all but the most critical changes in the dev version, and then release it quickly.
The one weakness happens when the MITM is between the SSL server and its only connection to the Internet, but the Perspectives developers appear to operate under the assumption what the whitepaper calls an "Lserver attack" won't happen often.
That attack can be recognized by the server being attacked pretty easily. All it has to do is to request its own cert from some notaries periodically, and compare what comes back to what should come back. The attacker could block these requests, but couldn't spoof them, so the site should shut itself down if the notaries begin returning the wrong cert or if too many of them are unreachable. This reduces the MITM attack to a DOS, and any attacker capable of intercepting and modifying a host's traffic can DOS it easily anyway.
Firefox is still the best browser in terms of customizability and (consequently) respecting users' privacy.
How does Chrome disrespect users' privacy?
The real problem with android, is that handset makers release closed source binary drivers.
While that may be a real problem, it's got nothing to do with the problem discussed in this paper.
You should look into Scantegrity, developed by security researchers David Chaum and Ron Rivest (the latter is the 'R' in RSA).
It is an automated, scanner-based voting system which is more secure than pencil and paper systems, precisely because it's more auditable. It actually enables each voter to verify that his or her ballot was counted correctly in the final tally -- but without giving the voter the ability to prove who they voted for to anyone else, to eliminate issues of vote coercion. The system also allows auditors (which can be anyone who is interested) to verify that no additional ballots were added to the system, and that the ballots were tallied correctly. Manual recounts can also be performed if someone doesn't trust the mathematical proofs of correctness (though the manual recounts are more likely to introduce errors than to correct them).
Technology actually can improve over the traditional ballot.
What does it say when I trust a bunch of random coders on the internet to give me a better performing, more secure, and overall more pleasing experience with my smartphone than the company that created it.
Except that the phones from the company that created the OS, Google, didn't have any security issues. CM is cool, but it's less secure than a standard Google build, not more. Although it probably is more secure than Android as delivered by the carriers.
You say this, like something complex is doomed to be incomprehensible to do correctly.
A claim which is particularly interesting in light of the fact that the Google phones had no significant flaws (at least under this analysis). Does it really surprise anyone that all of the crapware loaded by the carriers causes problems?
if they already suck at security, you think they're going to be able to do that?
lols x pi
Tracking down an IP address is much, much easier than implementing good security. Yes, it's entirely possible that they could track him down from their logs, even if they suck at security.
He's already violated several conditions of the Computer Fraud and Abuse act: conspiracy to access a computer without permission, accessing a computer without permission, including financial records
Maybe. He didn't say he *had* accessed the secure user accounts, just that he had discovered how. Granted that it's usually hard to know if your attack works without testing it, but it is possible to recognize an easily-exploited weakness.
Building a proof of concept doesn't necessarily require accessing the data, either. He could build the proof of concept, test it against his own system, and then send it to them (or perhaps even publish it) without having broken any laws.
You're either stupid, or a troll. After my extensive explanation of the meaning of baud, and it's relationship with bit rate, and how the two applied to different generations of modems, you persist in your error. Same with the rest. I'm done.
A friend from church mentioned to me a while ago that Zynga had been trying to recruit his son, a 16 year-old junior in high school.
Your friend is full of shit. There are so many coders/developers/producers out there with experience looking for jobs at any salary, and Zynga is so inundated with resumes, that they can't parse through them all. I have one friend who quit Zynga over the stock option fiasco, and several others trying to get in. I guarantee that they are not scouting out high schools for talent.
Think what you will. I do know his son was pissed at him for refusing to let him take the job. So if my friend was lying, his son was in on it -- and neither of them really have any reason to lie about this.
Also, there may be a lot of experienced people out there looking for jobs, but experience isn't the same as ability. My experience (having been out looking for a job as recently as last year, before Google hired me), is that if you're talented you'll have your pick of options. I'm no rock star, and I had a half-dozen good offers to choose from. Take a really smart kid like my friend's son, and it doesn't surprise me at all that he's being scouted by companies who are less than ethical.
For example, communication protocols (like this one) are specified in powers-of-10 units because they're based on measuring wireless frequencies, which are measured in powers-of-10 hertz -- in this case, I'm sure that 1.5 Gbps means 1.5E9 bits per second. A 14.4 kbps modem transmitted 14,400 bits per second. A T-1 line transmits 1.54 Mbps, meaning 1,540,000 bits per second -- and note that framing and other overhead bits mean that you can't just divide by 8 to get bytes per second.
You, like many modem vendors who labelled their products at X kbps, instead of X k, are just wrong.
This is really funny, because you're "correcting" my correct terminology with incorrect terminology.
You're confusing BAUD with BITS. A 56k modem is 56,000 BAUD.
Nope. As a communications and networking geek who lived through much of this history and has spent a fair amount of time fiddling with modulation and coding algorithms, allow me to explain:
Baud rate is a measurement of the number of symbols per second transmitted across a communication line. The earliest modems encoded only one bit per symbol, so for those modems baud rate and bit rate were identical. Even as early as 1200 and 2400 bps modems, however, this ceased to be true. 1200 bps (v.22 and v.22bis) was actually 600 baud with two bits per symbol. These modems were almost universally called "1200 baud" and "2400 baud", but they weren't. It was common during the time period those modems were widespread for geeks like me to correct those who said "2400 baud", but the corrections never really stuck, only the "baud is not bits" idea did, in the confused form you hold in your head.
This continued with 4800 and 9600 bps (v.32) modems, which were actually 2400 baud with two or four bits per symbol, but people continued incorrectly calling them 4800 baud and 9600 baud. 56k modems were essentially 8000 baud, with 7 bits per symbol. Well, sort of. More precisely, they're 8000 8-bit samples per second, with one bit of each sample as a parity bit. The distinction between "symbol" and "sample" is subtle, but enough that you really can't define a baud rate at all for 56k modems.
And yes, floppies were a cluster fuck. All of storage was, because they all wanted to advertise more space. 1 KB was 1024 bytes, and everyone knew it. But a MB was something new to a lot of people, so they thought they could get away with calling 1000 KB 1 MB.
Also incorrect. The earliest hard disk storage was the IBM 305 RAMDAC, released in 1956. It held five million 8-bit characters (six data bits, one parity bit, one space bit) on 50 platters of 100,000 characters each. MB meant one million bytes, and the base 10 unit trend continued for a long time, even on floppies. For example, the first floppy ever was an 80 KB 8" disk (read-only), which had an actual capacity of 81,664 bytes (32 tracks, 8 sectors per track, 319 bytes per sector). Later floppies shifted to power-of-2 sector sizes (as did hard drives), but power-of-10 capacity measurements were already firmly established by then.
Many of the early storage devices weren't actually specced in a number of bytes, anyway, they were specced to tracks, sectors, etc. which marketing goons confused/abused, take your pick.
This is a complete red herring. All disk-based storage (even today) is necessarily fundamentally defined by platters, heads, tracks (or cylinders) and sectors, but to argue that it would have been somehow more useful or accurate to advertise those numbers is just ridiculous. Nobody other than people writing low-level disk manipulation tools cares about that, and nobody wants to have to multiply five numbers (platter count, head count, track count, sector count and sector size) just to figure out how much a disk will hold. "Marketing goons" would have to have been truly stupid to advertise such numbers.