Hacker News new | ask | show | jobs
by markosaric 1926 days ago
BrendanEich has some ideas on the "trust but verify" aspects of this. Plausible is 100% open source with no proprietary parts but we'd love to work with Brave (and Firefox/EasyList/uBlock Origin) to provide proof to get verified and unblocked by them. It would be a very effective way to get many more sites/businesses to remove GA
2 comments
llarsson 1926 days ago
The thing is, say that you would be exempt by the blockers.

The way they work is not by downloading and checksumming scripts to see if they are allowed it not. They just downright refuse to download what is blocked.

So someone could use your special whitelist status to get their creepy tracking into visitor web browsers.

That does not make sense to allow for blockers.

Hence, you will continue to be blocked.

Great effort, though. I wish this were the future of analytics.

link
arp242 1926 days ago
But being "open source" doesn't really guarantee anything. How do I know that anything I send to mysite.plausible.io gets processed the way you say it does? How do I know that the code running on Plausible.io is the same code that's on your GitHub? Hell, even if I can verify your code then how do I know your proxy doesn't syphon it off to a second "secret" service?

Don't get me wrong, I have no reason to doubt your claims and do trust you specifically, but basing the entire system on "I decide to trust Marko from Plausible" doesn't really scale.

I am in the same boat as you as I run GoatCounter; I know I do everything like I say I do, but I also know that there's nothing preventing me from doing any of the above and actually collecting much more from what I say I do. It's not hard to set up and no one will ever find out. Theoretically there are legal limits on this. In practice this is a very weak guarantee. This is a big reason why self-hosting was always a first-class supported use case for this.

Theoretically there are some technical things you can do to improve matters; for example a per-domain device ID generated by the browser (or JS, doesn't really matter actually). But then you run in to legal limits due to the way the GDPR is phrased, even though it's more privacy-friendly and not really in the spirit of what the GDPR is about :-/ We talked a bit about this over email last year IIRC.

The real crux is finding something that's practical, usable, and will actually be implemented/used. We can all think of some idealized system, but if it's not realistic that it'll be implemented then it's a pretty academic exercise. In practice this means that any browser solution will need buy-in from at least the Chrome and Safari teams to really be useful, and I don't rate the chances of that as very high of happening any time soon.

This isn't even because I subscribe to some "Big Evil Google and Their Nefarious Dark Plans" view, but just because they have little incentive to do any of this and it's quite a lot of work to do it well. It's easier to just block the lot and, arguably, this is perhaps better than doing nothing. If GoatCounter is impacted by this then so be it. At the end of the day site owners are not the customers of Safari and Chrome: people using those browsers are.

link