That depends on the device, not the OS.

1. I don’t know, but according to this page, it seems there is some kind of profile support. I assume it’s part of the Android Open Source Project.
2. (Good thing I noticed that you edited your comment to insert this question.) I am not aware of an effective Google Play sandbox from any OS other than GrapheneOS. It doesn’t affect me either way, since I don’t use Google services.
3. Storage encryption is built in to Android these days. I don’t remember whether the latest version does it with file-based encryption or full-device encryption. (Both have been used in the past.)
4. It depends on who your adversary is. For example, a Google employee or a government might have remote access to a back door planted in a Pixel, but not to your boot loader. On the other hand, a TSA employee might be able to pwn your phone if granted physical access, but unable to do anything remotely. Pixels are generally more resistant to to physical access attacks because they allow user-supplied keys and boot loader re-locking, but there are companies that sell tools aiming to bypass even these protections, so I wouldn’t bet my life on them.

GrapheneOS is better in principle, but it requires that you (directly or indirectly) give money to Google and depend on Google-controlled hardware, both of which are dealbreakers for some people.

GrapheneOS also depends on hardware support files from Google, which are no longer readily available, making its future unclear.

LineageOS supports a greater variety of devices. The privacy/hardening features aren’t as strong as GrapheneOS, but many people find it good enough when:

• Google Play Services are not installed
• Commercial apps are not installed (open-source apps from F-Droid are the usual alternative)
• There is little risk of an adversary gaining physical access to the phone

Trying to discredit people because of the forum on which they discussed a topic, or because you view them as beneath your skill level, is a more than a little misguided, and frankly, disingenuous.

Epic themselves have admitted to copying Steam data and scanning running processes, as has been documented in various news articles. (example, example)

In any case, the point is not one particular incident or report, but rather that they have the capability, grant themselves permission to use it via their policy documents, and have earned distrust among a lot of gamers. Posting condescending emoji here doesn’t change that.

Edit: P.S. In future comments defending Epic, you might do readers the courtesy of stating up front that you are moderator of an Epic Games forum.

You might want to read my other comments elsewhere on this post.

Please keep in mind that no matter what technical measures you take, accepting Epic’s “free” games requires agreeing to their terms and conditions, which they can change after you get the games. I really don’t recommend it.

I do not recommend running Epic software at all.

You could download and play the games on a machine that is never used for any other purpose, but it would still be able to collect biometric data (mouse movement, keystroke patterns, voice if you have a microphone, etc.) and probe/fingerprint your network.

Short of a dedicated machine, the closest you’re likely to get is a hypervisor-based virtual machine. Of course, that won’t safeguard your biometrics or (in most cases) your network, either.

Such a machine would be safer if you never gave it network access, so it couldn’t exfiltrate any data that it had collected, but downloading games requires network access at some point, and it would only take milliseconds for a “helper” process (perhaps quietly installed or launched with the game) to leak the data.

In general, hostile code will always be unsafe. If it concerns you, it’s best to avoid it entirely.

Flatpak permissions are famously coarse, and its sandboxing mechanism is weak and full of holes. It can be useful for guarding against damage caused by programming mistakes, but I would not recommend it to anyone wanting protection from adversarial software.

Heroic Games Launcher doesn’t change the code in the game executable itself, so yes, it is still an issue when using Heroic.

One catch is that Epic’s mystery code is allowed to execute on your computer.

Note that I don’t mean just their launcher. Often, if not always, the games themselves are linked with Epic code, ostensibly for license checks and/or integration with Epic services. This gives them the ability to snoop on stored data, installed/executing processes, biometrics, etc.

Running those free games with an alternative launcher does not protect against this.

It’s not just a theoretical concern, either. Epic has already been caught copying Steam files, collecting friends play history, and scanning running processes.

https://www.resetera.com/threads/developing-epic-games-launcher-appears-to-collect-your-steam-friends-play-history-up2-valve-responds-see-threadmarks.105385/

https://old.reddit.com/r/fuckepic/comments/wakewr/epic_games_spyware_vs_steam_vs_as_comparision_ea/

https://www.pcgamesn.com/epic-launcher-spyware

I don’t trust them, their CEO, or Tencent (which owns a significant chunk of Epic), so I don’t run games that come from them.

Tencent owns a substantial portion of the company, and therefore has substantial access and influence. Nitpicking about the percentages is irrelevant.

Let’s be careful how we phrase things here. JavaScript form submission and navigation are choices, not needs.

Also, progressive enhancement / graceful degradation exists. When competent developers (or bosses) want script effects on our sites, we can include them and make the sites continue to function with scripts disabled. It might require more work, but it is absolutely possible.

Framing the script-based approaches to these things as if they were needs contributes to the problem, IMHO.

(I am referring to the vast majority of web sites, of course, not special-purpose web applications like games.)

Web developers are complicit in browser fingerprinting, by insisting that sites require JavaScript (or WASM).

All of us are complicit in browser fingerprinting, because we tolerate this script dependence.

IMHO, a web site being allowed to execute arbitrary code on visitors’ hardware should be an anomaly. The vast majority of them could be built to deliver the same information without requiring that inherently dangerous permission.

I bought an empty stainless steel bottle and fill it myself. :) It doesn’t take long for that to be cheaper than buying plastic bottled water.

Does it sound to anyone else like the video’s narrator used a pitch shifter on his voice? I wonder if he’s aware that a pitch transformation like that can be trivially reversed.

Let’s not forget that stainless steel drinking bottles exist, and some booze can be bought in ceramic bottles, so we do have safer alternatives for transporting/holding beverages. There are fewer options for carbonated drinks, of course.

If you put a SIM into a phone that has power and cell access, then an association between the SIM and the phone’s IMEI will be recorded somewhere.

If your identity is linked to that SIM, then it’s only one more step to link your identity to the phone, of course. You’ll have to decide for yourself whether that’s unsafe for you.

It’s also behind a third-party captcha service, which can fingerprint your browser, and collect a history of which articles you read and what pages you come from to view them.

Last I checked, archive.org usually didn’t work when articles are paywalled. Has that changed?

In my experience, it depends on when the snapshot is made. If made early enough that the paywall was not yet in place (probably because publishers want their articles to be indexed by search engines) then it will not have the paywall.

One nice thing about archive.org’s mirroring is that they list all their snapshots of a page by date and time, so if the latest one contains a paywall, you can sometimes go back to the first one and find it with no paywall.

I guess rsync can be told to remove removed files on the destination, too?

Yes. The --delete family of options are relevant here.