Live data from Hacker News

The Problem With Client-Side Analytics

spider.io

11–20 of 29 posts

Re: The Problem With Client-Side Analytics

#11
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.

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 could be an easy way to do it if you put, like, two good hours of work into it.

Re: The Problem With Client-Side Analytics

#12
post #10
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.

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.

Re: The Problem With Client-Side Analytics

#13

1. Considering most client-side analytics are based on IP address, you will require a large number of IPs. 2. It should not be terribly hard to filter out known open proxies or sessions with a specific nefarious pattern. Overall, I think this post addresses a problem that doesn't quite exist yet; and if/when it does, it can be addresses in many ways.

You wouldn't spoof it with an open proxy. This wouldn't be organized crime trying to screw up your A/B testing. This would be individual consumer advocates and reactionaries with a GreaseMonkey script that intentionally sent back wrong numbers or dupes.

And they'd be doing it because of a principle like "these companies don't tell us that they gather and make money off this consumer data. If they won't admit it up front, let's just not give the data to them."

Go ahead, tell me that won't happen at least a few times in the next 5-10 years.

Re: The Problem With Client-Side Analytics

#14
post #9
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.

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.

Re: The Problem With Client-Side Analytics

#15
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.

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 be a real problem.

Re: The Problem With Client-Side Analytics

#16
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.

While I haven't seen any real, meaningful efforts at spoofing analytics data (I vaguely recall some grad student project), I've certainly heard of companies spoofing their own analytics data to appear bigger than they are to interested parties.

More than one unscrupulous publisher has gamed comScore and Neilsen to pump up their reach figures and get access to more attractive advertisers.

Of course, scammers aren't going to use this service. There's a market selling verification services to advertisers, but there's a ton of companies in this area already - from my limited vantage point, Double Verify looks like the market leader.

Re: The Problem With Client-Side Analytics

#17
First, that's not a "digital signature", it's a MAC. It's the secret-suffix SHA1 MAC, to be precise.

Second, the secret-suffix SHA1 MAC isn't secure. Its insecurity is the reason we have HMAC.

This seems to me to be the kind of thing you'd want to get right if the whole value proposition of your solution was "verifying URLs with cryptography".

Re: The Problem With Client-Side Analytics

#19
This is a solution looking for a problem.

I know my Google Analytics aren't 100% correct, but I don't think people are spoofing them. The differences lie more in people who click through faster than GA can load (which can be easily possible on those still on 56k), or have "privacy blockers" in their ad block to remove GA altogether.

Post reply on HN