Risk
11/15/2011
08:58 PM
Connect Directly
Google+
LinkedIn
Twitter
RSS
E-Mail
50%
50%

Google Wi-Fi Privacy Fix, Explained

Workaround stops Google from storing your network's location in its database of Wi-Fi access points, but there's a naming catch.

After discovering early last year that its Street View cars had inadvertently been vacuuming up swaths of data traveling over unprotected Wi-Fi networks since 2007, Google said that it was mortified and took a series of steps to improve its internal privacy and security practices.

And when it settled with the Federal Trade Commission in March over privacy problems arising from the launch of its Buzz social networking service, Google's director of privacy, product, and engineering Alma Whitten said the company is "100% focused on ensuring that our new privacy procedures effectively protect the interests of all our users going forward."

Monday, Google took what it suggested was an additional step toward addressing privacy concerns related to its data collection practices. Peter Fleischer, the company's global privacy counsel, said that Google will honor a method that it is proposing to prevent location data associated with Wi-Fi networks from being stored in the Google Location Server, a database of Wi-Fi access points used for delivering location-based services.

[For more background, read Google 'Mortified' Over Wi-Fi Data Gathering.]

Google said in September it was developing a way to opt out of its Wi-Fi network data collection.

Wi-Fi network owners who wish to prevent the location of their network from being gathered and stored must append the suffix "_nomap" to the SSID they have chosen to identify their Wi-Fi network.

"As we explored different approaches for opting-out access points from the Google Location Server, we found that a method based on wireless network names provides the right balance of simplicity as well as protection against abuse," Fleischer said in a blog post. "Specifically, this approach helps protect against others opting out your access point without your permission."

Google's approach, however, seems certain to diminish the humorous potential of using SSID names as medium of free expression. Witty SSID names become less so with a punchline that ends in "_nomap."

Of greater concern to privacy advocates is the fact that while Google isn't storing location data associated with Wi-Fi networks that have opted out, it is storing the MAC addresses associated with Wi-Fi networks. MAC, or Media Access Control numbers, are unique numbers assigned to networkable devices by their manufacturers.

Google suggests this is not a privacy concern: "A MAC address tells you nothing about the owner or user of the equipment concerned. It's just a string of characters that's technically necessary for Web pages and other content to be properly delivered to your device over the Internet."

Not everyone agrees. As IT systems engineer Joe Mansfield put it last year in a blog post, "MAC addresses can tell far more about you than you think and keeping databases of where and when they've been seen can be extremely dangerous in terms of privacy."

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
hguckes193
50%
50%
hguckes193,
User Rank: Apprentice
11/17/2011 | 9:41:08 PM
re: Google Wi-Fi Privacy Fix, Explained
An opt-in option would truly protect privacy.
iWkRdr
50%
50%
iWkRdr,
User Rank: Apprentice
11/17/2011 | 5:42:55 PM
re: Google Wi-Fi Privacy Fix, Explained
Everyone should change their SSID to googlesucks
Liz Coker
50%
50%
Liz Coker,
User Rank: Apprentice
11/16/2011 | 11:43:22 PM
re: Google Wi-Fi Privacy Fix, Explained
Really? The average home user doesn't name their Wi-Fi network. They just leave it on the factory default (I don't know the numbers but I bet "linkys" is the most popular Wi-Fi name for the average household network. While I give Google credit for doing something, this seems pretty half-hearted. The proof will come in how and how broadly they communicate the opt-out option. If you are talking about a goal of simplicity and broad adoption, this is not the solution.
AustinIT
50%
50%
AustinIT,
User Rank: Apprentice
11/16/2011 | 9:09:53 PM
re: Google Wi-Fi Privacy Fix, Explained
I agree with Joe on his point about MAC addresses. They are globally unique for every network device and therefore act much like a finger print does.
jrapoza
50%
50%
jrapoza,
User Rank: Apprentice
11/16/2011 | 9:03:55 PM
re: Google Wi-Fi Privacy Fix, Explained
Most of this vacuuming of data by Google makes little sense. It must provide some form of profit for them, since they are fighting so hard to continue doing this. The biggest joke is that most open WiFi hotspots are from people not sophisticated enough to protect their network, which means they aren't sophisticated enough to add nomap to their SSID (SSI what??)

Jim Rapoza is an InformationWeek Contributing Editor
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Five Things Every Business Executive Should Know About Cybersecurity
Don't get lost in security's technical minutiae - a clearer picture of what's at stake can help align business imperatives with technology execution.
Flash Poll
Dark Reading Strategic Security Report: The Impact of Enterprise Data Breaches
Dark Reading Strategic Security Report: The Impact of Enterprise Data Breaches
Social engineering, ransomware, and other sophisticated exploits are leading to new IT security compromises every day. Dark Reading's 2016 Strategic Security Survey polled 300 IT and security professionals to get information on breach incidents, the fallout they caused, and how recent events are shaping preparations for inevitable attacks in the coming year. Download this report to get a look at data from the survey and to find out what a breach might mean for your organization.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7445
Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...

CVE-2015-4948
Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

CVE-2015-5660
Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

CVE-2015-6003
Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

CVE-2015-6333
Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.

Dark Reading Radio
Archived Dark Reading Radio
Security researchers are finding that there's a growing market for the vulnerabilities they discover and persistent conundrum as to the right way to disclose them. Dark Reading editors will speak to experts -- Veracode CTO and co-founder Chris Wysopal and HackerOne co-founder and CTO Alex Rice -- about bug bounties and the expanding market for zero-day security vulnerabilities.