Slashdot Mirror


Will London Monetize Wifi Tracking Data From Its Tube Passengers? (gizmodo.co.uk)

New questions are arising about how much privacy you'll have on London's underground trains. "For a month at the end of last year, Wi-fi signals were used to track passenger journeys across the network," writes Gizmodo. "The idea is that as we travel across the Tube network, Wi-fi beacons in stations would detect the unique ID -- the MAC address -- of our phones, tablets and other devices -- even if we're not connected to the Tube's wifi network." The only way to opt-out is to turn off your phone's Wi-Fi. An anonymous reader writes: London is struggling with the transport network capacity so the ability to learn commuters' travel patterns is compelling... Now it emerged that TfL, the operator of London Subway system, is planning to use the system to monetize passengers' data. TfL is also not ruling out sharing the data with third-parties in future.

More information shows that the privacy protection could not be as good as TfL maintains, with reversible hashing and options of giving data to law enforcement. A privacy engineering expert points out additional issues in pseudonymisation scheme and communication inconsistencies. Final deployment has been initially scheduled to start in end of 2017.

"Once the tools are in place, there will inevitably be a temptation to make use of them," warns Engadget, raising the possibility of the data's use for advertising -- or even the availability to law enforcement of location data for every passenger.

4 of 90 comments (clear)

  1. Overcomplicating matters by andrewbaldwin · · Score: 5, Insightful

    I can sympathise with TfL's stated aims - knowing how many people go from place A to place B via route C at certain times of day is useful and can be socially beneficial if it helps train scheduling.

    But this can be done in a simpler way (albeit not in real time - but is that really necessary?).

    Many years ago I recall using the metro and local trains in Copenhagen when they were doing a survey. When you entered the station they gave you a paper slip with the station name and timeslot written on it; when you reached your end destination there was a bin to drop the paper slip into. That's it from the passenger viewpoint - minimal inconvenience and no linking to you as a person (and you could even opt out by keeping the paper slip if you were so minded).

    I'm guessing that at the end of the day they collected the slips at each station and could work out just how many people went on each journey within hour long blocks.

      I do recall thinking that a bar code or QR block would simplify the counting process.

    But that's not cool enough - it's too simple for today's management to consider (and it cannot be subverted or surveilled).

    Slightly off topic - doesn't everyone turn off the phone wifi & bluetooth when not in use? -- doing so seems [in my experience -YMMV] to extend the time between charges by quite a useful margin.

    1. Re:Overcomplicating matters by oobayly · · Score: 5, Insightful

      The reason they did this was to track people's routes through the system - Oyster will only give the end points, not where they changed stations. The Gizmodo article explains that, if you bothered to read it...

      The Register did an article on this a few weeks ago and mentions that TFL did a good job anonymising the data:

      Fortunately, TfL did it right: they used ICO guidelines to protect users' privacy by grabbing and tracking MAC addresses and then depersonalized them using a salt which then discarded at the end of each day. That in effect makes it impossible to know what the original MAC address was.

    2. Re:Overcomplicating matters by AmiMoJo · · Score: 4, Interesting

      Maybe not... https://blog.lukaszolejnik.com...

      Aside from TfL's apparent confusion of various technical terms, it looks likely that the salts could be recovered. MAC addresses are not random, they are assigned in blocks to manufacturers. Some devices do randomize them, but some don't and it appears that they use only one salt per day for every MAC address they hash.

      You can assume that there will be a large number of devices running wifi chipset X and not randomizing. That gives you a way to check a salt for validity, i.e. if when combined with known MAC addresses from the ranges allocated to that manufacturer it produces a hash in the TfL dataset. And you can further narrow this down by taking your own device with a known MAC address onto the tube during the test.

      It's probably fine... But their lack of technical clarity and secrecy about the scheme they used (for all we know the salts could have just been the date or something silly) isn't very encouraging. As a branch of government they should set the gold standard for this stuff.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  2. Re:Randomize Wifi MAC ? by AmiMoJo · · Score: 4, Interesting

    Why would the chipset handle wifi packets when the wifi receiver is turned off? And even if it did, with the transmitter turned off how would the tracker ever know that it did? There is no energy going to the transmitter, no energy radiated.

    Perhaps you are referring to some Apple devices where the off switch doesn't actually turn the wifi off, but most devices don't have that fault.

    There used to be an issue where devices would broadcast the SSIDs of networks they knew about. That was to handle networks that didn't broadcast an SSID themselves, but it's mostly been deprecated and was one of the reasons that MAC address randomization was introduced.

    --
    const int one = 65536; (Silvermoon, Texture.cs)
    SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC