sleepless
Born on August 09, 2013•311 Karma
I much prefer Every Door, especially for updating opening hours and any kind of place details. Have you tried it?
— But that’s where the information is.
— Stop linking to Twitter/X, here’s a Fediverse link with more information.
— But it has fewer engagement.
— Stop linking to Twitter/X, here’s a Fediverse link with more information and more engagement.
— …
— OK, at some point, you need to recognize that you are the problem.
Why does posting there make a user a “problem”?
Who’s the judge of what’s a “problem” and what are the criteria, I wonder.
As someone without a Twitter/X account, their links are bad. I can only see the first post of a chain, can't see replies, etc. Mastodon is better in that regard.
This has nothing to do with the content of the platform, Musk, etc, btw. It's just the fact that now it's a bit hostile for logged out users/people without accounts. It used to be fine, but now it hides content, which is bad for me.
It only motivates me to avoid the platform.
It was always awful, in my opinion. Twitter does a good job at letting people publish "sound bytes"; little bits of what's on their mind. Past that (into longer form and discussion) it has never been good.
Clicking on almost any of the UI elements leads to a log in prompt, without showing anything else. For people without accounts (or those who don't want to make one), that's probably not functionally different from dropping a link to some forum that requires registration, albeit in this case I guess at least the main post is visible.
The Mastodon link in comparison has the discussion visible up front, which is nice to see! Now whether the fediverse is popular enough to actually have good discussions, that's a bit harder to say, but at least it's something!
I think Facebook also had similar issues, where it gates a lot of things behind a login prompt, quite user hostile, though also understandable why they'd do it that way.
I don’t have an Instagram account and don’t see a reason to create one, but my friends can still link me pictures or videos that I can look at. If I want to engage in any way or read past the couple top comments, I need to create an account.
Showing the user what they came for is a good way to get free advertisement, but requiring them to create an account to actually use the platform is perfectly reasonable.
If someone was telling me to look up information from a print edition of the Encyclopaedia Britannica from the 1970s, I'd have the same problem: it is an absurd thing to ask of me because there are better, more frictionless ways to obtain the information.
Why is posting there make the user a problem? Because, if the user is trying to communicate something, they are choosing a platform that isn't interested in making it effective at communication. A closed off community isn't the town square it claims to be. If you are communication on that site, you can be sure people directed aren't getting the full story.
Who's the judge? Me. I am the judge of what a problem is. So is the parent poster you were replying to. They are also a judge. It's odd that you hand off opinions to others and don't make your own.
I don't know who was the first moron who decided to post the first "long form writeup" on a platform that only supports blurbs... but I am absolutely amazed that people thought it was a good idea and followed suit.
2. Because you are basically linking to a deep link in the dark web.
3. We all get to make our own decisions, and the person calling out shitty websites that you should not bring to the group has my support.
For better or for worse at least you can view this single tweet now, but right after Musk took over he blocked all access without account which was just annoying.
Imagine if HN would require you to have account browse and read it. That's what's mostly happened to twitter (and happens to the rest of our benevolent overlords/social platforms like fb and instagram, to which regular web migrated with the information :/)
In any case, at least we can see the replies and other posts from the account without having to create an account. Still better than Twitter/X in my view.
While true, I'd much rather read discussions on HN than say X or even Reddit these days.
It is a serious problem that the ecosystem is held back by wasting resources on personal disputes with immediate consequences for end users.
Hate on OpenPGP all you want, it still is an important technology with unrealized potential and growth.
There is no breaking of backward compatibility. The crypto-refresh draft and the LibrePGP draft are equally backward-compatible.
See 'A Critique on “A Critique on the OpenPGP Updates”':
* https://blog.pgpkeys.eu/critique-critique
Both groups would create a new format (Libre = v5; crypto-refresh = v6). v4-only wouldn't be able to handle either new format, and newer software could presumably be told to create files in the older format.
The Proton folks are choosing to support both v5 and v6:
* https://github.com/ProtonMail/go-crypto/pull/182
As is the Thunderbird/RNP team:
* https://github.com/rnpgp/rnp/commit/fdfc1f5bb11d439e35f3c855...
(This is sidestepping the other parts of the comment that don't make sense, like why a single read implies multiple writes or why performing cryptographic upgrades is somehow uniquely, unacceptably risky from a data corruption perspective.)
It probably depends a lot on the application, but I think it's often much better to have something that will warn the user about security risks and let them decide what to do with that risk. If you do design something with these silent writes, you absolutely need to think hard about failure cases and test them, and not handwave them away. Having the most "secure" data be corrupted is ultimately an unacceptable outcome.
That's not even getting into the other problems, such as ... is it ok for the user to take a performance hit of writing X GB when all they want to do is read a file?
Put another way: your cryptosystem isn't responsible for saving your ass from not making backups. If your data is valuable, treat it that way.
This is exactly why your crypto system should not rely on spontaneously writing many gigabytes on a read operation, without asking. I couldn't have said it better myself.
What you are advocating is crypto intruding on the storage mechanism inappropriately. It's a layer violation.
I think if it's important to the end user, you could write fairly decent code at the app layer that asynchronously re-encrypts old data in a way that doesn't harm the user. That code would need to have a strategy for write failures. A basic cryptography tool should probably not have this as a built-in feature however, for a few reasons including those I've stated.
Again: nobody has said this.
Whether or not the tool does this in bulk, or asynchronously, or whatever else is not particularly important to me. The only concern I have in this conversation is whether it's contradictory to simultaneously assert the value of some data and refuse to encrypt it correctly. Which it is.
You said it. You said that's what the cryptosystem should do. It's a bad design.
From the original comment:
> This is sidestepping the other parts of the comment that don't make sense, like why a single read implies multiple writes
There is 100% value in being able to decrypt a 20 year old email. It doesn't matter if it is a broken cypher.
A 20 year old email has very little actionable in it, but can have value in other ways.
It is absolutely vital that a project like this, supports some means for a modern machine/stack to access older data.
Upstream spoke of deprecated support for older emails. My response is aimed there.
And there is loads of software that will not compile on modern hardware. End users don't often have that ability to re-write, or even to easily validate a random bit of code on github.
A project like this, needs to maintain backwards operability. For decades.
What's really being asked for here is the capability to seamlessly continue sending messages with the previous, weak constructions, into the indefinite future, and have the installed base of the system continue seamlessly reading them. I think that is in fact a goal of PGP, and one of its great weaknesses.
Users who still rely on that have to use the old software, against which there can be barriers:
- old executables don't run on newer OS (particularly in the Unix world).
- old source code won't build.
- old code won't retrieve the old data from the newer server it has been migrated do.
Things like that.
The barriers could be significant that even someone skilled and motivated such as myself would be discouraged.
Not all reliance is reasonable though.
Some legacy software can only do SSLv3 or lower, does that mean the rest of the internet has to carry that support around? Abso-f-lutely not.
The same applies here. If you really need that ancient stuff that loses support, repackage them in newer encryption or remove the obsolete layer. It's highly probable that information no longer needs to stay encrypted at rest anyways.
That is how it works. What you're missing is that everyone, both servers and clients, agrees that supporting old SSL versions is a bad idea. And they're right.
More precisely, I don't agree with web clients not connecting to old servers.
Plain HTTP is what people resort to when their browser refuses to connect to an old device or server using HTTPS, which is worse than old SSL.
The absurd idea that a user will have a 20 year old encrypted mail, because software still supports it, is ridiculous. What really happens is someone has a 20 year old mail no matter what, itcwill always exist, and the choice is, support it or not. Support it to be read, support it to be converted, warn the user, suggest fixes.
And your SSL example is senseless! In what world do you envision super secure stuff alongside weaker legacy, on the same damned server. You literally are not thinking sensibility about any of this, you examples are paper tigers.
This stance is absurb.
How do you alert the users that are running the problematic software and haven't yet updated it? The very premise is ridiculous.
> What really happens is someone has a 20 year old mail no matter what, itcwill always exist, and the choice is, support it or not. Support it to be read, support it to be converted, warn the user, suggest fixes.
Well yeah and the choice should be to not support it. If the user needs those letters they can either decrypt or just re-encrypt them. It's silly to claim that a message can somehow be both so vital to be protected by encryption, but not upgraded to something more modern.
> And your SSL example is senseless! In what world do you envision super secure stuff alongside weaker legacy, on the same damned server.
I'm not envisioning it. Nobody should be running such old useless garbage. What was suggested earlier in this thread does not work and must not happen in practice.
Where did you get the weird idea the software isn't updated? This entire discussion is about deprecation of older encryption methods in new versions of software.
You're not giving this thought. Good day.
In the trouble situations, one of the two pieces of software being upgraded is thrust upon the user.
Only when we are doing theatre. In the actual facts, lack of security is worse than inferior security.
Is there a real risk of this that I missed, or are you just free-associating off the term "backwards compatibility"?
The whole situation regarding key servers, key rotation, and the web of trust is a complete dumpster fire.
Can you explain why?
People elsewhere in this thread are saying that PGP sucks because it tries to do too many things at once, but it seems to me that the one big advantage of a tool which does everything at once is that you only need to solve authenticity one time for everything you do.
For example, if I'm communicating with an open source dev, having their known-authentic PGP key allows me to simultaneously verify the authenticity of their software updates, verify the authenticity of the email they send me, and encrypt my emails to them. Is there anything outside of PGP that accomplishes this?
Well, the key servers are useless because they are susceptible to that poisoning attack from a few years ago, and they happily send you fraudulent or revoked keys.
And the web of trust doesn't scale. The trust ratings mean different things to different people, the propagation of revocation certs and signatures is slow, and rotating keys is onerous.
>For example, if I'm communicating with an open source dev, having their known-authentic PGP key allows me to simultaneously verify the authenticity of their software updates, verify the authenticity of the email they send me, and encrypt my emails to them. Is there anything outside of PGP that accomplishes this?
How often do you check the fingerprints of that key? Do you verify out of band when the developer rotates their key? (Haha just kidding, PGP users essentially never rotate keys)
If you care enough to encrypt your emails, then what is the virtue of verifying less frequently that you're talking to the correct persons?
Why wouldn't you want separate keys for all those things?
Why would you want an adversary to be able to compromise a single key and have the ability to forge commits, emails, and whatever else?
I'm almost certain PGP best practice is to have a single master key, kept on an airgapped device, that's used to sign subkeys for various purposes like email, commit signing, etc. So I only have to verify out of band once, unless the airgapped device gets compromised or the master key encryption is broken.
More importantly, how do you know that your counterparty is one of that (extremely small) minority?
Don't forget about PGP smart cards either. You could keep the master key you use to sign subkeys on a smart card. A smart card should be harder to hack than your phone.
Qubes has built-in "split GPG" support that allows you to e.g. sign something using your private key while keeping it in a different VM. See https://www.qubes-os.org/doc/split-gpg/
I know PGP isn't for everyone, I just like the idea of keeping high-security options available for those who want them.
>More importantly, how do you know that your counterparty is one of that (extremely small) minority?
You could ask them :-)
But PGP doesn't provide a high-security anything.
- In order to achieve some reasonable level of protection from MITM attacks you can't just get someone's key from a keyserver. You have to go hunting for it and you're never really sure if there's a revocation cert out there that you just missed.
- Some people publish PGP keys on their websites, and you could use that to contact them over encrypted email. You are still vulnerable to metadata analysis and unless you manually re-key on every message (which you don't), you don't enjoy forward secrecy. Additionally, all it takes is one oopsie moment for someone to Reply-All and forget to encrypt first and now the entire conversation went out unencrypted. This has happened to me.
- You claim there's some unspecified benefit to signing commits with the same key you encrypt your emails with, though I don't see why that's superior to signify/minisign
- Best practices demand that you keep an airgapped machine with a long lived master key on it. No mention is made of how to prevent BadUSB-type attacks from jumping the air gap. If you really want to be sure nobody mints their own key from your airgapped machine to impersonate you, you now need to monitor your machine. That raspi in a drawer is still vulnerable to Evil Maid attacks, and the worst part is you won't know someone's impersonating you until it's too late.
All this attack surface just for the purported convenience of having some kind of unified "crypto identity" wherein you only need to verify someone once?
These are not the characteristics of a high security system. This is why people think PGP is a for security LARPers. It's objectively just not a very good tool.
This is a convenience consideration, not a security one.
>- Some people publish PGP keys on their websites, and you could use that to contact them over encrypted email. You are still vulnerable to metadata analysis and unless you manually re-key on every message (which you don't), you don't enjoy forward secrecy. Additionally, all it takes is one oopsie moment for someone to Reply-All and forget to encrypt first and now the entire conversation went out unencrypted. This has happened to me.
These are problems with encrypted email, not PGP. Encrypted email is not the only way to use PGP. See e.g. https://news.ycombinator.com/item?id=38575764
>No mention is made of how to prevent BadUSB-type attacks from jumping the air gap.
You could write newly minted keys to single-use CD-Rs.
>If you really want to be sure nobody mints their own key from your airgapped machine to impersonate you, you now need to monitor your machine. That raspi in a drawer is still vulnerable to Evil Maid attacks, and the worst part is you won't know someone's impersonating you until it's too late.
If physical access is part of your threat model, you'll want to monitor access to your stuff anyways.
Four of the major functionalities missing in the first official release of macOS Sonoma are:
Entire message data is not always passed to the extension making processing the encrypted message impossible
Reliably encrypted drafts
Support for setting the default state of the sign and encrypt button in compose windows which can lead to dangerous side-effects
Sign and encrypt button could go out of sync with internal state, if keyring changes are detected