No-log channel metadata key

[jwheare]

Channel owners might want to indicate to clients (particularly those that log everything in the cloud™) that they don't want their channel to be logged, to protect the privacy of their users.

Would a metadata key like nolog, nostore, etc, etc, or something make sense? I feel like channel modes are a bit of a dead-end for standardisation at this point, until we have something like named modes and a registry in place.

It would be on the honour system, but might still be a feature that privacy-minded clients would want to implement.

One obvious issue is that a user might immediately want to override such a setting and log anyway, if they disagree with the channel policy and rely on logs for their own reasons. Would that be an issue?

As long as the default behaviour of a client was to not log, channel owners might be satisfied that it's still a useful mitigation. Of course, you can't prevent all logging as long as people are able to copy/paste, but mitigation may still be worthwhile.

Any thoughts?

[DanielOaks]

I like the idea. Can make for a nice "please do this", but certain clients are gonna override it anyways. I wouldn't consider it an issue and think it's fine to throw in the metadata registry once the spec issues around metadata itself are all resolved.

[pinkgothic]

I'd be very interested in this - perhaps ironically due to IRC's multi-client nature, combined with its history of appearing as though one is speaking to a limited audience.

Some Background a/k/a "Why would you want this?"

From the "bad guys'" perspective, personal IRC logs have historically been highly distributed, without a convenient, single place to attack as to be able to access a large amount of logs. Even if someone wanted to save their data on a server they owned, that information was typically opaque, and the scattered nature remained. But this is changing - various HTTP proxies for IRC also come with bouncer services and an indefinite backlog, as long as one pays the bills for them, and their attractiveness as a target for attempts of (unauthorised) data mining is regrettably proportional to their popularity.

The old feeling "as long as I trust the people in the channel, I can say whatever I want" no longer seems to apply if we look at the technical circumstances (even to channels where all users are connected using TLS), but this is still very prevalent attitude. If a popular logging service is hacked five years down the line (despite going to great lengths to prevent breaches), I suspect a lot of very embarrassing, blackmail-worthy data will be in the hands of whoever exfiltrated the data.

Due to the varied clients that can connect to IRC, it might be a complete surprise even to the people affected that their data was ever on those breached servers in the first place. At the moment, knowing oneself to be at risk requires that one is (1) conscious of this potential issue, (2) aware of all popular logging services, and (3) willing to check what IRC clients all users in a particular channel are using any of those services.

A way to mark a channel as "please don't log this channel" would definitely help - hopefully, compliance with it would also be proportional to the popularity of the logging service. :)

Honour system

The possibility of overriding the preference in general doesn't necessarily null the value of the flag - people have logged IRC since the dawn of time, after all. What's changed is the centralised nature of services; and compliant services that know themselves a juicy target should probably not allow overriding the setting, leaving it to users to copy&paste if they really want to (and thus reintroducing the scatteredness of the logs).

I could even imagine quasi-compliance in the form of deletion-after-a-time, e.g. the service does log the data, but discards it after a week / a month / some other timespan they consider reasonable - this would still give the user e.g. some backscroll convenience, but offer some to significant protection from the problem described.

Flag Name

Not picky, those proposed so far are great. :) I like nostore as (to me) it insinuates the purpose of the flag better than nolog, but it's not important. nopersist also comes to mind as a possibility.

Thanks for hearing this idea out!

[KoraggKnightWolf]

I think on our own network we have found somewhat of a solution given two modules and our setup. We are operating InspIRCd 2.0 in the latest release version as of the time of thos post. The crux is combining two modules to gain the effect via a sensible config setup, the modules being m_classban and m_bannegate found at https://github.com/inspircd/inspircd-extras/blob/master/2.0/m_classban.cpp and also at https://github.com/inspircd/inspircd-extras/blob/master/2.0/m_bannegate.cpp respectively,

I will elabroate what these modules will do and how this is combined with the config setup.

From here on, I will refer to all BNC's and/or clients that log "into the could" and are shared by a multitude of people as public bouncers.

The config allows us to give IP's/hosts so called classes this is commonly used for session limit increases (also known as I-Lines occasionally). Every publicly used bouncer's IP/host address must be put into its own connect class (means each connect class can only contain EXACTLY ONE host OR IP address). This procedure would be followed for every publicly used bouncer (or at least those known to frequent the network or that might at some point in the future).

There is a connect class for in genereal all connections, from hereon referred to as main or the main class. This is used for pretty much any other connections (users, opers who do not require a session limite increase) thus by pretty much all who do not use a public bouncer and do not need more than the standard amount of connections.

The m_classban module implements an extban char that allows to set bans on individual connect classes. Now of course not every channel operator would know every single connect class especially as there are always more and more public bouncers coming and going (and it might be not good to disclose this information to users but this potential security concern is not for this discussion and will also not be releveant for this post).

This is where m_bannegate comes into play: As this functionality might already be known from other IRCd's, like charybdis and/or ircd-seven it bans the oppostie of the given banmask.

Now, back to the "but channel operators cannot/should not know every single connect class in the config!". With bannegate combined with the connect class extended ban, one would only need to know the main connect class, in most cases (at least on InspIRCd) called main.

As this is also a config default and would not need to be hidden as it applies to pretty much anyone, it can be disclosed.

Thus combining all of these ideas, if we say I am a channel operator and wish to keep all public bouncers out of #channel I will simply use /mode #channel +b ~n:main

With the ban set above, all public bouncers would be incapable of entering. The reason, sumemd up, is because they need session limit increases and for this must have their own connect class thus they will not be in the main connect class.

This is of course only a channel wide option and it is not perfect by any means but it addresses the issue at least to a degree.

I hope this poste can be of at least some benefit to others out there, at least to those who operate an IRCd similar to ours or even the same one.

Also please point out when/how this method would fail as I have not given it a field test yet and would love to know what to look out after/be prepared for. (The "but what if a public bouncer is forgotten to be added" shall be left out as this is one that has been taken into consideration and is not a technical fallady but just us opers not acting fast enough).

Thank you in advance for at least rading this post and I hope that at least someone has some ideas about how to implement this idea as it appears to be a very good one.

Regards,

Koragg

[KoraggKnightWolf]

As a tested and confirmed addition: The m_classban mdule can also take wildcards, allowing a channel operator to also simply ban just specific bouncers while allowing in others (given that the connect classes for public bouncers always have a name relating to the respective public bouncer(s)). This allows for a very fine graind control which public bouncers may join the channel, if any and if yes, which ones specifically.

Once again, thank you very much for your attention in advance and for helping to push IRC forward constantly.

Regards,

Koragg