Gentlebeings,

I would like to describe an enhancement to the NNTP protocol, with a view
to peer review.

# Rationale

I began using Usenet in about 1994. It was a remarkable forum -
possessing the property of being both public and yet private, as at that
time no one was archiving posts.

I may be wrong, but I think the property of being public and yet private
nature of Usenet was special and of particular value.

I would like to recreate that property of being public and yet private,
which is exactly to say that posts can be read by and only by a given
group of readers. The news-servers cannot read posts, nor can anyone
outside of that group of readers - so no archiving by Google, or anyone
else.

# Design

The mechanism for this then centers on the use of private-public key
pairs, and the introduction of a new type of moderation.

Moderation exists already in Usenet, and it is at the level of posts being
made to a group. Anyone can read any post in any group, but only those
posts approved by moderators can be posted.

I propose then a second form of moderation, which is and is only
moderation of what is in effect membership of a group - members are able
to read and post, non-members cannot read or post.

We begin with an empty newsgroup, with a moderator of the new type.

For a user to subscribe, they create a private-public key pair and provide
the *public* key to the moderator.

If their application is approved by the moderator, the public key is then distributed to all current members of the group.

All members hold then the public key of all other members.

It is possible to encrypt messages using more than one public key.

When a member posts, the post is encrypted by the NNTP client with the
public keys of every existing member, and then posted.

As such, the and the only people who can read that post are the existing members; they can all decrypt the message using their own private key,
which is secret to them.

The news-servers cannot decrypt posts, non-members cannot decrypt posts;
both can see and only see the encrypted text.

As such, when a post is made, only the current group of subscribers can
decrypt the post.

When a new member subscribes, they will be able to read posts only from
the moment of their subscription onwards; they will not have access to historical posts. A posting could be made into a group to alert all users
of a new subscriber, to allow for care in posting until that subscriber is trusted by the community.

Killfiles also develop new powers, as a news client can *not* encrypt a
post with the public key of members in the posters killfile. Killfiles
then would stop not only seeing the posts of those in the killfile, but
would also prevent those in the killfile from reading the posters posts.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

For your reference, records indicate that
Bixby <bixby@sctb.ch> wrote:

I began using Usenet in about 1994. It was a remarkable forum -
possessing the property of being both public and yet private, as at that
time no one was archiving posts.

Well, you’ve already started out with a false premise. Whenever it was Google acquired whatever archive they initially seeded Google Groups with,
I was able to find a post of mine from 1991. Just because the data isn’t widely available doesn’t mean it is “private”, and a good argument could be made that, in the wrong hands, that kind of data *held in private* is
the very opposite of *private*.

I would like to recreate that property of being public and yet private,
which is exactly to say that posts can be read by and only by a given
group of readers. The news-servers cannot read posts, nor can anyone
outside of that group of readers - so no archiving by Google, or anyone
else.

Again, false premise. Encrypted messages can be archived the same as any
other data. Whether or not there is *value* in that is another question,
and may depend very much on how long it takes for the encryption algorithm
to be broken or otherwise compromised. The most likely scenario is that
some side-channel attack will allow the plaintext message to be gotten
from one of the “given group”.

The mechanism for this then centers on the use of private-public key
pairs, and the introduction of a new type of moderation.

It’s not clear where you’re going here. I mean, you have yet to say
what will actually change about NNTP protocol itself. Encrypted
messages are nothing new or special; I recall encountering more than
one post to binary newsgroups back in the day that was encrypted, and presumably that still happens today.

I propose then a second form of moderation, which is and is only
moderation of what is in effect membership of a group - members are able
to read and post, non-members cannot read or post.

Not sure how that fits your initial definition of “public”.

It is possible to encrypt messages using more than one public key.

When a member posts, the post is encrypted by the NNTP client with the
public keys of every existing member, and then posted.

I’m no cryptography expert, but my understanding is that things aren’t generally done that way. Rather, the message is encrypted only once with
a strong symmetric cipher, and then just that key is encrypted with the
public keys of the intended recipients.

The news-servers cannot decrypt posts, non-members cannot decrypt posts;
both can see and only see the encrypted text.

As such, when a post is made, only the current group of subscribers can decrypt the post.

Still not seeing the “public” aspect of this. Still not seeing any change to the NNTP protocol.

When a new member subscribes, they will be able to read posts only from
the moment of their subscription onwards; they will not have access to historical posts. A posting could be made into a group to alert all users
of a new subscriber, to allow for care in posting until that subscriber is trusted by the community.

What’s the point? What do the existing members get out of having to deal with a stream of untrusted newcomers? What would new members expect to
be getting out of a group that has no other history than a bunch of
random data? Why is anybody participating in any of that?

Killfiles also develop new powers, as a news client can *not* encrypt a
post with the public key of members in the posters killfile. Killfiles
then would stop not only seeing the posts of those in the killfile, but
would also prevent those in the killfile from reading the posters posts.

I assure you that, despite my intensive use of filtering, I still see the
posts of *far* too many people I’m trying to ignore because other people continue to feed the trolls. Your scheme doesn’t change that.

Everything you suggest still seems like it could be layered on top of the
NNTP protocol as it already exists. People aren’t already regularly doing that because the result is far less useful than the existing public forum.

--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/8/23 14:01, Bixby wrote:

Gentlebeings,

I would like to describe an enhancement to the NNTP protocol, with a view
to peer review.

# Rationale

I began using Usenet in about 1994. It was a remarkable forum -
possessing the property of being both public and yet private, as at that
time no one was archiving posts.

I may be wrong, but I think the property of being public and yet private nature of Usenet was special and of particular value.

I would like to recreate that property of being public and yet private,
which is exactly to say that posts can be read by and only by a given
group of readers. The news-servers cannot read posts, nor can anyone
outside of that group of readers - so no archiving by Google, or anyone
else.

# Design

The mechanism for this then centers on the use of private-public key
pairs, and the introduction of a new type of moderation.

Moderation exists already in Usenet, and it is at the level of posts being made to a group. Anyone can read any post in any group, but only those
posts approved by moderators can be posted.

I propose then a second form of moderation, which is and is only
moderation of what is in effect membership of a group - members are able
to read and post, non-members cannot read or post.

We begin with an empty newsgroup, with a moderator of the new type.

For a user to subscribe, they create a private-public key pair and provide the *public* key to the moderator.

If their application is approved by the moderator, the public key is then distributed to all current members of the group.

All members hold then the public key of all other members.

It is possible to encrypt messages using more than one public key.

When a member posts, the post is encrypted by the NNTP client with the
public keys of every existing member, and then posted.

As such, the and the only people who can read that post are the existing members; they can all decrypt the message using their own private key,
which is secret to them.

The news-servers cannot decrypt posts, non-members cannot decrypt posts;
both can see and only see the encrypted text.

As such, when a post is made, only the current group of subscribers can decrypt the post.

When a new member subscribes, they will be able to read posts only from
the moment of their subscription onwards; they will not have access to historical posts. A posting could be made into a group to alert all users
of a new subscriber, to allow for care in posting until that subscriber is trusted by the community.

Killfiles also develop new powers, as a news client can *not* encrypt a
post with the public key of members in the posters killfile. Killfiles
then would stop not only seeing the posts of those in the killfile, but
would also prevent those in the killfile from reading the posters posts.

Would it be possible to encrypt messages with a key?
--
user <candycane> is generated from /dev/urandom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 8 Nov 2023 20:01:59 -0000 (UTC)
Bixby <bixby@sctb.ch> wrote:

<snip>

What you describe already exists in a well-designed form: Bitmessage.

Bitmessage has chans, which are similar to newsgroups. You can subscribe
and unsubscribe to chans by keyword. Bitmessage also has:

- public chans
- secret chans
- distributed mailing lists
- encrypted private messaging
- mailchuck remailer forwarding
- whitelisting and blacklisting
- uncensorable broadcasts

Homepage: https://bitmessage.org

Downloads:

