It's a very good question. The stand-in system itself has been built to have basically no external dependencies itself.
So, the question you are really asking is "to what extent are the other parties involved in the processing of payments resilient to AWS failure" – e.g. Stripe probably isn't and that's probably a decent chunk of e-commerce.
I definitely don't think this would be anything close to smooth sailing if AWS was to fully go down, but we do have the benefit that underlying payment infra is still dominated by on-prem with leased lines etc. My best guess of the actual behaviour would be that bank transfers would keep working, the card networks themselves would keep working but the average e-commerce website would not.
Naturally, we can only control for what we can control for – and for us the primary benefit of stand-in is what it gives us in the much more likely scenario of an incident in our platform.
Just in case it is relevant for anyone here this is what our security team have established thus far:
- Can be mitigated by enabling the root user with a strong password
- Can be detected with `osquery` using `SELECT * FROM plist WHERE path = "/private/var/db/dslocal/nodes/Default/users/root.plist" AND key = "passwd" AND length(value) > 1;";`
- You can see what time the root account was enabled using `SELECT * FROM plist WHERE path = "/private/var/db/dslocal/nodes/Default/users/root.plist" WHERE key = "accountPolicyData";` then base 64 decoding that into a file and then running `plutil -convert xml1` and looking at the `passwordLastSetTime` field.
Note: osquery needs to be running with `sudo` but if you have it deployed across a fleet of macs as a daemon then it will be running with `sudo` anyway.
I use ligatures in atom and they are 100% aware of context. I disable them in contexts where they don't make sense e.g comments and I disable them on the line the cursor is on.
I've not had any issues. The => ligature looking like the right arrow character is just like a cyrillic A looking like a latin A - it's a problem that never manifests itself.
The author has a very subjective opinion that they try and present as fact.
The illusion of knowledge about crypto is very dangerous. People get this stuff wrong all the time and introducing more examples with really bad mistakes will only make the situation work.
When I read the title I thought this would be a toolkit for writing databases.
A lot of the work involved in writing a database is systems stuff such as being sure that a commit log has actually been committed. Having a toolkit that does all that stuff for you would make it a lot easier to write your own database.