1. 94

  2. 41

    The title sells it short. This is an extremely informative and entertaining post.

    1. 13

      On the other hand: the title is perfect. No click-baity bs. Straight to the topic. It made me think that the author is serious about the post’s content and thus made me read it. It’s a paradigm of how titles should be.

      The title does not sell it short. The article is of equally high quality as the title :-)

      1. 1

        It’s like reading the script of a talk by Ellen Körbes and Tabitha Sable.

      2. 27

        I used to work at Facebook, and for a while, on the nearby friends product, which let you see where your friends were, with a similar type reporting of “2 mi/km away.” We were aware of both of the main problems pointed out in this post from the beginning and took similar steps to prevent practical trilateration. Later on, I worked on getting location data encrypted at rest and locked down — not even the main backend system (which was what ordinary engineers in the company worked on) could see real location data, only ask a highly-protected service for the sanitized distance and place name information. I was 1 of roughly a dozen people in the company who had access to that system. Not to defend FB in other areas, but we took the security of that data seriously and it’s amazing how sloppy other companies are with it. Our threat model was a lot darker than just stalking people too — think state-level coercion and infiltration of employees.

        1. 9

          Is this reverse-engineering?

          Yes, and I’ve suggested the corresponding tag. The reverse-engineering is well-explained and fits the emotional context of the narrative.

          Statistical attacks work even on rounded data. I am once again linking to “Sheaves are the canonical data structure for sensor integration”, which contains techniques for automatically improving sensor readings so that even rounded noisy location data can be used. I don’t think any of the strategies listed in the article will stop sensor fusion, since the only way to trick it is to send completely fake data, ruining the feature for users.

          1. 4

            Wow! What an article. I’ve done category theory and I’ve done sensor fusion, but never in my life did I think one could be applied to the other.

          2. 6

            It’s surprisingly common.

            I reverse engineered the Lex app last year, and found a vulnerability where people’s postcodes and addresses were revealed in full via the API. It was fixed shortly after I sent an email to them. Even scarier in that case since it’s an app for people who are minorities and therefore at a higher risk of stalking and all the other weird shitty stuff people do to others :S

            1. 5

              Incredible article, and the “minor inconvenience” part hit very close to home - it feels stupid to write those, if necessary.

              1. 3

                I love how this was written to be both entertaining and understandable for people who aren’t necessarily all that technical (I wouldn’t exactly say “a non-technical audience”, but it gets pretty close). Best written tech article I’ve read this year, I think!

                  1. 3

                    The blog post actually mentions this:

                    As one of the trailblazers of location-based online dating, Tinder was inevitably also one of the trailblazers of location-based security vulnerabilities. Over the years they’ve accidentally allowed an attacker to find the exact location of their users in several different ways.