- Binary (64bit, no separate installation of dependencies required)
- Windows: https://download.bitmessage.org/snapshots/
- Linux AppImages: https://artifacts.bitmessage.at/appimage/
- Linux snaps: https://artifacts.bitmessage.at/snap/

Detailed install instructions: https://github.com/Bitmessage/PyBitmessage/blob/v0.6/INSTALL.md

Instead of a central moderator, users moderate by using the whitelist
or blacklist functions. The whitelist is useful for blocking all
messages by default except for those coming from addresses added to the whitelist.

It also has uncensorable broadcasts, which are very useful for at-risk
persons who need to get information out on the wire without doxing
themselves. Communicants can share secret broadcast addresses or secret
private addresses for high-security messaging. Secret chans can also be
created using strong passphrases for discussing sensitive topics.

Some Usenetizens already chat via Bitmessage. The chan
'alt.anonymous.messages' has been in continuous use for years.

Here is copypasta of some public chans:

# Categorical List of Bitmessage Chans

### usual chans:

bitmessage general hello

### app chans:

bitboard freshmeet

### protocol chans:

fediverse tildeverse bbs usenet gopher

### usenet chans:

alt.anonymous.messages alt.privacy.anon-server sci.crypt

### encryption chans:

PGP alt.anonymous.messages insurance crypto

### hacker chans:

blackhat dump hamburglar hispagatos leaks linux

### crypto-currency chans:

Bitcoin Monero

### crypto-anarchy chans:

Crypto-Anarchist Federation cypherpunk

### shitposter chans

helicoptarian

### number chans:

0 1776 19 1984
33 3301 411 711
8200 9 911 numberstation

--
Baggy Jeans Mafia | https://syfershock.com/users/syfershock

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 8 Nov 2023 20:01:59 -0000 (UTC), Bixby wrote:

I may be wrong, but I think the property of being public and yet private nature of Usenet was special and of particular value.

*sigh* =-)

Proof-read all you like, there's always stuff you'll only see once you've posted.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Doc O'Leary , <droleary@2017usenet1.subsume.com> writes:

For your reference, records indicate that
Bixby <bixby@sctb.ch> wrote:

For a user to subscribe, they create a private-public key pair and provide >> the *public* key to the moderator.

If their application is approved by the moderator, the public key is then
distributed to all current members of the group.

All members hold then the public key of all other members.

[...]

It is possible to encrypt messages using more than one public key.

When a member posts, the post is encrypted by the NNTP client with the
public keys of every existing member, and then posted.

I’m no cryptography expert, but my understanding is that things aren’t generally done that way. Rather, the message is encrypted only once with
a strong symmetric cipher, and then just that key is encrypted with the public keys of the intended recipients.

Yes and no - when you’re looking at how asymmetric encryption of a
nontrivial message works, it does involve establishing symmetric session
keys and then encrypting the full message with those. But from a
higher-level viewpoint we’d still say that e.g. ECIES was “encrypting
with the recipient’s public key” rather than breaking it down into its constituent parts every time we mentioned it.


There are some challenges to work through.

First in the design as stated, the number of public key operations for
each message (point multiplications, modexps, or stranger PQC
operations) scales according to the number of recipients. Modern
computers are fast enough that with small groups of recipients this
isn’t a big deal but at some point your computer is spending rather a
lot of its time on the cryptography; latency will suffer too.

Second the security of the whole system depends both on the
trustworthiness of the moderator and their competence in selecting
recipients. Even assuming the moderator is trustworthy, as the number of recipients grows, the probability that one of them is one of the group’s adversaries grows with it.

In that case the value of the cryptography starts to fall (although not necessarily to zero, depending on the priorities of the group members,
the nature of the adversary, etc).

--
https://www.greenend.org.uk/rjk/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 09 Nov 2023 10:25:16 +0000, Richard Kettlewell wrote:

First in the design as stated, the number of public key operations for
each message (point multiplications, modexps, or stranger PQC
operations) scales according to the number of recipients. Modern
computers are fast enough that with small groups of recipients this
isn’t a big deal but at some point your computer is spending rather a
lot of its time on the cryptography; latency will suffer too.

Yes. This is an open question. How long would it take to encrypt a post
to a group with a hundred subscribers? or a thousand? or ten thousand?
could it be there must be limits to the number of subscribers?

Second the security of the whole system depends both on the
trustworthiness of the moderator and their competence in selecting recipients. Even assuming the moderator is trustworthy, as the number of recipients grows, the probability that one of them is one of the group’s adversaries grows with it.

Yes. Moderators as they exist now must be trusted in much the same way.
With regard to the inadvertant acceptance of subscription from an
adversary, there is some protection in that posts can be read only from
the time of subscription onwards. When there is a new subscriber, there
can be a post to the group, and users can moderate their posting until
trust is built up, and also individuals can at their own discretion choose
not to encrypt using the public key of any given member, and so if they
are unsure, they can hold off until they are more comfortable - perhaps
here we can imagine a feature, where-by users indicate to their client a
post is sensitive, and then it encrypts using the public keys only of
members who have subscribed for a given period of time, or a particular
subset of subscribers.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bixby <bixby@sctb.ch> writes:

On Thu, 09 Nov 2023 10:25:16 +0000, Richard Kettlewell wrote:

Second the security of the whole system depends both on the
trustworthiness of the moderator and their competence in selecting
recipients. Even assuming the moderator is trustworthy, as the number of
recipients grows, the probability that one of them is one of the group’s >> adversaries grows with it.

Yes. Moderators as they exist now must be trusted in much the same way.

Not reallty, moderators in the present system have no impacted on
privacy (because there isn’t any).

With regard to the inadvertant acceptance of subscription from an
adversary, there is some protection in that posts can be read only from
the time of subscription onwards. When there is a new subscriber, there
can be a post to the group, and users can moderate their posting until
trust is built up, and also individuals can at their own discretion choose not to encrypt using the public key of any given member, and so if they
are unsure, they can hold off until they are more comfortable - perhaps
here we can imagine a feature, where-by users indicate to their client a
post is sensitive, and then it encrypts using the public keys only of
members who have subscribed for a given period of time, or a particular subset of subscribers.

So:
- every participant must somehow decide whether every other participant
is really an attacker, not just the moderator
- discussion is inherently fragmented

--
https://www.greenend.org.uk/rjk/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 09 Nov 2023 13:40:03 +0000, Richard Kettlewell <invalid@invalid.invalid> wrote:

Bixby <bixby@sctb.ch> writes:

On Thu, 09 Nov 2023 10:25:16 +0000, Richard Kettlewell wrote:

Second the security of the whole system depends both on the
trustworthiness of the moderator and their competence in selecting
recipients. Even assuming the moderator is trustworthy, as the number of >>> recipients grows, the probability that one of them is one of the group�s >>> adversaries grows with it.

Yes. Moderators as they exist now must be trusted in much the same way.

Not reallty, moderators in the present system have no impacted on
privacy (because there isn�t any).

With regard to the inadvertant acceptance of subscription from an
adversary, there is some protection in that posts can be read only from
the time of subscription onwards. When there is a new subscriber, there
can be a post to the group, and users can moderate their posting until
trust is built up, and also individuals can at their own discretion choose >> not to encrypt using the public key of any given member, and so if they
are unsure, they can hold off until they are more comfortable - perhaps
here we can imagine a feature, where-by users indicate to their client a
post is sensitive, and then it encrypts using the public keys only of
members who have subscribed for a given period of time, or a particular
subset of subscribers.

So:
- every participant must somehow decide whether every other participant
is really an attacker, not just the moderator
- discussion is inherently fragmented

in active unmoderated public newsgroup forums, lurkers probably outnumber contributors (discounting spammers), thus increasing trust levels because
even the slightest error, intentional or otherwise, is more likely to get noticed and elicit helpful replies from less partial more objective users; whereas secluded discussions are less scrutinized and more prone to error

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 9 Nov 2023 01:17:10 -0600, Sugar Bug <3883@sugar.bug> wrote:

