Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Problem With Client-Side Analytics

spider.io

Post reply on HN
Print view View original

21–29 of 29 posts

Re: The Problem With Client-Side Analytics

#21

Post by angelbob »

gyardley wrote: post #15
angelbob wrote: post #11

Earlier quoted context omitted.

You don't think that, say, the same people who resent ads being shown and turn them off might think it was hilarious to send back bad analytics data to companies who are quietly profiting from same? The same people, who, say, use a housemate's phone number for their Safeway card so that Safeway can't determine their shopping habits? If there was an easy way to do it, many people would want to. It's clear that there c…

I co-founded and ran Pinch Media, a mobile application analytics company. We operated independently for around two years before selling. During those two years, I believe we got more bad PR than a typical analytics company. I certainly got my fair share of anonymous hate email. During that time, we received exactly two easily-filterable attempts to spoof analytics traffic. Historically, anyway, this doesn't seem to b…

Fair enough. You're much more confident than I would be about knowing.

I work in the Analytics group at Ooyala, a video platform company -- among other things we handle all the analytics traffic for all videos on ESPN.com and its various subsidiaries. We get huge amounts of traffic, weird data mangling constantly, and a wide variety of bad responses -- and that's only the stuff that gets past and mostly checksums.

It would take a pretty significant spoofing attempt for us to even know.

Re: The Problem With Client-Side Analytics

#22

Post by gyardley »

angelbob wrote: post #21
gyardley wrote: post #15

Earlier quoted context omitted.

I co-founded and ran Pinch Media, a mobile application analytics company. We operated independently for around two years before selling. During those two years, I believe we got more bad PR than a typical analytics company. I certainly got my fair share of anonymous hate email. During that time, we received exactly two easily-filterable attempts to spoof analytics traffic. Historically, anyway, this doesn't seem to b…

Fair enough. You're much more confident than I would be about knowing. I work in the Analytics group at Ooyala, a video platform company -- among other things we handle all the analytics traffic for all videos on ESPN.com and its various subsidiaries. We get huge amounts of traffic, weird data mangling constantly, and a wide variety of bad responses -- and that's only the stuff that gets past and mostly checksums. It…

Nice - nothing but respect for Ooyala.

You're right - it's possible we got thousands of attempts to spoof traffic that we automatically dumped for being malformed. Like you, we also got a ton of weird data mangling and bad responses which we just ignored. Most were bad implementations or issues with the phones themselves, but some could've been spoofing attempts.

It's also possible that smaller attempts to spoof traffic went by absolutely undetected by both us and our clients. Like you, it'd take a pretty significant spoofing attempt for us to notice. That said, what's the point of an insignificant spoofing attempt?

Re: The Problem With Client-Side Analytics

#23

Post by huhtenberg »

ceejayoz wrote: post #12
eps wrote: post #10

Earlier quoted context omitted.

What evidence is there that there are groups of nefarious hackers intercepting my shopping session at ToysRUs online store? Why the hell should I be spending my hard earned milliamps on this SSL thing? Certainly if someone wanted to mess with me, they would just whack me on the head in the dark corner of the street.

Intercepting a shopping session gets you a credit card number. Spoofing analytics adds a pageview to a stat you don't even get to see.

You are missing the point. The probability of an exploit being ultra-low or hard to mount is not a valid justification for ignoring it altogether.

Re: The Problem With Client-Side Analytics

#24

Post by angelbob »

gyardley wrote: post #22
angelbob wrote: post #21

Earlier quoted context omitted.

Fair enough. You're much more confident than I would be about knowing. I work in the Analytics group at Ooyala, a video platform company -- among other things we handle all the analytics traffic for all videos on ESPN.com and its various subsidiaries. We get huge amounts of traffic, weird data mangling constantly, and a wide variety of bad responses -- and that's only the stuff that gets past and mostly checksums. It…

Nice - nothing but respect for Ooyala. You're right - it's possible we got thousands of attempts to spoof traffic that we automatically dumped for being malformed. Like you, we also got a ton of weird data mangling and bad responses which we just ignored. Most were bad implementations or issues with the phones themselves, but some could've been spoofing attempts. It's also possible that smaller attempts to spoof traf…

The point of an insignificant spoofing attempt, if it isn't just ideological (and ignorable), would be to try to convince more people to do it (i.e. install the GreaseMonkey script).

