What TfL Learned from Tracking Your Phone on the London Underground(gizmodo.co.uk)
gizmodo.co.uk
What TfL Learned from Tracking Your Phone on the London Underground
http://www.gizmodo.co.uk/2017/02/heres-what-tfl-learned-from-tracking-your-phone-on-the-tube/
6 comments
this is really cool! do you have a writeup?
sadly not... it was my first personal project ever and I didnt know that documenting projects was a thing :) I'll try to find the phone, get the logs and document it next time I visit my hometown.
Thanks for the interest!
The fact that WiFi advertises your MAC address whilst searching is quite annoying.
Have there been any developments in randomising MAC addresses or other solutions to this problem?
Edit:
I found this app called Pry-Fi: https://play.google.com/store/apps/details?id=eu.chainfire.p...
Have there been any developments in randomising MAC addresses or other solutions to this problem?
Edit:
I found this app called Pry-Fi: https://play.google.com/store/apps/details?id=eu.chainfire.p...
OSX, IOS and "NetworkManager"(linux) do that.
Thing is that it is usually useless. Only instance where you would even send a package (thus showing your MAC) when searching is if you were searching for a hidden AP. Funny that Microsoft is the only one that got that right, as they have a checkbox that says "hidden AP". All others just assume that the AP may be hidden and try to connect anyway. (worse is that they scan in the background while you are connected. NM does it at least)
Thing is that it is usually useless. Only instance where you would even send a package (thus showing your MAC) when searching is if you were searching for a hidden AP. Funny that Microsoft is the only one that got that right, as they have a checkbox that says "hidden AP". All others just assume that the AP may be hidden and try to connect anyway. (worse is that they scan in the background while you are connected. NM does it at least)
The developer of Pry-Fi started it as a proof of concept. He didn't have the time to continue developing it though, but said he might revisit it at some point.
Why don't they just use Oyster card for this?
I'm sure the data from that is much more fine grained.
Update: Ah got it. With Oyster they can only register the entry and exit points and not the route taken.
I'm sure the data from that is much more fine grained.
Update: Ah got it. With Oyster they can only register the entry and exit points and not the route taken.
When connecting between different tube lines, much of the time users remain inside the ticketed area of the station, so only tap their Oyster/contactless card when they pass through the entrance/exit barriers at the very start and end of the journey. (Though there are a few stations where there is not a direct tunnel between lines, and travellers are required to connect via a separate street-level entrance, where they would tap their card mid-journey.)
In cases where there are multiple routes to complete a trip (eg remaining on one line vs making multiple connections for a faster journey) it was therefore previously not possible to determine what percentage of people chose which route.
In cases where there are multiple routes to complete a trip (eg remaining on one line vs making multiple connections for a faster journey) it was therefore previously not possible to determine what percentage of people chose which route.
The Oyster card will not tell you what route a commuter took, only the start and end point.
From the article: "The good news for the paranoid is that TfL appears to have gone out of its way to make sure everything is above board. In the documents that Giz UK has seen, it makes clear that it is only MAC data that’s collected (ie: they’re not monitoring the websites you visit) - and that this data is stored as encrypted hashes - so even if hackers could somehow break in and obtain the collected data, they wouldn’t be able to get any MAC address data."
"Encrypted hashes" isn't totally specific given the vague language used when talking to general audiences, but assuming it means a cryptographic hash, then that doesn't really give much (any) privacy. There are only so many possible MAC addresses, and it's pretty easy to try them all in minutes. I was going to do the math, but Threatpost already has an article about this.[1] There's also a stub Wikipedia article.[2]
Unique salts don't work if you still want to be able to compare MAC addresses, which is sort of the point. You can have a single salt for all hashes, or alternatively encrypt with a single key, but then it's just a matter of that single salt or key being leaked.
+1 for randomized MAC addresses.
[1] https://threatpost.com/research-finds-mac-address-hashing-no...
[2] https://en.wikipedia.org/wiki/MAC_Address_Anonymization
"Encrypted hashes" isn't totally specific given the vague language used when talking to general audiences, but assuming it means a cryptographic hash, then that doesn't really give much (any) privacy. There are only so many possible MAC addresses, and it's pretty easy to try them all in minutes. I was going to do the math, but Threatpost already has an article about this.[1] There's also a stub Wikipedia article.[2]
Unique salts don't work if you still want to be able to compare MAC addresses, which is sort of the point. You can have a single salt for all hashes, or alternatively encrypt with a single key, but then it's just a matter of that single salt or key being leaked.
+1 for randomized MAC addresses.
[1] https://threatpost.com/research-finds-mac-address-hashing-no...
[2] https://en.wikipedia.org/wiki/MAC_Address_Anonymization
Really interesting, well written article which discusses the openness of this trial. I suppose I'd probably rather be an asset to TfL than Google (who's tracking I am fearful of).
It was cool to find out that I was crossing daily with the same people in different places and yet we never met.
It was a small project I made for fun, nothing serious :)