131–139 of 139 posts
Earlier quoted context omitted.
Some banks, I assume, allow showing the documents in person and without a selfie.
Just showing documents? I never saw a bank that will do this. They always make a copy.
I had an interesting experience with my Revolut card. I only top it up when traveling, and the rest of the time it sits nearly empty, with like $3-4. At some point I started getting occasional notifications about transactions declining. Stuff like video game points and random little online shops. Clearly my card's been skimmed or otherwise leaked somehow. Bummer. Since Im months away from my next trip I didnt immedia…
Earlier quoted context omitted.
Not a bank until 2018 And they clearly figured that was easier than going through the UK where they had previously been licensed
7-8 years surely qualify as "for years"?
but compare that to their competitors who got a license at the very start
Earlier quoted context omitted.
That may not matter that much, as even if you run a relatively strict policy about where you send the reply, you can still easily get bitten by external mistakes there: Because of the huge number of individually administered departments that might each become authorized recipient of such data, a malicious party only needs to find one suitably dangling DNS delegation to score a "…@attacker-controlled-subdomain.legitim…
I think you missed the point - delivery of sensitive data should involve public key encryption of some sort and it should ideally be done through an application or website that's purpose-built for this. It should be made impossible for someone at Revolut (and every other org) to deliver this data into the wrong hands by accident.
Earlier quoted context omitted.
I think you missed the point - delivery of sensitive data should involve public key encryption of some sort and it should ideally be done through an application or website that's purpose-built for this. It should be made impossible for someone at Revolut (and every other org) to deliver this data into the wrong hands by accident.
Public key encryption as in DANE already achieves what can be achieved given the constraints. I have seen some purpose-built apps that use email for auth and then establish a different channel to exchange the documents. But that just nets the security properties that you already had with email.. just with some added methods of sideloading trojans past those pesky email attachment scanners. Turns out , you cannot just…
You're discussing this as some inachievable science fiction that would require every employee to learn how to use gpg. In reality this could be achieved through a simple to use website.
In fact this is a solved problem. My doctor is not legally allowed to email me my own medical records, not even the most mundane blood test result. Instead they send them through the government-operated portal which employs suitable authentication and prevents any sort of transport-level hijacking.
There is no excuse to be using non-e2ee email for this in 2026. None.
Earlier quoted context omitted.
Public key encryption as in DANE already achieves what can be achieved given the constraints. I have seen some purpose-built apps that use email for auth and then establish a different channel to exchange the documents. But that just nets the security properties that you already had with email.. just with some added methods of sideloading trojans past those pesky email attachment scanners. Turns out , you cannot just…
Christ, ease off the condescension, I'm very obviously not talking about "sprinkling in" domain name authentication, but encrypting the data for an eligible recipient using a suitable root of trust. You're discussing this as some inachievable science fiction that would require every employee to learn how to use gpg. In reality this could be achieved through a simple to use website. In fact this is a solved problem. M…
Except, it makes the user experience worse: I can certainly make it infinitely more tedious to open the document exchange site of $superimportantcompany on superimportantcompany.co (or was it .com? or .co.uk? or important-company-le.ai?), and spread out "my" inbox across 30 different sites and spend additional time navigating their unique interfaces to not just read, but also add each document into the appropriate local archive. But what have I gained in making it more likely that each correspondence is kept confidential between the only parties that should read it? Nothing beyond what I started with. Could have stayed with email, no?
I can see the appeal of mitigating part of the usability problem by pivoting straight to bundling up all thematically related messages into centralized repositories to limit the number of pseudo-mailboxes one has to maintain simultaneously, as done in the recent "everything medical related" cases. But someone would grab a full copy in the inevitable compromise, and that is a risk that should rather stay scoped to smaller groups of senders and/or recipients. It seems like a bad tradeoff to force every blood test of everyone into the danger zone for that, given that one could have instead spent 3% of the budget on.. merely policing away the DNS warts in public authorities (or, in the medical example, insurance companies) while keeping data custody unchanged.
Earlier quoted context omitted.
That's how chargebacks often work. Then they ask the merchant for evidence the charge was legitimate. If convinced, they will retract that initial quick refund.
Real chargebacks claw the money back from the merchant. They don't just provide a credit.
Earlier quoted context omitted.
Christ, ease off the condescension, I'm very obviously not talking about "sprinkling in" domain name authentication, but encrypting the data for an eligible recipient using a suitable root of trust. You're discussing this as some inachievable science fiction that would require every employee to learn how to use gpg. In reality this could be achieved through a simple to use website. In fact this is a solved problem. M…
What is the difference between making sure an HTTPs endpoint does not leak and making sure an IMAPs endpoint does not leak? I do not see much of a fundamental difference. Except, it makes the user experience worse: I can certainly make it infinitely more tedious to open the document exchange site of $superimportantcompany on superimportantcompany.co (or was it .com? or .co.uk? or important-company-le.ai?), and spread…