Why Google's Street View WiFi Data Collection Was Almost Certainly An Accident
from the technical-details dept
We've been among those who have believed that Google's collection of WiFi data via its Street View cars was likely an accident -- but some have argued that it is impossible to do such a thing by accident. In fact, in the various lawsuits and legal maneuverings around this mess, many people keep claiming that there's simply no way Google was accidentally collecting this data -- although we've yet to hear a single person explain what Google would possibly want with the data, or seen a single shred of evidence that anything was ever done with the data. However, for those who insist it is impossible to for this to have happened by accident, Slashdot points us to a detailed technical analysis of why it almost certainly was an accident, despite all the claims to the contrary.It explains, in great detail, how and why the collection of data packets would occur, mainly to help triangulate where the WiFi network was located -- something that Google has always admitted to doing. The problem was that some of the junk data (a very tiny amount, again, as explained in the article) got caught and retained, when it should have been dumped:
Although some people are suspicious of their explanation, Google is almost certainly telling the truth when it claims it was an accident. The technology for WiFi scanning means it's easy to inadvertently capture too much information, and be unaware of it.It then goes on to show how all of this works, using a specific example from within a Panera Bread restaurant that has open WiFi, which the author uses to demonstrate just how easy it is to capture stray data, why it would make sense and also just how useless most of that data really would be. It's pretty convincing, but I doubt it will satisfy the conspiracy theorists who are just absolutely positive Google had something nefarious planned.
The key issue, as has been pointed out repeatedly, is that most people arguing nefarious intent don't seem to understand what Google was actually doing. It was trying to map the location of WiFi base-stations, a perfectly legal activity that a small group of companies have been doing for years. But in order to best figure out the location of the networks, it's helpful to have as much data as possible that traversing over the access point. The system doesn't care or need to know what that data is, it just wants as much data as possible for the purpose of triangulating. The problem was that Google's system "kept" the data that it got, even though there's been no evidence presented that the the data was ever used for anything (a key point that those screaming "criminal intent" repeatedly gloss over). On top of that, no one even explains why Google would want such data. The little snippets would be so random it's difficult to come up with any reason why keeping such data would be useful.
Triangulation is a lot harder than you'd think. This is because many things will block or reflect the signal. Therefore, as the car drives buy, it wants to get every single packet transmitted by the access-point in order to figure out its location. Curiously, with all that data, Google can probably also figure out the structure of the building, by finding things like support columns that obstruct the signal.I agree with the conclusion to the post. Just because this was pretty clearly an accident, it still doesn't make it a good thing. Google clearly should have realized this much earlier and never allowed such data to be captured. But those running around screaming about how this was all pre-meditated by Google are going to have to offer up a lot more evidence.
What's important about this packet is that Google only cares about the MAC addresses found in the header, and the signal strength, but doesn't care about the payload. If you look further down in the payload [in the example data from an open WiFi network in Panera], you'll notice that it's inadvertently captured a URL.
Take a look again. Even though the access-point MAC address is highlighted, there's extra data in the packet. These extra data will include URLs, fragments of data returned from websites (like images), the occasional password, cookies, fragments of e-mails, and so on. However, the quantity of this information will be low compared to the total number of packets sniffed by Google.
That's the core of this problem. Google sniffed packets, only caring about MAC addresses and SSIDs, but when somebody did an audit, they found that the captured packets occasionally contained more data, such as URLs and e-mail fragments.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: data collection, triangulation, wifi
Reader Comments
Subscribe: RSS
View by: Time | Thread
Look for:
On top of that, no one even explains why Google would want such data.
Should close with
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
"Google is guilty of poor quality control on the WiFi mapping portion of it's stretview project. That poor QC caused them to unintentionally write data to disk that they did not require to complete the project as designed. "
One of the projects I am working on does something similar because of a closed source driver. Sometimes things like this are unavoidable and you dont realize its going on until much later.
[ link to this | view in chronology ]
Curious form of argument: state possible reasons,
You end merely stating that we've no evidence of *actual* mis-use. That's what the process of discovery is for; we should be able to find out what if any purpose they have. -- Surely our wonderful court system will soon find them not guilty, right? -- But I think that the average jury will take a dim view of this "incidental" snooping; the whole Street View scheme verges on invasion of privacy.
[ link to this | view in chronology ]
Re: Curious form of argument: state possible reasons,
Are you *really* so stupid and/or desperate to find something google "did wrong" as to have just accused them of trying to find structural weaknesses in buildings?
The data capture was a simple side-effect of their intended goal, i.e. to capture MAC addresses and signal strength. An unfortunate side effect, which is way overblown by idiots like, well, you.
[ link to this | view in chronology ]
@Christopher Weigel
I've skimmed your profile. You're merely negativism, usually a "drive-by" one-line ad hominem attack, delivered with condescension and the occasional "STFU", and evidence a complete lack of self-awareness that you are what you project onto others: a common troll. You'll remain so until you offer opinions.
[ link to this | view in chronology ]
Re: @Christopher Weigel
Oh, wait, what profile?
Simply because I disagree with your ill-stated opinions doesn't mean I don't have or express opinions of my own. A more detailed "skimming" would have shown that, but you've demonstrated ample evidence of your own trollishness.
[ link to this | view in chronology ]
Re: Curious form of argument: state possible reasons,
"
How is taking pictures along public streets even remotely similar to an invasion of privacy?
[ link to this | view in chronology ]
Re: Re: Curious form of argument: state possible reasons,
His comment verges on child pornography.
[ link to this | view in chronology ]
Re: Curious form of argument: state possible reasons,
[ link to this | view in chronology ]
^^^ @ 3 posts above
There's a gated community in Michigan, I think, which kept Google out. Those of us who live on private roads wish a degree of privacy.
[ link to this | view in chronology ]
Re: ^^^ @ 3 posts above
[ link to this | view in chronology ]
I agree.
Maybe it's not nice that they captured it, but instead of analyzing the background of the problem, everyone is jumping on big G.
I'm generally very cautious about my data, but this is just a farce, showing how people search someone to blame instead of fixing the damn problem.
[ link to this | view in chronology ]
First of all, your link is to an outdated speculative technical analysis. Try this for a fact-based analysis of what Google was actually doing. You can see that in the source code for gslite (Google's collection software), it specifically discards encrypted data while writing unencrypted data to disk. It is not reasonable to argue that Google "accidentally" coded their software this way. It is also tenuous to argue that this code somehow slipped through the cracks, since Google itself claims that it "makes extensive use of code reviews to ensure quality in its products; every line of Google source code is reviewed in this way." (emphasis added)
Also, I point your attention to Skyhook, which uses much less intrusive "active" scanning while still gathering the only two pieces of information needed to provide their location service: MAC addresses and signal strength. Skyhook's method makes any such payload data gathering impossible.
One final point. Whether or not Google's board of directors decided they wanted to gather payload data (which I do not believe to be the case), the words "intent" and "accident" may mean different things when put in a legal context.
[ link to this | view in chronology ]
Re:
2) Just because Google claims they have high QA standards does not suddenly mean they never have problems. Especially in situations like this where the type and amount of data you can get is effectively useless for nefarious purposes, which makes that particular change less important. It's a (small) configuration issue, not badly written code.
3) Skyhook does not appear to be aimed at the same situation that google was in, where cars were passing by and were far more pressed in the time and information they could get at any one place.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re:
1) What's your point? I'm not suggesting that Google should have stored encrypted data. I'm saying that the fact that they discarded encrypted payloads while keeping unencrypted payloads is evidence of intent.
2) I didn't say the code was badly written. In fact, I would say it's well-written. Well-written + code review = Just more evidence of intent.
3) I'm not totally sure what your point is here... In any case, Skyhook provides the exact same location service, but collects FAR less information in a much less intrusive way.
[ link to this | view in chronology ]
Re: Re: Re:
3) My point is that the skyhook example was irrelevant. There was no detail in that link at all as to how Skyhook gains its database of Wi-Fi hot spots. All it was an advert for a location service/technology that happened to use Wi-Fi hot spot information, nothing about the specifics of their data collection software, their policy regarding retention of data gained from unencrypted networks as they gather hot spot info, or anything else that might be of use.
Skyhook provides a location service, but I have no idea as to the methods they use to gather hot spot info nor whether their software retains unencrypted info. In fact the real link to info about their Wi-FI information gathering is here:
http://www.skyhookwireless.com/howitworks/coverage.php
But again, carries no real information. It's general promotional material, not specific details.
Practically none of what you have presented goes against Google.
[ link to this | view in chronology ]
Re: Re: Re: Re:
3) Here's a better link for how Skyhook works: http://www.xconomy.com/boston/2010/05/17/googles-passive-sniffing-technique-may-have-paved-the-way-f or-wi-fi-privacy-flap-skyhook
Skyhook's architecture does not, in fact CANNOT, see or capture payload data. The only data Skyhook gets is beacon packets from access points. Google sniffed data from access points AND clients.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
No it isn't. It's evidence that the software has multiple ways it can be configured and has multiple uses, like any other piece of software. It's evidence that someone configured it to do something that lead to this PR disaster, but it says nothing about intent. The fact that you regularly make claims to intent, and not the facts of what actually happened, including the specific information gathered and whether it could be in any way useful considering such short periods of data collection indicates how much of an agenda you have in pursuing this.
In fact, the history of the program used even indicates the issue is in configuration, not development/code review.
3) Skyhook describes 2 different methods of data collection (already addressed by another poster further down), that's about it. This doesn't show anything about intent, in fact Skyhook itself notes the issue with using the other method, being you miss access points if they're busy (which is likely for public Wi-Fi spots).
From the article:
Even Skyhook understands that there's a difference between coed review and how the software is setup.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
Of course you don't.
Also, believe it or not, the fact that Google did not choose to execute the program with different command line arguments is also legally evidence that they intended to run it that way. Now, there may be rebutting evidence. But right now, the only rebutting "evidence" we have is what Google says. You're welcome to just blindly accept what Google says (or rather, what Google's PR team approves).
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re:
Intentionally is a clarification to differentiate between unintentional (someone who doesn't know and/or realise what they're doing or that they've done so), not that intent in itself is illegal, especially when you actually take into account the various exemptions to wiretapping not being illegal (or not even being considered wiretapping by popular use of the term), which includes when information is broadcast over publicly accessible communications like unecrypted wi-fi, and assuming you haven't used the information for nefarious purposes, which there is no evidence of.
You're welcome to blindly parrot conspiracy theories that Google is genuinely wiretapping to use data for nefarious, illegal purposes based on misreadings of the law and misunderstandings and misuse of technology and technological terms.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re:
an unencrypted wireless hotspot, whether in your home or in a coffee shop, is Incredibly accessible. All of the data moving across and through is likewise accessible.
This is not a case of peeking through windows or trying to lean close enough to hear someones phone conversation. This is making a note of where you saw the lit billboard with BELKINWIRELESS ROUTERHOME written across it, or where you heard an announcement across a PA system "WIRELESS CONNECTION ON AISLE TWELVE! PLEASE TAKE INFORMATION FROM THIS WIRELESS CONNECTION"
Starting to whimper and moan about Wiretapping legislation and claiming the entire body of evidence shows "intentional" activity is just silly.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re:
The judge in that case said if they guy didn't protect his data and opened even by accident then the information was public.
So if the courts want to go that way Google is obviously clear at least in the U.S. and it will have no serious repercussion, on the other hand if they rule Google is responsible then they also need to re evaluate the decision for that pedo guy.
Now which one will the judges choose? Loose part of the ability to snoop onto others or protect the privacy of the population?
[ link to this | view in chronology ]
Re: Re: Re: Re:
What ???? YES, it does, and unit testing, field trials, usability, and suitability trials, "legals".
Code review in one part of a complate picture, are you saying you can review how code operates, without considering its configuration ?
Do much coding yourself ?
Someone also said, "engineers dont write laws" true, but they must abide by the laws, and professional engineers know about the laws regarding their field of expertise.
You think an engineer who deals with electrical power would not be aware of the laws regarding safe wiring, and correct legal procedures.
Its the first thing engineers learn,
Someone also said, "it's just because they use libraries", yes they do, but they do not HAVE to use the library functions just because they are in the library, if a library function gathers unwanted, or illegal data, you dont call that function.
NO, this was a premeditated decision from management, the crews in the fields did exactly what they were instructed to do, it was no accident. It was planned, they got caught and now they are acting stupid to try to mitigate what they have done.
Stupid, in saying it was an accident, It just happened, in multiple countries, and some of the projects lasted for 3 years !!. And during that 3 years they never reviewed the collected data ?
NO, they knew what they were doing, got caught, adding to just another Google SNAFU.
[ link to this | view in chronology ]
your insights on this
I'm not so informed on wireless data transmissions or software dev to form my own decisive opinion on what Google did here but my logic led me to believe this:
http://techdirt.com/article.php?sid=20100622/0340389918#c1447
Just from reading your perspective, I felt your knowledgeable enough to say what you have said so I want to ask you do you agree with my assessment. Its from a logical general standpoint. I do have experience in IT, PC Tech support and general networking, but like I said not so much with programming and wireless data trans. I have seen what I felt were knowledgeable opinions defending Google, but still feel they were aware of what they were doing.
[ link to this | view in chronology ]
your insights on this
I'm not so informed on wireless data transmissions or software dev to form my own decisive opinion on what Google did here but my logic led me to believe this:
http://techdirt.com/article.php?sid=20100622/0340389918#c1447
Just from reading your perspective, I felt your knowledgeable enough to say what you have said so I want to ask you do you agree with my assessment. Its from a logical general standpoint. I do have experience in IT, PC Tech support and general networking, but like I said not so much with programming and wireless data trans. I have seen what I felt were knowledgeable opinions defending Google, but still feel they were aware of what they were doing.
[ link to this | view in chronology ]
Intent of what exactly?
If I were writing the software I would have written it to store potentially useful data also by default as long as it cause no issues with the primary function of the software. It never hurts to have too much data while not having enough is unfixable. If you don't need it you throw it away.
The data was placed out there, by the owner of the data, publicly available to anyone with a wireless network card. The only way intent is relevant from criminal perspective is if the intent of the data capture was to use it for illegal purposes. Good luck with that.
This is like suing Google because someone found they could read the note they put on their front door in the picture Google took (I shouldn't mention it. It'll be the headline tomorrow). You can't arrest someone for reading a note you put on your door where anyone can read it even if you're stupid enough to put your credit card number or SSN on it. Now if someone uses it illegally it's a bit different. The key is that the collection of the information was in no way an issue either criminally or from a tort perspective if you placed it out in public. Especially in the case of someone driving by randomly collecting it. To claim otherwise shows a clear ignorance of what happened. This explains the political grandstanding about it.
[ link to this | view in chronology ]
Re: Intent of what exactly?
"Haha I have your SSN, birth date, driver's license, mother's maiden name, etc. and as long as I don't use it for illegal purposes I can't get in trouble."
[ link to this | view in chronology ]
Re: Re: Intent of what exactly?
[ link to this | view in chronology ]
Re: Intent of what exactly?
This point I think cuts right to the heart of it: Yes, from an engineering perspective, of course you save that data! It could be useful some day, and who wants to go back into the code to add it later? Why not just put that functionality in there the first time?
But engineers don't write laws, legislators do. And the Wiretap Act is very clear.
It remains to be seen whether a court will find that the payload data was "readily accessible by the general public" (which is the language in the Wiretap Act). People who are very familiar with the technology seem to think that the data is "readily accessible to the general public." But techies don't make those decisions; courts do. And I personally think the courts will rule that it isn't.
[ link to this | view in chronology ]
Re: Re: Intent of what exactly?
Note you misleading statement of the law.
[ link to this | view in chronology ]
Re: Re: Re: Intent of what exactly?
[ link to this | view in chronology ]
Re: Re: Re: Re: Intent of what exactly?
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Intent of what exactly?
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Intent of what exactly?
Once again it shows how much this is based on personal agenda, not on fact.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Intent of what exactly?
But my opinion is based on facts. And yours is based on ad hominem, "personal agenda" or "conspiracy theory" attacks.
[ link to this | view in chronology ]
Re: Re: Re: Intent of what exactly?
[ link to this | view in chronology ]
Re: Re: Re: Re: Intent of what exactly?
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Intent of what exactly?
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Intent of what exactly?
I don't even understand your original point in stating that in the first place. You didn't rebute anything, you just stated a fact (I assume referring to 4th amendment?).
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Intent of what exactly?
My point was that under the Wiretap Act, there is NO REQUIREMENT WHATSOEVER that Google do ANYTHING with the data they intercepted besides write it to disk; they are liable if the above two points are satisfied.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Intent of what exactly?
So... to rephrase..
And for the record, accepting your apology for confusing beacon packets and SSIDs, doesn't make me "see that [you] actually do have a very good understanding of the technology and what happened."
The whole problem with this situation is that people are flipping out even though:
Separately, am I the only one that has a weird feeling about constantly comparing Google in this instance to Skyhook, and the linking to what are basically promotional materials? For someone claiming that people are simply following along with Google's PR, you kind of come off sounding like Skyhook PR. "Google doesn't care about your privacy, but we do!"
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Intent of what exactly?
I'm not Skyhook PR. But if you understand the technological architecture differences, it's obvious that Skyhook took more care to protect users' privacy. Research it and form your own opinion, that's fine.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Intent of what exactly?
[ link to this | view in chronology ]
Re: Re: Intent of what exactly?
I fail to see how the wiretap act could ever be applied to data which was broadcast in the clear over a radio frequency.
Radio waves are indiscriminate. Should I be arrested for tuning in to NPR during my morning commute? Well, yes, actually but that's another story.
Users of wireless networks are broadcasting their data over radio, encrypted or not. Unencrypted network data is no different that unencrypted analog radio... anyone with an antenna and tuner in range has every right observe what waves they are being bombarded with.
Of course if Google picked up and stored the session data of someone downloading copyright infringing material.. well then they're fucked.
[ link to this | view in chronology ]
Re: Re: Re: Intent of what exactly?
[ link to this | view in chronology ]
Re:
And active scanning being less intrusive? I would expect the opposite: passively listening for the beacons is much less intrusive than actively sending probe requests and waiting for the responses (which uses bandwidth which could instead be used for data packets).
[ link to this | view in chronology ]
Re: Re:
Active scanning is not more intrusive. Here's a discussion of the difference: http://www.xconomy.com/boston/2010/05/17/googles-passive-sniffing-technique-may-have-paved-the-way-f or-wi-fi-privacy-flap-skyhook-ceo-says/
Passive scanning = packet capture in promiscuous mode.
[ link to this | view in chronology ]
Re: Re: Re:
The link has no discussion. http://www.my80211.com/home/2010/1/11/80211-client-active-and-passive-scanning.html would provide a better difference between the two. The issue with the code is that no matter how many code reviews or QA tests you run you will never catch all the bugs in a system. Intent would be if there was code that extracted the payload data specifically.
[ link to this | view in chronology ]
Re: Re: Re: Re:
And if you read the code review (here), you will see that Google did write code that specifically wrote payload data to disk.
[ link to this | view in chronology ]
Re: Re: Re: Re:
[ link to this | view in chronology ]
Re:
Werent they specifically looking for open wifi hotspots?
[ link to this | view in chronology ]
Re: Re:
No, they were looking for ALL hotspots, regardless of encryption. Google's software even captured data from hotspots that weren't broadcasting.
(Man, I gotta say, Google has done a whale of a job with their PR. People are uninformed all over the place.)
[ link to this | view in chronology ]
Re: Re: Re:
the googles have amazing technology that defies the laws of physics!
(ironic post about uninformed people is ironic)
[ link to this | view in chronology ]
Re: Re: Re: Re:
Sorry for not being specific, but I'm as informed on this stuff as anyone outside of Google is.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
I I can tell you are trying to say networks that are not broadcasting the SSID, but it is cute to watch you condescend people who do not understand what you think you understand ;)
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
It is just that, without beacons, it would quickly disconnect (as in, within a few seconds or less) due to beacon loss (it would look to the client as if either it had moved a long distance from the access point in a matter of milliseconds, or the access point lost its power). The end effect to the user would be about the same (impossible to use the access point).
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re:
You are thumping your chest saying you know as much about the topic as anyone outside of Google then claim they have the ability to collect data from access points that are not broadcasting! (impossible)
no wait! not broadcasting beacon packets ( A configuration that while is technically possible would not be found in the real world as the network would be unusable)
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re:
I did a very quick Google search and found: http://compnetworking.about.com/cs/wirelessproducts/qt/disablessidcast.htm
Perhaps I have been sloppy with my language, but when I say Google snooped on networks that weren't broadcasting, these are the networks I'm talking about.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re:
You realize a beacon packet and an SSID are two different things? And you realize when you claim to be knowledgeable on a subject and make condescending comments about how people must be gobbling up Google PR that posting inaccurate technical descriptions makes you look like a tool ? =)
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
Once you accept my apology, you'll see that I actually do have a very good understanding of the technology and what happened.
And you'll see that my point stands.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
If they were collecting control packets to try to find the SSID for networks with hidden SSID, then there would be a difference (if you are hiding your SSID, it is your misguided intent to have it not known). But what they collected was the content of the data packets, which does not reveal the SSID at all, so the effect should be the same independent of whether the SSID is being broadcast or not.
(Nitpicker's corner: by SSID I of course mean the ESSID here, not the BSSID.)
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
If they were collecting control packets to try to find the SSID for networks with hidden SSID, then there would be a difference (if you are hiding your SSID, it is your misguided intent to have it not known). But what they collected was the content of the data packets, which does not reveal the SSID at all, so the effect should be the same independent of whether the SSID is being broadcast or not.
(Nitpicker's corner: by SSID I of course mean the ESSID here, not the BSSID.)
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
Google recorded entire packets (including all header bits), so they did actually get SSIDs (and MAC addresses) as well as payload data.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
There is no difference between me running around a public place shouting my bank account numbers with a nametag on, and me doing the samething without a nametag on. I'm still spewing my information into public access spaces.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
Not to mention that when capturing the data packets you do not necessarily know whether the SSID is hidden or not (it is on the beacon packets, a completely different class of packets, and you can easily be too far from the AP to capture the beacons but near enough the STA to capture the data) - one more reason why it should be considered irrelevant to the real question.
[ link to this | view in chronology ]
Re:
After all, you do all your sensitive online work encrypted...
Right?
[ link to this | view in chronology ]
Re: Re:
That depends on your definition of "sensitive." For example, all facebook chats are sent in the clear. Even if you yourself don't send "sensitive" messages via facebook chat, you would probably admit there are tons of people who do.
Also, putting the onus on a user misses the point. The point is that Google likely violated the Wiretap Act. Regardless of whether or not their activity was normatively harmless, if a court finds that the traffic Google captured is not "readily accessible to the general public," what they did was illegal.
[ link to this | view in chronology ]
Re: Re: Re:
Not if you turn on WEP, or WPA, or WPA-2, or one of the many other myriad encryption options available on every home router.
[ link to this | view in chronology ]
Re: Re: Re: Re:
Expectation of privacy with unencrypted wireless is more nebulous. If you ask me, unencrypted wireless is like standing on your rooftop shouting to your neighbors. You can't get too P.O.'d if someone walking by heard what you said.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
Nice try, though.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re:
In order to get the most accurate geo-positioning information we MIGHT need more than the 24 bytes of the packet so I should write that data out.
OK
Hmm IF packet is encrypted than there is nothing we can use for improving the accurateness of our Geo-location so lets toss that out.
OK
Works great! ship it!
Without the followup that would show-
We have no use for anything beyond the first 24 bytes of any packet so that's all we need to write to disk
[ link to this | view in chronology ]
Re: Re: Re:
But even if your story is exactly what happened, Google still may have violated the Wiretap Act. The Wiretap Act requires no more than an "intentional interception" of data not "readily accessible to the general public." The second point has not been decided, but the "intentional interception" bit is pretty cut and dry once you read the source code review.
[ link to this | view in chronology ]
Re:
If Skyhook was such a wonderful company where everyone is filled with warm fuzzies all day because they respect privacy so much, maybe they wouldn't have tried to lock-up technology which allows people to collect wifi data using an "active" scanning method.
[ link to this | view in chronology ]
Re: Re:
And your ad hominem Skyhook attack is totally irrelevant. We're talking about the differences in architecture for their data gathering software, nothing more. In that context, Skyhook does a MUCH better job of respecting users' privacy.
[ link to this | view in chronology ]
Re:
You're right that the article doesn't seem to be written by someone with access to the source code or any data logs, but the author does seem to know what he is talking about. Also, his piece seems to be more about explaining what Google was doing (mapping networks to provide a pseudo-gps capability), roughly how they were they doing and the potential pitfalls rather than the gritty details of how the specific program worked.
You can see that in the source code for gslite (Google's collection software), it specifically discards encrypted data while writing unencrypted data to disk. It is not reasonable to argue that Google "accidentally" coded their software this way.
Looking more closely you can see that by default the program is written as you say, but the only difference between whether encrypted and unencrypted data is recorded is the setting of a flag. It's a 3second change one way or the other. Additionally, the default behavior can be overwritten by command line arguments when the program is started.
if you look at Google's original blog post you can see that gslite was written for a completely different project, perhaps one where recording data packets was useful and fully legal, ethical, etc. It was then appropriated for street view a year or so later (no reason to reinvent the wheel). What should have happened is that either (a) the source code could be changed to set the "discard_data_frame" flag to "false" just like the "discard_encrypted_body" flag or (b) the program that calls gslite (I doubt they're running it manually) should have had the command line argument to discard all data past the packet header.
Obviously this was not done and someone is in a lot of trouble as they well should be. Not setting a command line argument, however, is a much easier mistake to make than intentionally writing a piece of software to only work one way as you imply.
[ link to this | view in chronology ]
Re: Re:
You're right, configuring a command line argument incorrectly is an easy mistake to make. But Google was doing this for over three years. Why didn't they correct it when the data they were capturing included a whole bunch of extra payload data?
One more thing, if you're relying on Google to tell you the whole story... then you're not getting the whole story.
[ link to this | view in chronology ]
Re: Re: Re:
Who says they KNEW it was saving this data until recently? If they were not intentionally capturing the data why would they even know they had it?
[ link to this | view in chronology ]
Re: Re: Re: Re:
[ link to this | view in chronology ]
Software development
[ link to this | view in chronology ]
Re: Software development
[ link to this | view in chronology ]
- what degree of privacy (if any) do you have by allowing your data to be transmitted over an open connection
Considering how up-to-date the 4th Amendment is, I'm sure this isn't going to be a problem... Not.
So, its unclear whether or not Google intended on capturing the data or not. That is irrelevent. What people are going to have an issue with, is the fact that data WAS captured and they don't know what will happen to the data - anything from destruction to misuse by a disgruntled employee are probable. The latter is what runs through the minds of people when they realize data they were sending was captured.
As far as privacy is concerned, this doesn't seem to be so much a privacy issue as perhaps a wiretap issue or even a trespassing issue - altho I'm sure open Wifi could be considered public so it may not even be an issue in that case.
Bottom line is people expect something as "invisible" as wireless data transmission to actually be private. Why would anyone go to Panera or Starbucks to perform credit card transactions in the first place?
[ link to this | view in chronology ]
Re:
You might be on to something. People really can be stupid.
Now I'm going to switch on my radio and wiretap some overpriced generic music.
[ link to this | view in chronology ]
based on all of that, your post is suspect. this is the same standard you would apply to others, i am just applying it to your own posts and actions.
[ link to this | view in chronology ]
Re:
"blah blah. vague reference to an illicit relationship. blah blah. there must be more to the story."
Techdirt has repeatedly disclosed their relationship with Google, there are like 10 links on the front page alone to posts where they talk about the work they've done with Google.
[ link to this | view in chronology ]
Re: Re:
"Techdirt has repeatedly disclosed their relationship with Google, there are like 10 links on the front page alone to posts where they talk about the work they've done with Google." - enlighten me, i dont see any specific links on the front page that is "disclosure of relationship with google" or for any other company for that matter. the only disclosures mike has ever made is after comments like mine, otherwise he ignores the issue and considers it unimportant.
[ link to this | view in chronology ]
Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Too bad for all the Google haters...
[ link to this | view in chronology ]
Re: Too bad for all the Google haters...
While your analysis is close, any decent lawyer can poke holes in it. First of all, it's a district court case involving child porn. Courts are REALLY reluctant to let pedos off because of Fourth Amendment stuff. Second, Google CANNOT violate the Fourth Amendment (since it only applies to the gov't). Google's liability would be under the Wiretap Act, which uses "readily accessible to the general public" language, rather than "reasonable expectation of privacy" language.
While I agree that the case would support Google's position, it's by no means a slam dunk.
[ link to this | view in chronology ]
I wanna be like a blue collar comidian.
[ link to this | view in chronology ]
As long as we're talking conspiracy theories...
[ link to this | view in chronology ]
Re: As long as we're talking conspiracy theories...
[ link to this | view in chronology ]
Re: Re: As long as we're talking conspiracy theories...
http://en.wikipedia.org/wiki/Council_on_Foreign_Relations#Corporate_Members
Not that all that much should be made of such membership on the corporate level. In reality, pretty much every major multinational corporation is on there. It's part of being a MNC at this point, and the corporate members aren't thought to have much influence within the group, unlike select high ranking members that always seem to turn up in government.
Still, the fact that they're networking with these people is less than pleasant....
[ link to this | view in chronology ]
Still an accident - or gross incompetence by a leader in the field of data.
And you are saying that even when they are in trouble for sniffing open wifi in one country, and admiting they did it.
They were engaged in exactly the same practice in other countries. And you (and some blogger, refered to by slashdot), who explains who a packet sniffer works, and you think google would not know exactly what they were doing, and be able to only read the 24 bytes of the packer, and the signal strength info.
You say they do not use the data, then why have I seen google maps with open and closed WiFi ports overlayed ?
To say a company like google "accendently" collected that data is just an attempt at mitigating their actions, and trying to take away to premeditation that is required to undertake this act.
The other thing is "there is no such thing as an accident".
"An accident is a specific, unidentifiable, unexpected, unusual and unintended external action which occurs in a particular time and place, with no apparent and deliberate cause but with marked effects."
You just cannot have multiple exactly the same "accidents" in different countries, by different people, employed by the one company.
That is not an accident, its premeditated, deliberate, and clearly done for a specific purpose and outcome.
Considering it is so easy to correctly gather the **right** data, and not gather this information.
And a company like Google, are too big, and too expert in this field to claim it as an accident.
Sure, I concede that it was an accident for google to do it in the first place, and to get caught second.
Its a major accident to googles reputation as a company that acts responsibility and that is aware of the importance of privacy, and the responsible dealing with vast quantities of data. (that is not theirs).
So if a Mike, or a Joe blogs claims to accendently log open WiFi, I would not believe him either, but it is more feasible someone could do that one time by mistake, but not a Google, who while in trouble in one country for this perform the exact same act in several other countries.
That is not an accident, and Google is the last company I want having "accidents" with my data, thankyou.
So the blog, that slashdot quoted, that you quoted from slashdot, (thats Robert Graham of actual content).
He is a blogger like mike, what he says, makes no bearing on Googles acts. But Robert does show how it is trivial to do it right, which would imply a company like google would be fully aware of that as well.
No accident there.
and no explination of how it could possibly be an accident..
An accident is a unique event (at a particular place and time), it is not possible to have 'an accident' in multiple different countries at different times.
They are not the same accident, each one is an independent accident, which is not feasible.
So again, Googles claim it was an accident, is like asking a thief if he is guilty or not. Ofcourse, their opinion is highly biased.
Its up to observers to determine accident, or premeditation, and clearly repeating the same 'accident' after being called out for it in one country, must not be an accident.
An accident is something that happens that was not your INTENT.
You can drive a car, your intent is to get to your destination, an accident is something happening, unexpected and not predictable.
If you are driving far beyond the speed limit, you are not expecting to have a crash, but if you do crash it was not accendental, as you were driving wrongly. (too fast).
you can never perform that same event, that accident (caused by intent, by speeding), as an accident is something that occures at a particular place and time.
Are you saying that the google people spent months driving around all these sites, gathering data, and during that time did not review their work to date, and notice this information.
Ofcourse they did, and ofcourse they were away that data was provided, I assume under managements instructions.
You do not map vast areas of a country, and logs huge amounts of data and not test, review and examine the data and collection method until the end of the project.
You test these at the begining, prove the system before using it.
Your saying a company the size of google would do all this collection, and not MEAN to collect, and not notice DURING the collection that certain data was being collected ?
I guess claiming it was an accident might please some, but for most its beyond the possibility that google did not know what they were doing it, while they were doing it, and the multiple countries they were doing it in !!!..
but if you believe that, that is fine..
Go ahead trust google with everything you own.. for me,, no thanks.
Saying it was an accident means they are either lying or incompetent, take your pick ..
[ link to this | view in chronology ]
Re: Still an accident - or gross incompetence by a leader in the field of data.
Mapping public Wi-Fi spots is not illegal. Darryl storming in again with another misinformed, overly long, badly formatted post.
[ link to this | view in chronology ]
Re: Still an accident - or gross incompetence by a leader in the field of data.
I answered this last night in response to your other comment on this topic. They were mapping WiFi networks. That is not illegal. What you saw was perfectly legal and many companies do it.
The questions here are not about mapping WiFi. It's about the collection of data going through those routers. No one denies that they were mapping WiFi data points. But that's legal.
Consider we explained this to you last night, I cannot figure out why you would continue to repeat the same falsehood.
You just cannot have multiple exactly the same "accidents" in different countries, by different people, employed by the one company.
Again, this was explained to you last night. Of course you can: all Google locations were using the same technology, so of course the same thing happened everywhere.
Sure, I concede that it was an accident for google to do it in the first place, and to get caught second.
They didn't "get caught." They admitted it publicly once they found out about it.
An accident is a unique event (at a particular place and time), it is not possible to have 'an accident' in multiple different countries at different times.
Darryl, can you please stop and listen for one second: the *accident* was in setting the software to record the unencrypted packets. That happened once. But that was in the software that was rolled out to all the street view vehicles. So, yes, the "accident" happened once, but there were repeated uses of it afterwards, without people realizing it.
Let me ask a question: with all the reports of Toyotas automatically speeding up that were in the news a few months back, leading to widespread recalls, based on your reasoning above, this must have been "intentional" by Toyota, right? After all, it happened many times around the globe. By your reasoning here, Toyota "intentionally" planned to make its cars accelerate without warning.
But, of course, that's ludicrous. It seems clear that there is some flaw in Toyota's setup. That flaw is an accident. But it was rolled out to cars worldwide.
Same thing with Google.
Are you saying that the google people spent months driving around all these sites, gathering data, and during that time did not review their work to date, and notice this information.
They did review the info they were TRYING to collect. The location of WiFi hotspots. That's not the same as reviewing the payload data.
You have, in the past, claimed that you are a well known technologist. I'm having trouble believing that when you seem to be confusing some very basic technology issues.
[ link to this | view in chronology ]
Re: Re: Still an accident - or gross incompetence by a leader in the field of data.
Then after they did that, and got home they looked at the data and said "oh dear, we logged the entire country, taken weeks or months to do it, and only now that we look at the data we see we got too much".
Do you **NOT** think Mike they might do some small trials first may be a small city, then look at the data, and work out how to put it on a map ?
Or;
Do you think they went out and did the entire country, just **ONE** group, in a short period of time, and during that time did not look at their data to date, even just to check the system was working.
AND;
Do you expect us to believe that someone who is supposed to be technology savvy would make such a huge error, or undertake such a huge project without testing and trials first ?
AND finally; do you expect us to believe that ?
No, im not a well known technologist, im a knowlegable technical engineer.
and unlike the fellow you qoute here as your souce, I do not claim that "im a world leader in this (WiFi) technology and have been studying it for the past 20 years"
This guy you quote, has been studying WiFi technology since before it existed !!! amazing.
A car company that produces a part that is faulty, is an error not an accident. By definition.
Again, you dont have multiple accidents.
That is just wrong, as you should well know. You use words all the time Mike, you should use the right ones, and be accurate on using the right words to describe the right events.
I know you like to spin to a degree, and like to use violation over theft, (tell a 6 year old who has been violated why that is better than theft ?)
A single component, that is produced, that has an impurity or something falls into the machine is an accident.
A design error, that results in many faults is not an accident. Its not unexpected, if the designer had of done the right job in the first place the error would not occur.
In an accident, the designer can do everything right, but the part can still fail. Can you or anyone else see the difference.
You design a bridge wrong, and it falls down its not an accident, its criminal neglegence (or gross incompetence).
The bridge did not fall down accendently, it fell down because it was designed or built wrong.
So you cannot have multiple accidents, you can have multiple errors.
And you Mike, who tries to be a word smith, should take more care and accuracy in your statements. Should be desire to be taken seriously.
[ link to this | view in chronology ]
Dear AGB,
Here is a website that may help in your quest.
http://zapatopi.net/afdb/
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Google apologia?
It appears that you are ignoring a lot of relevant information...
My longer reply can be found at:
http://precursorblog.com/content/is-mr-masnick-becoming-googles-go-apologist
Scott Cleland
President, Precursor LLC
Publisher, GoogleMonitor.com & Googleopoly.net
[ link to this | view in chronology ]
Re: Google apologia?
First, I find it amusing that he still hasn't even noticed or responded to my response to his first totally false hatchet job. But that's typical. His job is not to respond to facts, but to lie about people who are actually getting it right.
As for what he said? Let's take a look.
Last week Mr. Masnick summarily dismissed the possibility that Google could behave anti-competitively in search
I did not such thing and already responded to this assertion. Saying that there is no such thing as search neutrality is NOT the same thing as saying Google couldn't behave anti-competitively.
Why would Cleland blatantly lie? I don't know.
Apparently Mr. Masnick has drunk the Google Kool-Aid since he is sure that Google could not do wrong in the antitrust and privacy arenas.
Again, I neither said nor implied any such thing. In fact, I have dinged the company on privacy issues in the past multiple times. I believe the company very much can and has done wrong on those things. But that doesn't mean I believe every fear mongering story that AT&T paid Cleland to write.
Mr. Masnick would retain more credibility if he acknowledged the possibility of Google's fallibility in these human endeavors.
I have and continue to do so. Amusingly, in Cleland's rush to say I never argue against Google, he appears to miss the two posts last week where I did exactly that. For example he totally missed this post: http://www.techdirt.com/blog/wireless/articles/20100610/1358039772.shtml
In last week's blind defense of Google that "There Is No Such Thing As Search Neutrality, Because The Whole Point Of Search Is To Recommend What's Best," Mr. Masnick effectively dismisses the possibility that Google could have monopoly power
I did no such thing. I don't know why he continues to say this. I also already responded to this charge in a post. Cleland repeating it is just kinda sad.
even though the U.S. DOJ Antitrust Division determined Google is dominant in search advertising and was prepared to bring a Sherman Act monopolization case against Google in November 2008, if it did not drop the proposed Google-Yahoo ad Agreement.
That has nothing to do with what I actually wrote about: which is whether or not "search neutrality" exists.
Mr. Masnick apparently does not understand the concept in antitrust that a company with market dominance or monopoly market power must operate under a different and stricter standard of conduct to prevent anti-competitive behavior.
I do actually understand that quite well. And I, unlike Scott Cleland, also seem to understand that this has absolutely nothing to do with what I actually wrote about.
But, since Cleland apparently is unwilling to deal with what I actually said, he needs to blatantly lie about what I said.
Note, by the way, that Cleland doesn't actually quote anything I said. He just pretends I said all sorts of stuff I never said.
Last week I rebutted Mr. Masnick's Google antitrust apologia by explaining that even Google itself disagreed with Mr. Masnick's characterization
No, as I already pointed out (http://www.techdirt.com/articles/20100621/0355239887.shtml -- though Cleland apparently didn't even bother to read it). What Cleland did was pretend I said something I did not. He pretended "search neutrality" meant something different than it does and pretended I made claims that I did not. When I responded, Cleland did not update or change his position. He just keeps repeating it.
Keep it up Cleland. It just makes you look that much more ridiculous.
I challenged Mr. Masnick because he was completely ignoring a serious and legitimate issue, search neutrality, and also ignoring substantial evidence in the public domain of a Google antitrust problem.
And I responded, but apparently Scott Cleland doesn't actually read responses to his lies.
Now this week Mr. Masnick is assuming the role of Google's go to apologist again by declaring he is "almost certain" Google's three-year WiFi data collection in over thirty countries by retrofitting its entire StreetView vehicle fleet with special WiFi antennae was "accidental."
Now this is the fun part. Cleland doesn't actually read or respond to what I wrote. He doesn't note that I linked to and quoted a security expert who explained in great detail what likely happened.
No.... instead, he seems to base his whole complaint on the headline, and makes it sound like I'm just giving my opinion without any factual basis to back it up at all.
Apparently Cleland assumes that his readers are so braindead that they don't actually read source material.
Has it ever occurred to Mr. Masnick that Google's well-known mission to organize all the world's information at least suggests the possibility that this particular WiFi data collection could have been intentional and not an accident, given that Google tracks most everything else that happens over the Internet?
Sure, that's occurred to me. But we weren't randomly speculating like you do. We looked at the actual evidence. Something Cleland is not fond of doing.
Mr. Masnick would have more credibility if he did not summarily dismiss the possibility that someone in the privacy offices of several nations, the FTC, Scotland Yard, and roughly 30 state Attorneys General who are now investigating Google's international WiFi data collection, might know something that Mr. Masnick might not be aware of?
Unlike Scott Cleland, I'm willing to wait until after these things go through before assuming what these investigators know or do not know.
I find this particular Clelandism telling. Multiple times now, he attacks me for ignoring evidence, but each time that "evidence" is merely a charge by either a gov't official or another company that Google *MIGHT* be doing something. To Cleland, just that is evidence. That Google has yet to actually face any of these charges in court apparently is lost on Cleland. Odd.
In short, Mr. Masnick would enjoy more credibility on these topics if he spent less time parroting the absolutist Google PR talking points and more time being "open" to the mounting evidence that Google may be acting anti-competitively and may be acting irresponsibly concerning consumers' privacy.
Except, of course, my points have nothing to do with Google PR.
Scott, just because you are well-paid to spout anti-Google talking points, you really shouldn't assume that anyone who proves you wrong is doing the same thing.
And, in the future, when you choose to write an entire hatchet job post attacking me, you could at least respond to what I actually wrote, other than what you pretended I wrote.
This, by the way, is why no one in DC even pays attention to Cleland any more. He's done this so many times his name is a joke.
[ link to this | view in chronology ]
Re: Re: Google apologia?
Seems to me that the only reason someone wouldn't respond to a total and complete reply (like Mike's) is if they knew that they were coming from a position entirely without merit to begin with.
Thank you, Mr Scott. Your silence is speaking volumes about you.
[ link to this | view in chronology ]
General question regarding this issue....
[ link to this | view in chronology ]
Bias Detector
[ link to this | view in chronology ]
Re: Bias Detector
Do you have something substantive to add? I have regularly sided against Google on this site. The idea that the few dollars I get from Google each year (significantly less than 1% of our revenue) influences the coverage is preposterous.
[ link to this | view in chronology ]
Re: Bias Detector
[ link to this | view in chronology ]
Quite a lot of the above
I was wondering what those commenting above might have to say in light of recent revelations regarding Google's (and others') alleged role in enabling wholesale incursions into citizens' private lives by our security organisations?
[ link to this | view in chronology ]