lemmyvore

Why do you assume they haven’t warned Mozilla in advance?

Also, Mozilla was fully aware that what they were doing is in breach of GDPR. I find it extremely hard to believe that the makers of Firefox are not fully familiarized with it by now.

Last but not least Mozilla is doing this for financial gain. It’s selling pur data to advertisers. Why should we excuse it? It’s a very hostile act.

If Mozilla has hit rock bottom and has been reduced to selling our data to survive then that’s that. We’ll find another way and another FOSS browser. Accepting it is not an option.

So what, are we giving Mozilla a free pass to do anything now? Is the new bar “not quite as shitty as Google”?

Bayesian filters are statistical, they have nothing to do with machine learning.

You should consider if you really want to integrate your application super tightly with the HTTP protocol.

Will it always be used exclusively over a REST-ful HTTP API that you control, and it has exactly one hop to the client, or passes through hops that can be trusted to never alter the HTTP metadata significantly? In that case you can afford to make HTTP codes semantically relevant for your app.

But maybe you need to pass data through multiple different types of layers and different mechanisms (socket protocols, pub-sub, file storage etc.) In that case you want all your semantics to be independent from any form of transport.

It’s a perfectly fine way of doing things as long as it’s consistent and the spec is clear.

HTTP is a transport layer. You don’t have to use its codes for your application layer. It’s often done that way but it’s not the only way.

In the example above the transport layer is saying “OK I’ve delivered your output” which is technically correct. It’s not concerned with logical errors inside what it was transporting, just with the delivery itself.

If any client app is blindly converting body to JSON without checking (at the very least) content type and size, they deserve what they get.

If you want to make it part of your API spec to always return JSON that’s one thing, but don’t do it to make up for poorly written clients. There’s no end of ways in which clients can fail. Sticking to a clear spec is the only way to preserve your sanity.

But denormalized databases are not a new thing. There are engines that build on it on purpose in order to be more efficient, like Cassandra. Most data warehousing engines use this “trick”. And of course you can do it with a regular RDBMS too.

To some extent all software is disposable. Some places take it to a more ridiculous level than others. If they have money to burn just make sure as much of it as possible ends up in your pocket.

Oof. I guess you can use typescript to make up for lack of IDE but it sounds like you had bigger problems anyway.

You know, you can validate data structures at runtime… and write unit tests… TS is not a substitute for those things.

Typescript only prevents typing bugs… why did they have so many typing bugs?

Who were they talking to.

I blame whoever had their chat open at 1am.

Which part do you think it’s FUD, and why?

PGP is not particularly related to email. It’s also used to encrypt files, partitions etc.

You can use public key cryptography with any system, because you simply encrypt the content and then send it through the normal unencrypted system.

But PGP does nothing for the headers and nothing for the fact messages are still waiting around on various servers. Also PGP on its own is very impractical due to the need to get keys for every recipient – but even if there were a generalized system of public key autodiscovery (over DNS) it still wouldn’t fix the problems with IMAP/POP3/SMTP.

Each of these things holds a piece of the puzzle – including what Proton & Tuta are doing – but these pieces on their own are useless. We need all of them to come together.

1. The email stored on T/P is not end-to-end encrypted. T/P have access to it without going through you. Why? Because that’s how email works. When receiving mail, their server is contacted by another (non-encrypted) server who says “I have a message for you, accept it and store it”. And they have to be able to do that 24/7 without involving you. Same for sending, they have to take your message and store it for several days until they can send it out in clear and another (non-encrypted) server has confirmed it has accepted it. Any pretense that any of this is secure is just security theater.
2. You cannot have multiple clients on multiple devices, because they’ve replaced standard protocols (IMAP and SMTP) with their proprietary wrappers to maintain the pretense. So you can only use their apps (insofar as they’re available for your devices), or their webmail, that know how to speak the proprietary protocols. This locks you into their service.

You can’t do secure email. You really can’t, sorry. Point (1) above is a game-ending design flaw that makes it impossible, and (2) is just lock-in and hoops to jump through without really adding anything of value.

You could do remote encrypted storage of your email archive but only if you give up the notion that you can also allow that storage server to send and receive messages for you. If they have access then it can be subverted and the whole proposition is worthless.

The way to achieve such storage is by using a remote file storage service reflected locally as a virtual filesystem, preferably with the encryption layer controlled by your device not their service, and use it to store messages managed by your local email client. Your local email client would then use IMAP and SMTP connections to unrelated email servers to send/receive messages. But you’d have to replicate this stack on every device, which is impractical.

The better approach is to self-host your mail archive, with a webmail client on top connected to a SMTP service, and have a local tool on the server that pulls emails from a POP3 server and deletes them afterward. And you can encrypt the disk there if you want, and use whatever you want to access your archive (regular email clients or webmail).

Frankly, I can’t really wrap my head around what services like Proton and Tuta are trying to do, so in turn I can’t get a clear idea of the threat model.

They’re basically running encrypted file storage servers that are used to store email messages, forcing their users to use proprietary protocols to access them. But sending and receiving email messages implies messages passing through other, non-encrypted servers.

The only scenario where they’d approach anything resembling security is if both the recipient and sender are on the same service. Not even passing messages between two such services (Tuta & Proton) is really secure. And since the vast majority of the average user’s messages are exchanged with other servers it means that the vast majority of their messages have a copy in clear on at least one other server out there, and have passed through clear relays that are also not encrypted at rest, making more potential copies available.

So what exactly is solved by having one copy encrypted if there are non-encrypted copies readily available?

They just need to tunnel the data and let the client decrypt it. Basically what Proton does with their bridge app. And also basically what Tuta’s client does.

Yeah that’s about what I had figured too, 400-600 kWh/mo per house during summer. Double that is more likely to be estimated capacity rather than actual use.

Um, why does the average Chinese home consume 1 MWh/mo? Or do they mean the battery capacity would account for one home consuming up to 1 MWh?

This whole debacle is a festival of stupidity:

• It’s a personal project that taxes the sole maintainer disproportionately.
• Millions of idiots use it blindly and end up building elaborate software on it. https://xkcd.com/2347/
• I’ll bet you 99.99% of those idiots use it only for ip.isPrivate(), which you can write yourself in 5 minutes.
• The CVE is a non-issue (who the fuck would call a function that takes string notation with hex numbers?)
• Appealing and reverting or downgrading CVEs is super complicated.

At this point the maintainer is fucked no matter what they do, so archiving the project and telling everybody to fuck off right back was really the only sane thing to do.

Then fork it and do that.

These projects are structured as hobbyist projects and get whatever time the maintainer can spare. I have projects like that, they’re useful, but I’m not gonna prioritize them over… anything else, come to think of it.

The fact so many people treat a hobbyist project with one maintainer as critical infrastructure is insane, but that’s on them. Everybody likes free software, nobody likes to help or pay the maintainer.