robinson-wall

Which aircraft have flaps or gear controlled by an autopilot? I'm just an armchair "Air Crash Investigations" fan, but I've never heard of any aircraft where either flaps and gear would be automatically controlled by their autopilot. Speedbreaks / spoilers are usually armed and moved automatically on landing.

Perhaps set size is a contributing factor? I've bought two sets over the last few years, and both of them have had a piece missing. One was 1969 pieces (no prizes for guessing which set that is!) and the other 1222 pieces.

Both occasions the pieces weren't structurally important, and were small decorative elements.

When a fake candidate accepts an offer, the first real runner up candidate gets a rejection and has fewer offers to choose from.

I can forgive the URL bar swipe to change between tabs, because there is a visual cue that the other tabs are there - the URL bars of the adjacent tabs peek onto the screen.

I bought a device with some kind of cloth pads held opposite each other, and when you close it they brush up against an inner pad which presumably removes grease from them.

It cost £20 and I was dubious about it, but it cleans better than I've ever managed by myself with a spray. Lasted about 1.5y before it stopped being effective (just moves grease around rather than picking it up) and I went and bought another one.

I've been a recipient of the "we're really sorry but object in bucket X at path Y has been irretrievably lost" email a couple of times.

Once you're storing a few million objects at standard durability it's par for the course.

Happy to take a look (next week, realistically, as I'm UK based) - you can dm me twitter.com/nickrw

Hey, I work on Twitter's search team.

This sounds like a bug we're aware of where an account that goes public -> private we'll reliably purge their tweets from the public index, but if an account goes private -> public sometimes we'll not re-populate the main index correctly.

> we had one person's account whose search results still showed searchbanned tweets

This part doesn't match what I'm describing, but could be explained by the logged in account having access to private tweets in search results that logged out / other accounts do not.

I'm not suggesting they aren't criminals. But there is a spectrum of criminality and I am suggesting they are considerably less so than the leaders of the fraud ring.

These ads are deliberately designed to prey on the desperate, unfortunate or the technically illiterate.

Some of them probably know exactly what they're doing and I have no sympathy, but some of them probably fall into the same category as people falling for Authorised Push Payment fraud.

You see ads on instagram offering to buy or borrow your bank account for £50... and when they're used for muling guess who it is that gets their account banned and then a CIFAS marker ensuring they can't bank anywhere else? The desperate kid who needed the money, not the actual criminals behind it.

It's still possible to design a badge system on an independent network (think just switched within a building) which syncs a local copy of the authoritative ldap from the corp domain, so your badge readers stay working if the link to the corp domain goes away.

It's just more expensive and another thing to maintain, and still doesn't account for _all_ failure modes (what if you sync really frequently and a bad change was made deleting all accounts?)

There's another great example of this in maps, where it will refuse to let you favourite your home or work address if it's not in the right format. It won't even tell you that it failed - it doesn't do it and the interface doesn't make it obvious that it didn't do it. So you're out of luck if you want to figure out _why_ it isn't working.

In my case I had a country name accidentally put in a region field, but it didn't look out of place because field labels are missing when filled in. Frustratingly, your contact card with that address will show a map preview that when tapped opens maps with a pin in the right place, so there's clearly some logic to "fix" incorrect addresses somewhere.

This could be very dangerous, depending where an exception happened. Variables can contain critical secrets, like your TLS keys or a user's password and if your stack trace printer isn't aware of what should be redacted now you've got that in your logs.

More than a decade ago I had an amazon interviewer write some perl on a whiteboard, and ask me to find the error.

There were two - I pointed out both and they didn't seem super happy about it. To this day I'm still not sure if one of them was an unintentional error.

This is a website which serves the sole purpose of encouraging people to copy snippets of text and paste them into their terminal, and there are plenty of techniques that ensure what you see on the page isn't what gets into your clipboard.

It's particularly frustrating because the framework for this feature already exists - if you link a new phone it offers to sync your history to it.

In this case Face/Touch ID represents something you have (the iOS device with a persisted credential in its secure enclave), and something you are (fingerprint/face).

Your editor should be able to help with that. For example in vim: `gqap` will reflow the current paragraph, or while in visual select mode you can use `gq` to reflow your selection).

The interesting thing about working for a UK challenger bank - I now have visibility into all of the outages going on at large, high-street banks here.

