rowbin's comments

Sideloading is already worse on iOS

You are using the security argument again. It is not used in an adverserial context. You are correct, that this is not secure. And messages can be tampered with. But this is not the application. The threat model of the application is that everything happens in a private context without adversaries. The communication is end-to-end encrypted and every participant of the chat has total control and is allowed to change everything in the chat, even messages from other users. So there is no point in protecting again adversaries that have access have to the secure channel, because they are already allowed to do anything, even if the hash were cryptographically secure, they are allowed to change everything. The integrity is only for synchronization, so that every participant can easily verify the state of the event history up to a specific point.

Interesting, I'd love to see some more opinions on this. I find the instant "MD5 is broken, don't use it advice" harmful. Not all applications are security related or need absolute highest speed. I actually had use cases in multiple hobby projects, but of course that doesn't there are many.

For example in a distributed event based LAN chat, I used MD5 for an "integrity chain". Every new event id is the hash of the old event id + some random bytes. This way you can easily find the last matching event two systems have in common. Just a random id isn't enough, when two instances integrate an event from a third system, while one of the two added a new event just before that.

No security needed, speed doesn't matter much, it is not designed for high throughput. MD5 seems like a very good choice, because it's easy to work with and can be verified on every system.

I think they use master for releases only. Development branch is actively worked on and more than 100 commits ahead of master which is totally active. Last full release March 2024 is totally fine. People can always build from develop branch.

Thanks for that. I loathe replys like "but lang/framework/... can do/will be able to do something similar/does something else which I like better/...". Well, it's not about that. It's about how easy it is to use, how good it is from preventing you to shoot yourself in the foot, sometimes how performant it is, ...

Because of the increased attack surface and maintenance burden. Which is totally understandable. But JPEG-XL should really be supported...

>> The stronger versions, things from List 1 and List 2, are mostly only seen in defense and intelligence

And I don't think that is enough. I agree that it easier and sufficient for most systems to just be connected over the internet. But health, aviation and critical infrastructure in general should try to be offline as much as possible. Many of the issues described with being offline stem from having many third party dependencies (which typically assume internet access). In general but for critical infrastructure especially you want as little third party dependencies as possible. Sure it's not as easy as saying "we don't want third party dependencies" and all is well. You'll have to make a lot of sacrifices. But you also have a lot to gain when dramatically decreasing complexity, not only from a security standpoint. I really do believe there are many cases where it would be better to use a severely limited tech stack (hardware and software) and use a data diode like approach where necessary.

One of the key headaches mentioned when going offline is TLS. I agree and I think the solution is to not use TLS at all. Using a VPN inside the air-gapped network should be slightly better. It's still a huge headache and you have to get this right, but being connected to the internet at all times is also a HUGE headache.

Why would the police keep the money? It doesn't get to keep other confiscated money, does it? Wouldn't the state be the "default" recipient?

IIRC Google used to do that and have a search option to specifically look for discussion type results only

But your are going backwards though. You have a sha-256 value and want to find an input with the same result. But this input again has to be a sha-256 result and you need to find an input for that as well, right? This would only work if you have the intermediate sha-256 value, that produces the final sha-256 or you can find a collision that itself is a sha-256 value.

TL;DR: risk is probably pretty low

I used to struggle with this too, but now I look at it this way: you're always at risk of being breached when connecting to the Internet (zero days in Browser, Router, maybe IoT devices on the local network, supply chain attack of some installed software, router, ...). Everything you add to your system/network adds attack surface. But: somewhat popular github projects are usually low risk, because 1) enough people are looking into it to be reasonably sure there's nothing funny in the code base, 2) it's not big enough to be an instetesting targeted for malicious actors.

I think a big part of why it feels scary is the unpredictability you mention. You don't know how you would be compromised and whether you would even notice. Sure you could get comprised and then spread the infection, but it's extremely hard to build malware like that. The much more likely scenario is the that the malware tries to steal crypto or encrypts your files. The chances that something really bad would happen are very slim (Do you even have large amounts of crypto? Do you not have any backups of important files?). In the end that's just a risk you'll have to live with (when connecting to the Internet) just like you're at risk of getting hit by a car when going outside.

Your house was $10,000-$99,999 and now having $1-$9 is a treat??

I'm counting wine

Win32 is probably as close as it gets

> needs active cooling

This sounds like a pretty big negative to me

Thanks, that helped

So like partially applied functions in Haskell?

Interesting, never heard tarballs being classified as odd before. They are still widely used.

Yes, every program will either halt or not halt. Some programs are guaranteed to halt (`int main() {return 0;}`) some are guaranteed to not halt (root comment). Some are undecidable (at least with infinite memory, with finite memory they are still undecidable in practice, because computing whether they halt or not would take until well after the heat death of the universe)

`while fetchRandomInt() != 0 {}`