It's got an upsell in it but it's not an advert.
344 karma · joined July 22, 2019
If you're feeling this way already, we'll likely never earn your trust, and that's fine. We appreciate you voicing your concerns, as you obviously care about privacy.
Have a great rest of day.
Also, we have over-provisioned cache & RDS with Vapor, whereas Heroku we were running on the edge.
Paul has publicly admitted that he was wrong on the podcast. It is funny in hindsight. He denied that we said we would OS it then I reminded him that he made the graphic announcing it!
Big mistakes made on the messaging of this and lessons have been learned.
We're looking to make the business sustainable so that we are in this for the long run. Without money, we couldn't spend the same amount of time on it that we are.
And we were definitely bad on the messaging and are going to be more careful in the future as it does cause upset.
We're still going to be updating the OS version of Fathom but I 100% support anybody creating another privacy-focused analytics platform. Additional alternatives to Google Analytics are great!
Good luck :)
I would suggest listening to https://fathom.transistor.fm/episodes/the-open-source-dilemm... too (published 10 days ago) as that'll give insight into our plans.
There will ALWAYS be an OS version. We don't know how the future will look but we know we have to keep a free privacy-focused analytics option available. It's the right thing to do.
Appreciate the comment. Good or bad, anything that makes us think about things is welcomed, so thank you!
1) The OSS version isn't going anywhere (listen to our podcast from 10 days ago, we talk about it: https://fathom.transistor.fm/episodes/the-open-source-dilemm...)
2) If you don't trust us, you shouldn't use our service.
3) Our fundamental guarantee regarding user data is that we don't sell it and we never will. We are already profitable and don't need to sell data.
And you're right. There are a segment of people who won't use analytics unless they're self-hosted. Totally understandable. We'll see what happens. It's not on the roadmap in the immediate future but we're not ruling it out.
1) They are different codebases. OS was written in Go by the previous developer. I rewrote everything in Laravel
2) We don't think we'll be porting it to OS but there's no decision on this yet
3) That's a great idea regarding a license, because a lot of people want to self-host... We'll have a think because we've purposely tied our app to certain infastructure, so we'd need to put in significant work to make it transportable. I'm not saying never, I just don't know.
We address some of the complications on the podcast.
These are solid questions, thank you.
Thanks for the love! The OS version has not been shitcanned. We spoke about our plans on our podcast 10 days ago: https://fathom.transistor.fm/episodes/the-open-source-dilemm...
Running 2 software products & working a full time job is hard but we'll get some updates to the OS version. We're likely going to hire a contractor to help us!
Under your logic, you would never trust us because we could just add $log->write(UserIp, UserAgent, Hostname, Path) in plain text. Trust is very important and what you do with the data is important under GDPR.
And we don't hold all the information to re-create the hash, that's the thing.
I thought a lot about "Oh but you could just do this, this and this" but, no, that argument doesn't hold. Our obligation under GDPR is what we actually do with data.
It's an interesting idea. We have multiple servers under the load balancers, so we'd be able to store them in Redis, but that is no better than permanent storage, since Redis could still be breached and you'd see it with ease.
And a hacker could indeed "win" if they broke into our system, got the salt and exported the DB. We didn't focus on this in our article, as it's unbelievably unrealistic, but it's still possible. Our next step is to address that.
Without the hash, it's practically impossible to brute force.
If they had the salt, IP and user agent, they’d have to also brute force every possible hostname and pathname, which would be insane. But I suppose they’d only have to do a few million based on the data we have on hostnames / pathnames...
Lots of ideas for improvement are popping into my head and I love how this community keeps challenging you to improve things. We had feedback on Reddit but it was much angrier!
The next step is to take your feedback and look into how we would defend against the scenario you’ve provided. Thank you!
And we can’t use cookies because of PECR!
> You don't need to "brute-force" the hash, you just need to find a user that matches your hash... which is 1 in 7 billion (or so), much more tractable. This is also the principle e.g. MD5 rainbow tables are based on...
Not quite. We use a SHA256 hash as our salt, and that changes each day, so you'd need to brute force that.
In terms of how many possible combinations there are for this salt, please see: https://stackoverflow.com/a/49520766 - you would need to brute force it and try each possible combination with every single possible IP / User Agent / Site combination to break a hash. This is why it's not theoretically impossible but it's practically impossible.
We would love to approach things in an easier way but PECR doesn't want cookies, even anonymous ones.
Now, one thing that we have uncovered thanks to someone on here is that we need to increase our resistance to data breaches. If someone had complete, unlimited access to all our data / servers, including the daily salt, then they could de-hash page views from the last 30 minutes. I have no idea how long that would take. There are 4,294,967,296 (?) possible IP addresss, and then over 3M (?) user agents, so it'd be an absurd, pointless exercise.... Anyway, we're going to be bringing in multiple salts that depend on the user IP address, meaning that, in the event of a data breach, a hacker won't know which salt has been used for a hash :) Perhaps we base the salts on the first 3 digits of an IP address? That would mean we'd have 720 possible SHA256 salts!
So one of the reasons we posted to HN was for conversations like this. Reading what you put makes me think we need to do more when creating the PageRequestSignature and the SiteRequestSignature, because if someone had access to our server, got the hash, stopped all cron jobs from processing data, then they could work it out after a huge amount of time / computing power. But to be honest, at this point, they could also add log($_SERVER) and get the entire request body of a user, so we would have much bigger problems in that scenario.
Anyway, you've given me a few new thoughts on hardening from data breaches. Because, yes, if they know the hash & have full access to our server then it becomes easier. So we almost need to move it to the point where they won't know the salt that was used for a particular user. So we'd not recycle a single salt, we'd recycle multiple salts that are based on, perhaps, the first 2-3 digits of a users IP address combined with the last 2-3 digits.... Then it would be much harder to break without first knowing the $_SERVER dump (the user's IP etc.). Obviously this wouldn't stop a "complete control of server" attack where they could just start logging everything but it would really ruin a brute forcers day because they wouldn't know what salt to start with.
What do you think of that idea? I'm running on little sleep so be nice ;) Also thanks so much for all your feedback so far, it's so appreciated!