Complete outages are rare, and well-publicised, but things go wrong a lot more[1] than you might think without any communications to customers that anything is wrong, sometimes outright denying[2] that there's a problem.

1: https://twitter.com/nickrw/status/1141058572547215360

2: https://twitter.com/nickrw/status/1164162320672669696

Your card issuer (at least in the UK) is obligated to block recurring payments from a particular merchant if you request it

https://www.fca.org.uk/news/news-stories/continuous-payment-...

Ah, here's a video of a note 10, which has the same fingerprint sensor as an s10, being fooled by a gel _case_ after being trained with a fingerprint normally.

https://twitter.com/Sta_Light_/status/1184475413252210688

Is there any indication of whether this only happens if the screen protector was present prior to training the fingerprint?

> After buying a £2.70 gel screen protector on eBay, Lisa Neilson found her left thumbprint, which was not registered, could unlock the phone.

This suggests that an attack of "put a malicious screen protector on phone to unlock" is possible. I'm curious whether there was any re-training after applying the protector.

Specifically this class of incident? Yes. They seem to be reasonably good at operational runbooks for known flaws, so I can imagine this class of incident being handed faster in future.

What worries me is the next unknown unknown, which is why we are insourcing. One thing I think Monzo can be particularly proud of is our incident response, and debugging of our own systems at speed.

That's why this article focuses more on what actions we are taking, and not what actions they are taking.

It happens all the time, and they just don't tell you. We get automated notices when banks connect and disconnect from the Faster Payments network, something happens every few days. Not always this length, but occasionally.

Just yesterday a major high street bank stopped sending payments for an hour, and was telling customers on Twitter that there were no problems.

Hell, the central system (what I called the Hub in this article) had a 12 hour split brain meltdown last July which had banks emailing each other spreadsheets back and forth for two weeks afterwards.

There's a good writeup by Oliver, our head of engineering, about our tech stack on our blog[1] with an accompanying Kubecon talk[2].

TL;DR- Largely Go microservices running on k8s, with http-based RPC calls for synchronous communication, and kafka for asynchronous communication.

As for sending and receiving of this kind of payment message, they are largely async but it does depend on the payment system we're talking about. When we build our own FPS gateway we're going to have to have something to manage "sessions" (TCP connections) which will block waiting for a response to an individual payment messages. Right now our communication with our third party Gateway is via a queue.

[1]: https://monzo.com/blog/2016/09/19/building-a-modern-bank-bac...

[2]: https://www.youtube.com/watch?v=YkOY7DgXKyws

The sending bank will have their Bank of England settlement account debited by the central FPS system, based on the central FPS system's view of the world, at the end of the settlement cycle.

The recipient bank will receive the money into their settlement account at that time. If the sending bank doesn't debit their customer then both sending and receiving customers will have the money in their accounts, but the sending bank will be out of pocket.

1. A mix of both, we have a culture of being transparent by default - it's one of the first things that attracted me to come and work here. I was the incident lead for this on the day, and volunteered to write up this post-mortem. I did have help from colleagues in the marketing team to try and make this as accessible as possible.

As another poster mentioned we already have a status page where we post about incidents as they happen (though obviously not in quite as much detail as here). Personally I think our main blog is a reasonable place to have this ️.

2. Multiple redundant payment processors would be great, but ultimately infeasible. As a settling FPS participant we have to have a single Bank of England settlement account, tied 1:1 to a "bank code". Multiple sort codes map to a single bank code, and migrating sort codes between bank codes is non-trivial.

It'd be great if we could migrate sort codes easily between redundant connections, but as we build our own Gateway we'll have complete control over how our failover mechanisms work. Here's to much greater uptime in the future!

3. As another commenter mentioned - yes! We're just doing staff testing for now, but we've got a waiting list up. It'll be a prepaid product issued by another bank before we get a US banking license, just like we were in the UK a couple of years ago.

I haven't seen the code personally, so I'm not sure. The condition was inside the code of the Gateway provider.

I would note that this status page says "Our FPS Direct gateway provider".

Sorry, perhaps this isn't very clear as I've tried to simplify the explanation to make it accessible to a wide audience.

What I meant here is they could tell that the corruption was being introduced by some component in their infrastructure, and they were only observing it for messages passing through one of their two active-active sites.