Congratulations; I hope this gives us a safe, effective, open location service.
The privacy policy[1] could be clarified for less technical readers, and even for others. I infer that collected data is anonymous because you write,
1) We receive publicly observable data about WiFi access points and cell towers around you, your estimated latitude and longitude, and the date -- Not associated with anything else, that may be anonymous data -- though you could guess my home network or home location by the most common/strongest wifi signals. If you track data by submitter, you also would have a good idea of their travels.
2) we may receive certain temporary data such as your IP address. This data is deleted after being used as follows ... -- You seem to be implying that you do receive non-anonymous data, and delete it after innocuous uses.
3) You can send us data anonymously or under a nickname -- Which implies anonymity is possible.
If what I infer is correct, why not restate it directly and unequivocally with something like the following:
Unless you choose otherwise, the data you send will be anonymous and not associated with you in any way. We will not record who you are or what phone sent the data. We do receive some non-anonymous data, but we delete it within X hours/days after using it as follows ...
Good questions! The stumbler reports Wi-Fi and cell tower locations and an optional nickname. The location data is stored anonymously. The nickname and just the number of reported networks is stored separately, solely for display on the leaderboard [1] or other gamification in the future.
The IP addresses are just a fact of life of web server logging. They are not stored in the location or leaderboard databases.
"fact of life of web server logging" = screw you, we're not even going to consider deleting our logs even as we talk a good line about how much we respect your privacy
edit after downvote: also, mozilla engineering PMs will intimate on hackernews that it won't internally correlate and potentially sell any of the location and other information it most obviously could correlate about people, even though it has already announced its intention to advertise.
one industry norm that makes these things tough (again, not Mozilla's fault) is that at least under US law, Mozilla could change its privacy policies at some point in the future and do a lot more than it currently does.
and... my parent comment was brash and probably deserved the downvote it received.
Selling user data would be completely against our mission and values, and I think it would be extraordinarily hard for such a change to make it through the internal immune system for such things. I think Mozilla is less likely to do bad things with your data than just about any other company (or government for that matter) out there.
(Disclosure: I work for Mozilla. I am helping write an updated set of privacy guidelines for engineering teams, to be as explicit as possible about how careful and respectful we need to be with data.)
"2) we may receive certain temporary data such as your IP address. This data is deleted after being used as follows". So yes, they do say they delete it. Also, Mozilla has a better track record with respecting user privacy than anyone else in this space. (And where is their intention to advertise?)
i agree that Mozilla has a better track record than most large tech companies in most areas, but that also sets a pretty low bar. i'm more of the opinion that if Mozilla really were as committed to user privacy as they claim to be, they might not respond so flippantly to questions about server logs. If it wanted to, Mozilla could even stop logging "certain temporary data such as your IP address."
there are indeed many useful ways that server logs can positively contribute to improving user privacy; i just thought the attitude of "well of course...that's what everyone else does" (even though that's true!) was dismissive of good-faith privacy concerns.
I feel very ashamed, as someone who works in IT, everytime this happens. I mean, people can opt-out, of course - but, in order to do that, they need to know what an SSID is, and how to change it. What about people who don't? Will we just assume that they don't care or that their opinion doesn't matter?
As someone who works in IT, I always feel ashamed to see outrage over this. We somehow want both privacy as well as a freaking radio beacon spreading out a signal to hundreds of meters away. Let there be no mistake: using a Wi-Fi router in your house means you are voluntarily broadcasting an identifier to anyone within hundreds of meters. There can be no honest expectation of privacy there.
If you don't want people obtaining information from a radio beacon in your house then do not put a radio beacon in your house. But don't pester companies for opting out of the passive database of radio signals you are voluntarily sending into the world. You cannot have your cake and eat it too.
Furthermore, there is nothing intrinsically revealing about an SSID. If your SSID tells people information about you, the problem is the SSID and not the collection of that information. It is trivial to change your SSID to a pseudonymous one.
I know that a lot of people are not aware of the privacy consequences, but those people are not the ones making a point out of this. Once you educate yourself about the privacy consequences of using a Wi-Fi router, do not blame people for collecting information that you are actively and voluntarily broadcasting!
As you walk around, your phone broadcasts a list of wifi access points that you have connected to.
The existance of these databases mean that anyone who has unrestricted access to query the database, can probably figure out where anyone else who enters their vicinity, lives and works, completely passively.
Well, having your curtains open also broadcasts an image of your living room on EM spectrum for hundreds of meters for anyone with optics... Same for eavesdropping (laser mic). Easy to listen maybe but you will still get convicted in both cases.
The difference being that having a Wi-Fi router means actively powering a device that sends a signal beyond the perimeter and privacy of your home. A signal that, as evidenced by this app, can be passively [1] picked up and processed by any casual passer-by.
Having a Wi-Fi router with an SSID is the equivalent of installing a speaker on the top of your house and have it constantly spell a uniquish name to the neighborhood. It might be useful for you to have that, but you might want to think a bit about what it means for your privacy.
[1]: Not having to aim or target anything, not having to have exotic instruments, but being able to be picked up by anyone at all by just listening.
One could argue that the main purpose of the device (or the main reason users use the device) is not to broadcast identity, it is to let the user connect to the internet within the perimeter of their domicile.
Just like you can argue that the main purpose of windows is not so that people can look in, it's so that people can look out, and light comes in.
I agree partially with what you're saying, but there is a mismatch between user expectation and what the technology actually does. I don't think the fact that the user used it implies they consented to the technical side effects.
I can also passively collect plenty of WEP traffic being broadcasted over public property and decrypt it on my computer (but I don't).
Mozilla's not aiming to do anything remotely as invasive as that, but I still don't find "anything that can be picked up passively from public property is fair game" a very compelling ethical standard, especially for an organization like Mozilla.
> I still don't find "anything that can be picked up passively from public property is fair game" a very compelling ethical standard
This is a strawman.
Any public information that can be picked up passively from public property is fair game is the real argument. Decrypting WEP, easy enough as it might be, is still unethical as the information was meant to be private. Making a database of public SSID broadcasts is completely ethical as there should be nothing private about an SSID.
Yep. These services only store and transmit the BSSID (which is most often the mac address of the network card).
The only place the SSID (clear text name) is used is in filtering out things on the client end. Both looking for "no SSID" / hidden networks and the _nomap suffix. The SSID is never sent to any service.
you're arguing that there's a clearly defined category of broadcasted signals that can be clearly defined as public; i'm arguing that at least in ethical terms, what matters is whether the person behind the device knows and understands that their signal is leaking, where, and how that information could be used. for most people most of the time, i don't think that's the case. maybe we should agree to disagree :-)
> you're arguing that there's a clearly defined category of broadcasted signals that can be clearly defined as public;
This is another strawman.
I'm not arguing for a particular clear-cut definition of "public" and "private" at all. I'm arguing that the distinction public and private can be made for some forms of communication, and that a radio broadcast to your neighborhood means it is public, and encrypting your traffic means it is private. In addition to that there is also a greyer area like unencrypted traffic over a wire, that should mostly be considered private from an ethical perspective.
I agree that most people don't really know what they're doing, and I agree that it is problem. I also think that most people don't really care, and considering no information is contained in most SSIDs rightly so. Lastly I think that education is important for this, not regulation (legislative or internal) for the collecting companies or individuals. But all of that is not what I was arguing against.
> I know that a lot of people are not aware of the privacy consequences, but those people are not the ones making a point out of this.
Of course they are not making a point - they are not aware. How would you expect them to make a point?
What you saying is: if they don't know enough about the subject to decide if a point should be made, then we should ignore the right to give (or not) an informed consent (because you can decide for them if the SSID is "intrinsically revealing" or not).
How about we stop being so condescending, educate people to make an informed choice, and stop asking Google, Mozilla and anyone with a smartphone to think for them?
I totally agree, and that's not the issue at stake. The issue is: what should we do while people are not educated enough to make an informed decision?
Mozilla, Google (and some people in this thread) assume that it's right for them to decide if there are privacy concerns and advance with their initiatives. I don't. And they are, by marking this as opt-in, thinking for them.
It's still someone's own choice to install a Wi-Fi router and powering it on. The fact that many of them don't exactly understand that it might be privacy issue (if and only if they put identifying information in the SSID) does not mean that Mozilla and Google are thinking for them. The assumption that the router owner does not mean the SSID to be public is also not warranted.
If the SSID was mandated to be identical to someone's name (or any other identifying information), I'd say the problem you describe was real. But since it the information broadcast is mostly pseudonymous, I think it's quite a small thing you are arguing. If people are including personal information in their SSID, by all means tell them!
Would you say the same thing if I set up an IMSI catcher at your home and geolocated the other radio beacons broadcasting from your home, or would that be creepy?
You might jump to say "stingrays are illegal so that's different" and in some ways, you'd be right. But it's also the case that the average user's expectations about how their wireless devices will be systematically located by third parties are better codified into law and policy in that case than in this one.
I don't understand your comparison. An SSID broadcast is meant to be public information. An IMSI catcher actively exploits weaknesses of implementations to MITM non-public connections. IMSI catchers do not catch public information at all, they break into meant-to-be-private connections.
the only thing most people most of the time mean when they set up wi-fi is that they want to be able to connect their ipads and chromebooks to the internet at home.
IMSI catchers intercept signals broadcasted from radios that commonly transit across public property. my point was that we routinely consider things other than protocol specs in determining whether and when signals should be collected.
> the only thing most people most of the time mean when they set up wi-fi is that they want to be able to connect their ipads and chromebooks to the internet at home.
These are not the people I'm arguing against, and I mentioned that in my first post. People should definitely be educated about the privacy consequences of their equipment. I'm arguing against people who do know that an SSID broadcast is a public radio signal they themselves transmit, and are still arguing that other parties (Google, Mozilla) should be responsible for their privacy regarding that signal instead of themselves.
> my point was that we routinely consider things other than protocol specs in determining whether and when signals should be collected.
A radio signal that is explicitly meant to be public should be public information. A radio signal that is meant to private, but can be made public by exploitation or specialized instrumentation should not be public information almost all of the time. If the meant-to-be-public signal can be collected en masse by an app such as Mozilla's, then there's really no way people should feel any expectation of privacy in this regard.
Unless Google or Mozilla affirmatively knows that a given user understands the implications of broadcasting their SSID, I don't think it's reasonable to assume that everyone still broadcasting their SSID is doing so deliberately in the informed-consent for mapping sense of the word. That doesn't make Google or Mozilla bad...I just don't think it's a reasonable assumption for organizations to make.
It's hard for me to think of ways these organizations could reliably know whether people don't mind their SSID being mapped or used for related purposes without asking them.
Can you say more about your privacy concern here? I'm not seeing it.
As far as I know, the sole use of this database is to say, "if you can see this set of wifi networks, then you are probably at this GPS location." It's literally the same thing, except at a different electromagnetic frequency, as saying "if you can see houses with these addresses, you are probably at this GPS location." Kind of like a street map.
I definitely think that privacy concerns can emerge when you aggregate public data -- is there something I'm missing here?
So, is it fair to say that there's no privacy concern if the API only exposes a one-way lookup? I.e. "here are the access points I can see -- where am I?"
That also addresses the other concern raised below, that the database could be used to search for known-vulnerable routers.
> is it fair to say that there's no privacy concern if the API only exposes a one-way lookup?
It helps, but no. The data is still there to use. The API or Mozilla policy may change, or security may fail.
From what I can tell, there's no need to record either the devices gathering data or the devices looking up their location. Just don't store that data and everything is fine.
Oh, another example that affects even the one-way lookup is stalking -- if I've been over to Joe's house before, and then he goes into hiding, I can say, "hey, I see Joe's access point, where am I?"
That could be mitigated by requiring at least two access points for a query.
Both the Mozilla API as well as Google have this "you need to know two" protection. At Mozilla we go a bit further and also make sure the two BSSID's you are sending aren't almost identical. That happens in a lot of modern access points who are setup with separate 2.4 and 5GHz networks or those who have a guest network.
Your point is wrong from the beginning: I don't have to explain my privacy concerns, and neither do the others who don't know what an SSID is. "Privacy" should be the default and without need for justification, not the other way around.
How do you feel that privacy is being violated by scanning SSIDs and pinning those SSIDs to GPS coordinates? I believe JackC's point is that there isn't a privacy concern here. The consumer's router is blasting out the SSID for everyone to hear, just like if you were standing on your roof shouting, or had a poster on the outside of your house. There's nothing wrong with those things being recorded, what makes SSIDs different?
I understand the sentiment but really feel like it falls when looking at the actual situation. It's checking on things that are broadcast outside of your own property, and even offering a way to opt out. It's like transmitting radio waves from your property and asking that no one listens. You have a control over the distribution method or whether or not it even exists.
so everyone should have to choose between having their home router's info added to large, aggregated databases and reconfiguring/not operating a router?
i know plenty of people for whom that's not a choice they're likely to know about. perhaps mozilla/google shouldn't be able to dictate my SSID or its visibility just because they don't want to incur the cost/complexity of obtaining affirmative, informed consent.
Yes, everyone should have to chose that. This should be a choice to make when you are broadcasting a signal out beyond your property. This would be like arguing that your wireless network shouldn't show up in the dropdown list you see when trying to connect to a wifi network. If it's a major concern, then you always have the possibility of using ethernet, but this information is publicly available.
I understand the spirit of your comment, but the number of non-technical people, especially in cities, that even know when signals are being broadcast outside their homes is likely quite small. And it's probably almost never deliberate.
If technology perfectly reflected people's intentions for their devices, I think we'd see relatively few people deliberately broadcasting wi-fi outside of their homes intentionally and most people's SSIDs wouldn't show up on any dropdown outside their home.
I agree that this information is often available from public places, but I was getting at whose priorities should dictate whether/how the information gets collected and how it's used--people who paid for devices they may not fully understand or be able to control, or organizations that want to systematically exploit signals from them for different purposes that may be different from those of the person who owns the device?
Everyone who travels past your home can see if the lights are on in the evening. They can also see which lights are on in the front of the house.
So I'm going to give you three scenarios and I want you to tell me when exactly it becomes a privacy issue:
1) A single person travels past your house and happens to notice which lights are on.
2) Someone travels past your house and records, on a piece of paper, which lights are on.
3) A Google car travels past your house and records, electronically, which lights are on.
Same thing with WiFi SSIDs here. It is like you standing on the roof of your home and shouting your ATM pin using a bullhorn, then complaining when someone else hears or records the information.
You want people to stop "monitoring" your SSID? Stop freaking broadcasting it at all.
That solution is suboptimal. If you don't broadcast it, then properly provisioned clients have to probe for it. Which they do, on every channel. So you go from one device beaconing the SSID (your AP) to all client devices
advertising it, on every channel.
I think the difference we're talking about here between #1 and #3 is that #3 makes it much easier/cheaper to (for example) predict when you'll be out of town if they want to break into your house (router)...potentially even without ever traveling past it.
Just because this information is legal to collect, doesn't mean people think a nonprofit that claims to be committed to user privacy should be moving the center of gravity closer to your third scenario.
But maybe more importantly, we're not talking about "someone else" recording the information or just a few "people" "monitoring" an SSID. We're questioning the wisdom of an organization building software to systematically collect, store, and make an SSID far more readily available to far larger numbers of people.
Analogies are analogies because they're similar, not identical.
> You want people to stop "monitoring" your SSID? Stop freaking broadcasting it at all.
This is technocentrical BS, washing the hands to justify doing what you want.
1) Most people don't know that their SSIDs are being recorded (with position), so how do you expect them to make an informed decision? It's not like the information is readily available (I work in IT and I did not know about appending "no_map" to the SSID).
2) Everyone has a router, broadcasting the SSID. Do you really and honestly expect everyone to know how to disable it?
> I gave an analogy above, you didn't even answer it. When does it become a privacy issue exactly?
You see, that's the problem - and that's the point. I did not answer because:
a) I don't really care about my SSID privacy. I do, however, care about other people right to know what's happening and to make informed (not implicit, by Google or Mozilla rules) decisions; and
b) I really don't (shouldn't) have to. It's not your concern when or how I feel my privacy being violated. I don't have to answer that, and it's a sad, sad society where this happens.
But SSIDs are not private. At all. Should what the outside of your house look like be private information? How would that work? What about when I appear in the background of a photo someone took on the street?
> Should what the outside of your house look like be private information?
Everyone knows that someone can record the outside of your house; not everyone knows that SSIDs with location can (and actually are!) registered. Do you notice the difference? You can't assume that WLAN specifics are as tacit as knowing that people can look at my house!
Even if you did explain to everyone that their SSIDs are being indexed - what would you tell them is actually being indexed? What personal information are they giving up? Your address, age, other residents of your house are already listed publicly. The name you gave your wireless network pales in comparison.
through no fault of mozilla's, most home routers are ridiculously, pathetically insecure. this is not a situation that would be improved by making it easier to geolocate routers from specific vendors. if vulnerable routers become easier to find, my communications passing through that router could quickly become a lot less private. would mozilla be responsible? no. but that doesn't mean mozilla sharing my probably-vulnerable router's location wouldn't play a role in compromising my privacy.
Using SSID naming conventions to do this is just dishonest: most of the people who will be scanned won't know what an SSID is. Even if they do, and do have the competence to change it, how many of them will know about this convention? More than this: how many "home network owners" know that their networks are being scanned and georeferenced? This opt-out scheme is ridiculous and plain "hand-washing" - they obviously don't expect people to use it.
> "Make this "opt-in"" is a statement, not a procedure. How, and why?
I don't really care about the procedure; Snailmail, if need be. Convenience is not a valid argument for breaking privacy.
> Would the cons outwheigh the pros?
The answer to this is dependent on one's stance. As you may imagine, from where I stand, they do (clearly). I can't see any "logistical inconvenience" justify breaking privacy by default.
the obvious option is to request consent instead of violating people's privacy and make a dragnet data collection effort like this opt-in instead of opt-out.
but that's clearly not the intention here, because how dare anyone question someone else's motives/objectives/priorities for collecting data about devices they don't own. in fact, we're supposed to think this is the "nice" version because a google-funded nonprofit is doing it instead of google doing it unlawfully with cars or through waze.
seeing mozilla move in this direction while talking about how much they respect everyone's privacy is a strategic stumble indeed.
Did you ever count APs during a short walk in a relatively low density neighbourhood? You have hundreds in under 100m.
Tell me, how do you plan to ask each and everyone of them? Ring on every doorbell?
-Sorry, is FritzBox!239?
-No, here is YouMakeTooMuchNoiseWTF
-Oh, I see, could you please pass a message to your neighbour? I'd very much appreciate if he could please fill in this form and send it back through paper mail to Mozilla…
that would be one respectful way to do it, and yes, challenging.
but the premise of your comment is that of course my device's SSID and related location should be collected in someone else's database because a google-funded nonprofit wrote an app for people to go wardriving with.
just because SSIDs can be legally observed and collected doesn't mean i have to be happy about it. I wasn't talking about this as a technical problem as much as an ethical/political one for an organization that claims to be committed to my privacy...except when it's not.
Hey, we're happy to hear about privacy concerns and ways that these might be addressed.
As for collecting your SSID information - devices are already storing SSIDs to do an active scan.
If you're not happy that the Mozilla Stumbler can record that SSID, you should probably also be unhappy that all WiFi devices capable doing a probe request - which is basically all wifi devices.
As far as the ethics concern - I'll bite.
This is one of the privacy reasons why we do not publish the wifi database yet. We haven't figured out a way to do this without exposing too much personal data yet.
We've got some rough ideas on how to do this, but nothing good enough yet that we'd be willing to expose our users to this risk.
"devices are already storing SSIDs to do an active scan" - Not mine, although I would readily acknowledge that I'm in the minority and this is generally a truism.
And thank you for acknowledging privacy concerns over publishing the wifi database, although I'm personally still concerned whenever that information gets aggregated systematically, even if it's internal to Mozilla.
One way I think about privacy for data like this is respecting people's intentions. When most people set up wi-fi, I would argue that their intent is almost never to help Mozilla or Google precisely locate phones or IP addresses; it's to connect wirelessly to the internet. More to the point, it's hard to find out someone's intention without asking them. Kudos to Mozilla for getting people to wardrive consensually; but that may still not make me feel much better if I'm just someone with wi-fi.
Just to clarify, the Mozilla Stumbler apps looks at SSIDs (to filter out "_nomap" and known mobile phone and transportation networks), but the SSIDs are not reported to the Mozilla Location Service. The BSSID/MAC addresses are, though.
Since you are underlining the provenance of Mozilla's budget, I guess that when Google stops financing Mozilla everything will change for you. Otherwise you are just lining up words to make a big impression but without any meaning or clue at all.
Don't you want everyone to observe your SSID? Hide it. You are cluttering the public's ether, so you are subject to public scrutiny. Don't you want to add "no_map" to the end of it? Shut up.
Or just do what Buckiminister Fuller told you to do: do not criticize a system but build a new and better one to obsolete the one that don't work. I promise to print your form if you start with a better approach. Unless you are not a complete idiot and understand that it is a theoretically possible way to deal with the problem but not a feasable one. Anyway, go on, just complain and talk nonsense: it will help. A lot.
i don't think i was the first or the only person to point out the similarity of this data collection program to google's street view program and related legal/policy/privacy issues that arose with it.
as engineers, we often end up offering people choices that aren't really choices. for my grandmother's ISP-provided wi-fi access point, adding no_map to her SSID isn't a choice she's prepared to make, and i don't think those are reasonable expectations for the average user.
when people suggest otherwise, i think that part of what they seem to be arguing is that the technical problem they're trying to solve--often for commercial gain--is more important than being respectful of other people. people shouldn't have to know how to hide their SSID or add "no_map" to their SSID to stay out of large databases by default.
my view is that the world is a better place when information sharing is consensual, even when it's otherwise legal to obtain that information. i think that's a better world than one in which we tell people to hide their SSIDs or add "no_map" to them. i'm interested in building software and systems that respect people and their devices.
I don't see your point. If you are ignorant enough to not know how to secure against such measly attempts at privacy breach, how will you secure against a more determined hacker?
Further more the SSID is publicly broadcast, so that any device you authorized can identify and connect.
i didn't say i didn't know how to secure against something like this or that it was not legal.
my point was that this approach to data collection, consent, and privacy sharply and directly contradicts claims mozilla makes to users about being committed to their privacy. i think this reflects the opposite.
maybe a better analogy would be someone from the ACLU photographing everyone they saw in public: legal and easy to defend against, but hypocritical/not cool in my opinion and it might make me question the organization's priorities.
I understand what you're saying, but you have to draw the line between privacy and common sense at some point.
It has been understood for awhile now that you have no expectation of privacy in public, at least as far as not being photographed, talked to, etc. Most people would probably agree that the paparazzi taking sneaky pictures of celebrities buying milk at Kroger aren't being very classy, but they'll also probably say it's fair game at that point.
Likewise, I would argue that broadcasting your SSID over the electromagnetic spectrum is public. As far as privacy is concerned (I have a slightly different opinion when it comes to security) I still haven't seen any compelling argument explaining how having your SSID mapped to a location is an any way a violation of privacy. Maybe you have one?
Sleazy paparazzi can exist in the world without breaking the law, but I expected more than that from Mozilla.
One hypothetical example: SSIDs often betray vendor names out of the box, and home routers are typically embedded devices that don't frequently receive security updates. Suppose Mozilla makes its database public and lists my SSID--or more likely, some weakly-secure hash of my SSID--in a public database that later gets compromised (e.g. plenty of people know their own SSIDs). Then, through no fault of Mozilla's, there's some 0day announced for my router. Now, every script kiddie in the neighborhood's using metasploit against a pre-selected list of vulnerable routers, potentially even remotely depending on their ability to integrate information from other sources. Maybe that sounds like more of a security issue than a privacy issue, but at some point, the effect is the same.
As you said, that's not a privacy issue but a security one. Also, in your example I'd argue it would just be easier to attack every single IP address and/or WAP rather than attempt to figure out which ones are Linksys and running a vulnerable firmware. It would take less time and also solves the case of non-default SSID names.
I'm still interested in seeing an example of how linking SSIDs to physical locations is a violation of privacy. Especially compared to, say, linking my full legal name to my house address which is already treated as public knowledge.
I don't think you'll like my answer, but I think it was Schneier who said that it's not necessarily any one thing: it's having easy access to a bunch of different things, together.
I believe that according to law, the onus is on the owner in question to make sure their WiFi Router is secure. If a hacker takes control of your router, and downloads pirated material, you are considered responsible if you didn't take even necessary steps to protect yourself. Then you sue manufacturer, and all routers come with a set of different passwords and _no_map by default. That is the most likely logical course of action.
Everything else is idealizing. Same as with video and with DRM. Mozilla could take a principled stance and say no to patented codes and no to DRM, and then Google says yes to both of those things, reap the benefits, while the end consumer abandon Mozilla because it doesn't play YouTube or Netflix, and then Mozilla is no more.
If you don't like it, you can fork Firefox and/or choose not to trust Mozilla. The situation is super sad, but what else can you do? Be principled and disappear? Or compromise and survive?
i never disputed the lawfulness of doing this--in fact i explicitly acknowledged it in my last comment.
i'm not making any legal claims to privacy--just pointing out that collecting everything that's lawful to collect runs counter to mozilla's policy stance of being committed to users' privacy.
> seeing mozilla move in this direction while talking about how much they respect everyone's privacy is a strategic stumble indeed.
Yup. I'm as heartbroken as I can be with a company.
A "hand-washing" attitude towards privacy from Google, Facebook or a telco is expectable. But from Mozilla? This saddens me, way more than the support of DRM in the web.
agree completely--it's one thing to do this sort of thing (it's probably legal, etc.), but to do it while claiming to be fighting for user privacy is really galling to me.
An option during router setup when SSID is named? An organized promotion of this approach, e.g. list of routers that make it simple, list of services that honor it. A cool name other than "Do Not Track".
That would require an action on the router-side, not on the mapping one. I think it could be a good option, but this doesn't apply for this case.
Also, what if I agree to put my SSID into an open database but not in a locked one? Apple's and Google's location databases do not compare, for me, to Mozilla's one: I am more than glad to be in the latter, but not to be in the two formers.
I used to use it a lot a few months back "mapping" my town and I had noticed that it would go at full strength even when I was staying in the same place for hours. Would it be possible to gradually slow down the collections when it detects that the user isn't moving?
geo-fencing was extremely rarely used. I think we had single digit numbers of people who enabled the feature and understood what it meant.
We decided to cut out geofencing because it was confusing to most people and reducing the number of knobs and dials on a program is usually a good thing.
Yes, anonymous is the default mode. :) The nickname is optional and only used to record a leaderboard "points". The nickname is not tied to any reported Wi-Fi or location data.
Mozilla Stumbler does not need to access your photos; it just needs to read/write to your sdcard (to cache map tile graphics and export KML data). "Access your photots" is Google's unfortunate explanation of accessing the sdcard.
Cool stuff, always interesting to see a new entrant to the location services field, especially an open one.
One question though. Will ordinary users be able to directly query the database via the API? i.e. if you want to geolocate a set of Access points and you have their MAC addresses will this service provide a direct supported API for retrieving their location?
The documentation on the API page implies that this isn't really a supported application?
Specifically
"If you are developing a native application or library for a desktop operating system or Android, you can in principle use this service via its HTTPS API. Please refer to the development documentation for the details. On most other operating systems, you cannot access the required cell and WiFi network information required to call the service API. "
and
"At this stage the service is open to anyone, who wants to contribute back to the service and applications supporting the Mozilla mission. "
btw, the Mozilla location database is currently used to power geolocation on the well-publicized Firefox OS "$25 smartphone"! That device does not have GPS hardware so all geolocation requires rely on Mozilla's location service and GeoIP.
This would be an interesting addition. I realized that Google is showing off Ingress as a game, but most technical users know it's about data-mining for maps and other location based products. Mozilla is openly showing this off as something that is about gathering data.
We have leaderboards showing the top stumblers overall and for the last seven days. We have lots of gamification ideas inspired by Ingress or the Nintendo DS game "Treasure World", but nothing in the works yet.
As an Android user, is it possible to modify my phone to use this service instead of Google's? Is it possible to upload the database directly to a phone or replace an APK to achieve this?
Hanno from Mozilla here. Marvin reached out to us about a month back and we have been slow to respond. He just got an email back a week ago. So I think this is still going to happen, but no concrete timeline yet.
Then try using a geolocation service like Google Maps or http://html5demos.com/geo . If it can't find your location, check Mozilla's zoomable coverage map to see if your neighborhood is covered: https://location.services.mozilla.com/map . If not, please consider installing Mozilla Stumbler to help map it. :)
I can't find the post, but I remember reading that they'd rather not expose full raw data because of privacy concerns — there could be a way to mine this data to de-anonymize users.
I'd love to play with the raw data too, but I understand their concern. So far many "anonymous" large data dumps ended up exposing too much (e.g. recently NY taxi data).
Oh I know this might be very sensitive privacy-wise. People should just be aware if they're contributing to a proprietary database (like Google Maps) or an open one (like OSM) when using Mozilla Stumbler.
A stumbler user's identity or location could be revealed by tracing routes from published GPS data or maps. In areas without much stumbler data coverage, you can see clear routes along highways and some residential streets.
Owners of Wi-Fi access points, including mobile phones with sharing Wi-Fi, may not want their unique BSSID/MAC address and location published. This is not exactly comparable to the Google Wi-Fi case in Germany. In addition to recording BSSID/MAC addresses, Google was (inadvertently?) logging Wi-Fi payload data that included cleartext user data.
btw, here's a zoomable map of the Mozilla Location Service's data coverage. Please help fill in the blanks! :)
About that map, a feature I would like is to fade spots which were scanned long time ago because WiFi access points might not last as long as cell towers. This way, as a contributor, I know in which areas to scan and, as a regular user, I know that the data for a specific area might be too old.
That's a good idea. The Stumbler app shows the coverage map (as blue clouds) on your mobile device, so you can see which individual streets are yet to be stumbled. Right now, our database is small and young enough that rescanning old data is not a high priority.
Well, Google's problem was that they chose an easily implemented solution - capture everything that looks even remotely like wifi and then physically ship the HDDs to Mt.View for analysis. It just so happens that the easy solution is sometimes blatantly illegal for incredibly obvious reasons.
Stumbler seems to anonymize the data on your device before sending it, which is the way it should be done. There is no reason to transmit any sort of wifi data except the AP's MAC address.
Thanks. As a follow-up, there are existing services that already have this database. So why build another one? Is it because the existing ones aren't open source?
There are a number of other location databases, such as OpenCellID and WiGLE. There are issues around incompatible data licenses for some location databases. Mozilla and OpenCellID have worked together to exchange data going forward. WiGLE's Wi-Fi and cell tower databases is only available for purchase with a commercial license, even though much of the data is collected by volunteer contributors.
The combined Mozilla + OpenCellID cell tower location database is public domain and published hourly here:
Will this work with WiFi-only tablets? I'd like to contribute but my Kobo Arc device is marked incompatible. I saw in the screenshot on Google Play that there is a WiFi-only report symbol.
I have a LTE Nexus 7, with no SIM, so it is basically a WiFi only, and yes, it works. I couldn't install it from F-Droid and I had to use an apk from github, but it worked like a charm and it auto-updates.
The server code is on GitHub, but I don't know offhand where the offline geolocation scripts are. The Stumbler app's map will show your phone's GPS position (blue dots) and Mozilla Location Service's estimate (red dots) so you can compare the difference.
We store signal strength for possible future use, but our current location algorithms don't use it. Wireless signal strength is notoriously flaky. From some reports I've read, signal strength is more highly correlated with the user's orientation (i.e. is their body blocking the signal to the source) than with distance to the source.
Wardriving is also the first thing I thought off (Wigle also being my app of choice). Massive co-ordinated wardriving. I can't help but feel that this is a bad idea.
I'm going to try getting an F-Droid build out today, but we've got some build issues with the fdroidserver. In any case - it will get to F-Droid real-soon-now.
I believe so. crankycoder1975 was asking for some pointers on #fdroid irc a few hours back to help build 1.0 for F-Droid. Hopefully any issues will get ironed out. While I appreciate my siblings comment about the app auto-updating - I'd rather have apps managed by a central area (F-Droid on Android, package managers on desktop Linux).
Apparently not from the current latest (0.30.0) version on f-droid. I just went through the MozStumbler menus and did not see anything about (auto-)updating.
I've been waiting for something like this. Most other location services I know about also crowd source data (after initially seeding it), but don't give the data back to the user.
Correct me if I'm wrong, bug I believe the issue with Googles wifi collection was because they had code which intentionally read (and stored?) all data being transmitted over open wifi networks.
No, Google was sued because in process of doing this, they "mistakenly vacuumed up e-mail messages, user passwords and other communication", that is, they recorded actual data packets instead of just the AP identifier.
As a programmer, I can completely believe I'd write a system for capturing and process beacons packets - to store the MAC and transmission power - that would also inadvertently capture and store data packets. In fact, using some off-the-shelve open source tools like Kismet, capturing data packets is the default - you need to manually disable it. That alone makes for an easy way to mess it up.
What I can't find is a "motive for the crime". What possible reason would they have to capture small samples of random data packets from random unencrypted APs?
per another comment below, i'm not arguing that they necessarily intended to collect additional information from the outset; just that they must have known that lots of other information would likely be swept up with beacon packets once they started collecting.
thinking about it counterfactually, they could have pretty easily discarded everything that obviously was not what they were claiming to capture at the point of collection (and interfaces to do so are built into the open-source tools you allude to), but it seems pretty clear that they proceeded for a pretty long time.
I think it is more likely than not that it was more or less unintended. Meaning that I think there is a good chance that none of the people building up and deploying the collection system had any interest in looking through packet fragments (which is where I would personally draw the mistake/intention line).
i'm mostly with you on this; i don't think anyone working on this project for google actively intended for lots of additional information to be exploited, even in relation to the project.
however i'm much less sympathetic to the notion that google didn't know that lots of additional information would be collected before they started collecting it.
so i think they may not have intended to use it before they started collecting, but i think they intended to collect all of what they collected.
care to elaborate? are you arguing that saving/processing the full contents of raw captures from monitor mode is somehow easier/cheaper to process than filtering out obviously extraneous information at the point of collection?
that's not at all obvious to me, and and one of the reasons i didn't find google's claims credible.
it seems much more reasonable that they would have realized upfront that limiting the volumes of captured data could have saved considerable time/money.... unless of course they had perceived additional value from capturing more information.
This data was recorded. It was not processed, it was not saved, and it was not filed under "lets-take-a-look-at-the-passwords-in-this-log.txt". The engineers thought "Hey, let's capture wifi data in aggregate and do cool geolocation stuff!" and ran with it without considering the fact that, in such data would probably be cleartext passwords.
As for time and money, those are two things Google has an indefinite supply of, so they aren't really relevant.
> ran with it without considering the fact that, in such data would probably be cleartext passwords.
This part, I just don't buy. Maybe full-take captures was the most expeditious at the time, but to me the notion that Google's engineers didn't know or didn't realize that they would end up doing a lot of "incidental collection" in the process is laughable.
And yet it's the one that Hanlon's razor explains very well. Goes to show that being terse in my original comment was the right move and you just can't wrap your head around the idea that, around the world, people do stuff without considering the consequences.
The people in charge of your country, of your internet, of your health and your whole life, they're all humans and don't have weird superpowers, omniscience or anything like that. They make mistakes, and a lot of them are going to do stupid stuff. Consequences may vary.
Not sure if you read the rest of my previous comment but Hanlon's razor is predicated on malice, so I still disagree.
I never assumed assumed malice here. But it's still preposterous that a company with such skilled engineers wouldn't know until they were sued that they had been collecting large volumes of additional information over the span of years.
That claim basically requires that this global mapping endeavour involving many people over multiple years was run by people who didn't understand the most basic aspects of wi-fi protocols but somehow flipped wireshark into monitor mode and then never looked at any raw captures anywhere to extract information from them, even while setting up collection systems used across the globe.
Doing that once could be a mistake; even collecting all of the data could be a mistake; but not even realizing they had collected vastly more than beacon packets--probably over most of the planet--for multiple years?
Hey...I guess anything is possible, but it doesn't pass the smell test for me.
I made a Firefox OS port: https://github.com/clochix/FxStumbler
But it was my first Firefox OS app, the code is awful and it would need a complete rewrite.
Nevertheless, if you have a FxOS device, don't hesitate to try this port and give me some feedback.
We cut a 1.0 release of the Mozilla Stumbler finally.
Have at it. File the bugs. Complain about battery life.
Help us make this thing not suck and build out a proper open location service.