What we talk about when we talk about sideloading

Definition & Framing of “Sideloading”

• Debate over the article’s use of Wikipedia: some say it cherry‑picks the “vendor‑approved” clause and misstates the term’s origin; others argue only the app‑distribution sense matters now.
• Several commenters see “sideloading” as a loaded, delegitimizing term for “installing apps outside the store,” and prefer just “installing software on your own device.”
• Others think the term is neutral, widely understood, and useful shorthand for “non‑store installs,” and see fights over wording as a distraction from the underlying lock‑down.

What Google Is Actually Changing

• New policy: apps must be signed by a Google‑verified developer identity to install anywhere (Play Store, third‑party stores, direct APK, etc.).
• Google claims “sideloading is not going away” because adb install and local dev/test builds remain allowed.
• Many argue this is misleading: requiring a registered identity for any install plus restricting on‑device installs effectively kills consumer‑grade sideloading and harms F‑Droid, NewPipe‑like apps, and private/one‑off apps (e.g., for family or internal use).
• Concern that adb could be further restricted once people build user‑friendly wrappers around it.

Security vs Freedom

• One camp: curated, locked channels significantly reduce malware for non‑technical users; some friction is desirable; phones are high‑risk devices (banking, identity) unlike PCs.
• Opposing camp: platforms already use malware‑scanning and permissions; security is being used as a pretext to enforce a distribution monopoly and protect ad/subscription revenue.
• Several note that Play Store itself hosts large amounts of malware and dark‑pattern apps, while F‑Droid’s reproducible‑build model may in practice be safer.

Ownership, Rights, and Device Control

• Strong sentiment that if you can’t install arbitrary software (or unlock the bootloader), you don’t really own the device.
• Frustration with forced updates, bundled bloat, locked bootloaders, hardware attestation, and DRM creeping from media into general computing.
• Analogies to cars restricted to “approved destinations,” smart appliances gaining ads via firmware updates, and historical light‑bulb/cartel behavior.
• Some argue phones and consoles have always been appliances rather than general computers; others respond that modern phones are clearly general‑purpose machines and should be treated like PCs.

Alternatives, Workarounds, and Regulation

• Suggested technical responses: use GrapheneOS or other AOSP forks while possible; explore Linux‑based phones (Librem 5, Pinephone, Ubuntu Touch, Fairphone); rely on tools like Shizuku, Termux, wireless ADB.
• Many point out these options are niche, expensive, or immature, and that hardware attestation and app‑side checks (Play Integrity) already limit them.
• Policy ideas: antitrust complaints (EU, US, ACCC, etc.), DMCA anti‑circumvention reform, right‑to‑repair‑style rules for bootloader unlocking and OS replacement.
• Some commenters are pessimistic about regulatory will; others see this as exactly the kind of behavior the DMA‑style laws are meant to address.