Skip to content

Data received by our airdrop monitoring server

silto edited this page Apr 27, 2018 · 1 revision

Rationale

During the airdrop phase of the Varanida project, tokens are rewarded to the extension's users for blocking ads. This is a way for us to make people realize how much their attention is worth and how many ads they see everyday. This also seems like a better and fairer airdrop mechanism than giving away tokens on a specialized forum.

To do this without having people cheat the system and emptying the reward pool (worth approx. 2 million USD in tokens at the ICO price) to put it in their pocket, we have to send a small amount of data to our server. We tried to make it as minimal as possible because we value user privacy. We also don't want to keep this data after the airdrop phase, we don't want to monetize it in any way, nor use it for targeting. Also even though we put everything in place so that this data stays safe, we don't want to make it a honeypot that might interest malevolent actors who would like to put their hands on personal data.

Details of the data that is sent to our servers

only data about the blocked request is sent. we don't send anything about any data that went through the ad blocker. In other words data that was sent is literally content that you did not see.

  • createdOn this is a timestamp of the request that was blocked. To reduce the charge on your browser we don't send data after each request, we send it in batches. This is why we need a timestamp to prevent fraud (a user seeing a thousand times the same ad in a 10 second interval is pretty suspect).

  • publicAddress this is the address of the Ethereum account linked to your extension. Your private address or account seed is never sent. Since you need an account to receive the reward, why we need this is pretty straightforward. We also don't send data until you have created/imported an Ethereum account, even though the ad blocking features are fully functional.

  • partitionKey this is an Amazon/Kinesis key, not related to your extension or your browsing activity in any way, just protocol stuff.

  • filter this is the regular expression (a string of characters) that matched the url that was blocked. you can see examples in filter lists like EasyList. Since we didn't want to send the full url because of privacy concerns, we assumed that transmitting only the matching filter would not be too revealing and still allow us to do some good duplicate/frequency analysis/fraud handling.

  • pageHash this is a cryptographic (not reversible) hash (Blake2S) of the domain where the request was blocked. We didn't want to send any url related to the browsing activity, but needed a fingerprint for fraud detection. As an example if you're not familiar with hashes, if the context of the ad that was blocked was https://www.thiswebsite.com, the hash our server would receive would be 665ec109343ece0907c46da6dd9d8eb3280babdc61b54ada4beb363dc47a7281.

  • requestHash this is a cryptographic (not reversible) hash (Blake2S) of the url of the request that was blocked. Same as pageHash above, this is used as a fingerprint for fraud detection.

Verify yourself

if you can read code, you might want to check if what we say is true by auditing the code yourself. The function responsible from fetching the batch of request from the internal queue, formatting the information and sending it is µWallet.recorderUpdatesHandler. You can also monitor the extension's request using your browser's debugging tools or a network sniffer like Wireshark.