On Wed, 8 Nov 2023 20:01:59 -0000 (UTC)
Bixby <bixby@sctb.ch> wrote:
<snip>
What you describe already exists in a well-designed form: Bitmessage. >Bitmessage has chans, which are similar to newsgroups. You can subscribe
and unsubscribe to chans by keyword. Bitmessage also has:
- public chans
- secret chans
- distributed mailing lists
- encrypted private messaging
- mailchuck remailer forwarding
- whitelisting and blacklisting
- uncensorable broadcasts
Homepage: https://bitmessage.org

such open encryption might work for "public yet private" purposes?
as a casual user of remailers for posting to newsgroups, "privacy"
is a simple matter, because none of the plain text content posted
to these unmoderated newsgroup forums requires decryption to read;
but some users may have more serious concerns about prevention of "unauthorized" access to unencrypted content regardless of format
or function, in such cases "whole message encryption" is strongly
recommended . . . see https://www.danner-net.de/omom/tutorwme.htm

OmniMix * Tutorial * Whole Message Encryption (WME) PreviousTopNext
It's obvious to prevent your normal e-mail correspondence from being
spied on by encrypting it with PGP. If the messages include attachments,
you have to encrypt those as well. But there are parts of your message
you can't hide this way, like its size, the subject, some language
specific characteristics, and last, not least the fact of sending a >multi-part message. That's where OmniMix's 'Whole Message Encryption'
comes to your aid.
Different from PGP frontends, which only allow to manipulate your
message before being sent by the mail client, a proxy server like
OmniMix is able to alter it as a whole, as long as the result remains
a compatible mail. Provided that the PGP keys of all recipients of a
mail are available, OmniMix can be advised to encrypt the entire
message, including the complete header section and some random dummy
data to disguise its real size, into one single PGP message block and
send it by means of a rudimentary header, which has to contain nothing
but the mail addresses and maybe some 'X-Hashcash' tokens. If it's sent
via a nym server an existing 'Nym-Commands' directive is also moved
outside the WME encryption block, but for reasons of security this
doesn't matter, as the message in any case is additionally encrypted
with the server's key. For an adversary, who's allowed to become
acquainted with the identity of the correspondents, the result of this >procedure is nearly worthless.
Moreover OmniMix even supports sending WME messages anonymously, which >usually isn't done to hide your identity from the recipients within
your WME community, but to prevent external observers from figuring
out the communication partners. Keep in mind, that the data within the
WME block aren't anonymized, but, though maybe shortened dependent on
an active 'Mail Permits' header filter list, handled like normal mail.
In order to allow an unrestricted, transparent communication without
adverse effects for the participants, among other things there's still
your 'From' address - which may be bogus - and the 'Message-ID'. If
the former can be found on the WME recipients list with 'Sign'
activated, the resulting signature may also expose your identity to
those who are able to decrypt the message. So check what gets
encrypted at the 'Data for Whole Message Encryption' section of the
'Raw Data' list as well as the 'Log' entries to assure yourself that
no sensitive data are unintentionally revealed to the addressees!
Caution: Don't send an anonymous mail to several addressees at a time
if you don't want them to become linked! In this case send a separate
one to each of them.
The recipients then either have to decrypt the PGP block manually and
import the result into their mail user agents, which certainly can
only be accepted in exceptional cases. On the other hand OmniMix can >automatically translate the messages back into their original state
in the course of its retrieval from the POP3 server, as far as the >corresponding secret PGP key and the correct passphrase are placed
at its disposal.
At the 'Dummy Load' page of the 'WME' section you're able to randomly >increase the size of your mail. This measure prevents adversaries
from estimating the kind of message, whether it's about a usually
shorter text or a more voluminous data transfer. Request a message-
specific dummy load by sending the desired block size range >('O-Wme-Dummy-Size-Min' and 'O-Wme-Dummy-Size-Max' header entry)
with your message. Values higher than the maximum block size defined
within OmniMix are refused, as the processing of a message extreme
in size may knock out your system. OmniMix now appends a random text
block to your message introduced by a line with a unique character
sequence. The contents of that indicator line is added to the message
header as the argument of an 'X-Wme-Dummy-Separator' entry in order
to allow the recipient's system to restore the original message by
removing the dummy load. It's important, that the dummy separator
header is named equally at the sender and recipient, as otherwise
the addressee won't be able to restore the original message.
Pros and cons of different communication methods
Ordinary PGP WME Remailing Remailing Nym Nym
Mail + WME + WME
Contents Protection No Reduced* Complete* No Complete* No Complete*
Reply Capability Yes Yes Yes No Yes Yes Yes
Anonymity towards an external observer No No No Yes Yes Yes Yes
Anonymity between the correspondents No No No Yes No Yes Yes
Latency Low Low Low Medium Medium High High
Reliability High High High Medium Medium Low Low
* Reduced: Net data only / Complete: Data + structure
The first step to set up WME is to add all required keys to the 'WME'
keyring ('WME' tab within the 'Nym Configurator'). You have to import
public keys for your correspondents and one or more public / secret
keypairs for yourself. Don't use any of your very secret PGP keys for
that transmission purpose, as its passphrase has to be stored on your >computer and both can be stolen by anyone who gets access! Better
create new keys and mark them with names, that point out their low-
security use, e.g. by adding the character sequence '(WME)' to the
User-ID. As decryption problems can't be ruled out otherwise, it's >recommended to create your keys within OmniMix itself.
You may notice that the WME section offers a greater variety of
partly more secure encryption and hash algorithms than allowed for
nym accounts. That's because there's no need to consider the
capabilities of remailers and nym servers.
Next is to go to the 'WME' tab of the main window and add the mail
addresses of all participants in your WME network to the list along
with the corresponding key and - if it's a private key of your own -
the passphrase. Based on this list, if WME is active, all mails,
whether sent normally or by one of your nyms, are examined for the
presence of corresponding encryption keys. If OmniMix finds keys for
all 'To:' and 'Cc:' recipients and there are no 'Bcc:' recipients
(who would be uncovered by an encryption using their keys), the mail
gets encrypted and only header data mandatory for delivery are left
outside the protected block. At request the sender's signature is
added in the course of the encryption to prove the authenticity of
the sent mail.
Finally you have to tell OmniMix, who's allowed to use the single
private key / password combinations to sign outgoing and decrypt
incoming WME mails. Therefore go to the 'User' tab and mark for
every user the 'WME' mail addresses that belong to that account.
Now you've finished. All outgoing mails are processed dependent on
the WME mode ('WME' tab, 'disabled' / 'enabled' / 'required'). If a
message has to depart from that rule, then use the according header >directive. 'O-WmeSend-Mode: required' e.g. rejects a message that
can't be WME encrypted, with 'O-WmeSend-Mode: disabled' you would
even be allowed to send a usual anonymous mail to someone whose key
is present at the WME keys list. The 'Sign' setting within the WME >participants list is binding in any case. Therefore, if signatures
are requested, the WME encryption has to fail as long as the
password isn't properly set for the WME key or the WME item isn't
assigned to the user account.

[end quote]

https://www.danner-net.de/om.htm
https://www.danner-net.de/omom/index.htm https://www.danner-net.de/om/OmniMix_2.7.0_Uno_Setup.exe (OmniMix_2.7.0_Uno_Setup.exe; 29.6 MB)
https://www.danner-net.de/om/History.txt

...
2.6.6 Bugfix: Size of Yamn Stats ListBox corrected.
Button to reset Tor status and thereby change the entry guard added.
Log list now also shows Tor startup parameters.
Tor updated to a modified version 0.4.8.0-alpha-dev (git-b733f9d6ace63c71)
custom build, which allows a variable circuit length from 2 to 9 nodes
(including respective OmniMix controls), and, in order to keep the TorIp
feature functional, removes the IP address retrieval ('getinfo address')
restrictions now providing also client instances with their IP address.
Path to location of GeoIP/GeoIPv6 files added to Tor's torrc configuration
file, obsolete 'CircuitIdleTimeout' parameter removed.
2.6.7 Bugfix: O-Newsgate-Number header switch had no effect on nym postings'
number of mail2news gateways.
Due to steadily shrinking remailer networks default value for parameter
MAXLAT increased from 2 to 3 and DISTANCE decreased from 20 to 4.
2.6.8 Tab dimensions reshaped to meet Linux Wine requirements.
2.6.9 Bugfix: Check of NNTP/SMTP/POP3 server login conditions revised with
Authentication mode option None removed.
Bugfix: File hash protection now ignores XP specific Tor .DLL files in
other Windows versions.
Switch for de-/activation of Tor safelogging of IP addresses added.
MINREL decreased from 97 to 95.
Tor updated to a still customized version 0.4.8.5 (git-4fc1bb3e86b263aa).
2.7.0 Bugfix: A concurrent access to the OmniNym .ini file while closing the Nym
Configurator led to an application crash.
At the Nym Configurator m2n@neodome.net added to the nym reply mail2news
default list.

