coffeeClean

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.

Whenever you accept the TOS, your device is somehow registered/authenticated against their servers. Such a session establishment of course should be secured through TLS, just like all web traffic in general.

The MAC address and assigned IP address are both visible outside that TLS tunnel. What information are you protecting from what threat?

Btw, the complaint of you not being able to do banking through your browser anymore while it does not support TLS 1.3 really made me laugh, thank you!

You’re confusing different situations. The TLS 1.3 issue has nothing to do with the bank. Desktop computers are not trapped on old software. Androids are. The bank requires customers to:

1. buy a new recent smartphone, repeatedly (because the bank’s app detects when it is running on an Android emulator and denies service)
2. subscribe to mobile phone service (which also costs money and also requires supplying national ID to the mobile carrier to copy for their records which you then must trust them to secure)
3. share their mobile phone number with a power abusing surveillance capitalist who promotes the oil industry (Google / Totaal)
4. create a Google account and agree to their terms (which includes not sharing software that was fetched from the Playstore jail)
5. share their IMEI# with Google
6. share all their app versions with Google, thus keeping Google informed of known vulns for which they are vulnerable
7. share with Google where they bank
8. install proprietary non-free software and trust the security of non-reviewable code
9. share the mobile phone number with the bank

I am ethically opposed to every single one of those preconditions independently, not only because of sloppy infosec and reckless disclosure but being forced to support a surveillance advertiser and also the power imbalance implied by non-free software. But just from an infosec PoV, why would a reader of cybersecurity on infosec.pub agree to all that?

I don’t think you realize just how big the risk is that you are putting yourself in with such old software.

You don’t seem to realize Android phones are designed for obsolescence and desktop PCs are not. The elimination of web access ensures users will be accessing their bank accounts with older software. Why would you endorse that? Not sure you realize that using an Android emulator ensures the ability to constantly run bleeding edge updated software. But the bank won’t have it. You also overestimate the security of code you cannot see to satisfy your threat model. How do you know the bank itself does not have spyware in their app that’s contrary to your security posture? Of course they do. They want to KYC.

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.

Since when has anyone said housing is a right?

International Covenant on Economic, Social and Cultural Rights
Article 11

1. The States Parties to the present Covenant recognize the right of everyone to an adequate standard of living for himself and his family, including adequate food, clothing and housing, and to the continuous improvement of living conditions. The States Parties will take appropriate steps to ensure the realization of this right, recognizing to this effect the essential importance of international co- operation based on free consent.

CHARTER OF FUNDAMENTAL RIGHTS OF THE EUROPEAN UNION
Article 34 Social security and social assistance

…
3. In order to combat social exclusion and poverty, the Union recognises and respects the right to social and housing assistance so as to ensure a decent existence for all those who lack sufficient resources, in accordance with the rules laid down by Union law and national laws and practices.

Universal Declaration of Human Rights
Article 25

1. Everyone has the right to a standard of living adequate for the health and well-being of himself and of his family, including food, clothing, housing and medical care and necessary social services, and the right to security in the event of unemployment, sickness, disability, widowhood, old age or other lack of livelihood in circumstances beyond his control.

wtf, why is this a graphical image instead of actual text? It’s like saying fuck the blind users and fuck those who are on measured rate internet connections. Lemmy is broken. Curl -LI falsely gives a content length of zero, so we must decide whether to download an image without knowing its size. Really fucking sucks when it’s a graphic of just text.

Your first priority should be to get on an android version from this decade. Lollipop came out in 2014 and went eos in 2016.

My first priority is to not financially support systems of premature forced obsolescence that has led to more smartphones in the world than people (despite ½ the world’s population having no smartphone at all). Buying a new phone just 6 years after another would make me part of the problem. I am writing this comment from a 16 year old machine that runs just fine. My AOS 5 device still uses the original battery. Only incompetence could explain inability of /software/ to outlive a /battery/.

I cannot think of a more absurd reason to upgrade a phone than to keep up with captive portals. Apart from that, I must say that I may have to argue in court soon that I no longer have access to my bank account because my bank closed their website and forced people to install their closed-source proprietary app from Google Playstore. It will be easier to argue in court that the bank’s software does not run on my phone than it will be to say I have philosophical and ethical objections to sharing my phone number with a surveillance advertiser just to open an account just to fetch software, of which the non-freeness I also object to. So I am trapped on this phone for higher legal endeavors.

When you say “this decade”, you’re disregarding the age and saying the line should be drawn at years that are multiples of 10. So a phone bought in 2019 would be “obsolete” in 2020 by your logic. Obviously that’s obtuse and reckless. I bought my AOS 5 phone new from the retail shop of a GSM carrier in 2018, 3rd quarter. It’s been in service less than 6 years.

Apple is borderline reckless and they officially support phones for 10 years IIRC. And that limitation is imposed by the business bottom line. Capitalism aside, engineers who can’t make a smartphone that lasts 20 years would be lacking in competency.

As for your liability comment. I highly doubt the vendor had any liability or or requirement to support such on old os.

Captive portals are a messy hack. You do not need a captive portal to supply Wi-Fi in the first place. The suppliers do not advertise “we have a captive portal”. They advertise “Wi-Fi”, which my oldest phone (AOS 2.3) and my Nokia n800 (pre-smartphone) supports out of the box. They still connect to wi-fi today. You might be right that a pusher of forced obsolescence by way of incompetently implemented captive portal can argue in court that their advertising has immunity to old devices, but this won’t fool engineers who know they’ve needlessly drawn an arbitrary line. If the truth-in-advertising outcome would be that their “Wi-Fi” sign has to become “Wi-Fi available only for new phones”, I would be fine with that.

I appreciate the suggestion. But that site is a tor-hostile Cloudflare site.

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.