A distributed spam attack across the public Matrix network
matrix.org
matrix.org
I hope they don't have to tighten things down to the point of interfering with functionality because Matrix is excellent as it is.
On the other hand, on IRC which I also use a lot it's just a fact of life.. We just apply some minor workarounds such as +r channels, roll our eyes and move on with life. I'd much rather have a free open network with some spam than a curated one by big tech that's free of spam.
PS: Another thing I do foresee happening if Matrix really takes off is big tech datamining it. It's very hard to make a network open and yet hide as much metadata as you can, e.g. how many users are on which servers, who do they communicate with across the network etc. If some big tech entities control some of the servers it becomes really hard to keep that locked away. Of course Matrix's encryption will help but not for all metadata. Again I think it's something we'll have to mitigate rather than prevent outright.
Especially because Matrix is pretty good at what it aims to do already.
I don't think there's anyone that can actually keep their system abuse-free. Things like Messenger certainly have a lot of spam.
I agree. One solution is "have a real human identity you can't delegate with real stakes if you're banned." What we need is a blue checkmark for everyday people.
Most times, harassers are protected by their legal system, not the victims. But if someone dares insult the police, then they'll find you in a second and put you on trial.
We need better tools to manage trust and consent in a decentralized settings without revealing the social graph. I heard the expression "Fog of Trust" a few times to refer to that.
Such policies have definitely not cut back on spam (at least not according to my definition of spam), but have prevented countless legit users like me from taking part in such networks. Retrospectively it's a good thing that these networks don't want people like me, we're doing much better elsewhere.
I propose you a challenge: if you can view age-restricted videos on Youtube and create a Facebook group without giving your ID, credit card, address, phone number or IP address... i'll send you a cupcake over mail? :P
1. User registers a non-transferable username (maybe an NFT?)
2. User signs into the client with the username NFT
3. The server admin maintains a list of shadowbanned username NFTs -- if yours gets added, then the server won't relay your messages.
Non-transferability means no one will squat usernames (since there's no money to be made by reselling them), and since it costs money to register but costs nothing to shadowban, the asshats only lose money by being asshats (and their spam doesn't even get read).
It sounds like all you've actually invented is "identifying people by their bank accounts", only with more steps.
I suppose if the NFT could be registered using an anonymous cryptocurrency, it might end up being a more privacy-preserving system than getting people to pay for an account using traditional methods.
It also might be cheaper than paying to join multiple services, if you only have to pay once and can use your NFT username across them all. On the other hand, a single malicious admin could try to extort you by threatening to ban you from all those other services.
A better approach would be a blockchain-based anonymous identity system, which is apparently what BrightID is:
Trivially. You make it so that there's no recognized way to change the private key for a username.
> It sounds like all you've actually invented is "identifying people by their bank accounts", only with more steps.
I've created a layer of indirection between usernames and bank accounts. The system doesn't need to know or care about how you managed to burn tokens for the username.
> A better approach would be a blockchain-based anonymous identity system, which is apparently what BrightID is:
Does BrightID guarantee that asshats have an asymptotically worse time registering usernames than admins have shadowbanning them? If usernames are easy to come by, then so are sockpuppets and one-off spam and troll accounts.
Making it impossible to rotate keys doesn't sound like it follows cryptographic best practices, but in any case, there's nothing stopping someone from selling their private key to someone else.
If you just want to avoid squatting/speculating, you could make the user IDs be random unique values but associate them with a non-unique human-readable name.
> If usernames are easy to come by, then so are sockpuppets and one-off spam and troll accounts.
I haven't used BrightID, but I believe it works by having users meet in person and mutually verify each other as being unique humans. It should be impossible for someone to pretend to be two people in the same place at the same time, so that does seem viable.
The fact that the original owner(s) can still use the name would prevent resale. For example, the admins could simply shadowban a username if they verify that multiple users have the same key (e.g. if my private key was stolen, I'd report it to the admin).
> If you just want to avoid squatting/speculating, you could make the user IDs be random unique values but associate them with a non-unique human-readable name.
The literal identifier isn't important to account resale value. User accounts include all of the state as well as the literal identifier, including reputation, longevity, and associated app content. This is all valuable to asshats -- they want high-reputation accounts to broaden their spam audience. But in order to make it costly for asshats to gain high-reputation accounts (more costly for them than for admins to shadowban them), we can't give them any shortcuts -- the system should compel them to spend time and energy to earn their reputation like everyone else. So, account resale shouldn't be supported by the system.
> I believe it works by having users meet in person and mutually verify each other as being unique humans. It should be impossible for someone to pretend to be two people in the same place at the same time, so that does seem viable.
This does not sound like it prevents a small number of asshats from just creating a bunch of fake sockpuppet accounts. If creating accounts is a cheap (or cheaper) than shadowbanning them, then the asshats will eventually overwhelm the admins.
The buyer would know that maybe the seller still has the key, since cannot be rotated
> user IDs be random unique values but associate them with a non-unique human-readable name.
I think scuttlebutt does something like that
> It should be impossible for someone to pretend to be two people in the same place at the same time
A group of people cooperating can pretend to be 99999 people?
If the buyer is a spammer, they won't care that the seller can still send non-spammy messages with the account. If the seller is a squatter/speculator, they have nothing to gain from interfering with their customer's account.
> A group of people cooperating can pretend to be 99999 people?
It would be easy to determine from the (anonymous) social graph that those 99999 people are only connected to each other and a small group of other (real) people. An algorithm looking at this graph could then select 100 people out of the 99999 group and require them to meet with 2 other distantly-connected people at a specified public place. If less than 102 people show up, then those 100 lose trust points. That's how I guess it would work, anyway.
What if the seller is a spammer or scammer, and first sells the account, remembers the private key, and a bit later starts spamming or scamming
> It would be easy to determine from the (anonymous) social graph that those 99999 people are only connected to each other and a small group of other (real) people
If the "group of people" is small, yes. I didn't say that the group was small though.
If it is larger, and they arrange the connections in realistic looking ways (for detection algorithms), then they can get away with it. Think of an island where most people are connected with others on the island only -- and maybe 10% of them connected to people on the mainland. Something like that can happen in real life I suppose, and the "group of people" (possibly many, paid by a company or a state) could construct such graphs and pretend to be more than what they are
> An algorithm looking at this graph could then select 100 people out of the 99999 group and require them to meet with 2 other distantly-connected people at a specified public place
That's an interesting way to try to handle that. However, first the algorithm would need to realize that a part of the graph is suspicious. (And people would need to be really motivated to, in real life, actually go to somewhere :-) ? what of they're busy with friends and family)
To achieve this, it would be sufficient to make it so the cost of registering a user account is asymptotically more expensive than the cost of shadowbanning an account. If the software required that each additional account a user registers costs more in USD terms than the previous account, while keeping the cost of shadowbanning a username constant, then the honest participants will win in a struggle against asshats who must keep registering accounts to circumvent the shadowban.
A strawman approach would be to require all user accounts to be tied to real-world identities. Then, the software can track how many accounts a real-world person has registered, and bill them accordingly. This obviously has other unrelated problems, but it does make it possible to penalize asshats more and more harshly for each infraction.
I was suggesting that a blockchain could be a useful building block here, since it already exists, is widely deployed, and costs money to write state. A more practical approach than the strawman could be to implement a username registration system on a blockchain, such that each registrant must burn some of the blockchain's tokens to register a username (thereby imposing a cost to doing so). Crucially, the number of tokens burnt per name would increase as more and more usernames get registered (or as more and more time passes), and in doing so make it more and more costly for asshats to circumvent a shadowban. This would also make it so asshats would lose a war of attrition against admins, and could be implemented today.
This is just a tax on the young.
1. it's slow, requires insane amount of storage, power and traffic
2. nobody wants non-transferable username for real
Compared to the infrastructure required to uniquely identify every human in order to stop them from registering lots of troll accounts, and implementing a fair and accountable law enforcement apparatus to make sure the rules are followed? The blockchain might be cheaper.
> 2. nobody wants non-transferable username for real
Which is the worse outcome -- you can't transfer your username (but you can register a new one for a fee), or trolls and squatters can trash the system?
No problems with spammers or trolls at all. And that's literally my experience with 20+ homeservers that I configured
Again, nobody wants unique permanent ID per human.
PS: regarding "a new one for fee" - I hate services that work this way (hello, Blizzard), IMO.
Just humans learning how to behave, maybe one-day it'll all be peace and productive quiet, until then, and on our journey to there, a warzone.
Then it wouldn't be "a prime example of attacks making the target stronger", it would be a, err, sub-prime example?
All things considered, I can't say that the Matrix.org team responded slower than I've seen any IRCops respond. The main difference is you don't tend to see news about this happening on IRC as much anymore because IRC has had spam problems for decades, and there's hardly as many people who are out and about making it news.
Plus, for what its worth, most of us who run our own homeservers never encountered this issue at all, because public registration isn't open in the first place. It seems awfully dismissive to wave off Matrix for purely this one incident as it being "immature" as a protocol / platform.
IRCs are absolutely archaic, for sure. Inspircd’s modules are awkward to use, single characters have special meaning… there’s g/k/u-lines and don’t get them mixed up!
But, they’re very powerful and absurdly flexible. We’ve been able to mitigate absolutely huge spam attacks with quite complex logic, and you have strong moderation tools at every level- from the channels with quite rich permissions (voiced, half-ops, ops, admins, founders) and the network level (the aforementioned lines).
Maybe matrix has caught up- but it’s hard for me to run a public network without such rich moderation tools.
Even if those tools are clunky and awkward.
But this will be one of many _novel_ attacks on what is a more complicated network.
When clients and servers need to be updated to fix these issue, it becomes a drag.
Actually, the only time a server under my management was hacked (CEO installed some random WordPress plugin with RCE, sigh) was to run an IRC spambot to send out exactly this sort of abuse. Hurray for firewalls also blocking outgoing traffic by the way: as far as we could tell this was all just dropped and never impacted anyone.
Either way, this doesn't sound like a "Matrix problem".
Since then IRC has actually evolved into a more mature userbase but its inherent lack of protection to this and the ease of writing a bot makes a few idiots capable of spamming the entire IRC world.
Nevertheless like I said in another post I think this is just a tradeoff we have to learn to live with. Being fully open is great, but comes with drawbacks and implied trust. I still prefer it as it is.
[1] I said organization, but what is the right word here? Group? Domain? Do IRC and Matrix have their own terms for these things? I wanted to say server at first, but surely there is more than one server.
That said, you _do_ have to worry about spam from other homeservers, but that only matters if you have users from that other homeserver in your room. You can choose to federate / not-federate on a room-by-room basis, or just not federate at all ever.
Needless to say, you're right that it is a bit different than IRC in that regard (IRC can just kline hosts / IP ranges from the whole service if you're spamming). However, in practice there's a lot less instances of random spam such as in the article than you would think.
For myself, I never noticed any of these spammers at all (anectodal, so mileage may vary). I do have my own homeserver through Element Matrix Services, but I am part of a good number of rooms that exist purely on the Matrix.org server. Certainly I have to "police my users," but that's pretty easy since I run a small homeserver for ~5 users, and we just federate with the greater network when needed.
I guess I agree with you in general that there's different failure modes, but I don't think it's as simple as dismissing matrix because it "has the same spam problem as email" compared to IRC. In practice at least, it doesn't seem to be as much of a problem despite how much larger than IRC Matrix has become.
So spam becomes a part of the log, which means that it'll consume far more resources than just network resources.
The matrix-docker-ansible-deploy playbook will install it for you very easily. All it takes is enabling one config option.
I thought that fell under the umbrella of common knowledge, so far as Matrix goes. If you've got data indicating otherwise, I'd find that interesting to see. I'm actually finding hard stats very difficult to locate (the few I can find seem incomplete, but corroborate this very strongly, for what they're worth), but again, I thought this was basically assumed to be true by Matrix users. I mean, if you search "matrix protocol" or "matrix chat" or "element chat" and follow the Happy Path of clicks to try it out, you'll have a Matrix.org account. The way you veer off that path? You have to know the address of another Matrix server. You won't be presented with other options, just the ability to type in the address of a different server. That this would result in Matrix.org having the lion's share of users seems a predictable outcome.
the “unblocking” requests to abuse@matrix.org are to remove the servers with spambot accounts from the blocklists we publish as matrix.org; nothing to do with centralisation.
As for the latter, that's immaterial—the more important it is to get server-to-server federation un-blocked with matrix.org, the more that can be taken as a sign of centralization. Moreover, if a large percentage of servers follow the Matrix.org blocklist, that's precisely the kind of centralized control the original poster was asking about.
(mind, none of this is intended as judgement, just clarifying why matrix.org would have substantial de facto "control" of the ecosystem & network, to use the original poster's word)
This was my point. We never blocked server-to-server federation with matrix.org. We published a blocklist of the abusive servers, and blocked them from the rooms which we manage on the server. There was never any centralised control applied, and there is no mechanism to do so (unless room/server admins opt in to using the blocklists we publish, but they are very welcome to use their own).