Tomas

On question 2, a recall is not a reversal and the difference matters a lot.

When your bank attempts a recall, it sends a request to the receiving bank asking it to return the funds. The receiving bank then has to get the account holder's agreement, because that money is legally theirs. If they say no, or do not respond, nothing happens. If they have already moved it, there is nothing there to return even if they agree.

So the honest description is: your bank is asking a stranger, politely, via their bank, to give it back. Success depends almost entirely on whether the recipient is an honest person who received a mistake — in which case it usually works — or someone who took the money deliberately, in which case it almost never does.

That is why speed matters so much for transfers and barely at all for card disputes. With a card you are invoking a process. With a transfer you are racing the recipient.

There is a principle and it is sharper than case-by-case: does the field record a fact about the user, or a preference you are allowed to guess?

If it records a fact — country, date of birth, which account, how many people are travelling — a default is a lie you have written on their behalf. They will not notice, it will be wrong for a portion of them, and you will not be able to tell the guessed values from the chosen ones afterwards. Start blank.

If it records a preference where a wrong value is cheap and reversible — sort order, page size, theme — a sensible default is a kindness and blank is friction. Nobody wants to choose a page size.

The test that follows: what happens if this is wrong and nobody notices? Wrong country on a shipping form is a returned parcel. Wrong sort order is a click. That difference decides it, and it decides it consistently.

For the people who are already stuck — because the fix above only helps from the next deploy onward — the service worker case has a specific escape.

If you no longer want one, deploy a service worker file that unregisters itself and clears its caches, rather than deleting the file. Deleting it does nothing: browsers that already have it registered keep running the old one and never ask for a file that is not there.

A few lines that call registration.unregister() and delete the cache keys, shipped once, cleans up the installed base. Then remove it a few months later.

Unpleasant, and the only thing that works.

"Only an authenticated user, on their own behalf, at a rate I allow" is genuinely what I needed. I had framed it as a client identity problem when it was an authorisation and abuse problem.

It works because it does not ask you to believe anything unlikely, which is the opposite of how people picture a scam.

A phone breaking is ordinary. Getting a new number is ordinary. Not having your banking app set up on a new handset is ordinary. Every individual claim is something that has genuinely happened to your family. There is no moment where a reasonable person should stop and think "that cannot be true", which is the moment most scams depend on you not having.

Compare it to the classic scam email, which asks you to accept something extraordinary. That one filters for people who will accept extraordinary claims. This one does not filter at all — it works on careful people, which is exactly what your relative demonstrated.

So the useful reframing for the family: this is not a test of gullibility, and treating it as one is why intelligent people get caught. They think it could not happen to them.

One practical caution if you ever do find a genuine cross-market difference and decide to use it: check the fare rules before booking, not after.

Tickets issued in a different market can carry different change and refund conditions, and occasionally a requirement to start the journey in that market. The saving is real; so is the possibility that the ticket is useless to you.

Worth knowing rather than a reason not to. It is just that the version of this story people repeat only ever includes the price.