• 3 Posts
  • 397 Comments
Joined 1 year ago
cake
Cake day: June 20th, 2023

help-circle



  • I think if your photos are on any kind of public website, AI idiots will scrape them regardless of the provider. So at minimum you have to password protect them. That said, I’d feel ok using this:

    https://www.hetzner.com/storage/storage-share/

    It basically runs NextCloud. You’d configure it so that only logged-in users can view the pictures, and give accounts to your friends and family. I don’t think Hetzner is likely to train AI with it, though you could check through their privacy policy. Part of the issue with eg. Google Drive is that everyone wants stuff for free, so Google recovers some of its costs by advertising, AI training, etc. Hetzner charges enough to actually make a profit, while still being IMHO affordable at the level we’re discussing. That means they don’t have to do crap with advertising etc. I have 5TB in their Storage Box product and am happy with it.

    If you want to be more hardcore, you could set up a dedicated server with an encrypted HDD, but now you have to deal with the hassles of self hosting, including backups. It still wouldn’t be end to end encryption, which would require your users to run some kind of special client, or maybe use some awful javascript client.


  • It would help if you gave some numbers. How much data, within a factor of 1000 say? A few megabytes? A few gigabytes? A few terabytes? A few petabytes? The approach you need will change depending on the level. What is your budget?

    What bothers you about cloud storage? Are any of the photos edgy?

    Anyway it sounds to me like you would be fine with a decent web hosting plan and a basic photo gallery app.



  • You’re broadcasting to family who will likely be using gmail, so what difference does it make? Google will get all the emails either way. Anyway, logical argumentation is completely useless in a personal situation like that.

    If you want the address to be stable in the long term, you should probably use your own domain name instead of gmail or proton, if you’re not already doing that. After that, it’s possible to switch the hosting without changing the email address.






  • It was ok at the time, and if it isn’t ok now, that means you want to run something that is too bloated for its own good.

    Really though, special hardware for this doesn’t make too much sense. A raspberry pi with two ethernet interfaces would be great, but if you can live with ethernet plus wifi, the current rpi’s will do it. Otherwise there are lots of similar boards that really do have two ethernet.

    I have not really felt much use for self hosted server hardware at home. I use VPS’s for that and it’s less hassle. Maybe it doesn’t count as completely self hosted, but conceptually it’s a miniature colo box.



  • Your public key block is a cumbersome thing and it’s enough to just append its fingerprint, if you consider email to be trusted against forgery but not against eavesdropping. The other person can then use the hash to authenticate your key that they get some other way (or they could just ask you to email it).

    Back in the day, lots of nerds would have their PGP key fingerprint (32 hex digits) printed across the bottom of their business cards. So if someone got a card in person, they could use the fingerprint to authenticate a key that they later received by email.

    Your post doesn’t ask about signing your emails without a good reason, but some commenter seems to think you are asking about that. That can be good, bad, or both, since it means that anyone who gets a copy of the message, including attackers, can now authenticate that the message came from you. Anything that gives attackers capabilities that they didn’t already have, must be examined critically. Dan Bernstein came up with an clever authenticator scheme designed to prevent this exact attack, but PGP doesn’t implement it and I actually don’t know of any software that does.

    Finally, at least some of the old-time PGP community now thinks that PGP solved, to some extent, the wrong problem. It not only made no attempt to conceal metadata, but it actually advertised it, in the form of key servers and key signatures connected with keys. Even if the attackers couldn’t read the encrypted messages, they could still tell who was talking to who, which is almost as bad. Remailer and broadcatch systems tried to solve this, with mixed success. A quote by cryptographer Silvio Micali has stuck with me for a long time: “a good disguise does not reveal the person’s height”. I.e. don’t just try to conceal the message contents from attackers while letting them collect other information. Rather, don’t give them ANY information.

    It’s possible to get rather “Spy vs Spy” about this type of stuff but it can help you think about security. As always, “Security Engineering” by Ross Anderson is a fantastic book if you’re interested in the general topic of how to be paranoid. Or to quote the proverb, it’s not paranoia if they really are out to get you ;). The book is here, 1st and 2nd editions downloadable as pdfs: https://www.cl.cam.ac.uk/~rja14/book.html


  • These days all those closed containers are virus spreaders so better to fly and get less exposure time. Wear an N95 either way.

    In the old days I did some long bus and train trips and it wasn’t so bad unless there were noisy or otherwise annoying people on board. Basically bring a long book to read, sleep when you can, and enjoy the scenery when there is something to look at. A travel pillow can be a help, and also warm clothes or a blanket. On international trains (EU) you can meet interesting people too.



  • If whatever they are doing has been working for stuff written in languages other than Rust, we have to ask what makes Rust special. Rust is a low level language, so its dependencies if anything should be simpler than most, with just a minimal shim between its runtime and the C world. Why does any production software have a version <= X constraint in any of its dependencies anyway? I can understand version >= X, but the other way implies that the API’s are unstable and you’re going to get tons of copies stuff around. I remember seeing that in Ruby at a time when Python was relatively free of it, but now Python has it too. Microsoft at least understood in the 1990s that you can’t go around breaking stuff like that.

    No it’s not all C99. I’m using Calibre (written in Python), Pandoc (written in Haskell), GCC (written in C, C++, and Ada), and who knows what else. All of these are complex applications with many dependencies. Eclipse (written in Java) is also in Debian though I don’t use it. Bcachefs though is apparently just special.

    Joe Armstrong (inventor of Erlang) said of OOP, “you wanted a banana but what you got was a gorilla holding the banana, and the entire jungle”. Rust begins to sound like that too. It might not be inherent in the language, but it looks like the way the community thinks.

    I also still don’t understand why the Bcachefs userspace stuff is written in Rust. I can understand about the kernel part, but the concept of a low level language is manual resource management that a HLL handles for you automatically. Writing the userspace in a LLL seems like more pain for unclear gain. Are there intense performance or memory constraints or what?

    Actually I see now that kernel part of Bcachefs is also considered unstable, so maybe the whole thing is not yet ready for production.