ericselin

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"`.

But you're right, complaining about big tech surveillance didn't help with making that point at all.

I guess control-panel.statichost.eu is still possible, of course, but that already seems like a pretty long shot.

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

And for what it's worth, it feels great to actually pay for something Google provides!

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.

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.

"Projects that are smaller in scale or are temporary or seasonal in nature will likely be declined. Examples of this might be private-use, sandbox, test, lab, beta, or other exploratory nature changes or requests. It should be expected that despite whatever site or service referred a requestor to seek addition of their domain(s) to the list, projects not serving more then thousands of users are quite likely to be declined."

Maybe the rules have changed, or maybe you were lucky? :)

It basically goes: growing user base -> growing amount of malicious content -> ability to submit domain to PSL. In that order, more or less.

In terms of security, for me, there's no issue with being on the same domain as my users. My cookies are scoped to my own subdomain, and HTTPS only. For me, being blocked was the only problem, one that I can honestly admit was way bigger than I thought.

Hence, the PSA. :)

I'm also trusting my users to not expose their cookies for the whole *.statichost.eu domain. And all "production" sites use a custom domain anyway, which avoids all of this anyway.

Helping people avoid potentially devastating mistakes is of course a good thing.

The last point is actually the one I'm trying to make.

The new separate domain is pending inclusion in the PSL, yes.

Edit: the "effort" I'm talking about above refers to more real time moderation of content.

Currently, a particular site exists as static files on one specific server, with some failover mechanisms in place. So mainly availability is achieved by having enough server resources and having a minimum amount of moving parts :)

The tricky thing to solve for with HA is TLS termination. It is probably the most complicated thing (and for sure the most computationally intense thing) a static HTTP server does. I haven't done any testing, but my hypothesis is that TLS termination is what will start failing first. Barring DNS-based tactics (mitigation, not cure, in my opinion) you just have to accept that this is your single point of failure.

But a great question! Keeping our sites online is of course something we're working on all the time.

And yes, it was all fine before the cloud! Alas, a single server was (much?) more stable in the early days than a single instance/node/pod is today...