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
5 Reasons the Cybersecurity Labor Shortfall Won't End Soon
Steve Morgan, Founder & CEO, Cybersecurity Ventures,  12/11/2017
BlueBorne Attack Highlights Flaws in Linux, IoT Security
Kelly Sheridan, Associate Editor, Dark Reading,  12/14/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
The Year in Security: 2017
A look at the biggest news stories (so far) of 2017 that shaped the cybersecurity landscape -- from Russian hacking, ransomware's coming-out party, and voting machine vulnerabilities to the massive data breach of credit-monitoring firm Equifax.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.