[end quote]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 09 Nov 2023 13:40:03 +0000, Richard Kettlewell wrote:

Bixby <bixby@sctb.ch> writes:

Yes. Moderators as they exist now must be trusted in much the same
way.

Not reallty, moderators in the present system have no impacted on
privacy (because there isn’t any).

I mean in the sense that trust has to be placed in the moderators. Not
the particular purpose of that trust.

With regard to the inadvertant acceptance of subscription from an
adversary, there is some protection in that posts can be read only from
the time of subscription onwards. When there is a new subscriber,
there can be a post to the group, and users can moderate their posting
until trust is built up, and also individuals can at their own
discretion choose not to encrypt using the public key of any given
member, and so if they are unsure, they can hold off until they are
more comfortable - perhaps here we can imagine a feature, where-by
users indicate to their client a post is sensitive, and then it
encrypts using the public keys only of members who have subscribed for
a given period of time, or a particular subset of subscribers.

So:
- every participant must somehow decide whether every other participant
is really an attacker, not just the moderator
- discussion is inherently fragmented

For the first point, by and large, I imagine users posting to all
subscribers - trusting the moderator. What I note here is that
subscribers control the privacy of their own posts, and so would have the option should they come to disagree with the moderator to themselves
prevent the subscriber in question from reading their posts.

For the second, yes, but when and only when such behaviour occurs. I
would think by and large it would not be common. Thinking back to when I posted regularly, to unmoderatored groups, I can think of one person I
would have blocked in that way (someone who was abusing the group, and I suspect who was in most killfiles).

There are many problems which can occur, but most never do.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 9 Nov 2023 15:22:38 +0100 (CET), D wrote:

in active unmoderated public newsgroup forums, lurkers probably
outnumber contributors (discounting spammers),

Regarding this, of course, we can still have public posts, unencrypted, or encrypted with a generally available key.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bixby <bixby@sctb.ch> writes:

I propose then a second form of moderation, which is and is only
moderation of what is in effect membership of a group - members are able
to read and post, non-members cannot read or post.

We begin with an empty newsgroup, with a moderator of the new type.

For a user to subscribe, they create a private-public key pair and
provide the *public* key to the moderator.

If their application is approved by the moderator, the public key is
then distributed to all current members of the group.

All members hold then the public key of all other members.

It is possible to encrypt messages using more than one public key.

When a member posts, the post is encrypted by the NNTP client with the
public keys of every existing member, and then posted.

As such, the and the only people who can read that post are the existing members; they can all decrypt the message using their own private key,
which is secret to them.

If I understand this correctly, you have a forum with the following
properties:

1. A forum with a limited audience, requiring people to join before they
are able to receive the messages.

2. A central point of authority who decides who should receive the
messages.

3. An automatic system for distributing new messages to all current known
recipients.

This is indeed a useful system, but I'm not sure why you would use NNTP to implement it, since at first glance it sounds like a mailing list. NNTP's flood-fill algorithm is incredibly wasteful in this system, since it would
send the messages to loads of people who can't read them.

Encrypted mailing lists that work roughly the way that you describe are
already a thing, although instead of encrypting at the NNTP client, they usually decrypt and re-encrypt at the mailing list host. I realize you
may view that as undesirable and want to instead encrypt at the client,
and that makes sense given your use case, but at the point that you're
already expecting a client to track user public keys, tracking email
addresses to which to send the messages is a trivial amount of additional
work.

I'm guessing that the appeal of NNTP in your design may be that you feel
like email addresses expose too much personal information about the
recipients? I'm a bit dubious of that belief, but I realize this is a dearly-held belief in some quarters. So maybe the role of NNTP in this
model is something akin to the old anonymous remailer network? I guess
that would make sense; there are some systems like that where the point is
to waste so much resources that it's hard to find the signal in the noise,
as a way of defeating metadata analysis.

There have been a lot of proposals somewhat similar to this over the
years, and I've heard (but have never looked for myself) that this sort of encrypted message stream is used from time to time in the binary groups.
It never sounded like something I would want to support as a server administrator, so I've always been happy that normal binary filtering
discards all such messages.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 09 Nov 2023 09:11:12 -0800, Russ Allbery wrote:

Bixby <bixby@sctb.ch> writes:

If I understand this correctly, you have a forum with the following properties:

1. A forum with a limited audience, requiring people to join before they
are able to receive the messages.

Yes.

Also, once joined, people can read only messages posted after they joined.

2. A central point of authority who decides who should receive the
messages.

Yes and no.

There is a central point of authority who decides who can join - receive messages - but once joined, the central point of authority is out of the picture.

3. An automatic system for distributing new messages to all current
known recipients.

This being NNTP.

This is indeed a useful system, but I'm not sure why you would use NNTP
to implement it, since at first glance it sounds like a mailing list.

Couldn't you say newsgroups are like mailing lists and question why
newsgroups exist?

The advantage is that NNTP is global and places a large number of groups/ mailing lists in one place. Accessibility and convenience.

NNTP's flood-fill algorithm is incredibly wasteful in this system, since
it would send the messages to loads of people who can't read them.

All news-servers would receive copies of all messages, but people (in the
sense of end-users of NNTP) would not; why subscribe to a group you cannot read?

This I think though is a good point, and one I had not thought of.

On the other hand, most choices are about cost and benefit. Would adding
this functionality to NNTP contribute to a revival of use? in this day
and age of ubiquitous surveillance, perhaps it has considerable value.
Perhaps these costs are necessary to regain privacy, in its various forms
(such as privacy within a group, as posited here).

I'm guessing that the appeal of NNTP in your design may be that you feel
like email addresses expose too much personal information about the recipients?

No. I'm motivated by remembering how Usenet used to be, before it was
tracked. Public and private. That's the goal; to be able to emit
messages which only a given group can read.

There have been a lot of proposals somewhat similar to this over the
years,

I cannot imagine I'm the first to think of this, since I can think of it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 09/11/2023 05:55, Doc O'Leary responded to Bixby :

It is possible to encrypt messages using more than one public key.

When a member posts, the post is encrypted by the NNTP client with the
public keys of every existing member, and then posted.

I’m no cryptography expert, but my understanding is that things aren’t generally done that way. Rather, the message is encrypted only once with
a strong symmetric cipher, and then just that key is encrypted with the public keys of the intended recipients.

Ok, so each and every message would be sent in two parts, one being the
message itself encrypted with one key, the other being the list of
couples (member identity, key encrypted with its public key).

I don't think that I would ever be a member of such a group, where every
little message is completed with hundreds of useless stuff, just because
I will find one little information in this bunch of garbage... and where
I will have to decrypt each of these messages before even knowing if I am interested by its contents!

A mailing list would much better do the task.

[...]

Everything you suggest still seems like it could be layered on top of the NNTP protocol as it already exists. People aren’t already regularly doing that because the result is far less useful than the existing public forum.

+1

--
Olivier Miakinen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 09/11/2023 11:25, Richard Kettlewell a écrit :

[...] Even assuming the moderator is trustworthy, as the number of
recipients grows, the probability that one of them is one of the group’s adversaries grows with it.

Yes, and as soon as such a member exists, he/she may decide to re-publish any message he/she has received so far on a completely public alt.* newsgroup.


