Maybe one of these?

https://system76.com/desktops/

https://www.dell.com/en-us/search/linux

https://www.tuxedocomputers.com/

Cloudflare is a provider that you can choose to have as a part of your own infrastructure.

Indeed.

man in the middle implies “attack”

That can be a convenient shorthand if the parties in a discussion agree to use it as such in context. For example, in a taxonomy of cryptographic attacks, it would make sense. It is not the general meaning, though, at least not a universally accepted one. Similarly, “counter” does not imply “counter attack”, unless we happen to be discussing attack strategy.

More to the point, nothing that I wrote misrepresents the situation as was claimed by that other person. If I had meant attack, I would have said attack. Rather, they made a leap of logic because I (like most of my colleagues) don’t happen to follow a convention that they like, and picked a fight over it. No thanks.

You’re conflating MitM,

Heh… It’s safe to assume I’m well versed in this topic.

You’re going to have to prove any of your claims, or else I am just going to assume you’re talking out of your ass.

I am not, however, inclined to indulge rudeness. Bye bye.

It bugs me when people say Cloudflare is a MitM, because that is a disingenuous representation the situation.

No, it is a clear description of what is happening: Instead of https keeping the traffic encrypted from user to service, it runs only from user to Cloudflare (and then in some cases from Cloudflare to service, although that’s irrelevant here). The result is that a third party (Cloudflare) is able to read and/or modify the traffic between the two endpoints. This is exactly what we in mean in cryptography discussions by man-in-the-middle.

You can decide that you don’t mind it because it’s not a secret, or because they haven’t been caught abusing it yet, but to say it’s not a man-in-the-middle is utter nonsense.

and you opt into it.

No, the service operator opts in to it, without consulting the user, and usually without informing them. The user has no choice in the matter, and typically no knowledge of it when they send and receive potentially sensitive information. They only way they find out that Cloudflare is involved is if Cloudflare happens to generate an error page, or if they are technically inclined enough to manually resolve the domain name of the service and look up the owner of the net block. The vast majority of users don’t even know how to do this, of course, and so are completely unaware.

All the while, the user’s browser shows “https” and a lock icon, assuring the user that their communication is protected.

And even if they were aware, most users would still have no idea what Cloudflare’s position as a middleman means with respect to their privacy, especially with how many widely used services operate with it.

To be clear, this lack of disclosure is not what makes it a man in the middle. It is an additional problem.

it cannot be a MitM because both sides of the connection are aware of this layer.

This is false. Being aware of a man in the middle and/or willingly accepting it does not mean it ceases to exist. It just means it’s not a man-in-the-middle attack.

music group IFPI complained that while Cloudflare discloses the hosting locations of pirate sites in response to abuse reports, it doesn’t voluntarily share the identity of these pirate customers with rightsholders.

“Where IFPI needs to obtain the customer’s contact information, Cloudflare will only disclose these details following a subpoena or court order – i.e. these disclosures are mandated by law and are not an example of the service’s goodwill or a policy or measures intended to assist IP rights holders,” IFPI wrote.

So the corporations enjoying enormous profits from other people’s work are unhappy that Cloudflare doesn’t make it easy for them to circumvent due process. What a surprise.

(I’m generally not a fan of Cloudflare, because its man-in-the-middle position between users and services has grown to an unhealthy scale, making it ripe for dragnet surveillance and other abuses. But it would be even worse if it was actively helping these greedy, predatory corporations dodge the law.)

When I’m driving, it’s actually unsafe for my car to be operated in that way. It’s hard to generalize and say, buttons are always easy and good, and touchscreens are difficult and bad, or vice versa. Buttons tend to offer you a really limited range of possibilities in terms of what you can do. Maybe that simplicity of limiting our field of choices offers more safety in certain situations.

Or maybe being able to consistently and reliably operate the thing without taking your eyes off the road has something to do with it? Hmm… Yes, this is really hard to generalize.

A quick search for the mentioned product names found their safety data sheets:

https://www.crcindustries.com/media/msdsen/msds_en-1003333.pdf

https://www.tmkpackers.co.nz/wp-content/uploads/FUELITE-TMK-SDS-ISSUE-6.pdf

This comment from PaulG.x caught my eye:

Electronics technician with 48 years in the industry here.

