The nickname of kubernetes is k8s because kubernetes starts with a k, ends with an s, and in between there are 8 letters.
that is a disappointing revelation but at least now I know 
thanks
I’m sorry to tell you this, but Jill isn’t unhackable. Because “security through obscurity” isn’t security.
Obscurity in the context of security engineering is the notion that information can be protected, to a certain extent, when it is difficult to access or comprehend. This concept hinges on the principle of making the details or workings of a system less visible or understandable, thereby reducing the likelihood of unauthorized access or manipulation.
It might make it more difficult, but still very much possible. For the same reason you change the SSH default port to something else, to reduce your attempted login log-file. Not for actual security.
See also: https://wikiless.org/wiki/Security_through_obscurity
First, welcome back to the forum @RyuKurisu and to respond to your comment, we don’t actually believe using floppies unhackable. With that said, Jill doesn’t just use floppy disks alone, the data on the floppies is encrypted and most of the time not connected to the internet due to the age of the hardware and there are other factors . . . however that is way too much stuff to put on a t-shirt 
I think the review of the Xamalicious malware was seriously flawed, especially the harping on Google not managing file permissions correctly:
- Android file permissions management has been improved massively since 2020 - mainly due to the security concerns you mentioned. Specifically the “full access” permission was deprecated and constrained in Android 10 and has been completely removed in Android 11. Applications on those versions can only request access to their own data, and also can ask the user to go through a lengthy manual process to allow access to one folder that isn’t a system folder.
- The malware in question does not even use the file system permission. As reported by McAfee and elsewhere, the malware uses the accessibility permissions that allows an app to manipulate screen controls. Granted this could be used more invasively than just file system permissions, but at least get your facts straight.
- The process for enabling the accessibility control permission isn’t just “press OK on this notification” as you claimed - it requires pressing “OK”, then the app triggers the accessibility control panel where the user has to locate and select the application that they’ve just installed, then go through another dialog that says scary things such as “have full control of your device” and an eye and hand icons, and then click on “allow” button, instead of “deny” and then go back to the app.
- The comparison to iOS is indeed apt - iOS does not allow application to implement accessibility features, which is why many many people cannot use iOS as it doesn’t offer the accessibility features that they need to function and they cannot install 3rd party applications to help them on iOS. These users must choose Android as there are tons of helpful accessibility applications that can function on Android and can never be made to work on iOS because of Apple restrictions.
Using the fact that Android is a better OS - because it allows use cases that Google never designed into the system - and the fact that some users are so oblivious that they go through a rigmarole just to give malware some permissions, to attack Google about not putting enough hurdles in front of good well meaning developers that want to offer useful accessibility services to people who need it, because… “think of the children!” - this is just FUD.
This is like saying that if a Linux user goes to a web page where they read “to fix this or that problem, copy rm -rf / --do-what-i-mean and paste it in your command line” and trash their system - then that is a problem with the Linux permission system and the Linux company should really get their act together.
In order to provide useful features that a single system developer did not envision, consider and design into the system - some freedoms must be afforded application developers. This is a hard choice and its benefits and drawbacks are apparent in the Android ecosystem that both has a flourishing good and useful accessibility app market, and requires users of those apps to go through a manual process to grant the required permissions - often requiring help from friends or family to do so, because of their disabilities that necessitated such apps. If you look at any decent smart-phone accessibility review you’d note that one of Android strengths is quoted as having third-party accessibility app support while in iOS accessibility-challenged people are limited to only what iOS designers have put in place.
I find the fact that in a podcast calling itself “Destination Linux” and supposedly extolling the virtues of an open and free software ecosystems, there will be such disparaging of an open and free ecosystem in favor of a commercial closed garden with limited capabilities offered by an oppressive commercial company that mistreats app developers - to be deeply disappointing.
First, thanks for sharing your thoughts on this episode and while my responses below may seem blunt, I want to be clear that I appreciate the feedback and it has made me revisit this topic so I can be better informed on future episodes.
This is fair, there have been many changes for the permission system of Android in the past couple of years. I do acknowledge this and thanks for pointing out the “full access” permission was remove. It should have never existed in the first place but good its deprecated.
I think it is also noteworthy that historically Android’s permission system has been not just bad but hot garbage for at least 12 years. I am happy to see them improving it but it still needs some work. The fact that a color control app for an LED light can require GPS permissions to function, not just request but require this permission is still hot garbage.
We didn’t say it was using the file system permission. We didn’t even say “file system permission” at all so not sure why you are complaining about “getting your facts straight” when we didn’t even say “file system”.
Okay sure, it’s 3 “Okay’s” instead of 1. Yes, it does warn the user and that is great but if this were an effective solution the issue wouldnt have worked so clearly this warning does not warn enough. I am sure the people who allowed it, did not read the message and simply pressed “Allow”. The minimum is text warning but the icon at the top should not be the app icon, this should be a large red warning icon. Yes, people ignored the warning and got infected but the warning is not sufficient and we both know that people would absolutely click that Allow without reading it. Yes, this is their fault but Google should change the icon to an actual warning icon at the very least.
Apple provides a lot of accessibility features themselves built in . . . but what are the functions that iOS doesn’t have that Android users can have because of this permission allowance? *Note - this is a genuine request for details
First, which is a better OS is subjective. Second, we never took a stance on which was best for accessibility. We said iOS’ permission system is more strict and that being a good thing. Accessibility was not in the discussion here so this argument has no relevance to what we said.
This is an analogy to a point we never made. However, I will respond anyway. This is much different since the Linux system requires sudo and your password to run this. “–do-what-I-mean” is not a real flag in rm, you have to type “–no-preserve-root” which is much more specific. Beginners wouldnt know what preserving root means but it might make them stop when seeing “preserve”. This also has to be done in a terminal which will scare some people from even attempting. So yea, this is not the same thing.
by the way, you probably mean the “do as I say” thing that Debian used to do but finally fixed making that much harder to do.
what apps are overwhelming valuable on Android vs iOS in this case? I am very curious.
Android is not an open and free ecosystem. Google requires the use of Google Play Services for a vast majority of Android features and all of the apps that were open on Android were closed by Google years ago, it is now just a skeleton system they offer in AOSP. I don’t know what your criteria is for calling Apple “oppressive commercial company” but I would bet whatever the criteria is probably also applies to Google just as much. Google used to be a company that I supported proudly and Android used to be the only platform I would consider and then they decided to do messed up stuff and drastically limit Android in terms of openness that it lost it’s credibility to be anything other than yet another massive tech conglomerate.
Here’s the transcript of that part where you describe Xamalicious:
and here’s how it works - Android of course has a terribly orchestrated privilege system in Android, as we all know, and they have a thing orchestrated Android store, so when you combine these two things together - what it allows them to do is to have a company like that come in and abuse both those things,. So because for some reason an app has the ability to request cart-blank [sic] access from the user to have access to everything in the file system on an Android device is the user gets the little popup and clicks OK “allow access” now…" [Gets derailed about the popup being hidden behind other things or otherwise clicked by mistake - which isn’t possible on Android]
You are correct that you didn’t say “permission”, you said “privilege” - which except that being the same thing is also incorrect in that the technical term used everywhere is “permission”, so I just used the more correct and used term.
The reason it must be the app icon is that the user isn’t just presented the popup when the application runs - as I’ve explained - they need to go into a control panel and find the app in a list of accessibility apps and tap it - which is why you need the icon: to help the user find the app in a list that can be larger than the screen, and then in the popup shows the user that they chose correctly. This is basic UX stuff. The McAfee article’s example only shows the malicious app in the list, but that list often includes more - I have 4 such apps on my device and people with serious disabilities often have more. If you stop treating this process as a poorly designed backdoor to sneak malware and look at it as a system attempting to allow useful workflows and trying to find a compromise - you’d see it makes sense.
I understand that you think there should have been yellow stripes up and down and red sirens when a user tries to grant accessibility permissions, but the point of the exercise isn’t to scare users away from installing useful apps, nor to train users to click “OK” every time a scary dialog pops up (like Windows UAC does) but to give user a calm explanation that “full control is appropriate for apps that help you with accessibility needs, but not most apps”.
I don’t understand how a Linux enthusiast can be against treating users as rational thinking beings.
As I’ve mentioned above, there are many useful and good accessibility apps that do stuff even iOS developers didn’t consider - or considered and decided not to implement because one company, no matter how big, cannot create all the software everyone will ever need, even if they try really hard (see Joy’s law). You can peruse the Android Play store’s accessibility section, or I suggest reading Accessibility Spark’s “Awesome accessibility apps for Android” article - while some capabilities offered by such apps are available on iOS - a lot aren’t, but these apps exist because people need these features.
Google’s Android team can make less built-in features, and even move some features to standard apps offered on the market, which they do - there’s quite a few Google developed accessibility apps that you can install just like any other accessibility app - because there’s a rich ecosystem were 3rd party developers that are more knowledgeable about accessibility needs can come in and fill the gaps. And if you don’t need accessibility help, then your device’s OS is now smaller, faster and easier to maintain.
I obviously know that 
I was trying to avoid using the real flag because the whole point of this UX is that if a user tries to remove their root, they get a warning and the correct flag to use, so they have to read and understand what they are doing. Giving the actual flag in the text defeats that - which is why in the past that flag wasn’t even in the man page.
Maybe that’s a solution to the accessibility permissions issue - there should be a math-captcha-like text box “if you really want to install this, what’s the answer to the question you were asked in the description” (this was sarcasm, mind you, this won’t actually prevent people that insist on doing stupid things from doing them, see: “greater fool, n.”).
I’m talking about 3rd party developers (the OS and services being free/open or not is a good argument, in which Google is still massively better than Apple, but let’s leave that aside).
Apple start by requiring all developers to run (a recent) Macos and pay them $100/year/dev, then has horribly strict limitations on what apps can be offered on their store - you cannot offer certain kinds of apps at all (e.g. non-safari browsers), or get special permission in writing ahead of time (e.g. offering paid subscriptions through your own processing, but only if you are big enough), they often prevent updates for existing apps for all kind of stupid and often mysterious reasons (e.g. the WordPress app debacle, the Hey email client debacle and tens of thousands more you haven’t heard of) or your update can get stuck in some queue for 3 weeks, they are not allowing side loading apps at all (there’s some affordance for testing new apps, but it is very limited and you have to jump through hoops), and - of course - they prevent 3rd party app stores at all (or unless you’re in the EU and pay them $1M and don’t have the wrong colored “get” button, see Epic vs. Apple). I had an app update rejected because a reviewer decided that they need me to provide them an account “so they can properly test” (even though account creation is free and uses a callback feature for verification).
The Android Play store, OTOH, accepts apps without requiring pay-to-play, has no limitations on the type of apps that you can offer, updates always go through quickly and you can always sideload apps or get them from many (free to create and install) 3rd party app stores.
Yes, the down side is that there are a lot more avenues to sneak malware into users’ devices, but that’s the price you pay for freedom, and Google tries really hard to fight that with on-device scanning (if you install their optional closed source Play Services1).
1) this is a dig at Apple where none of the services are optional, even if you don’t use them - such as iCloud that turns itself on after being turned off and always stores some of your data in the cloud even if you turned it off.