You obviously lack a bit of knowledge about Cloudflare and how it operates. I suggest reading the link you overlooked:
I suggest also understanding a bit about Cloudflare as an organisation:
https://git.kescher.at/dCF/deCloudflare/src/branch/master/subfiles/rapsheet.cloudflare.md
Cloudflare is antithetical to every objective of the federation. Most importantly: decentralization. You don’t decentralize a platform by giving central access control and traffic visibility to a single tech giant in the US. It defeats the core purpose.
You might prefer smaller instances; … This part of it is clearly not a bug, however you put it. It is a difference of preference.
My personal preference happens to align with fedi principles. Don’t let that consistency fool you. I’m not advocating for what’s best for me. I am saying the list should be ordered in a way that’s healthy for the fedi based on the federation’s purpose and mission.
Showing the biggest communities on top may be your personal preference, but that is not healthy for the federation.
I myself am on an instance that’s almost identical in size to yours.
FYI, aussie.zone is centralized on a US tech giant (Cloudflare) and thus contrary to fedi principles. Though it’s not the worst manifestation of Cloudflare because they have whitelisted Tor. But there are still many other demographics of people likely being excluded from aussie.zone.
I do not see the value in smaller communities being prioritised when they each cover the same topic. If there’s !android@lemmy.world with 10,000 subscribers and !android@mypersonalinstance.net with me and my twelve mates, lemmy.world is the one the app should show people first. It wouldn’t matter to me whether that 10,000 is on lemmy.world or midwest.social, it makes sense to show users the place they’re likely to have the most interaction.
That is not healthy for the federation. That imbalance is a problem that Lemmy has failed to control. The disproportionately large communities need no promotion. Too many people know about them already. They should either not be listed at all or be pushed lower on the list. It’s an extra slap in the face and injustice that these are exclusive Cloudflare instances that are getting prioritized. These are instances without self-control on their growth and power.
It’s not instance-related at all.
It is instance related. If you search for Android on other instances you will get different lists. Users on infosec.pub have subscribed to every Android community in existence which makes the manifestation of the problem unique to infosec.pub. The !android@hilariouschaos.com community is also federated to infosec.pub by way of my subscription. It is true to fedi principles of inclusion and decentralization, unlike those that get listed on the top. So it’s an unhealthy sequence.
It could even be one user account that caused this. The activism.openworlds.info Mastodon instance was getting hammered with traffic. After investigation, they discovered that one user was following a shit ton of other accounts. All those follows were responsible for the admins struggling to cope with all the traffic. That instance eventually went under because it could not cope with the bandwidth demands.
This belongs in discussion around lemmy-ui, the various Lemmy apps & alternative front-ends, or in Lemmy itself with what gets returned by its search API.
The software part of the problem is specifically in the stock Lemmy web client. The bug tracker for the Lemmy web client is jailed in MS Github’s walled garden, hence why it was originally posted in !bugs@sopuli.xyz. There may be a configuration element to this, which is why it’s posted in this infosec.pub community. If there is an inactive account with all these android subscriptions, that can be remedied on the instance.
order should be descending order of size.
If bigger is better, why are you here instead of Facebook and Twitter? Fedi principles and philosophy have completely escaped you. In the fedi, we consider power imbalances, privacy abuses, and exclusivity resulting from centralization to not only worsen UX but to be an injustice. Encouraging disproportionate growth in the fedi is to advocate the destruction of what brings us here.
You seem to make the assumption that CF is storing that level of your data.
What have I said that would imply a presumption of retention?
What if I am reporting a GDPR offender who (e.g.) neglected my article 15 request? If I make the assumption you are suggesting and add to my Article 77 complaint that the data controller also needlessly exposes passwords to Cloudflare and it turns out to be untrue for that particular service, then my report loses credibility and puts a DPA on a run around.
It’s not always the case though. If you look at vivaldi.net and stackexchange, the creds take a CF-free path.
I think you can assume that your credentials go via Cloudflare.
That would be my natural assumption until the contrary is verified.
But the only thing you can do on lemmy is post stuff publicly, and presumably you are using randomised passwords, so what’s the cyber security risk?
I would not register on a CF site for anything AFAICT, and most certainly not a CF Lemmy site amid non-CF Lemmy sites (it would be a compromise for nothing and also help grow a walled garden that excludes people and centralizes the fedi to the detriment of undermining fedi philosophy). Lemmy.world is just a good example for my question because the code is obfuscated.
My problem is often that I register on a non-CF service then it becomes CF and it’s not always social media. Indeed I use unique unguessable passwords for each site. But that’s not what the masses do (I’m asking as well to work out how the masses could detect this - in principle their browser should tell them; what should I tell my grandma to look for?). I’m also trying to work out what diligent users do.
I’m not sure how many people will evade my question. So I’ll try some examples to overcome that.
Example 1
Suppose my bank becomes Cloudflared, without announcement (thus no time to pull my money out before it happens), and they charge a high fee for paper statements. The customer may choose good unique passwords, but this does not mean that password does not need to be protected. Most banks’ terms of service make customers liable for sharing creds with a 3rd party, and the ToS also includes an indemnity/disclaimer for that bank. So if creds are compromised via CF the ToS is written to make the customer liable.
Example 2
Suppose I am reporting a GDPR offender to a regulator. I want my report to be complete. If they are sloppily passing sensitive info like login creds through Cloudflare, I should check that and if yes smear them for it in my report.
Examples aside, I’m asking how a diligent user checks whether their creds are shared with CF.
They’re not at odds. We don’t have to choose between protecting UDHR Art.3 and Art.17. It’s foolish to disregard some portion of the UDHR needlessly and arbitrarily.
The real problem with @Blaster_M@lemmy.world’s comment was to blame the victim. It may be sensible to blame the victim, but let’s not lose focus on the perp.
Don’t try to strawman this. Human rights are violated when someone is deprived of their property (their data in the case at hand). If food is withheld from starving people in Gaza, your argument is like saying:
“Claims human rights are being violated because someone failed to drive a truck”
beehaw.org defederated from lemmy.ml. And I don’t blame them. I actually try not to post to lemmy.ml or any of the Cloudflare-centralized nodes (lemmy.world, sh.itjust.works, lemm.ee, etc) but it slipped my mind when I posted here.
(edit) sorry, i’m confused. I thought beehaw.org defederated from lemmy.ml, but both the post herein and the original are on lemmy.ml yet you can reach this one. So I’m missing something. I wonder if you are able to see infosec.pub-mirrored content and maybe the original community has no infosec subscribers? hard to say.
You’re very trusting of your corporate overlords. I’m sure they are grateful for your steadfast loyalty and trust.
No amount of money you pay for your phone up-front will make that malicious code magically go away. You can pay cash, and you can even tip the seller. The code that reduces your control remains in that device. If you don’t control it, you don’t own it.
If you fail to use rights granted to you by free software licenses, you can blame yourself.
You’re not getting it. Again:
If you don’t control it, you don’t own it.
Buying something does not mean you control it. You might have bought an Amazon Ring doorbell but if Amazon does not like your behavior they can (and will) render it dysfunctional.
If you don’t control it, you don’t own it.
I guess a closer analogy would be rental storage. If you don’t pay your mini storage bill, in some regions the landlord will confiscate your property, holding it hostage until you pay. And if that fails, they’ll even auction off your contents.
So in the case at hand the creditor is holding the debtor’s data hostage. One difference is that the data has no value to the creditor and is not in the creditor’s possession. It would be interesting to know if the contracts in place legally designate the data as the creditor’s property. If not, the data remains the property of the consumer.
This is covered by human rights law. Universal Declaration of Human Rights, Article 17 ¶2:
“No one shall be arbitrarily deprived of his property.”
If the phone user did not sign off on repossession of their data, and thus the data remains their property, then the above-quoted human right is violated in the OP’s scenario.
I was imagining how a well-designed mail client might detect likely tracker pixels and signal the user. If MUAs were sufficiently evolved, that kind of convenience/sloppiness of transmitting tracker pixels but then putting the switch somewhere on the server wouldn’t fly. Anyway, I appreciate the insight. It certainly raises a transparency issue.
If the creditor wants to collect on a debt, there is a court process for that. I’ve used it. It works.
Locking the phone is not repossession. It does nothing other than sabotage the device the consumer may need to actually make the payment. The phone remains in the buyer’s possession and useless to the seller.
Power is also misplaced. What happens when the creditor decides to (illegally) refuse cash payments on the debt? Defaulting is not necessarily the debtor’s fault. This in fact happened to me: Creditor refused my cash payment and dragged me into court for delinquency. Judge ruled in my favor because cash acceptance is an obligation. But this law is being disregarded by creditors all over. If the creditor had the option to sabotage my lifestyle by blocking communication and computing access, it would have been a greater injustice.
#WarOnCash
You’re still not grasping how free software works. Users have a right to see the code and the right to change it. They also have the right to redistribute the code. Your complaint is unfounded because not a single user of a fully free platform is forced to have remote management code installed.
Selling your soul for a slightly faster load time is your personal preference but arbitrarily trading off inclusion of marginalized groups of people so some people get a faster load time is not in line with the netneutrality principles that the fedi community values. Diversity and inclusion trumps faster load times of some dude in Australia.
That’s not true specifically for Lemmy. Images do not get copied. If a LemmyWorld user posts an image in a federated community, everything except the image is accessible on other instances. So those of us in Cloudflare’s excluded groups get a broken threads (people talking about an image we cannot see - we just see the discussion because only text is mirrored).
Even if you are in CF’s included group of those permitted access, if you are on a measured rate uplink you would want to see the size of an image before downloading it. That is something else that Cloudflare breaks. There is no
content-length
HTTP header. So CF also discriminates against those on measured rate connections.There are also various other circumstances requiring users to visit a thread’s copy on another host. If that other host is Cloudflare, CF’s access restrictions determine whether the user gets access. If bob@fedi-respecting.node needs to revisit an old thread to recall a link, and fedi-respecting.node had to delete the thread in a periodic cleanup to recover disk space, bob might need to access another node directly which hosted the same thread. Yes, I’ve been there. And if that other node is Cloudflared, bob will be blocked if he is in CF’s excluded groups.
Cloudflare’s wall breaks the fedi in so many bizarre ways I should probably start a log of the various circumstances that CF causes enshitification to manifest.
That’s not true either. Cloudflare gets a view on all traffic, both public and private including access credentials. Users are deceived because of the lack of disclosures about the CF MitM. E.g. users commonly expect a DM to be visible to the admins of both hosts with no idea the Cloudflare also has visibility as well. Most users don’t even know about the existence of CF. Aussie.zone, for example, is not responsible enough to disclose to users that CF has that visibility.
Of course it completely changes the equation when the same single corporation who has visibility on about half all web traffic in the world also has a view on people’s social media DMs and acct creds, it’s an all-eggs-in-one-basket kind of compromise. That abusive level of visibility increases in the extent of the compromise when all that data can be aggregated. So the centralised nature of just the data exposure alone makes it antithetical the fedi philosophy from a privacy standpoint, most particularly coupled with the masses being uninformed about it.
Certainly not. It’s centralized by Cloudflare’s access controls on all Cloudflared nodes under a single corporate policy. What aussie.zone is doing is very rare. Cloudflared nodes run with CF’s default access controls, which blindly gives CF blanket centralized authority over who gets access. This goes directly against the purpose of federation philosophy.
Even when a node like aussie.zone whitelists Tor, there are still half a dozen other demographics of people who they uniformly and centrally discriminate against and this is strictly under Cloudflare’s control and beyond the control of aussie.zone.
Of course it would. You have something like 5 of the 7 biggest fedi instances dependent on Cloudflare. If there is CF-wide downtime (regardless of whether it’s all on one data center or more realistically broken logic that’s distributed like cloudbleed was), the benefits of decentralization fails to deliver. Lack of network diversity makes disproportionately large number of people vulnerable to a single point of failure.