Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
message-tags without client-only tags #333
I would like the option to enable message tags such as account-tag, msgid, labeled-response, but without permitting client-only tags (+tags).
Of course, I and others can just strip client tags, executing "moderation privilege", but perhaps it would be better to indicate such a restriction in CAP so clients don't even try.
Thanks for the feedback. Can you describe your security and moderation concerns in more detail?
The whole idea behind client tags is to avoid having to wait for lengthy server software support and then network upgrade cycles for new features to be usable on IRC. Personally I think it's a wasted opportunity to just opt out of this entirely, rather than to address the concerns head on.
I do understand the cautious sentiment behind just wanting to close your eyes and opt out of it, even if it feels like a cop out to me :) So perhaps a CAP value to indicate support (or lack thereof) for +client tags might be appropriate.
Without such a value, you are absolutely welcome to add a moderation config option that removes them all. Client tags are not meant to be relied on to be visible to every other client, so there should never be a spec that's outright broken by a server filtering them entirely. But I do agree that in that case, it would be nice for clients to know that this is happening, to avoid presenting UI options to users that would never function as expected.
But I really think we need to discuss any moderation and security concerns in much more detail as well.
The problem is that client initiated tags allow an entire backchannel of about 4k per message (either through PRIVMSG, NOTICE or TAGMSG). This is a secondary information stream in the same channel that people normally won't see unless they are looking at raw IRC traffic. That is the problem and that is also the intent. Which makes it hard, if not impossible, to solve.
I'll try to bring it down to two points, (mis)using client-tags:
You cannot solve point 1 because it's a design decision to allow freeform tags and to hide them from clients that don't know these tags. I don't see any way to address this problem.
There's actually more to it than the two points raised above. Such as the question if we should want "additional" or "secondary" features to exist at all in conversations that (potentially) only a few clients will see. Leaving others out of the conversation, or these features anyway. For small things, like the previously mentioned typing indicator, that probably wouldn't matter. But for features that provide "significant enough value" other users may feel left out. They may make communication awkward because some people only see part of the conversation and I don't like that idea at all for IRC. Whether a thumbs up emoji in react qualifies for "significant" I don't know. But think of a vomiting emoji in react when someone tells he's gay, that certainly qualifies for me. You can see how that will cause havoc and confusion if only part of the channel sees it and people start swearing at the person who did the react.
Sorry but I thought this is all obvious. I assume the spec makers weighted it and considered that the "need for client-tags" outweighs the downsides. That's fine and it could very well be true in a closed business environment where people all use the same client and there are no bad guys. I certainly weigh things differently and so may various admins.
Just to be clear, this is in no way a personal attack, it's strictly technical. I know you know, so just saying it for anyone else. For some reason (on our bug tracker anyway) people often take things very personal if you don't agree with someones feature suggestion. That is just silly IMO. I'm just trying to do things in the interest of IRC, and I'm sure you do as well. We may just have different views on some issues, that's all.
I guess I'm not entirely sure what the issue is if people are using a backchannel to communicate pseudo-privately. Either it's completely hidden from everyone in which case, who cares, or it's visible to some people, in which case those people can report it to the channel/server mods who can take action. Yes, those mods would need to be aware of the use of tags and possibly be able to check/log them themselves if they want to verify the abuse. But for a real case of ongoing abuse, that should be perfectly possible. They might need a tool to do it, if their client doesn't support tags natively, but it's not completely infeasible.
But, if they don't have a tool and just don't want to deal with it at all, instead of just blocking everything on the server, why not provide channel/network admins moderation tools to block usage in a more granular way if it gets abused. Extbans and channel modes could be used, perhaps we can try to define or suggest them in the spec. Choosing mode/extban letters that everyone can use isn't really going to be feasible, but we can describe functionality.
For instance, you could have an extban like (ignore the specific letter, prefix, and format, it's an example)
You could also implement these filters/blocks at the server config level if it's a widespread issue.
Choosing to filter all tags is extreme. In order to be visible, tags will need to conform to a specific client tag spec implemented by clients, and thus you can know its name to be able to block it directly.
So yeah, I don't really accept that the moderation issue can't be addressed or solved.
So an op needs to be informed by another user that happens to support the client-tag. Then, indeed, the op needs to verify if this claim is true with a tool or whatever (unspecified how). Then the op can add an extended ban or something you suggested (complex). You can see how this isn't really working well, right?
One cannot know the name of all tags because servers just pass on any client tags. They don't maintain a list of "approved" client-tags. Quoting you (and similar text in the draft for next version):
I could comment on more (and so could you) but I think it's clear that you and I just disagree.
I think we probably agree more than you make out, I just prefer to think through the problem before we decide whether or not to formalise and encourage servers to just block client tags entirely.
There's a bit of a disconnect between the havoc you're worried about happening and the apparent lack of awareness of channel mods about who might be responsible if it were to happen, and how to respond to it. I guess my feeling is that, in a real situation where this might occur, mods will have an obvious recourse. Either they verify it's happening (possibly through other people in the channel confirming it) or they just trust the complaint and use their judgment to, yes, in probably most cases, just kick/ban that person.
The extban example I proposed is complicated, but so are many of the other extbans in existence. Chanops may or may not know how to use them, but I presume they were created to solve real problems. I'm not saying it's a trivial solution, but it is a possible one. And it's an avenue that you've even been exploring yourself recently https://forums.unrealircd.org/viewtopic.php?f=1&t=8771
You can't know the names of all tags that might possibly be used, but you can know the name of tags that are specifically being abused. The list of approved client tags is maintained here: http://ircv3.net/registry.html#tags
If a client tag is being used and is visible to users to the point that it can be abused, it's because it was specced and documented there.
Anyway, you've raised some worthwhile points, and it's definitely something that needs some thought and input from a variety of implementors. That's something I want to encourage more than just saying "yes/no we can/can't allow you to just block them all". We might even end up doing both.
Even if my knee-jerk reaction is to push for just sending everything through always, a number of networks will want to be more granular with the features they let clients use (just disregarding the spam and possible abuse issues mentioned above). Especially when we've got a major server implementer like syzop wanting to implement this but not because of the open-ended nature of it, probably means it's worth allowing some flexibility there.
I'd be fine with allowing servers to work more on a whitelist basis than a blacklist one for C2C tags.
In terms of how this could work, it's hard to communicate an amorphous whitelist or blacklist of allowed tags to clients (since that white/blacklist could grow really large). If nothing else, I'd say either silently strip the tags or send back a message which states "C2C tags were disallowed: X, Y, Z".
This line of the specification seems like it would cover not allowing client-only tags if you really don't want them. You could just throw them away after receiving them just like you do with unrecognised tags.
Indeed, @SaberUK, and:
So it shouldn't be any problem.
But yeah, as mentioned by a number of people it would still be a good idea to advertise this in advance to the client. As someone said, the client can then disable certain UI elements (like react, for example). And of course, it would reduce needless traffic (data that won't be used anyway).
It can be a CAP but it could also be ISUPPORT since client tags can never occur in the handshake, right? Or is there a situation, maybe not now but in the future, that they might be? Like, I don't know, client tags suddenly appearing in an AUTHENTICATE command or something.
Anyway, so there may be a few cases:
Here is an example using a whitelist approach:
Here is an example using a blacklist approach:
As you can see I'm getting some help from the
Those are just some quickly sketched ideas, feel free to throw in others. The only thing that matters is that it would be nice to indicate the 4 cases previously mentioned in some way to the clients (or 3 cases, if you think the advertising should be omitted in 1 of the 4 cases, eg for the allow-all-case)