Comment by huehehue | Hacker News Reader

Comment by huehehue | Hacker News Reader

Bit of a tangent and, for those not familiar, Yik Yak is an anonymous, upvote-downvote, location-based forum (kinda) where posts are automatically deleted if they net -5 votes.

In college, I was really interested in how Yik Yak worked and found out that, given a list of N user ids (which were super easy to generate), one could send downvote requests to the server and instantly delete any post with a score <= (N - 5). Infinite loop + pass in a list of locations (e.g. a list of colleges in the US), and it's pretty darn easy to disable Yik Yak for the entire country.

There was no location checking to see if a user id was being used in both Florida and Montana at the same time, and there was no real throttling. I hit up their support, and tried to reach out to their devs, but I kept getting brushed off.

Of course this is just one small thing, but I'm not exactly surprised at how things are turning out if this was the level of interest that the Yik Yak team showed in their own product.

I think they started requiring a real phone number type identification to deal with the issue instead of any type of real IP/region/rate-limited/Captcha based spam detection.

I used it up until they asked for a real phone number. It was kinda cute, but yea, mostly filled with college students. Depending on where I travelled in the world, there may have been messages from three weeks ago on the top for that area. I was surprised how many remote areas had at least a few yackers; although very few non-English posts.

I think my favourite Yak: "If you ever feel down about Uni, just remember there's still someone from your home town trying to make it as a rapper."

A problem I've mused on for a few years is related to this: when a phone submits a lonlat to an API server, how can you make the server more confident it can trust the location? I mean with curl I could POST any lonlat I want---I don't even need a phone! I don't think this is truly solvable, but how can you make spoofing the location harder?

The scale I'm thinking about is "Are you really in the store you say you're in?" where all users are from the same fairly dense city. So geolocating the IP isn't good enough. Accuracy to a city block or two seems good enough though.

My best idea so far is to submit a list of available wifi access points, and use that as a "password" to prove that you're where you say you are. If your list is 80% like the list of other users at that location, we trust you.

Unfortunately in iOS you can't get that list! It requires a private API, so calling that method will get your app rejected from the store.

Does anyone have any other ideas?

I think the reason that API is private is because people do not want that level of tracking. And there are very few applications which absolutely, positively need this level of accuracy. And, I'm sorry, but marketing/advertising doesn't count.

In my case it is: the store gives you a secret code, and you enter it on your phone to earn discounts and raffle entries. We would like to prevent people taking the code home and sharing it with all their friends. So it's not about tracking. Still I get why the restriction needs to be there.

Make them have to submit it via a WIFI network in the store?

Or arrange some kind of (perhaps NFC based) token signing system.

QR codes. Show them on a screen to invalidate them every time they're used.

Why don't you make a unique code for each user?

If you have a mobile application, you can use that + beacon based location, so the code can be used only inside a store.

Send temperature and barometric pressure. Temp will vary (inside/outside) but pressure should be reasonably consistent.

How is that any more trustworthy? You can probably use the same source the server would use to verify that information.

Not to mention, most phones may not have those sensors.

Some very popular phones have a barometer[1]. If you are getting data from a bunch of phones, and most of them are legit, then you'll have a good idea of where the air pressure 'should' be, and if you get a barometer reading that is outside that data set by a standard deviation you can probably 'guess' that it is not coming from a phone at the same lat/lon as the other ones.

[1] https://www.phonegg.com/list/303-Cell-Phones-with-Barometer

So users on phones without barometers cannot use your app, and you are decidedly mobile-only, forever.

Not at all, the question was how to combat or at least estimate fraudulent 'adjustment' of the karma in a location based service. The way to do that is to take information that is specific to the location, and changes, and provide that data in the input stream to help understand where your clicks/votes are coming from. If one in 5 phones has a barometer with a high degree of probability, then you can use set bounds on the likelyhood that all 5 votes came from legitimate users. It won't be perfect but it will make it harder for scammers to scam without being there.

This is a really clever idea. Do you have sources of information about what sensors are present in which phones?

That only adds one extra step to spoofing - now I have to check weather.com for the barometer reading in the location I plan to poof before sending. NBD...

Also, pressure in vs outside can vary more than you'd think...

As with anything, it can be over come at a cost, and the only thing anyone can hope for is to keep the cost of defrauding a system higher than the expected return of successfully defrauding it.

Phone temperature is completely useless if the device is kept in a pocket next to human body temperature. Phones are also self-heating, especially when running Pokemon Go.

Barometers aren't very widely spread and I'd be wary of their calibration.

Even if you could fingerprint the location accurately, how do you know I'm there now, vs. capturing all of the information when I was there and replaying them later?

