LWN.net Logo

Security quotes of the week

A conventional hacker or criminal isn't interested in any particular target. He wants a thousand credit card numbers for fraud, or to break into an account and turn it into a zombie, or whatever. Security against this sort of attacker is relative; as long as you're more secure than almost everyone else, the attackers will go after other people, not you. An APT [Advanced Persistent Threat] is different; it's an attacker who -- for whatever reason -- wants to attack you. Against this sort of attacker, the absolute level of your security is what's important. It doesn't matter how secure you are compared to your peers; all that matters is whether you're secure enough to keep him out.

APT attackers are more highly motivated. They're likely to be better skilled, better funded, and more patient. They're likely to try several different avenues of attack. And they're much more likely to succeed.

-- Bruce Schneier

The US will be able to block a site's web traffic, ad traffic and search traffic using the same website censorship methods used by China, Iran and Syria.
-- Mozilla on the "Stop Online Piracy Act" (SOPA)

A while back Homeland Security asked Mozilla to take-down an add-on without a court order or a finding of liability. Under a SOPA regime, it appears the same incident would allow the putative plaintiffs to petition the Attorney General to issue an injunction compelling take-down based only on a specious claim of contributory infringement. Oddly SOPA makes one really appreciate the DMCA.
-- Harvey Anderson, general counsel for Mozilla

We're introducing a method that lets you opt out of having your wireless access point included in the Google Location Server. To opt out, visit your access point's settings and change the wireless network name (or SSID) so that it ends with "_nomap." For example, if your SSID is "Network," you'd need to change it to "Network_nomap."
-- Google adds a privacy option that many access point owners may find challenging to use
(Log in to post comments)

Security quotes of the week