--
Olivier Miakinen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Bixby,

I am not a very good reader/writer of English, so it will take time for
me to read all the discussion. Then, maybe my questions were already asked
and I apologize for that -- if that is the case, feel free to not respond because I will read the answer later when I read all of the discussion.

Le 08/11/2023 21:01, Bixby a �crit :

I would like to describe an enhancement to the NNTP protocol, with a view
to peer review.

# Rationale

I began using Usenet in about 1994. It was a remarkable forum -
possessing the property of being both public and yet private, as at that
time no one was archiving posts.

I doubt that no one was archiving posts at that time, be it for their
private use.

However, for a publicly accessible archive, I am sure that it existed
already in 1995 :
<https://en.wikipedia.org/wiki/Google_Groups#Deja_News>
�
The Deja News Research Service was an archive of messages posted to Usenet discussion groups, started in March 1995
�

I may be wrong, but I think the property of being public and yet private nature of Usenet was special and of particular value.

In my humble opinion, the particular value of Usenet was (and still is)
its public and not centralized nature : as soon as an article is posted
on Usenet, it may be spread all over the world for anyone to see it.

I would like to recreate that property of being public and yet private,
which is exactly to say that posts can be read by and only by a given
group of readers. The news-servers cannot read posts, nor can anyone
outside of that group of readers - so no archiving by Google, or anyone
else.

Because of what I said before, I disagree with the word "recreate" about
that very new property you are wanting to give to Usenet. In my (again)
humble opinion, a private mailing list would best suit your needs.

# Design

[...]>
For a user to subscribe, they create a private-public key pair and provide the *public* key to the moderator.

If their application is approved by the moderator, the public key is then distributed to all current members of the group.

All members hold then the public key of all other members.

Ok.

It is possible to encrypt messages using more than one public key.

You mean that a message encrypted with say 100 public keys could be decrypted by the only knowing of *one* of the 100 corresponding private keys?

I am very curious of that. Do you have a web page which explains this mechanism?

Of course, you will not ask any newsreader to implement it, so it will be the task of the moderator to receive the message in clear and encrypt it using the 100 public keys, before posting.

--
Olivier Miakinen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 10 Nov 2023 12:38:38 +0100, Olivier Miakinen <om+news@miakinen.net> wrote:

Le 09/11/2023 11:25, Richard Kettlewell a ecrit :

[...] Even assuming the moderator is trustworthy, as the number of
recipients grows, the probability that one of them is one of the group's
adversaries grows with it.

Yes, and as soon as such a member exists, he/she may decide to re-publish any >message he/she has received so far on a completely public alt.* newsgroup.

like a whistleblower... perhaps posting anonymously under a nom de guerre, albeit that doesn't seem likely among peers discussing nntp server issues

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

For your reference, records indicate that
Bixby <bixby@sctb.ch> wrote:

For the first point, by and large, I imagine users posting to all
subscribers - trusting the moderator.

But why? Or, put another way, what real purpose does the moderator serve?
What real purpose does the encryption serve? With everyone just trusting everyone, it seems like you’re introducing a lot of overhead that doesn’t materially matter.

prevent the subscriber in question from reading their posts.

But only directly. The very nature of discussion threads means messages
get quoted in whole or in part.

There are many problems which can occur, but most never do.

By that same measure, I struggle to see the occurrences of the problem
you’re trying to solve for in this encryption scheme. Regardless, no
change is necessary in the NNTP protocol to accomplish it, nor does “moderation” seem necessary. You’re welcome to experiment with a client that posts encrypted messages and manages public keys to decrypt them.
Let us know how the interpersonal dynamics play out with those technical measures in place.

--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 10 Nov 2023 12:31:16 +0100, Olivier Miakinen wrote:

Ok, so each and every message would be sent in two parts, one being the message itself encrypted with one key, the other being the list of
couples (member identity, key encrypted with its public key).

No. Each message would be encrypted with every public key - such that the private key of each of those public keys can decrypt the message - and the encrypted text would be posted.

I don't think that I would ever be a member of such a group, where every little message is completed with hundreds of useless stuff, just because
I will find one little information in this bunch of garbage... and where
I will have to decrypt each of these messages before even knowing if I
am interested by its contents!

Decryption would be performed automatically by the news client. It would
hold your private key, and so would be able to do so.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

For your reference, records indicate that
Bixby <bixby@sctb.ch> wrote:

Also, once joined, people can read only messages posted after they joined.

I have yet to hear why this is a desirable feature. There are indeed
certain contexts where “no history” is a feature, but topical discussions that Usenet encourages benefit from FAQs and memes and other “timeless” content.

I mean, you still need to chart out the use cases for these encrypted
groups. I’m hard pressed to imagine why I would join a group that has
I can’t “binge” in order to understand what it’s all about. For people already in a group, it sounds like the ultimate form of Eternal September.

Couldn't you say newsgroups are like mailing lists and question why newsgroups exist?

You absolutely could, and many do, and many no longer even know about
Usenet and still use mailing lists. The fundamental feature Usenet
provided was discoverability. That is less needed these days, and is absolutely destroyed by using encryption.

The advantage is that NNTP is global and places a large number of groups/ mailing lists in one place. Accessibility and convenience.

Nah. The Internet has made the world small in a digital sense. Social
media has made a business out of putting information (and misinformation)
in everyone’s pockets. Usenet is already a hard sell. Usenet with encryption is not an easier sale.

All news-servers would receive copies of all messages, but people (in the sense of end-users of NNTP) would not; why subscribe to a group you cannot read?

But that’s the same reason that server admins would give for not accepting those messages at all. Encryption is all the problems of binary groups on steroids. This is actually where a change in the NNTP protocol would be generally beneficial. Store-and-forward is inherently wasteful, and
really should be replaced by a demand-driven distribution of messages.
But other protocols already do that, so NNTP simply playing catch up isn’t going to bring in a lot of new users.

Perhaps these costs are necessary to regain privacy, in its various forms (such as privacy within a group, as posited here).

Certainly true, and I’m sure everyone here uses encryption in many other contexts. But I still don’t see a compelling use case for a public forum like Usenet.

No. I'm motivated by remembering how Usenet used to be, before it was tracked. Public and private. That's the goal; to be able to emit
messages which only a given group can read.

It was never private. Some messages simply got “lost” over time. That still happens, but it happens less and less because storage has gotten so
cheap and spying on people has gotten so profitable. Encryption would
help “lose” messages to a certain degree, but it’s a tricky thing to make usable on a system like Usenet. You can already dead-drop encrypted
messages in newsgroups, though, so nothing inherently needs to change
above the client level.

--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 10 Nov 2023 12:31:16 +0100, Olivier Miakinen <om+news@miakinen.net> wrote:

Le 09/11/2023 05:55, Doc O'Leary responded to Bixby :

It is possible to encrypt messages using more than one public key.
When a member posts, the post is encrypted by the NNTP client with the
public keys of every existing member, and then posted.

I'm no cryptography expert, but my understanding is that things aren't
generally done that way. Rather, the message is encrypted only once with
a strong symmetric cipher, and then just that key is encrypted with the
public keys of the intended recipients.

Ok, so each and every message would be sent in two parts, one being the >message itself encrypted with one key, the other being the list of
couples (member identity, key encrypted with its public key).
I don't think that I would ever be a member of such a group, where every >little message is completed with hundreds of useless stuff, just because
I will find one little information in this bunch of garbage... and where
I will have to decrypt each of these messages before even knowing if I am >interested by its contents!
A mailing list would much better do the task.

[...]
Everything you suggest still seems like it could be layered on top of the
NNTP protocol as it already exists. People aren't already regularly doing >> that because the result is far less useful than the existing public forum. >+1

""

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-11-10 12:18, Olivier Miakinen wrote:

Hello Bixby,

For a user to subscribe, they create a private-public key pair and provide >> the *public* key to the moderator.

If their application is approved by the moderator, the public key is then
distributed to all current members of the group.

All members hold then the public key of all other members.

Ok.

It is possible to encrypt messages using more than one public key.

