151–160 of 160 posts
Earlier quoted context omitted.
You can!
Specifically you can do two things: 1) planned incremental improvements, 2) simpler designs. For 1), write down the entire manual workflow. Start automating pieces that are easy to automate, even if someone has to run the automation manually. Continue to automate the in-between/manual pieces. For this you can use autonomation to fall back to manual work if complete automation is too difficult/risky. For 2), look at y…
my patch: delete WebAssembly injected with uBlock into every browser context before page loads.
Earlier quoted context omitted.
My guess is that the main feature which enables this kind of automation is that they can take down any node without consequences. So they can just install an update on all the machines, and then reboot/restart the software on the machines sequentially. If you have implemented redundancy correctly, then software updating becomes simple.
We actually update each machine while it is serving live traffic, with no downtime. We start a new instance of the server, warm it up (pre-load popular Workers), then move all new requests over to the new instance, while allowing the old instance to complete any requests that are in-flight. Fewer moving parts makes it really easy to push an update at any time. :)
Earlier quoted context omitted.
Look for a company who's business model includes uptime, security and scalability. And is big enough to not outsource those parts. And in a mature market where customers can tell the difference.
I once worked for a company that tried to set up a new service, they asked for 99.99999% uptime. This worked really well for the 'ops' team which focused on the AWS setup and automation, but meanwhile the developers (of which I was one, but I didn't have any say in things because I was 'just' a front-ender) fucked about with microservices, first built in NodeJS (with a postgres database storing mostly JSON blobs behi…
Earlier quoted context omitted.
I once worked for a company that tried to set up a new service, they asked for 99.99999% uptime. This worked really well for the 'ops' team which focused on the AWS setup and automation, but meanwhile the developers (of which I was one, but I didn't have any say in things because I was 'just' a front-ender) fucked about with microservices, first built in NodeJS (with a postgres database storing mostly JSON blobs behi…
99.99999% uptime is about 3 seconds of downtime per year. Yikes! Does any service on Earth have that level of uptime?
* They set an easy measurement that doesn't match customer experience, so they say they're in-SLO when common sense suggests otherwise.
* They require customers jump through hoops to get a credit after a major incident.
* The credits are often not total and/or are tiered by reliability (so you could have a 100% uptime and not give a 100% discount if you serve some errors). At the very most, they give the customer a free month. It's not as if they make the customer whole on their lost revenue.
With a standard industry SLA, you can have a profitable business claiming uptime you never ever achieve.
Earlier quoted context omitted.
That isn't sufficient. You know why? exploit("X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*") Okay, so we remove strings. Good thing the in-memory object format isn't known by the atta– wait. Okay, never mind; we can get rid of objects too. And bignums, while we're at it; that leaves us just with bog-standard floating-point integer primitives. Which are stored in a JavaScript call frame. Oops.
1. String are not executable code 2. Can be sanitised to be valid UTF-16 3. Can be intentionally mangled in memory to prevent abuse
https://news.ycombinator.com/item?id=16312317
But yeah you could try and mangle it and represent them internally as e.g. a rope, but that's not a bullet proof solution.
Ah yes. Perfect timing. Just 2 days after I was heavily downvoted for saying that you're not particularly safe if you don't disable JS. This absolutely made my day. HN truly is a source of nonstop entertainment.
I could go ahead and say diable internet unless you dont want to be particularly safe. I mean there are CPU level zero days. But on a serious note, how would one protect oneself from Apps other than browser and talk to internet? I mean we can't ask regular users to learn and turn off stuff.
What I do, while using OpenBSD, is limit which users access which apps, dividing my activities by user according to risk level and which apps a given user uses and sites that user browses to (some user accounts I use regularly do not use a browser). Also obsd has pledge and unveil built in, which are kernel API calls they put in apps which limit which syscalls and directories an app can access. Those combined give me some increase of confidence.
(Edit: On Debian I could do this with multiple simultaneous X sessions, moving data between them via a shared text file. On obsd, one could use SSH and some scripts, so they can share a desktop if/when desired.)
Maybe there is a maturity and effort level continuum, where we can help people along as appropriate, per their desires, interest, and situation.
Ah yes. Perfect timing. Just 2 days after I was heavily downvoted for saying that you're not particularly safe if you don't disable JS. This absolutely made my day. HN truly is a source of nonstop entertainment.
I could go ahead and say diable internet unless you dont want to be particularly safe. I mean there are CPU level zero days. But on a serious note, how would one protect oneself from Apps other than browser and talk to internet? I mean we can't ask regular users to learn and turn off stuff.
Earlier quoted context omitted.
yeah k, ill use my notepad
You don’t have to use your notepad. You can just disable JavaScript. Vast majority of text content sites work fine. You always have the option to use JavaScript for sites you explicitly trust.
Edit: critiques welcome of course.