[-] [email protected] 3 points 4 months ago

This comment is a perfect example of why I have written https://loudwhisper.me/blog/proton-fediverse-burnout/

The 88 thing is the complete tip of the iceberg for me. I can't honestly imagine the thought process needed to reach a conclusion that a Taiwanese guy (8 is a lucky number) born in '88 would put that number as a dog-whistle (which is not really part of his own cultural landscape) for Nazis, while dealing with a PR issue.

It's like looking at a crashed car, tire marks on the ground and suggesting it must have been a sharknado and not a car accident.

[-] [email protected] 2 points 4 months ago

Yes, that's absolutely true. Assuming a full PGP flow, (e.g., proton to proton) even in that case the recipient and other metadata (in tuta, excluding subject line) is still visible to the provider.

Hopefully the more people move to secure providers, the more the general case will be transparent PGP, but we are a long way from there...

[-] [email protected] 3 points 10 months ago

Not that I know, which is the reason why I essentially didn't consider those threats relevant for my personal threat model. However, it's also possible it happened and it was never discovered. The point is that there are risks associated with having the same provider having access to both the emails (and the operations around them) and the keys/crypto operations.

The cost of stealthily compromising a secure email company is simply disproportionate compared to the gain from accessing my emails. Likewise, it's unrealistic to think some sophisticated attacker would target me specifically to the point that they will discover and then compromise the specific tooling I am using to access/encrypt/decrypt emails. Also, a $5 wrench could probably achieve the same goal in a quicker and cheaper way.

If I were a Snowden-level person, I would probably consider that though, as it's possible that the US government would try to coerce -say- Proton in serving bad JS code to user X. For most people I argue these are theoretical attacks that do not pose concrete risk.

[-] [email protected] 3 points 10 months ago

Thanks!

Can you make the images clickable? They’re impossible to read at that size.

I will look into it, there might be a zola option for it. If there is, sure!

This paragraph should probably mention that this won’t work if the provider uses E2EE

That paragraph is in the context of what I call "transparent encryption", which means E2EE works until the provider is not compromised and the E2EE is effectively broken by delivering malicious software or disclosing the key. E2EE is as resilient as the security of the provider, which is why picking a trusted one is important. Of course, compromising the provider and breaking the E2EE is quite complex.

[-] [email protected] 3 points 11 months ago* (last edited 11 months ago)

Oh, it looks like! Something went wrong with Zola build and I must have not noticed. Thanks a lot for pinging me about that, I will fix it today!

EDIT: Fixed! That's what you get when you forget to bump the Docker image version after you upgrade zola version locally with a breaking change in the config! :) Thanks for letting me know, it would have taken me a long time to see it was broken!

[-] [email protected] 3 points 11 months ago

Yes, I have used it in the past and it was annoying...

You can get SSL certs with letsencrypt, but you need to use the http verification method.

[-] [email protected] 3 points 11 months ago

That is basically the essence of this post too! Except crowdsec is used to do what fail2ban does + some light form of WAF (without spinning another machine - which is not strictly needed for a WAF, you can use owasp modsecurity-ready proxies).

[-] [email protected] 2 points 1 year ago

I will have a look if there is something that suggests how to "make" a light theme. Thanks for the info!

[-] [email protected] 2 points 1 year ago

Why not outsourcing just the hardware then? Dedicated servers and Kubernetes slapped on them. Hardware failure mitigated for the most part, and the full effort goes into making the cluster as resilient as possible, for 1/5 of the cost of AWS. If machines burn, it's not your problem (you can have them spread over multiple sites, DCs, rooms, racks) anymore.

[-] [email protected] 2 points 1 year ago

Not OP, but they are comparable efforts, especially since it's a relatively infrequent activity. You can rent dedicated boxes with off-the-sheld hardware almost instantly, if you don't want to deal with the hardware procurement, and often you can do that via APIs as well. And of course both options are much, much, much cheaper than the Cloud solution.

For sure speed in general is something Cloud provide. I would say it's a very bad metric though in this context.

[-] [email protected] 3 points 1 year ago

but that also shows that most modern software is poorly written

Does it? I mean, this is especially annoying with old software, maybe dynamically linked or PHP, or stuff like that. Modern tools (go, rust) don't actually even have this problem. Dependencies are annoying in general, I don't think it's a property of modern software.

Yes, that’s exactly point point. There are many options, yet people stick with Docker and DockerHub (that is everything but open).

Who are these people? There are tons of registries that people use, github has its own, quay.io, etc. You also can simply publish Dockerfiles and people can build themselves. Ofc Docker has the edge because it was the first mainstream tool, and it's still a great choice for single machine deployments, but it's far from the only used. Kubernetes abandoned Docker as default runtime for years, for example... who are you referring to?

Yes… maybe we just need some automation/orchestration tool for that. This is like saying that it’s way too hard to download the rootfs of some distro, unpack it and then use unshare to launch a shell on a isolated namespace… Docker as you said provides a convenient API but it doesn’t mean we can’t do the same for systemd.

But Systemd also uses unshare, chroot, etc. They are at the same level of abstraction. Docker (and container runtimes) are simply specialized tools, while systemd is not. Why wouldn't I use a tool that is meant for this when it's available. I suppose bubblewrap does something similar too (used by Flatpak), and I am sure there are more.

Completely proprietary… like QEMU/libvirt? :P

Right, because organizations generally run QEMU, not VMware, Nutanix and another handful of proprietary platforms... :)

[-] [email protected] 3 points 1 year ago

Not to the level I can get with rofi and i3. The only way to get somewhat similar is to use yabai, which needs SIP disabled to have somewhat similar features.

view more: ‹ prev next ›

loudwhisper

0 post score
0 comment score
joined 2 years ago