[VLM]

The internet bucket is too big, you got free for all http or secure (ish) https providing authentication, authorization, accounting, and encrypted data transfer.

I'd argue that HN doesn't require encrypted data transfer at all, and encrypted data transfer is illegal on ham radio freqs anyway. The other three AAA words are what HN requires as a multi user BBS like service, and are legal under ham radio rules, or at most only need to be bent slightly into being legal.

I was motivated enough to look up the Apache webserver docs to force a https ciper; apparently "SSLCipherSuite" lets you force a specific openSSL cipher name; then I checked openSSL docs and for better or worse "cleartext" is not an allowable cipher for openSSL. Via some code changes in browser and server you could technically implement something like HTTPS that would work legally over ham radio.

Although this is a slight simplification, conceptually there's nothing wrong with the idea of accessing HN while using a cipher of cleartext. I really want to know that I'm not getting MITM'd when I read and post, and I want that CA proof that I'm talking to the genuine CA approved HN server. I really don't care if the general public can read the contents of this post so cleartext would be fine. Logging in by typing my password would be an obvious corner case to handle.

[geofft]

Yeah, recent versions of TLS don't specify a "null" cipher any more.

One of the reasons I think we should allow encryption over ham links is that you can't run normal internet protocols - you have to do significant code changes/hacking to make things work. The internet community has decided (for reasons of national security, even!) that it's just not worth having the option.

[msla]

> I'd argue that HN doesn't require encrypted data transfer at all

It's still a good default, because it sets up a social expectation of privacy, which is very important in this era of data mining.

[KirinDave]

Unencrypted communication to a website with identity would require some radical restructuring and very smart clients to generate and check the MAC codes. Pretty sure everyone everywhere would hate that.

[tuxxy]

> I'd argue that HN doesn't require encrypted data transfer at all

I guess you're okay with sending your passwords in plain, then.

[TeMPOraL]

With that one obvious little caveat. But that's an authentication issue, and does not require all other HN communication (posts, comments) to be encrypted.

[tuxxy]

But you're widely ignoring all the privacy issues that come with cleartext traffic. Why would you give up this clear win for consumers and users and relegate them to easily trackable, non privacy-preserving techniques?

Do you not see that you're literally arguing against privacy here? Why should amateur radio not get the same benefits? All I hear are arguments in defense of regulation and Kafkaesque government bureaucracy.

[TeMPOraL]

clears eyes. What?

HN is a public board, viewable without logging in. There is no expectation of privacy in communications here.

[tuxxy]

There's no need to be dense here...

There are privacy implications _outside_ of User communications to this website. Arguing that there is no expectation of privacy on HN is a complete non sequitur.