Readit Newsericselin commented on Google Safe Browsing incident statichost.eu/blog/google... · Posted by u/ericselin
What sort of size would be needed to get on there?
My open source project has some daily users, but not thousands. Plenty to attract malicious content, I think a lot of people are sending it to themselves though (like onto a malware analysis VM that is firewalled off and so they look for a public website to do the transfer), but even then the content will be on the site for a few hours. After >10 years of hosting this, someone seems to have fed a page into a virus scanner and now I'm getting blocks left and right with no end in sight. I'd be happy to give every user a unique subdomain instead of short links on the main domain, and then put the root on the PSL, if that's what solves this
Based on what I've seen, there's no way to get that project into the PSL. I would recommend you to have the content available at projectcontent.com if the main site is project.com, though. :)
ericselin commented on Google Safe Browsing incident statichost.eu/blog/google... · Posted by u/ericselin
This is the kind of thing that customers rely on you to do _before_ it causes an incident.
The thing is, for users, having a separate domain wouldn't have made any difference without the PSL. And you cannot get on there before you're big enough - which I'd say is roughly at the same time as you start grabbing the attention of scammers.
ericselin commented on Google Safe Browsing incident statichost.eu/blog/google... · Posted by u/ericselin
It's hard to get that point because you're conflating two different stories.
Folks around here are generally uneasy about tracking in general too, but remove big brother monitoring from Safe Browsing and this story could still be the same: whole domain blacklisted by Google, only due to manual reporting instead.
"Oh, but a human reviewer would've known `*.statichost.eu` isn't managed by us"—not in a lot of cases, not really.
Sure, and sorry for being so unclear. The point of my post was meant to be a) Google has this enormous cannon, is this "right"? And b) they will use it to kill anything bigger than a mosquito.
But you're right, complaining about big tech surveillance didn't help with making that point at all.
ericselin commented on Google Safe Browsing incident statichost.eu/blog/google... · Posted by u/ericselin
I am not implying you’re putting “everyone” in danger. I’m merely implying that you’re putting your own service in danger by allowing clients to act like a trusted subdomain like controlpanel.statichost.eu, .secure, or Unicode similarities of www.
Ok, I see. You mean the possibility of users impersonating statichost.eu itself. That is actually a good point, and the exact reason why user subdomains are required to have a dash in them. Edit: Also, only ASCII is allowed. :)
I guess control-panel.statichost.eu is still possible, of course, but that already seems like a pretty long shot.
ericselin commented on Google Safe Browsing incident statichost.eu/blog/google... · Posted by u/ericselin
It's fine if you personally didn't know that. But if I'm paying for a service, I expect the provider to understand basic security best practices that have been industry standard for 20+ years. And if they don't, they should be hiring people who do.
XKCD 1053 is not a valid excuse for what amounts to negligence in a production service.
Author here. What kind of security negligence are you referring to? What would be a specific attack vector that I left open?
Regarding the PSL - and I can't believe I'm writing this again: you cannot get on there before your service is big enough and "the request authentically merits such widespread inclusion"[1]. So it's kind of a chicken and egg situation.
Regarding the best practice of hosting user content on a separate domain: this has basically two implications: 1. Cookie scope of my own assets (e.g. dashboard), which one should limit in any case and which I'm of course doing. So this is not an issue. 2. Blacklisting, which is what all of this has been about. I did pay the price here. This has nothing to do with security, though.
I'm sorry to be so frank, but you don't know anything about me or my security practices and your claim of negligence is extremely unfounded.
[1] https://github.com/publicsuffix/list/wiki/Guidelines#validat...
ericselin commented on Google Safe Browsing incident statichost.eu/blog/google... · Posted by u/ericselin
> In order to limit the impact of similar issues in the future, all sites on statichost.eu are now created with a statichost.page domain instead.
This read like a dark twist in a horror novel - the .page tld is controlled by Google!
Thank you for this hacker-minded and sharp comment! <3 Seriously, not all comments on here are as fun to read for me as the author and fellow hacker.
And for what it's worth, it feels great to actually pay for something Google provides!
ericselin commented on Google Safe Browsing incident statichost.eu/blog/google... · Posted by u/ericselin
So… you were hosting user generated content on the same TLD as your website, without using the PSL, and you blamed G when things went south?
By putting UGC on the same TLD you also put your own security at risk, so they basically did you a favor…
Many commenters are implying that there is a security issue here, and that I'm putting everyone in danger. That is quite frankly a pretty absurd claim to just casually make. I'm of course very curious to hear more details on what the security risk here actually would be?
Do you think I'm reading/writing sensitive data to/from subdomain-wide cookies?
Also, yes, the PSL is a great tool to mitigate (in practice eliminate) the problem of cross-domain cookies between mutually untrusting parties. But getting on that list is non-trivial and they (voluntary maintainers) even explicitly state that you can forget getting on there before your service is big enough.
ericselin commented on Google Safe Browsing incident statichost.eu/blog/google... · Posted by u/ericselin
Not sure who changed the HN headline, but I appreciate the change. Especially since the concept in the headline is buried at the bottom of the post.
Post author is throwing a lot of sand at Google for a process that has (a) been around for, what, over a decade now and (b) works. The fact of the matter is this hosting provider was too open, several users of the provider used it to put up content intended to attack users, and as far as Google (or anyone else on the web is concerned) the TLD is where the buck stops for that kind of behavior. This is one of the reasons why you host user-generated content off your TLD, and several providers have gotten the memo; it is unfortunate statichost.eu had not yet.
I'm sorry this domain admin had to learn an industry lesson the hard way, but at least they won't forget it.
Author here. I understand that my post and what I'm trying to say is unclear. And that there are too many different aspects to all this.
What I'm trying to say in the post specifically about Google is that I personally think that they have too much power. They can and will shut down a whole domain for four billion users. That is too much power no matter the intentions, in my opinion. I can agree that the intentions are good and that the net effect is positive on the whole, though.
On the "different aspects" side of things, I'm not sure I agree with the _works_ claim you make. I guess it depends on what your definition of works is, but having a blacklist as you tool to fight bad guys is not something that works very well in my opinion. Yes, specifically my own assets would not have been impacted, had I used a separate domain earlier. But the point still stands.
The fact that it took so long to move user content off the main domain is of course on me. I'm taking some heat here for saying this is more important than one (including me) might think. But nonetheless, let it be a lesson for those of you out there who think that moving that forum / upload functionality / wiki / CMS to its own domain (not subdomain) can be done tomorrow instead of today.
TL;DR takeaway for HN techies: when executing resource-intensive workloads on Node.js, pay attention to its max heap size. It can be increased with the `--max-old-space-size` option, e.g. via the env var `NODE_OPTIONS="--max-old-space-size=16384"`.