Have there been any reports claiming that Google 'borrowed' any bandwidth? All I've seen so far is that they might have created a log of open AP's, which is basically a passive activity. I was going to say it's hard to believe that would be illegal, but then you said this:
Sounds like the laws might be the bigger problem.
The laws are actually a model of private data protection. We should be so lucky in the USA.
The Wi-Fi traffic collected by Google's world-roving Street View cars included passwords and email, according to a report citing a preliminary study from the French data protection authority.
IDG reports that the French National Commission on Computing and Liberty (CNIL) has examined part of the data, after it was turned over by Google. "It's still too early to say what will happen as a result of this investigation," CNIL told IDG.
"However, we can already state that [...] Google did indeed record e-mail access passwords [and] extracts of the content of email messages."
MORE:
That's not good but if folks are using cleartext passwords over a wireless connection, they really shouldn't have a "reasonable expectation of privacy".
If I were one of those "victims" I'd be more worried about the other folks who may have recorded that info (and not very worried about Google). But, of course, Google represents a much more attractive target for those seeking financial reward for their own stupidity.
I respectfully disagree -- the problem is the fundamentally flawed POP3 protocol that many (most?) ISPs still use -- it shouldn't take a computer science degree to use basic Internet services. Shame on us.
POP3 is certainly an issue but you can't hang that one on Google.
It would be interesting to know the distribution of the captured passwords, by protocol.
I'm guessing that they caught more HTTP Basic Authentication passwords than POP3 since most of the inexperienced users (that I know) use webmail versus POP3/SMTP.
At least those are "encrypted" with Base64 ;-)
POP3 doesn't necessarily need to be insecure. In fact, both of the POP3 servers I connect to use TLS. One is live.com on port 995 so POP3S, the other is on port 110 but the client and the server negotiate TLS without any intervation on my part.
That's up to the ISP, not the customer.
Not just using cleartext passwords over wifi, using cleartext passwords over UNPROTECTED wifi. (If they had any protection on their wifi, then Google wouldn't have connected or recorded anything.) In that case they absolutely have no expectation of privacy. It's like shouting your password to your friend across the street.
jc
Most ISPs offer protected protocols. I use protected protocols with all my email accounts on 3 different ISPs.
Most end users don't bother to learn how to setup their software to use the protected protocols. This is not the ISPs fault.
jc
Some do, some do not, and there's no excuse for those that still market and provide unsafe and insecure service.
You're not typical.
It absolutely is the fault of the ISP to market and provide an unsafe and insecure mail protocol to non-experts, just as it would be the fault of a car manufacturer to make a car without enough bolts to hold on the wheels.
Average users are not required to become computer experts just to use standard Internet services safely.
The problem is hardware manufacturers that marketed insecure wireless devices, not the unsuspecting victims that bought them -- users are not required to become computer security experts just to use Internet services safely. The industry has at last faced up to its responsibilities, and is now doing much more to ensure that wireless networks are secure by default: Wi-Fi Protected Setup.
The NFC option has been suspended due to lack of test bed support.
"Notice on 9th June, 2010: Test bed device support for the NFC (Near Field Communication) test option for Wi-Fi Protected Setup has been discontinued. Additionally, no member has responded within the past 30 days to a request for new NFC candidate devices for the test bed.
Due to the lack of test bed equipment support and in accordance with the MRD requirements for NFC testing, Wi-Fi Alliance staff has suspended NFC option testing and will be removing the test feature from the WSC1.0 test plan and certification system testing menu. Reinstatement of NFC as an optional certification feature will require a new initiative within the task group and associated blind poll/plugfest work."
That's only one of four methods -- there are three other methods. Every Wi-Fi Protected Setup certified product must support the PIN method.
PBC is also mandatory and as far as I am concerned a pain in the neck. I have found a number of people, including myself, who have had difficulty getting this to work with some routers and have had to eventually input the encryption manually. If manufacturers are not prepared to support present test beds to make things easier for users then wonders what the future will bring.
Only for the access point, not for the client devices.
Correct. When "most do" then obviously "some do not".
Bullshit.
More bullshit. Many users use software that can only fetch email with POP3. There's absolutely nothing wrong with offering this protocol for those who request it.
That's a very stupid analogy, but I'm not surprised you brought it up because it's exactly what I expected of you.
A much better analogy is like selling a car where you can't easily lock all of the doors with one button or twist of the key. Where you have to actually take the time to lock each door individually.
They don't have to be experts. They only have to ask the question - is this the most secure way to setup my system?
jc
JC,
As a (now-retired) tech partner at a law firm, I was the person who had to ask that question to our computer consultant for a firm of twenty people. I also had to deal daily with computer problems of my less computer-literate partners and staff, so I feel qualified to comment on your opinion. You presume too much about the average user, and particularly the average older user. (By older, I mean over about age 35, before computers were available in most elementary schools.) Many users expect their computers to work the way their TVs work: turn them on, and turn the channel to the program they want. They don't know enough to ask your question, much less answer it. It's not the ISPs' fault that many people don't bother to learn everything there is to know about computers; it's just human nature.
The problem is not only with the ISPs, but also the equipment manufacturers. Both of them have historically understated security risks, to sell more services and equipment by avoiding scaring away consumers.
I know that my solution is not popular among tech people, who are notoriously libertarian. However, IMHO, one good role for the FCC would be to standardize security UIs and protocols (including updating procedures) so that it would be easier for consumers to keep up with their security needs. (I am not against an industry committee coming up with, and maintaining, the standards, but there should be standards.) Of course, that would not stop a determined hacker, but it would reduce the likelihood of wardriving and of what Google did.
Neil
True. Perception is everything. Users expect things to be secure out of the box and without any (or much) effort on their part. A worst case example are the commodity wireless routers, which if installed using the default configuration, are as insecure as one could possible be. The default passwords are well know. There's no encryption enabled. The SSID is not unique.
Yet, the same product has security inscribed on the package, documentation, and advertising literature multiple times and in multiple places. Looking at the packaging and literature, one would assume that it's secure based solely on the number of security related buzzwords that encrust the packaging and literature. No so, but (to my knowledge) the concept of vendor liability for security breaches on consumer electronics has not been tested in court.
Email security is similar. The perception is that email is secure because nobody knows the users password. Never mind that some systems still send the POP3 and FTP passwords unencrypted. Never mind that the password may be secure, but the contents are easily sniffable.
They do after a security breach. Few people take security seriously until after it fails.
The FCC does not specify the details of transmission standards. It merely specifies that there should be encryption, security, or some protocol. The details of these are produced by industry standards organizations (NIST, EIA, IEEE, APCO, etc) and adopted by manufacturers to be compliant with the FCC guidelines. For example, FCC Part 15 does not specify anything about wi-fi encryption except that it's allowed. The IEEE wrote 802.11(a-z) specifications. The Wi-Fi forum provides certification.
I'm not sure which organization would be the proper standards manufacturer. Since the IEEE inscribed most of the industry standards now running the internet, methinks such a security protocol should be well within their area of expertise. All the FCC needs to do is demand that all public data network transmissions be encrypted.
Not all parts of wi-fi transmissions are encrypted. The headers, source and destination MAC addresses, system management packets, control packets, and some broadcast packets are not encrypted. One could easily map a network by simply collecting the source and destination MAC addresses. I have not seen anything from Google indicating exactly what data they were collecting, but my guess(tm) is that it was MAC addresses, SSID names, and possibly sniffing broadcasts to determine the type of connectivity. They were apparently only logging uncrypted data, but from the vague wording, could include payload data. From the unencrypted data, they'll get a user count, network map, equipment type, and a good guess as to the backhaul type. If that data was NOT encrypted, they would get IP addresses, payload type, service number, and RIP broadcasts, which would reveal considerably more information about the system and its topology.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.