message-tags without client-only tags

[syzop]

I would like the option to enable message tags such as account-tag, msgid, labeled-response, but without permitting client-only tags (+tags). In my opinion, I as a server software maker and server admins should have this option. There's a significant difference between allowing server initiated message tags (like msgid) and client initiated tags that are passed to other users. Such client initiated tags allow an entire backchannel of about 4k per message (either via PRIVMSG, NOTICE or TAGMSG) that nobody normally sees unless they are looking at raw IRC traffic. From a security and moderation point of view I don't like that at all.

So:

• Would that be an option?
• Am I the only one thinking this?
• What would be the best way to communicate this?

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.

[jwheare]

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.

[syzop]

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 can have an entire discussion/communication in channel that others don't see: this poses a moderation problem
• You can flood the channel which nobody will see: this poses a security problem

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. You can use flood protection to partially limit point 2 (obviously, anyone not doing flood protection is an idiot), but that doesn't help any if you stay below the flood threshold. It's also very hard to establish a flood threshold at all since you don't know for what client tags will be used. It could be used for anything. If you knew beforehand it would be for rare events you would set the limits "tight", but they could just as well be used for typing indicators or whatnot which would mean you would have to set them very "loose".

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. Also, I wasn't planning to make this a "why I think this idea is bad" thread (hence my limited opening post). But, since you asked.. :D

[jwheare]

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)

~C (for Client tag, using unreal's prefix style)
~C:type:tag:value:mask

// Remove all reaction tags for all users
+b ~C:filter:draft/react:*:*
// Block any message with a reaction tag matching vomit
+b ~C:block:draft/react:*vomit*:*
// Filter all tags for a specific user
+b ~C:filter:*:*:troll!*@*
+b ~C:filter:*:*:~a:troll_account

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.

[syzop]

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? I think your suggestion MAY work in case clients - including the op - do support the client-tag and see (for instance) the react. Then they could use your suggested extban straight away. Though, honestly, I would just kick or ban the user. And I have my doubts if users/ops will understand how to use the extban. But I don't agree your suggestion adequately fixes any of the previously mentioned issues. So the case where only part of the users see the messages and it doesn't solve the flood issue. (Well, okay, it does solve them if you add a filter banning all client-tags)

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.

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):

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.

I could comment on more (and so could you) but I think it's clear that you and I just disagree.

[jwheare]

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

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.

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.

[DanielOaks]

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".

[SadieCat]

To avoid abusive content being sent in client-only tags, servers, services and management bot implementations may wish to enable moderation features that act on tag content as well.

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.

[syzop]

Indeed, @SaberUK, and:

There is no guarantee that other clients will support or display the client-only tags they receive, so these tags should only be used to enhance messages with non-critical information. Messages should still make sense to clients with no support for tags.

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. If you do have doubts, then go with CAP, if you are sure it won't ever.. then go with ISUPPORT I'd say. Or actually I don't care at all ;)

Anyway, so there may be a few cases:

• Server allows all client tags
• Server disallows all client tags
• Server allows some client tags
• Server disallows some client tags

Here is an example using a whitelist approach:

• Server allowing all client tags: client-tags=*
• Server disallowing all client tags: client-tags=!* or an empty one? client-tags=
• Server allowing only a subset of client tags: client-tags=+typing,!*
• Server disallowing some client tags: client-tags=!+typing,*

Here is an example using a blacklist approach:

• Allowing all: do not advertise banned-client-tags, or show empty set: banned-client-tags=
• Disallowing all: banned-client-tags=*
• Allowing only a subset: banned-client-tags=!+typing,*
• Disallowing some: banned-client-tags=+typing

As you can see I'm getting some help from the ! operator here. Maybe there is a better way.

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)

[jwheare]

Closing in favour of #410 to work out a concrete solution to this.