Seems I'm the idiot then, missed the "gateway" bit... so this basically sits between something providing VNC/RDP and makes it accessible with just a web server?
One would hope Tesco would cover any costs incurred by customers that are a direct result of this. I know banks in the past have cancelled non-arranged overdraft fees when they've screwed up, but that's easier to do as it's cancelling a charge rather than actually paying money out.
One would hope, but again time is a factor. I've had a weird "I'll be OK soon but for now I'm in trouble" situation before with Bank of Scotland back when I was a student. BOS randomly decided overnight that instead of having an agreed-upon student overdraft limit of GBP 2000 I had none whatsoever and needed to start paying them the full balance immediately. Eventually this was resolved, but for four days I was unable to pay rent or buy food. I was extremely lucky I had friends/family I could rely on in the meantime and that it was resolved so quickly, others may not be so lucky.
I am astonished how many people in this discussion are completely unaware of the idea that some people aren't as lucky as us and work paycheque-to-paycheque. I know HN/SV is a bubble, but surely we're not so out of touch with reality...
I'd rather keep my money in one place - if you've got 3 accounts in separate banks that means 3 accounts to pay attention to to make sure nothing is going out that shouldn't and also multiplies the risk factor?
So the risk of something happening is larger (but not quite 3x due to shared vulnerability and multiple event), however is risk of being locked and unable to function is significantly smaller as long as you can operate with the subset of accounts.
If you are in the position (like most) where all your account contents are guaranteed and the only thing you are hedging on is convenience vs risk of cashflow problems.
The JSON standard(s) are very simple. But in practice this simplicity leads to a lot of edge cases. Very deeply nested structures, numbers that run on to infinity. The point of this post is testing various parsers against these malicious structures.
"In conclusion, JSON is not a data format you can rely on blindly." - that suggests the format is bad when it's highlighting problems with the parsers. I see it like saying "Plain text is a bad format because notepad bails on large files"
Since many (all?) of Dyn's authoritative server IPs are anycast, attack traffic is probably not well distributed either. If you're routed to a server that's getting a lot of attack traffic, you're likely to have problems, but a server without much attack traffic will work fine.
Oops, thanks for that - seems the results from the first run of the example somehow got lost in the final version and I didn't notice.
The order of the output is dependent on when each call finished - they run in parallel, so it's not guaranteed that functions will end in the order they were invoked.