Posted Nov 17, 2011 2:10 UTC (Thu) by smadu2 (subscriber, #54943) [Link]

"To opt out, visit your access point's settings and change the wireless network name (or SSID) so that it ends with "_nomap." For example, if your SSID is "Network," you'd need to change it to "Network_nomap.""

Wrong on so many levels.

Security quotes of the week

Posted Nov 17, 2011 4:53 UTC (Thu) by thedevil (subscriber, #32913) [Link]

"Wrong on so many levels."

Very true, but does it cross the line into *evil*?

Security quotes of the week

Posted Nov 17, 2011 7:34 UTC (Thu) by smadu2 (subscriber, #54943) [Link]

IMHO yes it does when it says opt out.

Security quotes of the week

Posted Nov 17, 2011 6:06 UTC (Thu) by raven667 (subscriber, #5198) [Link]

I only see one other technical option and that is entering the MAC of your AP into a Do Not Track web form similar to Do Not Call, anything else would require a protocol change.

Security quotes of the week

Posted Nov 17, 2011 8:03 UTC (Thu) by Cato (subscriber, #7643) [Link]

Google should really provide this option - while it requires an update if you change your router, it's much easier for me to put a MAC address in a web page than to change the SSID and ensure that 6 home clients use the new one.

There's also something unpleasant about even having to opt out of being monitored by Google...

Security quotes of the week

Posted Nov 17, 2011 12:13 UTC (Thu) by ekj (guest, #1524) [Link]

The _nomap-option has the benefit of authenticating you in the same step. By changing the SSID, you demonstrate (to Google) that you're disabling gathering of information from a access-point that is, infact, under your control.

If you just put MACs in a web-form, it'd be tricky for google to know whether those numbers where *your* numbers, or someone elses. Additionally, MACs aren't globally unique, they may be in the default case, but many devices have the capability of using a software-set MAC. (they must be unique for one segment, for things to work, though)

Security quotes of the week

Posted Nov 17, 2011 17:11 UTC (Thu) by raven667 (subscriber, #5198) [Link]

That was what google said but there are some unstated assumptions behind that that are probably worth mentioning.

Why would confirming ownership before allowing privacy opt-out be required? The Do Not Call registry doesn't authenticate requests AFAIK. What is the downside of allowing unauthenticated opt-out requests? Worried about a competitor or privacy activist nuking the database by submitting every possible MAC?

MACs not being globally unique either because the manufacturer has to recycle the numbers or the owner manually set it means that it can't be a unique primary key and would need to be combined with some other info, like a rough location (maybe postal code) to be unique. That may mean that for a web form opt-out there would be a need to disambiguate and ask for more information that just the MAC, which may reveal more than is desired about how the data is collected and stored.

But again, what are the assumptions driving the desire to authenticate ownership when opting out?

Security quotes of the week

Posted Nov 17, 2011 18:45 UTC (Thu) by Darkmere (subscriber, #53695) [Link]

Apply the same approach to their search index.

Allow anyone to file a "do not index" for any site possible. Require website owners to manually re-enable search once you've dropped them.

Sounds feasible? No? Doesn't sound very good, does it? Better to own&prove that you do not want indexing (/robots.txt) instead?

That's where we end up.

Security quotes of the week

Posted Nov 18, 2011 4:28 UTC (Fri) by raven667 (subscriber, #5198) [Link]

The difference here is that with search, a malicious "Do Not Search" request would harm the site owner and not google, a malicious Do Not Index may harm google's accuracy but not the site owner

Security quotes of the week

Posted Nov 20, 2011 17:55 UTC (Sun) by geuder (subscriber, #62854) [Link]

> malicious Do Not Index may harm google's accuracy but not the site owner

Malicious do not index will harm geolocation aware browsing (implemented e.g. by Firefox (and I'd bet Chrome although I have not tried it there)).
It was really a surprise 2 years ago to learn that they can locate me down to only 10s of meters as long as I have WLAN active.

So the harm is both for a user who wants to benefit fron geolocation and the web site provider who offers some service based on it. (which at the moment means it is minimal, at least I have not seen much use of the feature) Google is not immeditely affected, I understand nobody pays for using the feature.

But anyway the _nomap thing is weird. That you have to tell the whole neighborhood publicly if you don't want to be in Google's does not match well with the idea if privacy.

Security quotes of the week

Posted Nov 20, 2011 20:51 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]

Remember that you are telling the entire neighborhood who you are publicly in the first place. If you weren't, Google wouldn't be picking up your SSID broadcasts.

your access point is periodically shouting your ID to anyone in the area and you are getting upset when people make note of it.

Security quotes of the week

Posted Nov 20, 2011 23:41 UTC (Sun) by geuder (subscriber, #62854) [Link]

> your access point is periodically shouting your ID to anyone in the area

10 times a second typically...

Who somebody is is much less of a privacy issue in the neighborhood. Most people talk to their neighbors anyway and don't try to keep their existence or even names secret. And that somebody owns a WLAN AP shouldn't be too sensitive information either.

But that somebody opposes Google or their data collection is already a different thing. At least in this country here political opinions and who you vote for are big secrets for many people. (This might sound strange for Americans who put little flags of their favorite candidates in their garden, but that's the way it is.)

Security quotes of the week

Posted Nov 17, 2011 9:28 UTC (Thu) by michaeljt (subscriber, #39183) [Link]

>> "To opt out, visit your access point's settings and change the wireless network name (or SSID) so that it ends with "_nomap." For example, if your SSID is "Network," you'd need to change it to "Network_nomap.""

> Wrong on so many levels.

Yes, there is something amusing about having to broadcast a request for privacy over the airwaves.

Security quotes of the week

Posted Nov 17, 2011 19:17 UTC (Thu) by smadu2 (subscriber, #54943) [Link]

I left my door open - so you have the right to take pictures of what can be seen from my main door. To opt out please change your address so that it ends its with _noicturesplease.

Security quotes of the week

Posted Nov 17, 2011 20:07 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

> I left my door open - so you have the right to take pictures of what can be seen from my main door.

Actually, that probably is the case, at least in many jurisdictions. Anything you can see unaided from public property (e.g. the street or sidewalk) is generally considered fair game for photos. If you leave the door open, people can take pictures through it. They're not even required to heed an opt-out request.

Security quotes of the week

Posted Nov 17, 2011 10:09 UTC (Thu) by epa (subscriber, #39769) [Link]

If you're running an access point that broadcasts its presence to the world, it seems okay for someone else to make a compilation of that information, unless you ask otherwise.

For gathering and aggregation of public information, opt-out is a more sensible model than opt-in. Think of robots.txt for example.

Security quotes of the week

Posted Nov 17, 2011 17:14 UTC (Thu) by raven667 (subscriber, #5198) [Link]

That seems sensible to me but OTOH we always have the right to make rules that are more restrictive than just allowing what is technically possible, depending on how we want to live.

Security quotes of the week

Posted Nov 17, 2011 19:05 UTC (Thu) by smadu2 (subscriber, #54943) [Link]

"If you're running an access point that broadcasts its presence to the world, it seems okay for someone else to make a compilation of that information, unless you ask otherwise."

Compilation of broadcast information while itself may be fair - associating that compilation information with location and what not is the main problem here.

Security quotes of the week

Posted Nov 17, 2011 21:41 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

both pieces of information (the fact that you are broadcasting your id, and the location I am at when I hear it) are public information. why should it be a 'problem' to combine specific different pieces of public information?

and if it is a problem to combine public information, where do you draw the line?

Security quotes of the week

Posted Nov 17, 2011 22:57 UTC (Thu) by smadu2 (subscriber, #54943) [Link]

"both pieces of information (the fact that you are broadcasting your id, and the location I am at when I hear it) are public information. why should it be a 'problem' to combine specific different pieces of public information?"

Sure it is, especially when you combine and associate a lot of such said public information,

A IP address by itself is public information.
A home address is a public information.
lwn.net is a publicly available webiste.

I dont want some body (say my ISP or Google) to associate all this and label me falsely as a Linux geek :)

Security quotes of the week

Posted Nov 20, 2011 18:13 UTC (Sun) by geuder (subscriber, #62854) [Link]

> A IP address by itself is public information.

At least according to German courts an IP address is "person related information". And it's forbidden by law to store or process person related information if the purpose is not explicitly stated by law or you have an explicit agreement from the person the data is related to.

That's the reason why using Google Analytics on a web site was deemed illegal in Germany.

Disclaimer: I don't live in Germany and I'm not sure whether there has been reached any kind of compromise regarding Google Analytics in the meantime.

Security quotes of the week

Posted Nov 18, 2011 6:10 UTC (Fri) by jamesh (guest, #1159) [Link]

When deciding whether Google's location service is a privacy problem, it is worth looking at how they allow the general public to query the database.

You pass a list of the MAC addresses of near by access points to the service, and receive a location estimate back based on that data. Most people don't publish the SSIDs of their networks, let alone the MAC addresses, so chances are the person using the location service knows this information because it was broadcast to them independent of Google. They've probably already got a general idea of where they are, so the service acts as a way to improve that accuracy. And if they are already in the local area, they could conceivably triangulate the position of the access point themselves.

Now if Google provided a way to query the database based on SSID or starting location, things would be different.

Security quotes of the week

Posted Nov 18, 2011 6:29 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Now if Google provided a way to query the database based on SSID or starting location, things would be different.

Who says they, or other services which gather the same data, don't provide a general query product? I would think that law enforcement and intelligence services or criminals may be interested as they are more likely to have AP MAC information from compromised hosts that they'd like to know the physical location of.

If there weren't plans to use the data thusly then there wouldn't be many privacy implications.

Security quotes of the week

Posted Nov 17, 2011 17:46 UTC (Thu) by nettings (subscriber, #429) [Link]

"Dear Google! If you do not wish to see your sites DoS'ed to a screeching halt by a herd of zombie machines, just change your domain name to google-pleasedonthackme.com."

Somebody needs to take the Big Foam Cluebat to Google campus asap...

Security quotes of the week

Posted Nov 17, 2011 20:13 UTC (Thu) by robert_s (subscriber, #42402) [Link]

I hope you're just kidding and you do understand the difference between the two situations.

Google paranoia is one of the strangest phenomena around these days.

I mean, did you know there's an an organization around (in most countries) that gathers most peoples phone numbers in a book along with their addresses and names and publishes it? Scary stuff.

Security quotes of the week

Posted Nov 17, 2011 23:40 UTC (Thu) by nettings (subscriber, #429) [Link]

Like most people, I like to choose the SSIDs of my networks as I see fit, without any intervention by others. Forcing anyone to add a suffix to avoid being listed in a dubious directory is just as ridiculous as asking Google to change their domain name to avoid attacks. That's the whole point, nothing to do with paranoia.
Google putting hallucinogens into our drinking water is an entirely different issue - i just googled for it and it's telling how they have eliminated all traces of evidence in their search database. ;)

Security quotes of the week

Posted Nov 18, 2011 6:18 UTC (Fri) by raven667 (subscriber, #5198) [Link]

I don't understand your response at all. How is anyone intervening in how you choose SSIDs? How are you being forced to do anything? How is assisted GPS location dubious? How is the domain name example relevant to anything?

I think you are just making up rationalizations because you enjoy being angry for some unknowable reason.

Security quotes of the week

Posted Nov 17, 2011 23:28 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Just wait for some other mapping company to say that to opt out of theirs, you need to append '_dontmap' to it.

Security quotes of the week

Posted Nov 18, 2011 0:56 UTC (Fri) by cesarb (subscriber, #6266) [Link]

There is at least one positive consequence of this bizarre approach: it would make people who hide their SSID, under the mistaken belief that this gives them security, to stop doing that.

(The "correct" way of doing this opt-out would be to define a new IE for that specific purpose, but how many access points allow one to add a new IE to their beacon and probe response frames?)

Security quotes of the week

Posted Nov 22, 2011 14:17 UTC (Tue) by jwakely (subscriber, #60262) [Link]

Why would it make them stop hiding their SSID?
And why is it a positive consequence if they stop hiding it?

(Honest questions - I'm a wifignoramus and never even had wifi at home until this summer when I left the dark ages and got an android phone)

Hiding SSIDs

Posted Nov 22, 2011 22:46 UTC (Tue) by cesarb (subscriber, #6266) [Link]

> Why would it make them stop hiding their SSID?

First, an explanation about SSIDs. Every 802.11 network broadcasts a packet, usually around ten times per second, with information about the network. One of the pieces of information contained in this beacon packet is the "Service Set Identifier", or SSID, which identifies the wireless network. It is this SSID which is shown to the user as the network name on the list of visible wireless networks, and which is used by the stations (like your laptop or cell phone) to find the access points on the same network.

When you hide your SSID, you either send a zero-length SSID, or a SSID filled with zero bytes. AFAIK, "hiding" the SSID in this way is not part of the 802.11 standard, and in fact goes against the standard.

So, if you have a hidden SSID, how does the station find the access point? The answer is that it can send a "probe request", containing the SSID, and the access point answers with a "probe response".

So, let's say you follow Google's proposal and append _nomap to your network's SSID. On a normal 802.11 network, that SSID is then sent with every beacon frame, so Google's software will always see it. But what if you are "hiding" your SSID? Then the only way the Google software could know its SSID ends in _nomap, without waiting for someone else to connect to the access point, would be to send a probe request... containing the SSID it does not know!

So, the only way this opt-out could work is if you are not hiding your SSID. And I believe that the sort of person who hides their SSID because they read somewhere that it would make them more secure is also the same sort of person who would add _nomap to their SSID because they read somewhere that it would make them more secure.

> And why is it a positive consequence if they stop hiding it?

First, "hiding" the SSID gives a false sense of security, like MAC filtering. Every station, when connecting, has to send both the SSID and its MAC address in plain text (and the MAC address is in fact sent unencrypted with every packet). But since it *appears* to work (you cannot connect unless you know the SSID - that is, unless you know the tools to get it easily), nontechnical users can get fooled by it and not use encryption (or use the weaker easily broken encryption), which is what really can protect the network.

Second, it can actually *decrease* security, if they tell their computer to connect automatically. Since the computer cannot know it is near the access point by listening to the beacon frames or sending broadcast probe requests, it has to actively broadcast probe requests with that specific SSID, *even if nowhere near the access point*.

Third, it can cause breakage. Things like dropping the connection more often, or having trouble roaming between access points on the same network (on 802.11, you can have several access points on the same network, and in fact this is the true purpose of the SSID - to identify access points belonging to the same wireless network).

> (Honest questions - I'm a wifignoramus and never even had wifi at home until this summer when I left the dark ages and got an android phone)

I was in that situation before too, and when I first set up a wireless network (at work), I also made the mistake of hiding the SSID. Luckly, one the first machines I added to it was running Windows Vista, which warns you that hiding the SSID and having it connect automatically is a dumb idea. So that hidden SSID lasted less than a day.

Since then, I have read and learned a lot about 802.11 wireless networks. There are a lot of details I did not mention here (for instance, the BSSIDs, which I believe is what Google is actually after).

To close this long reply, some links about SSID hiding:

* https://en.wikipedia.org/wiki/SSID#Security_gains_of_SSID...
* http://superuser.com/questions/43836/automatically-connec...
* http://tisc-insight.com/newsletters/416.html

Hiding SSIDs

Posted Nov 23, 2011 23:44 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]

but the only way that google is going to record who and where you are is to watch for an SSID in any case.

otherwise all they know is that some packet was transmitted, they don't know where the base station is.

unless you think that recording the MAC address (or 802.11 equivalent) is somehow a problem?

as far as I know, what google is tracking is SSID and location (the vehicles may _capture_ everything sent over the air, but once the data is processed what they are keeping is much more limited)

I'm one of the people who considers that anything you broadcast is fair game for anyone who chooses to listen.

Hiding SSIDs

Posted Nov 24, 2011 9:19 UTC (Thu) by cesarb (subscriber, #6266) [Link]

I believe what Google records is the BSSID, which is nothing more than the access point's MAC address. There is no way to hide it; every 802.11 packet has the BSSID somewhere, since it is what identifies which wireless network the packet belongs to.

Since AFAIK Google's intention in recording wireless information is for coarse-grained location, recording BSSID/location/signal strength tuples makes sense. You listen for the beacons, and ask the Google server where you should be, given that you have seen these BSSIDs with these signal strengths.

Recording the SSID, for the purpose of location, is useless. To get your location from wireless beacons, you have to know the approximate location of the access points. However, there can be *several* access points with the same SSID, either for roaming within an ESS, or simply because it is a common SSID (like "linksys" or "Home"). The BSSID, on the other hand, is supposed to be globally unique, since it is a MAC address.

The MAC address for stations is useless, since they are often mobile. However, the MAC address for access points (that is, the access point's BSSID) is much more useful, since they are often fixed.

Yes, there is no private information (other than the access point manufacturer) in the BSSID. No, I have no idea why people would be scared of Google (or Skyhook Wireless, or who know how many other entities) creating a database of BSSID/location pairs. But since some people are for some reason scared of Google (even if they are not the only ones, or even the first ones, to create such a database), it seems Google decided to give them a way of opting out, so they go away. The strange way Google decided on for this opt-out is to change the SSID, since it is something easy for people to do.

I agree with you that 802.11 beacons are public; they are supposed to be public, since after all, they are your access point announcing its existence to the world.

Hiding SSIDs

Posted Dec 12, 2011 17:17 UTC (Mon) by jwakely (subscriber, #60262) [Link]

Thanks very much for the detailed reply.

(I only had a chance to catch up LWN comments yesterday)

Security quotes of the week [Mozilla about SOPA]

Posted Nov 17, 2011 11:45 UTC (Thu) by jimbo (subscriber, #6689) [Link]

China, Iran and Syria.

They've sold out to Big Media, too?
--
J

Biggest Media

Posted Nov 18, 2011 9:50 UTC (Fri) by man_ls (subscriber, #15091) [Link]

Yes, to the biggest media organization of all: [Central Scrutinizer voice] the Government.

Security quotes of the week

Posted Nov 19, 2011 7:33 UTC (Sat) by gmaxwell (subscriber, #30048) [Link]

> APT attackers are more highly motivated. They're likely to be better
> skilled, better funded, and more patient. They're likely to try several
> different avenues of attack. And they're much more likely to succeed.

They're also much less likely to exist. Most of us don't have any APT at all.

Security quotes of the week

Posted Nov 20, 2011 18:25 UTC (Sun) by geuder (subscriber, #62854) [Link]

Plenty of comments on Google's _nomap thingie already. But everybody has already accepted the fact that Google is the absolute monopoly?

What if Bing reqired you to append _foo and Yahoo required you to append _bar in order to prevent being included in their DB?

Disclaimer: I use 98% Google and 2% Yahoo services myself.

Security quotes of the week

Posted Nov 20, 2011 20:58 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]

it's far more likely that bing and yahoo will adopt the same thing than that they would each require something different

being the biggest dog in town an being the first to suggest a way to let others know that you don't want to be mapped does not make them a monopoly, let alone an absolute monopoly.

as for the question of if google is a monopoly, that's hard to say, they are by far the biggest, but also far from the only search engine. the barrier to entry for a new search engine is relatively low (yes, it does need a fair amount of hardware and bandwidth, but those aren't _that_ expensive nowdays, far less expensive than when google got it's start competing with the established search engines). There's not much in the say of lock-in here, If someone else comes up with a better search engine, it can gain a significant amount of users very quickly (or even if they just advertise heavily the way that bing did)

and in any case, it's far from being illegal to be a monopoly, it's only illegal to abuse your monopoly position

Security quotes of the week

Posted Nov 20, 2011 23:48 UTC (Sun) by geuder (subscriber, #62854) [Link]

> it's far more likely that bing and yahoo will adopt the same thing

What about consumer choice? If I wanted to trust/or work with 1, 2, 3, providers out of n? Not really possible with this naming scheme.

Security quotes of the week

Posted Nov 21, 2011 0:03 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]

It doesn't seem to make sense to complain about that possibility before there is an actual conflict.

you are assuming that some other provider will pick an incompatible tag to add to the SSID and that google will not also honor whatever this other way of tagging ends up being.

you are assuming malice when I don't see any reason to yet.

Also, other than saying that google is not allowed to listen to public broadcasts and record their location, what would you suggest that they do?

Security quotes of the week

Posted Nov 21, 2011 7:04 UTC (Mon) by geuder (subscriber, #62854) [Link]

I did not talk about malice. That's your interpretation.

All I said is that the solution is technically poor. In a free market economy the choice should not be boolean, but an array of boolean. And I made the observation that none of the numerous commenters had a problem with that. My conclusion is just that people have impicitly accepted that Google acts as a monolopy. I did not comment on malice from Google's side, I commented on the lack of criticism from what I expect to be critical audience.

Of course the problem is theoretical for the time being. Just like "640 K is more memory than anybody will ever need" was the answer to a completely theoretical problem at times.

Security quotes of the week

Posted Nov 24, 2011 16:40 UTC (Thu) by nye (guest, #51576) [Link]

>All I said is that the solution is technically poor

You're welcome to suggest a solution which is technically better.

Remember that your solution must be compatible with hundreds of millions of existing devices, without requiring that any of them be modified.

Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds