sudneo

There are certain things that are known facts, there is no need to prove them every time.

The simple fact that:

• There is not a standard tool that is common
• The amount of people who use PGP is ridiculously low, including within tech circles. Just to make one example, even a famous cryptographer such as Filippo Sottile mentions to receive maybe a couple of PGP encrypted emails a year. I work in security and I have never received one, nobody among my colleagues has a public key to use, and I have never seen anybody who was not a tech professional use PGP.

You can also see:

• https://www.latacora.com/blog/2019/07/16/the-pgp-problem/:

We can’t say this any better than Ted Unangst: "There was a PGP usability study conducted a few years ago where a group of technical people were placed in a room with a computer and asked to set up PGP. Two hours later, they were never seen or heard from again." If you’d like empirical data of your own to back this up, here’s an experiment you can run: find an immigration lawyer and talk them through the process of getting Signal working on their phone. You probably don’t suddenly smell burning toast. Now try doing that with PGP.

• https://fosdem.org/2024/schedule/event/fosdem-2024-3297-sequoia-pgp-rethinking-openpgp-tooling/

A recent talk, I will quote the preamble:

Although OpenPGP is widely considered hard to use, overcomplicated, and the stuff of nerds, our prior experience working on another OpenPGP implementation suggested that the OpenPGP standard is actually pretty good, but the tooling needs improvement.

And you can find as many opinion pieces as you want, by just searching (for example: https://nullprogram.com/blog/2017/03/12/).

However, if you really believe I am wrong, and you disagree that PGP tooling is widely considered bad, complex and almost a meme in the security community, you are welcome to show where I am wrong. Show me a simple PGP setup that non-technical people use.

P.s.

I also found https://arxiv.org/pdf/1510.08555.pdf, an interesting paper which is a followup of another paper 10 years older about usability of PGP tools.

They generally require to have data visible on the server and/or handle independently encryption/decryption with related tools and key management (including key discovery).

For some, it might be worth, for 99% of the population who wouldn't be able to do this but also doesn't want their content availablento the provider, it's not.

GPG is a huge pain in the ass to manage. Everyone knows this, because it's the case. The web of trust also doesn't scale and has many problems, handling key securely is hard, making GPG work on all devices is something which is completely impossible for people without solid technical skills.

If you think otherwise, you are just in a bubble.

It's actually fairly simple: if the server never has access to the keys or the plaintext of messages (or calendar events, etc.), then you need a client tool to handle decryption and encryption operations.

They use PGP, and they have implemented this feature in a way that it's completely transparent to the user to make it mainstream. So they chose building dedicated tools (bridge, web client), rather than letting users use their own tools, because the PGP tooling sucks hard and it's extremely inaccessible for the general population.

This means that you need a fat client, whatever you do, or otherwise the server will have access to the data and there is no e2ee. Instead of using enigmail or other PGP plugins/tools, they built the bridge.

Companies have to comply with law enforcement. If anything, the little amount of data they were able to give after being forced is a good proof of their overall claim. If there is someone to blame here are courts using antiterrorism laws to catch environmental activists.

Thanks (grazie?)! I was looking for something similar and kanidm looks great feature wise and simple to deploy!

I guess Poland? I know from my colleagues that internet infrastructure jumped from old slow stuff to fiber there and it's fairly cheap.

I struggled with this for a long time, and then I just decided to use synology photos.

It has albums, tagging, geolocation, sharing. It has phone picture backup, it is inherently a backup as it's on my NAS and I back that data up again.

I want to keep the thing that I really care about the most friction free and also not too dependent on myself so that I can still experiment.

I didn't try PiGallery2 though, maybe I will have a look!

Super cool project, thanks for sharing! I think I will try to integrate it with my static sites.

Did it sound cold? Because I didn't mean that, I just meant to actually answer the question from my PoV. Just for the record, I also did not down vote you.

So yeah, use whatever footgun you prefer, I don't judge :)

Or rustic! It is compatible with restic but has some nice additions, for example the fact that supports a config files. It makes operations a bit easier IMHO (I am currently using both).

I really thought swarm was dead :)

To be honest, some kubernetes distributions make the cluster operations minimal (I use k0s managed via ansible)!

Either way, the moment you go from N containers on one box to N containers on M boxes you need to start considering how to handle stateful applications, load balancing, etc. And that in general requires knowledge on a domain which is different from having simply applications wrapped in containers locally.