Things you can’t do with the website:
- Login with biometrics. Wants password and 2fa each time. As it should, but it gets tedious, especially when I want to confirm online payments (which need to be confirmed inside the interface after you login).
- No contactless payments. You can enroll a card into Google Pay but fuck Google, I don’t want them seeing what I buy.
- No notifications, hope the bank is willing to send SMS instead.
- Bit more tedious to send money to someone because the website can’t look up contacts by name, have to look them up separately and copy the phone number over.
Similarly, a flower pot falling on your head is not a hypothetical, it just hasn’t happened to you.
But does it mean you should wear a helmet every time you go outside?
To begin with, the probability of keylogging being used in an attack against you is abysmal. Not because it can’t be done, but because it’s a complicated, inefficient attack, and if the attacker can run code on your machine there are much better ones.
Secondly, keylogging is still possible on Wayland, if the malicious code can attach to the relevant processes. Such as a vulnerability in your browser, which also happens to be a place where you type passwords and CC numbers a lot.
Third, as Wayland evolves it will have to develop better IPC features. You can’t have a functional desktop with zero communication. And we’ll be back to square one.
Fourth, desktop communication is not even that sensitive. 99% of it is stuff like “window id 0x09123 was maximized”.
Last but not least, if keylogging were a real issue, don’t you think it would have been addressed in the 40 years that X11 and Xorg have been around? It’s fascinating how some people think that Wayland was the first to discover this previously completely unknown threat that threatens to doom us all.
keyloggers is because it allows an attacker to perform privilege escalation by recording your sudo/root password and automating an attack
So does putting a script called sudo in your PATH.
Keylogging is one of the lamest, most inefficient methods of attack. If you can run code on someone’s machine there are so many other things you can do.
The fact Wayland has wasted so much time and complicated things so much focusing on a non-issue is mind-blowing.
The majority of users do not use such tools and should probably use Wayland.
Don’t worry, this is not the only thing holding back Wayland adoption.
Do you sandbox each and every process? Do you whitelist everything each process can do? Every file it can access, every which way it can use the network, every bit of CPU and RAM and hardware resource it can use?
If you don’t do that, why do you want to impose upon me a complete block of inter-window communication, which I use for desktop automation, and which has basically zero security impact in the wild?
I don’t mind Wayland having security features, but why are they so heavy-handed and non-optional? Things like firewalls, AppArmor, cgroups, they’re all customizable. Why is Wayland all or nothing?
Again, if you have malicious code running on your computer it can do lots of things. It can access your files, the network etc. You have to keep an eye on security vulnerabilities all the time anyway, which thanks to FOSS is easier. You’re pigeonholing on keylogging but there are lots of ways that malicious code can hurt.
Windows has chosen to go the route of allowing malware in and dealing with the fallout later. It didn’t work out so great. UNIX and Linux have been on the side of not allowing malware in at all if possible.
If you want to use a system that restricts access to all apps to all resources all the time you can, but I think you’ll find it very limiting and inconvenient. But it would be your choice.
In the meantime, if my choice is to disregard the purely hypothetical threat of keylogging, I should be able to do that, especially since breaking inter-window communication also breaks all desktop automation.
And that’s why I don’t use Wayland: it broken desktop automation and it won’t give us a choice in the matter, for the sake of one, randomly selected, purported security issue.
You can also delete the payment token that was issued to that website.
My bank lists the currently valid recurrent tokens explicitly next to each card, and lets me revoke them individually (but I can also re-add a card to the merchant if I want to).
In the Revolut app it’s a bit wierder, you have to go to a card, tap on a past payment, and then you get a “block future payments” button that prevents that merchant from ever using that card, but there’s also a “subscription payment” toggle that only revokes the recurrent token for that particular payment.
The “block future payments” feature is severely limited on the free Revolut accounts, you can only do 3 blocks per month and can only have 5 total overall active. So you probably want to turn off the subscription toggle instead.
My bank will assign cards to specific accounts and only draw payments with that card from that account. And they let you make multiple cards and multiple accounts, naturally.
So for me the easy solution is to simply not keep money in that account (because it’s a debit account and will simply refuse payments when there’s no money).
The other simple solution is the fact that the bank also lists the tokens currently associated with each card, and lets you remove them. Once the token is gone the website has to ask for explicit permission again.
For those not familiar, nowadays websites can no longer store actual CC details (it’s a huge compliance violation) and in fact they never even get to see the CC details anymore. You enter the CC details on the processor’s page (which is a separate entity), they send them to your bank, the bank verifies them, asks for a 2FA confirmation from you, and if everything checks out they issue a token to the website.
The token can be good for a one time payment, or for recurring payments. If it’s a recurring token my bank will list it next to the card involved and let me revoke it. The website can use the token for as long as it’s still listed – if I delete it they have to ask for a new one.
I suspect that this is the main shortcoming of Revolut’s one-time cards, they issue one-time tokens (naturally) and it’s easy for the website to see that it’s not a recurring one.
Edit: I should also mention that in the EU this token mechanism is NOT used for utilities. For utilities (and for other EU recurring payments) there’s a similar but explicitly separate mechanism called SEPA. It’s similar in the sense you can set up the payments and you see them listed next to your account, you can revoke them at any time, they also use a tokenization system, but they draw directly from an account, there’s no CC involved and no CC processors, it’s a system that works directly between EU banks.
Most online places are now aware of Revolut’s disposable CC numbers and reject them. They haven’t worked for at least a year now. They’re basically useless.
Edit: I should clarify: all CC payments nowadays use tokenization. The website doesn’t get the CC details, they get a token issued by your bank. The token can be one-time use, or recurrent. Naturally, for one-time cards Revolut issues one-time tokens. The problem is that many websites have caught up to it and require indefinitely-valid, recurrent tokens for any payment. I don’t think this is something that Revolut can solve on their side.
If someone gets access they can delete your keys, or set up something that can intercept your keys in other ways.
The security of data at rest is just one piece of the puzzle. In many systems the access to the data is considered much more important than whether the data itself is encrypted in one particular scenario.
You. Don’t. Store. Secrets. In. Plaintext.
SSH stores the secret keys in plaintext too. In a home dir accessible only by the owning user.
I won’t speak about Windows but on Linux and other Unix systems the presumption is that if your home dir is compromised you’re fucked anyway. Effort should be spent on actually protecting access to the home personal files not on security theater.
Many people have a warped understanding of what “two factor” means.
They conflate it with devices and they think it means that one of the factors (why one? which one? who knows) needs to be restricted to exactly one device.
What “two factor” really means is that you should have more than one required factor of authentication so that if one is compromised the attackers still can’t get in.
Ideally the factors should be spread across the “something you know” / “something you own” / “something you are” categories to complicate the manner in which they can be compromised.
We can only reliably rememeber a limited amount of passwords, so like it or not we have to use some devices at least some of the time.
The trouble with “something you own” is that it can be lost or damaged or stolen, and if you only have one of it then you’re fucked. So adding some redundancy is not a bad idea.
The larger issue is that everybody is stuck into extremely rigid and outdated mindsets that date back decades. “Two factors” don’t have to be exactly two, and they don’t have to include exactly one password, and so on. It should be fine if you wanted to secure your account with 3 passwords, and should be up to you if one of those password is a barcode tattooed on your taint so you need a mirror and to bend upside down to scan it.
Bottom line, use whatever you want and use your best judgment as to how secure is each factor. If you want to use something that syncs to multiple devices, go ahead. What you should consider is who has access to those devices and how it would affect you if they’re lost or stolen.
I’m fairly sure the only reason for which Apple is using RCS is to circumvent the EU DSA, which requires them to make iMessage interoperable with other chat systems. So instead of opening access to iMessage they’re using a completely different system as a distraction.
I mean, they could’ve said that iMessage is already interoperable via SMS but the feature disparity is too large. RCS will serve nicely to confuse the issue.
There’s otherwise nothing to gain for Apple by adopting RCS. iMessage already does everything RCS does and more.
They could also kill RCS tomorrow if they wanted to, by simply releasing iMessage for Android. But then they wouldn’t have a red herring to show the EU — if anything they’d be in an even worse position as per DSA. It would also antagonize Google although I’m not sure how much they care about that.
I beg to differ. In my country (Europe) they can get almost nothing on their own (if I haven’t volunteered it on social media). Public institutions, schools, banks, the police etc. do not release information to random people.
When we have the odd American client that insists on hiring a background check they come to me to give them paperwork that proves education, past employees and (lack of) criminal history. Then they start bitching that they can’t get in-depth information about each of them and I tell them to fuck off.
I’m curious what exactly they’re trying to get, maybe you can offer some insight. With the stuff I give them they are able to confirm that I really went to that school and worked at those places, should that not be enough?
I’m just gonna add this for completion, DroidCamX can be installed on a smartphone and its cameras will act as an IP camera. DroidCamX also has a Linux package that will make the connected phone show up as a V4L2 device. You can connect the phone over USB or over LAN in two ways (PC connects to phone or phone connects to PC).
Now obviously a phone isn’t ideal for running 24/7 but since this is about privacy I thought it’s worth mentioning.
I’m just gonna address the domain question.
ccTLD’s for countries that are members of the EU usually have pretty strong privacy protection, especially if you are buying as an individual.
.de (Germany) is probably the cheapest (3-4€) but if you’re not a resident you will need the registrar to arrange a mailing address for you for a small fee (another 3€ or so). Still going to be a pretty low price.
.nl is another cheap option, without any residency requirement.
The only issue with both is that you can only buy for one year at a time.
The owner’s details in the registry are never published. Legit requests in case of abuse etc. need to go through the registry.
Ah cool. It’s starts being very competitive very fast if you need more than one mailbox and/or more than one domain. Regular services will ask for something like $5/mo (per domain and per mailbox!) which adds up very quickly.
Wish more services used the “all you can eat” model. Charging for emails sent/received and for storage space is all that’s needed. Charging for “mailboxes” or “domains” or “aliases” has always been a scam.
You’re using the publisher’s arguments in your comment. If anybody’s interested, here’s the IA’s counter-argument. It boils down to the fact publishers are challenging practices that used to be considered fair use… just because they can.
This decision has wide-reaching implications that will affect all libraries, not just the IA.
Ultimately we’ll just have to see what the appeal decision will be.
I believe that rclone already has Proton Drive support.