After roughly a month of using Yik Yak, I finally decided to dig deep and see what information it saves and shares with other users on the service. I was quite surprised right off the bat, as there were a number of sketchy details the privacy conscious may want (or not want!) to know about. Let’s dive in!

Yik Yak API Response Breakdown

Let’s take a quick look at the way Yaks are returned from the Yik Yak API. Since this post is about promoting anonymity, I won’t be using existing Yaks by real people, rather I’ll create a fake Yak data and inject it into the app using a handy tool called mitmproxy (man-in-the-middle proxy — basically, it allows me to view and edit responses sent from a device to any other routable server on the Internet). If you’d like to see the source code for the in-line script used for this post, take a look at this gist.

Here’s the JSON object we’re going to inject into each response body every time the app makes a request to the API route /api/getMessages. The data corresponds to a fake Yak with a faked location of a Chipotle location in Beaverton, Oregon.

{

"comments": 0,

"deliveryID": 102,

"handle": null,

"hidePin": "1",

"latitude": 45.4953056,

"liked": 1,

"longitude": -122.8090428,

"message": "This Chipotle is delicious!",

"messageID": "R/5476c66b5542a75500257f30813b4",

"numberOfLikes": 1337,

"posterID": "9cb4afde731e",

"reyaked": 0,

"score": "2.1417070187",

"time": "2014-11-27 05:34:27",

"type": "0"

}

Some readers out there may have had a reaction similar to the one in this gif when they noticed the numeric and boolean values stored as strings. If you’re not that technical, just know that that’s widely accepted as not a great practice to follow.

Not surprisingly setting non-numeric values in some of those strings can brick the app — I’ll get to that later in the post. For now, let’s break down the JSON object key-by-key. Any key omissions are done so for the sake of brevity.