The common cause of the buttons losing sensitivity is that the silicone absorbs skin oils and these oils act as insulation on the pads and tracks.

If you look at the tracks under the pads that are least sensitive , you will see the oily residue. You can clean the tracks and pads with alcohol for a short term fix but the pads will exude more of the oil that is within the silicone.

A longer term fix is to soak the whole key pad sheet in Fuelite (Petroleum Spirit) Fuelite is the main ingredient in CRC Contact Cleaner (in fact it is the only ingredient). Use liquid Fuelite to do this , not Contact Cleaner because you have to immerse the silicone sheet.

Soak the sheet for 5 minutes , it will swell a little , let it dry thoroughly and it will return to normal dimension.

While the silicone has still some absorbed Fuelite in it , it will be easily torn so treat it carefully.

Then reassemble the device.

This fix should last several months depending on the state of the silicone sheet

It’s one thing to make a reasonable assumption/prediction about how things probably are based on surrounding circumstances.

It’s quite another thing to have objective, quantifiable data showing how things actually are. Even better if it includes the fine details: the underlying reasons behind the scenes that might not be exactly what we expected.

Nobody finds a report like this surprising, but it is important nevertheless.

You can’t know with certainty on Signal that the client and the server are actually keeping your messages encrypted at rest, you have to trust them.

This is untrue. By design, messages are never decrypted on servers when end-to-end encryption is in use. They would have to break the encryption first, because they don’t have the keys.

Some advantages are listed in this /c/Technology comment:

https://lemmy.sdf.org/comment/15398090

Room membership and various other room state events are not currently end-to-end encrypted, which means a nosy admin on a participating homeserver could peek at them. (They’re still not visible on the wire, though, nor on homeservers whose users haven’t been invited.)

I don’t know if Signal is actually much better here, since I haven’t looked at their protocol. They hyped their Sealed Sender feature as a solution to some of this, but it can’t really protect from nosy server admins who are able to alter the code, and they fundamentally cannot hide network-level meta-data like who is talking with whom. There’s a brief and pretty accessible description of why in the video accompanying this paper.

I don’t have a list of Matrix events that remain unencrypted in encrypted rooms. You could read the spec to find them if you’re motivated enough to slog through it, but be warned that network protocol specs tend to be long and boring. :) Unfortunately, the few easy-to-digest blog posts about it that I’ve encountered have been both alarmist and inaccurate on important points (one widely circulated one was so bad that the author even retracted it), so not very useful for getting an objective view of the issue.

However, the maintainers have publicly acknowledged the issue as something they want to fix, both in online forums and in bug reports like this one:

https://github.com/element-hq/element-meta/issues/1214

Could someone smarter than me explain Matrix to me?

I wouldn’t assume that I’m smarter, but I do have more than a little experience here, so I’ll try to answer your questions. :)

It’s a real-time messaging platform. The most common use for it is text chat, both in groups (like Discord or IRC) and person-to-person (like mobile phone text/SMS). It supports other uses as well, like voice chat, video conference, and screen sharing, although much of that is newer and gradually showing up in clients.

What would be the utility for someone, who cares about privacy and currently uses Signal and email for communication?

Compared to Signal:

• Matrix doesn’t require a phone number, or even an email address (although some public homeservers want an email address these days, as a recovery method in case you forget your password).
• Matrix has a variety of clients, so it’s more likely that an app fitting your needs exists.
• Matrix clients typically don’t require Google services at all; neither to get the software nor to receive notifications.
• Matrix cannot be monitored at any single location, so it’s more resistant to meta-data tracking at the network level.
• Matrix cannot be shut down by any single organization, so it’s more resistant to censorship and denial-of-service attacks. If a homeserver is ever forced offline, only the accounts on that homeserver go away; all your other contacts remain intact. Same thing if a service operator changes its policies or goes out of business.
• Matrix (last time I checked) had better support for using multiple devices on the same account. Phone, laptop, and office computer, for example.
• Matrix homeservers can be self-hosted by anyone, and still participate in the global network.
• Signal’s encryption covers more meta-data at the application level than Matrix currently does. This might be important if you’re a whistleblower or journalist whose safety depends on hiding your contacts from well-positioned adversaries.

Compared to email:

• Matrix has end-to-end encryption, with forward secrecy, built in. It’s generally better for privacy than bolting PGP onto email, and it’s far easier.
• Matrix is well suited to instant messaging.
• Matrix supports features that people have come to expect from modern chat platforms, like reaction emoji and editing after sending.
• Email has a greater variety of servers and clients.
• Email apps often have more composition features to support long-form writing.

What advantage would it give me over other services?

We already covered Signal, and there are too many other services to compare every difference in all of them, but here are some more common advantages:

• Matrix is a completely open protocol, developed through a public and open process, with open-source servers and client apps. This is important to people who care about privacy because it can be scrutinized by anyone to verify that it operates as it claims to, and can be improved by anyone with a good idea and motivation to participate. It’s important to people who care about longevity because nobody can take it away.
• Matrix has multiple clients for every major platform: desktop, mobile, and web.
• Matrix handles groups of practically any size (including just one or two people).
• Matrix messages are delivered even when you’re offline.

Is Matrix anything good already, or is it something with potential that’s still fully in development?

Until recently: Ever since cross-signing and encryption-by-default arrived a couple years ago, it has been somewhere between “still rough” and “pretty good”, depending on one’s needs and habits. I have been using it with friends and small groups for about five years, and although encrypted chats have sometimes been temperamental, they have worked pretty well most of the time. When frustrating glitches have turned up, we sorted them out and continued to use it. This has been worthwhile because Matrix offers a combination of features that is important to us and doesn’t exist anywhere else. I haven’t recommended it to extended family members yet, because not everyone cares as much about privacy or has the patience for troubleshooting in order to get it. However…

Recently: The frequency of glitches has dropped dramatically. Most of the encryption errors have disappeared, and the remaining ones look likely to be solved by the “Invisible Encryption” measures in Matrix 2.0. Likewise with things like sign-in lag and client set-up.

If you’re considering whether it’s time to try it, I suggest waiting until Matrix 2.0 features are formally released in the clients and servers you want to use, which should be very soon for the official ones. I wouldn’t be surprised if I could confidently recommend it to family members in the coming year.

How tech savvy does one need to be to use Matrix?

If you just want to chat, not very. Even one or two of my friends who can barely use email got up and running pretty quickly with a little guidance. Someone who can get started using Lemmy by themselves can probably handle it on their own.

If you want to host your own server, moderately tech savvy.

Matrix Spec Change. It’s how the Matrix protocol evolves, similar to the RFCs (requests for comments) used by Internet Engineering Task Force protocols.

You shouldn’t crap on people being honest about the problems that have existed,

I haven’t “crapped on” anyone. I just pointed out that a comment, which was an absolute declaration in present tense, is misleading, poorly informed, and needlessly quarrelsome. Because it is. And the author then tried to justify it by putting words (“has always been”) in someone else’s mouth. None of that is honest. It was arguing in bad faith, and it’s important to call that sort of thing out, because letting it go is how misinformation spreads.

If they had instead just presented their view as historical experience to help inform about track record, I wouldn’t have taken issue with it.

Too much in the open source community is people saying this is great!

Perhaps, although that’s common around proprietary software as well.

Great is subjective. Matrix has struggled with some problems that rightly frustrated people, but it also has accomplished some things that no other messaging platform has. By that measure, it is a great project. And the announcement we’re all discussing here demonstrates that it is getting better. Just as barkingspiders said.

rolling their own crypto

No, it uses well-known, well-proven, standard crypto.

It also uses double-ratchet key management, much like what Signal does.

The reference server is a bit heavy if you’re federating with large public rooms, but lighter alternative servers are available.

I sometimes report such posts when I think of it.

I don’t think corporate news satisfies Rule 2 just because the corporation happens to do something with technology. (Practically every corporation does things with technology, after all.) I expect posts here to be about the technology itself.

So you were aware that this announcement includes fixes for the encryption issues, yet you decided to post a comment complaining about them anyway, ignoring the point of this post and giving readers the false impression that the issues are unaddressed.

And you did it just to contradict someone who finds the project useful.

That’s not helpful to anyone. Quite the opposite, I’d say.

This is /c/technology, not /c/stocks.

Looks like someone didn’t read the article. See part 4: Invisible Encryption. (Also note the Conclusion paragraph that explains the new functionality is only just starting to appear in clients.)