1178
this post was submitted on 03 Oct 2025
1178 points (99.2% liked)
Not The Onion
18294 readers
1486 users here now
Welcome
We're not The Onion! Not affiliated with them in any way! Not operated by them in any way! All the news here is real!
The Rules
Posts must be:
- Links to news stories from...
- ...credible sources, with...
- ...their original headlines, that...
- ...would make people who see the headline think, “That has got to be a story from The Onion, America’s Finest News Source.”
Please also avoid duplicates.
Comments and post content must abide by the server rules for Lemmy.world and generally abstain from trollish, bigoted, or otherwise disruptive behavior that makes this community less fun for everyone.
And that’s basically it!
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
"They" is now a dirty word?
Sideload wasn't loaded language before Android OS and still isn't: it's a bogus, overreactive claim.
All of them are valid install methods. Developers will always need a way to load their experimental apps not yet suitable for release: they won't block the methods they need to do that.
Clear use cases for casual users exist for
"They" are drama-queens, because despite legitimate use cases to address actual problems posing high-cost risks to users (even as Google turns out to be a shitty authority) & clear documentation that power users can still install any package they want, they choose to catastrophize.
"They" is a pronoun. Hope that helps clear things up.
The term "sideload" was coined by i-drive, a bunk dot-com contributor who applied to trademark the term because they were corporate ghouls. Their version of sideloading involved giving them a link to a file on the internet, and they would store it for you, so you didn't have to download it yourself. The idea behind sideloading is just transferring a fucking file. It's loaded language, despite whatever freedom or restrictions an implementation provides. Call it what it is, a file transfer.
What about the clear use case for a FOSS developer who doesn't want to go through the Google authority for validation? What happens when Google thinks an app is dangerous when it shows no clear malicious behavior? What happens when Google enforces the idea that blocking ads is malicious?
In my opinion, what a massive understatement.
Edit: Put the documentation where your mouth is. Show me the "clear documentation that power users can still install any package they want," because F-Droid would like to have a word with you. While you're reading that, do take care to note that Google already has a service to protect against malicious applications. They don't need to limit application installs based on developer registration. They need to make a profit for their shareholders. They're corporate ghouls.
Not the question.
Nothing you wrote supports that. In the i-drive case, it draws a distinction between a (1) direct transfer between remote systems (without intermediary) and (2) a transfer between a local & remote system.
Other OSs have this concept. My first exposure to the concept came from administering Windows systems. Their definition draws an unopinionated distinction between official & unofficial distribution channels
& their distinct installation methods with similar caveats
That's the entire point of the term there: to express that the installation method & checks differ.
Sign it yourself or bypass verification as stated before.
It was linked above: try reading.
which is reactive & doesn't deter the installation of malicious apps via sideload like the new feature will.
Hey man, just interested if you’d like to write more bootlicking prose about this: Google, with their Play Store, have previously let registered developers upload (and even lets end users download!) straight-up malware. Do any of these changes prevent registered developers from distributing malware on Google storefronts?