A much easier problem than "are you really where you say you are?" is "are you likely to be sending me fake locations?", which is hard to do with a single location update, but if the user is moving rapidly, or in geographically distant locations across multiple updates it's much easier to catch.

you could maybe just trust them but flag/disable accounts that jump between locations extremely quickly.

Might be tricky accounting for air travel but even then you could safely assume nobody's taking more than two flights a day and six a week or something like that

Yep, trusting every submission initially is fine, and we do use tricks like you suggest to flag suspicious accounts. For instance if you submit "11111" then "11112" then "11113" on up through "99999" (I've seen it happen!) then we might disqualify you from the raffle. :-) (We have better heuristics than that too.) But having the phone send some kind of extra proof would still be helpful. To point is just to make location spoofing "hard enough," not impossible. Also it is a small enough event that fraud isn't a true problem right now, so this is more just a fun mental exercise for me at this point. Still, good to be prepared!

Swarm/Foursquare I believe solve this problem by tracking the time between check-ins and then consider the distance between the places you've checked into and how long it would take to travel between them. You can't check into a store in New York Times Square one minute and then the next minute check into a place in Los Angeles. Sure you can lie, but with this restriction and restrictions around how frequently you can check in and other levers they have made a high quality experience that works for what they want to do.

IIRC credit card companies do a similar thing to reduce fraud

Can you ask them?

Make the user take a pic of the store, then check the EXIF for the timestamp. The pic should be very easy to shape-compare with other submissions of the same store (hardware doesn't move much, as opposed to faces), and the pic should never be exactly the same (refuse submitting twice the same pic).

Other solutions require the participation of the store: Dynamic QR codes, microphone authorization, or a website on the store's Wifi internal network.

There is no better case study for this than Pokemon Go, where the interest in spoofing location reached unheard of levels (outside of state actors). This is a good writeup:

http://engineering.shapesecurity.com/2016/08/pokemon-go-api....

Basically sign your API requests with the most obscure function of phone context variables imaginable, and recognize that if you get so popular that it's cracked, you can just hire a machine learning team anyways. And pin your certs!

Before Pokemon Go there was Ingress and hoo boy was/is this a problem.

This is something that I'm currently dealing with as well. However, I'm a little less concerned with trusting the location in particular and more in whether or not the client itself is trustworthy.

Do you have a user login system? Can you easily isolate fake data to a certain set of accounts? Or are you dealing with anonymous requests?

One possible solution you can look into is signature authentication of the headers to verify that the request is coming from a trusted source. You can either us a public/private key pair or a symmetric key with HMAC. That being said, this isn't foolproof - you have to keep the key secure, and that isn't totally possible in an app. If someone attaches a debugger they will be able to get your secret key if they're determined enough. The best you can do is obfuscate / encrypt the key so that it can't easily be read out from the strings in your app.

If you wanted to verify the location data itself, you could look into modeling the user's movements and look for abnormalities in the sequence of locations. Also, you can check the location against an API like Google or Foursquare on the back end.

Curious to hear what other people think as well.

https://www.locationsmart.com provides a service to locate devices at the cell tower level. You can use it to verify location updates from the device are in the ballpark of where they say they are. I haven't used it personally but a friend did.

Looks like they just do a HLR lookup to get cellphone location, which at worst gives you the cell tower location and sector the phone is connected to.

Ping the clients and average out data from clients near the lat/long sent with the request and compare to the client in question.

Apply a max threshold to check if a client is reasonably close to potential "co-located" clients.

You can't shrink physical distance. Pinging a server in a nearby US city is 13ms. Hong Kong is 232ms.

Honestly, I'm continually amazed by the level of absolute garbage people can ship with any level of popularity. And worse, get funding to ship it.

But it doesn't really matter does it? It's a social application, not a banking system. If your garbage gets users it's not garbage.

If a company gets users but fails to retain them, causing the product to fail and the investors to lose their funds, then it certainly isn't a success.

Sure, but it's a calculated risk -- maybe they decided that growth features were more important than uptime or data integrity. That still doesn't mean the app is garbage.

Yikyak didn't fail because of garbage code, it failed because of absolutely stupid decisions of direction. Adding usernames absolutely killed the app

No, that just means it's popular garbage.

And that's infinitely better than scalable, well-designed garbage nobody uses.

The quality of code and level of popularity are not directly correlated.

In fact, I've found often times they're inversely correlated. Maybe something to do with where time is spent?

It amused me last year when I realised that 95% of my phone use was the facebook app, tinder, and pokemon go. One a notorious battery drain, the next crashed regularly, and then the last was worst at both. I definitely think there are a lot of programmers who place a too much weight on the effect of quality when it comes to consumer apps.

Reply on news.ycombinator.com