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.)
“Welcome to the dark side of cozy.”
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.
Cloudflare has a long track record of not abusing that position, though.
Well, Cloudflare is not all that old, and we can’t see what they do with our data, so I would say it has a medium-length record of not getting caught abusing that position. But that’s not the point.
The point is that most Lemmy users’ actual browsing is in fact not private between them and their server. Many instances have a big network service corporation like Cloudflare watching everything read or written by every user, so that info is available to anyone with sufficient access or influence there, like employees and governments.
That applies to most of the internet,
Not exactly, but it does apply to a great many of the biggest web sites, so we could say it applies to much of the internet’s traffic.
And that’s part of the problem. Cloudflare is in a position to watch much of what people do on the web, across many unrelated sites and services (often including domain name lookups), and trivially identify them. This includes whatever political, religious, or NSFW posts they’re reading on Lemmy, and who they are when they log in to their bank accounts.
In any case, I replied not to be pedantic, but just to let our community know that they shouldn’t assume their reading habits on Lemmy are safely anonymized behind a made-up username, or confidential between them and their instance admins. If your instance uses a provider of DDOS protection or HTTPS acceleration, as many big instances do, then the walls have ears.
Your actual browsing of lemmy is moderately private, provided you trust your server.
Not exactly. Many of the big instances have Cloudflare (or similar) sitting between you and the server, providing the HTTPS layer while watching everything you read and write on Lemmy. In cryptography circles, we call this a man-in-the-middle.
Your instance (sh.itjust.works) is one such instance, by the way, as is lemmy.world.
A quick search for the mentioned product names found their safety data sheets:
https://www.crcindustries.com/media/msdsen/msds_en-1003333.pdf
| Chemical name | Common name and synonyms | CAS number | % |
|---|---|---|---|
| 1,1,1,2-tetrafluoroethane | HFC-134A | 811-97-2 | 45 - 55 |
| 1,1,2,2-tetrafluoro-1-(2,2,2-trifluoroethoxy) ethane | HFE-347PCF2 | 406-78-0 | 45 - 55 |
https://www.tmkpackers.co.nz/wp-content/uploads/FUELITE-TMK-SDS-ISSUE-6.pdf
| Chemical Ingredient | CAS No. | Proportion (% ) |
|---|---|---|
| Heptane and isomers | mixture | 35 - 55 |
| Cyclohexane | 110-82-7 | 25 – 35 |
| Methylcyclohexane | 108-87-2 | < 15 |
| Hexane | 110-54-3 | <10 |
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 important to post these things every so often. There will never be a day when everyone already knows. :)
It’s a bit of a leap to say the “owner” changed. Ryujinx is MIT licensed, allowing anyone to clone the original code locally, build upon it, and publish it to a public host. Looks to me like that’s what happened here: a fork, but without using github’s built-in “fork” feature, perhaps to avoid being included in a mass take-down. There are others on non-github sites, although I don’t know if they have been getting new commits.
I don’t see any reason to think the original repo was renamed or moved to another user’s account. The top contributor is gdkchan presumably because gdkchan’s commit history was preserved.
For the record, gdkchan’s last commit to the original repo was on 2024-10-01.
Edit: The README confirms what I thought:
This fork is intended to be a QoL uplift for existing Ryujinx users. This is not a Ryujinx revival project.
Beware online “filter bubbles” (2011) - Eli Pariser
https://www.ted.com/talks/eli_pariser_beware_online_filter_bubbles
Ah, so it is. I wonder when that happened. I guess .world might have outgrown beehaw’s ability to make up for spotty moderation.
I’m pretty sure they don’t block sdf. That’s where I am, and I’ve had several interactions with Beehaw folks while here. :)
Fun fact: Beehaw and sdf are among the few well-known instances that don’t hand their users’ traffic (all their activity on Lemmy) over to Cloudflare.
I know by having seen it discussed in one or two beehaw communities, but you can look it up here:
One of those is dead.
One is blocked by OP’s instance.
One is hosted on an instance that more than a few people avoid.
One is nearly empty, but maybe worth joining and starting some discussion? [email protected]
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:
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:
Indeed.
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.