You mean that a message encrypted with say 100 public keys could be decrypted by the only knowing of *one* of the 100 corresponding private keys?

I am very curious of that. Do you have a web page which explains this mechanism?

This is the basic behavior of most mail encryption systems, including
PGP and S/MIME, all he is really proposing could be done by integrating
them into NNTP clients such that there is a UI and database for
remembering the public keys of other members +/- personal distrusts.

Of course, you will not ask any newsreader to implement it, so it will be the task of the moderator to receive the message in clear and encrypt it using the
100 public keys, before posting.

No, point was to add logic to newsreaders and use the UseNet servers for distribution of encrypted posts and moderator announcements of
membership changes.

Personally, I find the entire plan counterproductive to the traditional
use of UseNet, though it may make sense as a means of keeping past correspondence out of view of future meatspace contacts (such as future employers).

One simplification would be for clients that trust the moderator's
invitations to encrypt to a group-wide public key, then a moderator run
bot will decrypt and re-encrypt everything to the known member public
keys. If posts contain a traditional expiry date, the reencryption bot
would also mail those articles directly to new members that join before
that date, but not to any later members (This is to give new members the
same view of recent discussions they would have gotten from plain text newsgroups, but still get rid of "Google remembers everything forever").


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 S�borg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Olivier Miakinen <om+news@miakinen.net> writes:

You mean that a message encrypted with say 100 public keys could be
decrypted by the only knowing of *one* of the 100 corresponding private
keys?

I am very curious of that. Do you have a web page which explains this mechanism?

You generate a random symmetric encryption key (probably AES), and you
encrypt the body of the message in that. Then, for every recipient public
key, you perform a public key encryption of the symmetric encryption key
and append that block to the end (or start, whatever) of the message.

Any recipient with a matching private key of one of those public keys then finds the block encrypted to their public key, does a public key
decryption of that block with their private key to recover the symmetric
key, and then uses the symmetric key to decrypt the message.

The size of the message therefore increases by the number of recipients,
but not by that much since the symmetric key is short. Usually the more important bottleneck is that public key encryption is slow, so encrypting
to a whole bunch of public keys potentially gets a bit slow. However, for
the typical number of netnews posts someone sends, I doubt anyone would
really notice. Modern computers are very fast.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bixby <bixby@sctb.ch> writes:

On Thu, 09 Nov 2023 09:11:12 -0800, Russ Allbery wrote:

This is indeed a useful system, but I'm not sure why you would use NNTP
to implement it, since at first glance it sounds like a mailing list.

Couldn't you say newsgroups are like mailing lists and question why newsgroups exist?

Yes, exactly. Netnews has always been a weird way of distributing mailing lists, if looked at from a particular angle.

What netnews provides over mailing lists is local caching and local
archiving using a much more convenient protocol than mailing list archives (which are not standardized). Each site pays the cost of message
transmission and reception only once, no matter how many local users want
to read the message, and any local user can see all the recent messages,
as opposed to the normal mailing list situation where you can only see the messages sent after you joined. That also gives you distributed infrastructure, so that no one site is responsible for keeping the
"mailing list" going.

Netnews therefore makes sense primarily for topics that would otherwise be
very large mailing lists, which benefit from those features. Otherwise,
the message format is essentially identical and both mediums support
roughly the same features. (For example, the news reader I use is also my email client; its handling of news and email is almost identical.)

Your system is getting rid of the two big advantages of netnews: the
people receiving the messages is limited, and archives are useless since
you can't read them until after you join. So it doesn't benefit from the
two primary features of NNTP.

It *does* arguably benefit from the distributed infrastructure, although
you still have the moderator point of failure. But I can see the argument
that the moderator is more easily replacable than a mailing list host.

I suppose the other advantage I can think of is that running a mail server
in this day and age is a giant pain in the ass because of spam filtering,
and running a news server is arguably easier, so you might get more people willing to run news servers for an encrypted message network.

On the other hand, most choices are about cost and benefit. Would
adding this functionality to NNTP contribute to a revival of use? in
this day and age of ubiquitous surveillance, perhaps it has considerable value.

It just feels simpler to use encrypted mail if you're not worried about exposing email messages, although I suppose the flipside of netnews and
email being so similar is that you can pretty easily implement anything
with either. But the floodfill approach only seems warranted if it's moderately likely that any site will have some readers.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 10/11/2023 18:20, Russ Allbery wrote :

[explanation of the mechanism for encrypting with more than one
public key]

Many thanks for that!

Best Regards,
--
Olivier Miakinen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 10 Nov 2023 14:57:11 -0000 (UTC), Doc O'Leary , <droleary.usenet@2023.impossiblystupid.com> wrote:

For your reference, records indicate that
Bixby <bixby@sctb.ch> wrote:

Also, once joined, people can read only messages posted after they joined. >I have yet to hear why this is a desirable feature. There are indeed

certain contexts where "no history" is a feature, but topical discussions >that Usenet encourages benefit from FAQs and memes and other "timeless" >content.
I mean, you still need to chart out the use cases for these encrypted
groups. I'm hard pressed to imagine why I would join a group that has
I can't "binge" in order to understand what it's all about. For people >already in a group, it sounds like the ultimate form of Eternal September.

Couldn't you say newsgroups are like mailing lists and question why
newsgroups exist?

You absolutely could, and many do, and many no longer even know about
Usenet and still use mailing lists. The fundamental feature Usenet
provided was discoverability. That is less needed these days, and is >absolutely destroyed by using encryption.

The advantage is that NNTP is global and places a large number of groups/
mailing lists in one place. Accessibility and convenience.

Nah. The Internet has made the world small in a digital sense. Social
media has made a business out of putting information (and misinformation)
in everyone's pockets. Usenet is already a hard sell. Usenet with >encryption is not an easier sale.

All news-servers would receive copies of all messages, but people (in the
sense of end-users of NNTP) would not; why subscribe to a group you cannot >> read?

But that's the same reason that server admins would give for not accepting >those messages at all. Encryption is all the problems of binary groups on >steroids. This is actually where a change in the NNTP protocol would be >generally beneficial. Store-and-forward is inherently wasteful, and
really should be replaced by a demand-driven distribution of messages.
But other protocols already do that, so NNTP simply playing catch up isn't >going to bring in a lot of new users.

Perhaps these costs are necessary to regain privacy, in its various forms
(such as privacy within a group, as posited here).

Certainly true, and I'm sure everyone here uses encryption in many other >contexts. But I still don't see a compelling use case for a public forum >like Usenet.

No. I'm motivated by remembering how Usenet used to be, before it was
tracked. Public and private. That's the goal; to be able to emit
messages which only a given group can read.

It was never private. Some messages simply got "lost" over time. That
still happens, but it happens less and less because storage has gotten so >cheap and spying on people has gotten so profitable. Encryption would
help "lose" messages to a certain degree, but it's a tricky thing to make >usable on a system like Usenet. You can already dead-drop encrypted
messages in newsgroups, though, so nothing inherently needs to change
above the client level.

all plus ones . . . governments, militaries, industries, corporations, organizations, clubs, gangs, syndicates, etc. are inherently secretive;
surely that is why unmoderated usenet newsgroups have become so popular

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 10 Nov 2023 12:38:38 +0100, Olivier Miakinen wrote:

Le 09/11/2023 11:25, Richard Kettlewell a écrit :

[...] Even assuming the moderator is trustworthy, as the number of
recipients grows, the probability that one of them is one of the
group’s adversaries grows with it.

Yes, and as soon as such a member exists, he/she may decide to
re-publish any message he/she has received so far on a completely public alt.* newsgroup.

For groups where the subject matter is sensitive, a post can be made when
a new member is accepted. Existing members can then moderate their speech until confidence is developed. The moderator also has a responsibility to
vet new members. Existing members also by their own control can choose
not to make their posts visible to arbitrary members, including new
members.

Of course, nothing is perfect or foolproof, but by having multiple
methods, each which has some effect, we can reasonably hope that the
frequency and severity of undesirable outcomes can be very greatly
reduced.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 10 Nov 2023 13:44:09 -0000 (UTC), Doc O'Leary , wrote:

For your reference, records indicate that Bixby <bixby@sctb.ch> wrote:

For the first point, by and large, I imagine users posting to all
subscribers - trusting the moderator.

But why? Or, put another way, what real purpose does the moderator
serve?

To prevent archivers from subscribing to the group.

If the group is open, archivers (such as Google Groups, or TLAs) can
subscribe and copy everything.

Moderators factorize the effort required for subscriber validation.
Rather than all subscribers needing to perform validation on all new
users, the moderator alone undertakes this task.

prevent the subscriber in question from reading their posts.

But only directly. The very nature of discussion threads means messages
get quoted in whole or in part.

Yes. That's a good point. However, such quoting is going to be much less
in quantity of text than all posts being readable.

There are many problems which can occur, but most never do.

By that same measure, I struggle to see the occurrences of the problem you’re trying to solve for in this encryption scheme.

The purpose is to provide a large-scale public forum which at the same
time is private to given groups, and which has non-permanence of record.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 10 Nov 2023 17:32:22 +0100, Jakob Bohm wrote:

On 2023-11-10 12:18, Olivier Miakinen wrote:

Of course, you will not ask any newsreader to implement it, so it will
be the task of the moderator to receive the message in clear and
encrypt it using the 100 public keys, before posting.

No, point was to add logic to newsreaders and use the UseNet servers for distribution of encrypted posts and moderator announcements of
membership changes.

Yes.

Personally, I find the entire plan counterproductive to the traditional
use of UseNet, though it may make sense as a means of keeping past correspondence out of view of future meatspace contacts (such as future employers).

I would say though that non-permanence of record is central to normal
human life and interactions. When we meet new people, they do not have
access to our full history of speech, writing, behaviour, and so on.

I do not know of a system which is large scale and public but which offers *non* permanence of record.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bixby <bixby-nospam@sctb.ch> writes:

I do not know of a system which is large scale and public but which
offers *non* permanence of record.

Indeed, because when something is public, anyone can archive and republish
it, and in our current era of effectively free storage, someone will.

Your system essentially proposes to make it not public, which is the
obvious solution, but the trade-off is that then it's, well, not public,
with all that entails (no casual browsing, no casual discovery, an ongoing requirement for policing the boundary of the group, arguments over
membership, etc.). There are a bunch of ways to create private discussion systems and your system has some interesting trade-offs that may put it at
a different place in that spectrum, but it's still broadly the same
solution: get rid of the public part.

If you want to stop archiving in a world with ubiquitous archiving, I
think you're going to be stuck with small, private, controlled forums with
a sufficiently small number of participants that you're below Dunbar's
number and can rely on effective community pressure to keep people from breaking the social contract and maintaining or publishing an archive. Technology can manage the membership process, but it can't make words
harder to archive and republish. (And even then, I bet people will retain private archives, which always have the possibility of leaking.)

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 11 Nov 2023 17:15:45 -0000 (UTC), Bixby <bixby-nospam@sctb.ch> wrote: >On Fri, 10 Nov 2023 17:32:22 +0100, Jakob Bohm wrote:

On 2023-11-10 12:18, Olivier Miakinen wrote:

Of course, you will not ask any newsreader to implement it, so it will
be the task of the moderator to receive the message in clear and
encrypt it using the 100 public keys, before posting.

No, point was to add logic to newsreaders and use the UseNet servers for
distribution of encrypted posts and moderator announcements of
membership changes.

Yes.

Personally, I find the entire plan counterproductive to the traditional
use of UseNet, though it may make sense as a means of keeping past
correspondence out of view of future meatspace contacts (such as future
employers).

I would say though that non-permanence of record is central to normal
human life and interactions. When we meet new people, they do not have >access to our full history of speech, writing, behaviour, and so on.
I do not know of a system which is large scale and public but which offers >*non* permanence of record.

if natural law has anything to say about it, then for every action there is
an equal and opposite action; unmoderated newsgroups encourage openness not secrecy

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 11 Nov 2023 09:52:27 -0800, Russ Allbery wrote:

Your system essentially proposes to make it not public, which is the
obvious solution, but the trade-off is that then it's, well, not public,
with all that entails (no casual browsing, no casual discovery, an
ongoing requirement for policing the boundary of the group, arguments
over membership, etc.).

Yes.

There are a bunch of ways to create private
discussion systems and your system has some interesting trade-offs that
may put it at a different place in that spectrum, but it's still broadly
the same solution: get rid of the public part.

Yes.

If you want to stop archiving in a world with ubiquitous archiving, I
think you're going to be stuck with small, private, controlled forums
with a sufficiently small number of participants that you're below
Dunbar's number and can rely on effective community pressure to keep
people from breaking the social contract and maintaining or publishing
an archive.

Yes, very much so. Enough people and of course *someone* will do anything
that can be done, regardless of anything.

Technology can manage the membership process, but it can't
make words harder to archive and republish.

Yes - the fundamental problem being that once someone has the decrypted version, well, that's that. It's out.

(And even then, I bet
people will retain private archives, which always have the possibility
of leaking.)

I was part of a particularly intimate group, populous, both active and
lurkers, which was active for many years, and this was never seen to
happen, FWIW.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 11 Nov 2023 20:35:53 +0100 (CET), D wrote:

if natural law has anything to say about it, then for every action there
is an equal and opposite action; unmoderated newsgroups encourage
openness not secrecy

They continue to exist.

Note also openness necessarily means the absence of privacy.

Privacy has its place, too.

We do not as humans or groups of humans function in a completely public,
or completely private fashion.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 10 Nov 2023 09:15:25 -0800, Russ Allbery wrote:

Bixby <bixby@sctb.ch> writes:

On Thu, 09 Nov 2023 09:11:12 -0800, Russ Allbery wrote:

What netnews provides over mailing lists is local caching and local
archiving using a much more convenient protocol than mailing list
archives (which are not standardized). Each site pays the cost of
message transmission and reception only once, no matter how many local
users want to read the message, and any local user can see all the
recent messages, as opposed to the normal mailing list situation where
you can only see the messages sent after you joined.

The more established mailing lists sometimes have web-based archives.

Your system is getting rid of the two big advantages of netnews: the
people receiving the messages is limited,

But only in much the same way that any given group is already limited;
only so many people subscribe to any given group. The only difference now
is that there is moderator of who subscribes. In all likelyhood, this typically will make very little difference to the number of readers of a
group. Most people who want to read a group and fit to do so; we can
imagine excluded are the mass archivers, and the sociopaths, both of who
are small in number but profound in effect.

and archives are useless since
you can't read them until after you join. So it doesn't benefit from
the two primary features of NNTP.

Archives - long retention - was not always a properly of news. Back in
the late 90s, retention was for a week or so. My argument of course is
that for some use cases, this is advantageous, and we should look to
obtain this functionality.

It *does* arguably benefit from the distributed infrastructure, although
you still have the moderator point of failure.

Already the case for existing moderated groups. If the moderator goes
away, or goes bad, a replacement must be found. The existing mechanisms
for this can be used for the new type of moderator.

I suppose the other advantage I can think of is that running a mail
server in this day and age is a giant pain in the ass because of spam filtering,

Amen. I gave up running my own SMTP server. No matter what I did,
delivery was poor, and it was based on IP. You have to pay for a
reputable IP. Personal SMTP is a thing of the past.

On the other hand, most choices are about cost and benefit. Would
adding this functionality to NNTP contribute to a revival of use? in
this day and age of ubiquitous surveillance, perhaps it has
considerable value.

It just feels simpler to use encrypted mail if you're not worried about exposing email messages, although I suppose the flipside of netnews and
email being so similar is that you can pretty easily implement anything
with either. But the floodfill approach only seems warranted if it's moderately likely that any site will have some readers.

Being part of news solves the discoverability problem. That's critical.
Google et al are now overwhelmed by SEO.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

For your reference, records indicate that
Bixby <bixby-nospam@sctb.ch> wrote:

On Fri, 10 Nov 2023 13:44:09 -0000 (UTC), Doc O'Leary , wrote:

For your reference, records indicate that Bixby <bixby@sctb.ch> wrote:

For the first point, by and large, I imagine users posting to all
subscribers - trusting the moderator.

But why? Or, put another way, what real purpose does the moderator
serve?

To prevent archivers from subscribing to the group.

But how? You’ve outlined no mechanisms to validate that trust. In
reality, *any subscriber* can be an archiver, whether intentionally or unintentionally.

If the group is open, archivers (such as Google Groups, or TLAs) can subscribe and copy everything.

Given sufficient reason, they’d likely archive the encrypted posts anyway. Given that the client would be doing encryption targeting limited
recipients, there would be valuable meta data in that alone. Trying to do private things in public vastly expands your attack surface.

Moderators factorize the effort required for subscriber validation.
Rather than all subscribers needing to perform validation on all new
users, the moderator alone undertakes this task.

Yeah, I’m not buying it. I can’t think of a single use case where I
would trust some unknown moderator to completely screen anonymous
subscribers. You’d do well to think critically about how this would play
out in reality. I still see it as Eternal September v2.

prevent the subscriber in question from reading their posts.

But only directly. The very nature of discussion threads means messages get quoted in whole or in part.

Yes. That's a good point. However, such quoting is going to be much less
in quantity of text than all posts being readable.

But that’s just worse! Quoted text is identified *signal*, whereas “all posts” are just so much noise.

The purpose is to provide a large-scale public forum which at the same
time is private to given groups, and which has non-permanence of record.

You keep saying that but, again, I don’t think you have put forward a plausible way for that to be become reality. Don’t just hand wave away
the fundamental issues. It remains the case that no change to the NNTP protocol has to be made to support your goals. You are free to take any
open source newsreader and add the features that accomplish what you
want. If you are right, people will adopt it. If not, it should become quickly clear what the issues are (likely including some new ones we
haven’t even covered in this discussion :-).

--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 12 Nov 2023 10:50:06 -0000 (UTC), Bixby <bixby-nospam@sctb.ch> wrote: >On Sat, 11 Nov 2023 20:35:53 +0100 (CET), D wrote:

if natural law has anything to say about it, then for every action there
is an equal and opposite action; unmoderated newsgroups encourage
openness not secrecy

They continue to exist.
Note also openness necessarily means the absence of privacy.
Privacy has its place, too.
We do not as humans or groups of humans function in a completely public,
or completely private fashion.

doubtless most would agree . . .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

For your reference, records indicate that
Bixby <bixby-nospam@sctb.ch> wrote:

Archives - long retention - was not always a properly of news. Back in
the late 90s, retention was for a week or so. My argument of course is
that for some use cases, this is advantageous, and we should look to
obtain this functionality.

Much of that had more to do with the limitations of computing resources at
the time than anything specific to do with Usenet. Storage is cheap these days, as it computing power for compression. Technological progress is directly at odds with ephemeral data. Encryption can certainly address
some of that, but the real nut to crack is how to eliminate the value of
data that is *already* public. That seems to be more of a human/social
problem than a technology problem.

On Fri, 10 Nov 2023 09:15:25 -0800, Russ Allbery wrote:

I suppose the other advantage I can think of is that running a mail
server in this day and age is a giant pain in the ass because of spam filtering,

Amen. I gave up running my own SMTP server. No matter what I did,
delivery was poor, and it was based on IP. You have to pay for a
reputable IP. Personal SMTP is a thing of the past.

Not so, and I’d argue the opposite of this, for much the same reason you
want more ephemeral messages to return to Usenet. I run my own SMTP
server. I jump through enough hoops that deliverability is high and
incoming spam is low (so low I don’t do any filtering). It’s not *that* hard, and if you don’t want the big guys sifting through all your
messages, you’d benefit from getting back to the days of private email.

But on the topic of spam, it is important to note that eyeballs draw
spammers; it isn’t just an email problem. Spam on Usenet was a much
bigger issue when it was more popular, and if you’re seeking to make it popular again, you’ll have to think about the mechanisms that need to
be put in place to limit abuse. There are ways encryption could help
that, but there are also ways it could end up making it worse.

Being part of news solves the discoverability problem. That's critical. Google et al are now overwhelmed by SEO.

Because . . . eyeballs. Usenet is no longer a primary source for
discovery, and encryption would make it *less* so. Today, I can pop into
a group that seems interesting, see the subjects of discussions that have
been happening over the last month/year/whatever, check out some of the
posts to see if the community is cool or not, maybe lurk for a bit, and eventually contribute to the discussion. That entirely goes away with encryption, and I can’t see that replacement being very attractive.

--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Doc O'Leary , <droleary@2017usenet1.subsume.com> writes:

Yeah, I’m not buying it. I can’t think of a single use case where I would trust some unknown moderator to completely screen anonymous subscribers. You’d do well to think critically about how this would
play out in reality. I still see it as Eternal September v2.

I think the exact opposite is more likely: almost no one joins the groups
after the initial enthusiasts.

The very specific problem that you (Bixby) have here, I think, is that you
have no obvious way to ease someone into the group. The encryption setup
makes it all rather all-or-nothing: either they can read and send messages
or they can't. (Yes, some people can leave them out of their list of
keys, but in practice very few people are going to want to micromanage
that.)

The advantage of traditional moderation is that you can let anyone read
and get a feel for the place, and then you can screen their first few
postings and make sure they understand the cultural norms. Then you can transition them to autoapprove, but you can always go back to screening if
you need to. This works great for easing someone into the group and
watching out for bad behavior from someone you don't know yet.

Closed groups always have a stagnation problem because the barrier to
entry is high, and after a few bad experiences (particularly if it
requires a whole annoying thing to get someone out of the group again),
people stop wanting to take risks on new members.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bixby <bixby-nospam@sctb.ch> writes:

On Fri, 10 Nov 2023 09:15:25 -0800, Russ Allbery wrote:

What netnews provides over mailing lists is local caching and local
archiving using a much more convenient protocol than mailing list
archives (which are not standardized). Each site pays the cost of
message transmission and reception only once, no matter how many local
users want to read the message, and any local user can see all the
recent messages, as opposed to the normal mailing list situation where
you can only see the messages sent after you joined.

The more established mailing lists sometimes have web-based archives.

Right, but there's no standard protocol to read messages from them, so
usually you have some crappy and dysfunctional web-based
pseudo-mail-reader that's awful. That's one of the big advantages of
netnews; you can read the available archives with the same protocol that
you read new messages.

Archives - long retention - was not always a properly of news.

Sure, I agree. But *short-term* archives are vital to the entire social experience of netnews and have been since the very beginning. As someone
who was on Usenet before the Great September, the standard culture was to
read the available articles in the group before jumping in with your own postings. Often that would include a FAQ, and it would always include
some typical discussions, so that you knew what the group was like in
advance.

Back in the late 90s, retention was for a week or so.

Two to four times that was more common in my experience, but sure, it
wasn't years.

It *does* arguably benefit from the distributed infrastructure,
although you still have the moderator point of failure.

Already the case for existing moderated groups. If the moderator goes
away, or goes bad, a replacement must be found. The existing mechanisms
for this can be used for the new type of moderator.

Right, but again I'm comparing to just running an encrypted mailing list,
which is in some ways easier to set up. Any one person with a server can
do it; you don't need a network of news servers willing to carry your
traffic.

Amen. I gave up running my own SMTP server. No matter what I did,
delivery was poor, and it was based on IP. You have to pay for a
reputable IP. Personal SMTP is a thing of the past.

This may be the strongest argument for using a private netnews hierarchy
for this sort of encrypted messaging: it seems to now be easier to share netnews servers than mail servers. Which is sort of weird, since arguably
you could do the same thing with mail and just give people POP accounts,
but the resource and account dynamics of netnews are different in useful
ways.

Being part of news solves the discoverability problem.

It absolutely does not when all of the messages are encrypted. I think
this is the biggest flaw in your plan.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)