Put it this way - say Richard Stallman suddenly decided that companies collecting analytics data and profiting by it (Ooyala doesn't sell it exactly, but we profit by it) was a bad thing and people needed to install a GreaseMonkey script, analogous to an ad blocker, that sent back bad data (wrong URLs, repeats, garbage, etc). That would be an individually-insignificant spoof which was potentially nasty in aggregate.

If designed well, it would also look an awful lot like a high level of background noise, but otherwise condition normal.

Re: The Problem With Client-Side Analytics

#25

Post by storborg »

lmkg wrote: post #5

...wut? That's ridiculous. What evidence is there that there are groups of nefarious hackers out there spoofing analytics data on people's websites? I don't think there is a need for this solution because the problem doesn't exist. If I wanted to mess with someone's websites, there are much better ways than injecting some false data into their Google Analytics.

I've often seen a different, but related effect of client side analytics where content thieves will "accidentally" spoof analytics data by simply copying a site verbatim, with the analytics tag included.

In this case it's usually relatively easy to filter out, because the analytics host will identify the fake requests as coming from pages served on a different domain. However, it is annoying, and a combination of content theft plus hijacked DNS could result in more sinister influences.

Re: The Problem With Client-Side Analytics

#26

Post by bluesmoon »

We noticed this problem at Yahoo! (I worked on the web performance analytics). Approximately 2% (note, that's 2% of 200 million daily) of our beacons were "fake". Now there are two reasons for fake beacons.

1. (Most common) many small sites seem to really like the design of various Yahoo! pages, so they copy the code verbatim, and change the content, but they leave the beaconing code in there, so you end up with fake beacons.

2. (Less common) individuals trying to break the system. We would see various patterns including XSS attempts in the beacon variables, and also in the user agent string. We'd see absurd values (eg: load time of 1 week, or 20ms or -3s, or bandwidth of 4Tbps).

It's completely possible to stop all fake requests, provided you have control over the web servers that serve pages as well as the servers that receive beacons. It's costly though. Requiring you to not just sign part of the request, but also add a nonce to ensure that the request came from a server you control (avoid replays). Also throw in rate limiting for added effect (hey, if you're random sampling, then randomly dropping beacons works in your favour ;)).

It doesn't stop there though, post processing and statistical analysis of the data can take you further.

It gets harder when you're a service provider providing an analytics service to customers where you do not have access or control over their web servers.

At my new startup (lognormal.com) we try to mitigate the effect of fake beacons the best that we can.

Re: The Problem With Client-Side Analytics

#27

Post by lamnk »

mpclark wrote: post #14
lamnk wrote: post #9

Earlier quoted context omitted.

It's a problem of information asymmetry in the online (display) advertising industry, not a problem with hackers. Because advertisers don't know how many pageviews/visitors a website has, advertising agencies often have to make purchasing decisions based on numbers from Comscore, Quantcast, Google Analytics etc. Clearly, if the website owner can spoof his analytic data, he can sell his inventory at higher rates.

...but not for long, because his CTR will be down on the floor. This feels to me like a clever solution for a problem that doesn't exist.

Sure, that's why I wrote "online (display) advertising", which often has its cost measured in CPM, not in CPC, so CTR doesn't matter. This shows advantages of CPC ads over traditional display advertising and partially explains the success of Google.

I do not have technical ability to judge whether his solution can really solve this problem, however the problem does exist, though not widespread, and who can solve it will have a great chance to earn a lot of money. AFAIK advertising agencies pretty much trust the data from the like of Comsore. It's not that they don't know the data is not really accurate, it's that they don't have anything else. How much does Comscore sell its packages? I don't know, but I'm sure it's not cheap and online advertisers/marketers still have to buy them.

Re: The Problem With Client-Side Analytics

#28

Post by ceejayoz »

huhtenberg wrote: post #23
ceejayoz wrote: post #12

Earlier quoted context omitted.

Intercepting a shopping session gets you a credit card number. Spoofing analytics adds a pageview to a stat you don't even get to see.

You are missing the point. The probability of an exploit being ultra-low or hard to mount is not a valid justification for ignoring it altogether.

No, but it being a rather useless exploit is.

Re: The Problem With Client-Side Analytics

#29

Post by skeltoac »

In before solution waiting for a... oh, too late. It is a problem. However, signing resources means no HTTP caching of the most expensive resource we generate. That is not practical where I work. Guess the cache can be programmed to do the signing.

There are trade-offs just like every other CAPTCHA-class problem out there. Isn't that what you are after: an automated human detector?

Post reply on HN