[-] coffeeClean@infosec.pub 1 points 6 months ago* (last edited 6 months ago)

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.

[-] coffeeClean@infosec.pub -3 points 6 months ago* (last edited 6 months ago)

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.

[-] coffeeClean@infosec.pub 1 points 7 months ago* (last edited 7 months ago)

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?

[-] coffeeClean@infosec.pub 1 points 7 months ago* (last edited 7 months ago)

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.

view more: ‹ prev next ›

coffeeClean

joined 1 year ago