It’s really interesting to see HackerNews get its knickers in a twist about the concept of a end-to-end-secure “chat” group which might have (for the sake of argument) 1000 participants:

Their question is: “Is such a big group not effectively ‘public’? Is a message sent to onesuch group not already somehow public content, fit for filtering to meet public social mores?”

The answer is: no, it’s not public, and they are making a category error by looking at, and discussing, the abstract concept of a ‘message’ in the context of the ‘group’.

They should look instead at the message and the expectations of its sender regarding the sender’s agency to define who will be the recipients (“ends”) that are able to read the message’s content.

There’s a couple of options here:

1. The message can be read by anyone, without requiring any necessary authentication, nor authorisation, nor any other barrier other than possession of a receiving device such as “ears”, “a radio”, “a television” or “a web browser”. Essentially this is “broadcast” messaging, and is “public”.
2. Conversely: the message can only be read by someone who possesses some form of authorisation credential or mechanism, to the exclusion of all others who lack. Such authorisation might include: “being in a particular meeting room at a given time”, or “membership of a particular community at a given time”, or “possession of an access credential such as a password or cookie at a given time”. Essentially these are all forms of “multicast” or “unicast” messaging and are “not public”.

This is a binary distinction: there are only two options in this model, although of course each option can be further decomposed / have nuance applied to it.

As I argue as part of my development of a “duck test” to determine whether a messenger system implements end-to-end security, my proposed test of E2E-Security is essentially whether it is possible for someone outside of the sender’s expectation, to receive the sender’s message in whole or in part:

As such: even a 1000-person end-to-end-encrypted messenger group chat — however awkward it might be for real-world conception — is not a public messenger group, because it excludes “the public” in several different ways (e.g. chronologically there would be no access to past history for new participants, and no access to content at all for anyone outside of the past, current, or future participant sets, etc…)

Summary

When considering whether a group is “public” or not, the test is whether access to a piece of content is closed against people who were not participants of the group at the time when the content was composed and sent to the (contemporary) group participants; this, with an obligation that that set of participants (or: an equivalent policy defining the set of participants) was fully visible to the sender at the time of sending.

More on this project at Medium and the related work-in-progress Internet Draft.

I aver that we should not dilute this definition of “public” because doing so would negatively impact upon protecting both public and private discourse; that some authority should arbitrarily propose that “…a chat group considered public if there are over 10 participants” is dangerous, especially when they may lower the privacy protections offered to “public content”.

This is not to mention the arbitrariness of a number such as “10“; why not one hundred, one thousand, one million? In software engineering, enforcing number-limits other than zero or one are generally (a) arbitrary and (b) unwise. See also: rate limits, DDoS attacks enabled by rate limiting, …

Even more worrying are those people who argue (often following a “arbitrary 1000 users in a group” definition) that “public content”, shared in and amongst such large groups, is somehow unworthy or undeserving of the:

• protections of end-to-end encryption
• treatment of the group as being closed
• treatment of the content as being private

We already use YouTube, Twitter, and other sites for broadcast communication by means which provide transport-level “ECDH” end-to-end-encrypted HTTPS connections. In the case of such public (Twitter?) content we don’t suddenly drop back to shipping such “public” data over unencrypted HTTP on the (specious) basis that “privacy is not worth the hassle for public data” – not least because the encryption also provides tamper resistance and assurance.

Fortunately we’re starting to see aspects of access control be considered in a separate light, for instance the LinkedIn vs: HiQ anti-scraping case, where LinkedIn are apparently attempting to frame their content as being “private”, or at least “non-public” irrespective of not protecting it with authentication, and propose therefore that LinkedIn can decide for themselves what constitutes unauthorised access.

Encryption is a general benefit to most, perhaps all communication; and end-to-end encryption offers more value, for instance that it can offer limited control to the sender in terms of substantially “freezing” the set of potential recipients — often a desirable trait in communication; obviously this is limited in turn by how “leak-proof” those recipients are.

Nonetheless: end-to-end encryption enables the sender to choose to extend their limited set of communicants, to include other people in the world. End-to-end encryption offers them more choice and more agency. It’s a lot harder to do the converse of that, when the feature is generally lacking.