You could root it, and that would actually give you full control to delete/install/modify whatever you want.
I think the real lesson here is that if you do not have full control over a device, it is not truly yours and may disobey you.
It's like when people state that online voting should be safe because online banking is safe. I'm pretty sure if a nation state really wanted to steal a few grand from your (individual) bank account, they'd be able to do it. But it'd probably cost them more money/power in doing so then it's worth it.
You can believe in that, and trust them, but you cannot prove that, unless you have access to the source of everything installed by Google/Apple, and source of third party apps, favored by Google/Apple. But, even if you're working for a government agency and have access to sources, it's still a monumental task to do, because of the volume of the sources. It's why we, Linux owners, were crying when trivial initd and trivial shell scripts, which are easy to read and understand in about an hour or two, were replaced by Systemd, which may take days just to read source.
...
Last time somebody tried to sue Google for billing them for some random game, it didn't work out that well
Nah, most Linux owners didn't care and the fact that the most distribution voted with their feet to switch should say enough. Also, full init script were not trivial.
At this point, every distribution disables that setting, but it shows that systemd's developers cannot be trusted to make reasonable defaults, and must be double-checked to avoid blatant foolishness.
And you can't just pull out "Yeah but it might break sometime in the future" because it never has broken for me, and that same argument can be used against literally every thing in existence.
The vast majority of linux users have very positive experiences with systemd and it's cli tools are very good.
This isn't an argument about whether something "might break in the future", as you so kindly put words into my mouth. This is an argument that I do not trust the systemd developers to make reasonable choices, as they have shown a willingness to break long-standing standards for benefits that are marginal at best.
Discussion at the time: https://news.ycombinator.com/item?id=11797075 Continued defense of the decision as January 2019: https://news.ycombinator.com/item?id=19023232
I tried to read those threads but I couldn't really gather much information, a lot of the rhetoric is pretty extreme and outrageous. I would suggest to avoid ad hominem comments about "adults in the room" and such, as it distracts from your argument. (more reading on this subject here http://www.paulgraham.com/disagree.html)
Typically, logging out (intentionally or through dropped connection) sends SIGHUP to the active process, then recursively to all children. If SIGHUP is explicitly caught, then the process continues to live. With systemd defaults, logging out sends SIGKILL to processes, unless they they were started with "systemd-run --scope --user $PROCESS". In both cases, programs can persist, so there isn't a security benefit. However, one removes portability because it requires calling a systemd binary or linking against a systemd library, rather than being part of the POSIX standard.
The short-term benefit of KillUserProcesses=yes is that programs that erroneously request to be long-lived remain alive. The short-term drawback is that programs that correctly request to be long-lived are killed. The long-term benefit of KillUserProcesses=yes is nil, because programs can still erroneously request to be long-lived. The long-term drawback is increasing dependence on systemd internals, code complexity, and lack of portability. In both short and long term, the drawbacks massively outweigh the benefits.
The vitriol received in those threads was in large part due to systemd developers not recognizing those drawbacks. From their comments, requesting to be long-lived through the standard POSIX method is a hack, allowing the short-term drawbacks to be dismissed, and that a hard dependency on systemd libraries is not a long-term drawback.
With regard to my tone, perhaps I should have combined my two comments in this thread into a single one. The distributors being the adults in the room and overriding the systemd default was intended as a conclusion, to more fully describe an appropriate view toward the systemd developers. However, it appeared at the start of my second comment, and so I can see how it would appear as an attack rather than as a conclusion.
I can't agree, IMO processes left over after a network connection terminating could be considered a security hole. That's up to the sysadmin how to set it up. I certainly don't suggest getting into the habit of launching long running tasks in an ssh session, a remote sysadmin could already very easily end your processes if they find you AFK launching things on a sensitive machine. Systemd just gives some standard tools to do that.
>Typically, logging out (intentionally or through dropped connection) sends SIGHUP to the active process, then recursively to all children. [...] The short-term drawback is that programs that correctly request to be long-lived are killed.
This is incorrect, traditionally SIGHUP only means that the controlling terminal was disconnected. What you are describing is only correct for a single login shell with no sub-reapers, on a modern setup there are other things besides logging out that will send SIGHUP, such as for example if you run your program in an xterm and then close the window, or if you are operating within a sub-shell, etc. SIGHUP provides no way to differentiate those conditions, plus some programs will overload SIGHUP to be a "reload config" command, etc. SIGHUP is just not a reliable way to do it, I would not describe that as correctly requesting to be long-lived. SIGKILL is unfortunately the only method the kernel provides to do a reliable cleanup.
>The long-term drawback is increasing dependence on systemd internals, code complexity, and lack of portability. In both short and long term, the drawbacks massively outweigh the benefits.
AFAIK there is no portable or simple way to do this, please enlighten me if I am missing something. Using daemon(3) and SIGHUP is not adequate here for reasons described above. Of course other init systems are free to create their own simplified implementation of systemd scopes, while skipping the Linux specific directives if they want. So it's not clear what your actual complaint is and what you mean the drawbacks are. Do they need help doing this? If so I would be happy to advise.
>in both cases, programs can persist, so there isn't a security benefit.
This is also incorrect, in the case of systemd scopes, you can further restrict the ability to create them with polkit or SELinux or similar. So you could make it so only tmux is allowed to start one for example. That would be one of the big benefits of having a real API for this versus just sending a signal and hoping the program is well behaved.
>The vitriol received in those threads was in large part due to systemd developers not recognizing those drawbacks.
I don't think that is warranted, systemd developers can decide for themselves the trade offs of their program. The vitriol is not needed and is in fact likely to weaken the argument. In any case there are several other inits to choose from with their own set of strengths and drawbacks, I suggest focusing on what choices you have rather than agonizing over the small decisions of just one of them.
Not sure I understand why you would cry about that, systemd is actually not a very complex project if you're used to low level C daemons. The most complicated part is the d-bus portions, but those are mostly a lot of boilerplate, and you should be understanding it anyway if you use a modern system with d-bus. Trivial initd and trivial shell scripts are also lacking in quite a bit of functionality compared to systemd, at least in my experience those would tend to grow until they became brittle and unmaintanable.
unfortunately, thats a strawman position.
They all could do it, but are you aware of any manufacturer-installed malware or rootkits on a device that have? They don't steal your bank account info or impersonate you ever as far as I know, they make money off you in the same way every other company does.
If we can't show any instances, then it becomes difficult to find this materially worse than what other tech companies do. It becomes more like embarrassment from being owned by a obscure foreign company rather than a famous American one.
That account name is apt. Everybody -could- do it. Even your spouse, your best friend, your parents. They could all steal your shit. But for sanity’s sake a balance has to be struck between trust and paranoia.
These oversized American corporations are practically untouchable to the majority of people. They'll pay their laughable fines, pinky promises to better self-regulate for real this time, and move on. Leaving you in the dirt.
Got a new phone at some point and tried it again, and they were on some real shit by then. All the default built-in programs for like, /music playing/ would force you through a Xiaomi Cloud sign up process just to play music /already on your phone/.
Granted, Google is now on the same shit; I found with my latest android they've removed all the basic apps for file browsing, music playing, and the like. Now only "Google Play" versions remain, that of course require a Google account.
I feel like the camera and calculator are the only non-play-required default apps left, but I won't be surprised if I find one day that the camera is somehow integrated into Google Photos, which will of course not open until you sign in.
a) only turns its spotlight on companies above a certain size/visibility,
b) can be defeated with a large enough marketing/lobbying spend, and
c) can be waited out by companies with other lines of business that bring in profits, and
d) can be combated with cycles of withdrawing, quietly reintroducing, then withdrawing again, and reintroducing again until
d1.) media outlets get bored with it, or
d2.) all other companies in the same line start to do the same thing, a traditional way of price-fixing. Once this happens, the only way you'll be stopped is with legislation, because e.g. every TV has banner ad pop-ups from the manufacturer now.
AFAIK, Samsung and cheap Chinese brands (Vizio, TCL, and similar) do this.
Months ago I was between buying a LG or a Sony because they don't have bad reputation around this, and the LG I finally bought haven't any ad. Also, cookies, extra internet stuff, and the Alexa service can be deactivated separately without affecting apps like Netflix