The move comes as Apple removed ICEBlock after direct pressure from U.S. Department of Justice officials and signals a broader crackdown on ICE-spotting apps.
It’s not a suggestion for an alternative.
Sideloading is not even blocked: unblocked apps remain sideloadable.
Sideloading is not “fucking anti-property-rights loaded language” & the word existed a while before Android OS.
They’re just being uninformed drama-queens as usual.
It is a fairly loaded word, implying it’s an alternative method of loading data to the primary, more actively vendor-supported method. Those methods you previously mentioned are actively subverting the primary application install methods (Google Play) and are 1 minor software update from being completely axed. Name-calling an opposing “they” is not quite productive.
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
deterring them from installing software by bad actors that’s known to be malicious
verifying non-malicious software hasn’t been modified possibly maliciously before installing it.
“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.
Sideload wasn’t loaded language before Android OS and still isn’t: it’s a bogus, overreactive claim.
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.
Clear use cases for casual users exist for
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?
(even as Google turns out to be a shitty authority)
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.
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
Sideloading apps is when you install apps that aren’t from an official source, such as the Microsoft Store. Your organization can create its own apps, including line-of-business (LOB) apps.
& their distinct installation methods with similar caveats
When you enable sideloading, you allow installing and running apps from outside the Microsoft Store. This action might increase security risks to the device and your data. Sideloaded apps need to be signed with a certificate that the device trusts.
That’s the entire point of the term there: to express that the installation method & checks differ.
What about the clear use case for a FOSS developer who doesn’t want to go through the Google authority for validation?
Sign it yourself or bypass verification as stated before.
Show me the “clear documentation that power users can still install any package they want,”
It was linked above: try reading.
Google already has a service to protect against malicious applications
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?
It’s not a suggestion for an alternative. Sideloading is not even blocked: unblocked apps remain sideloadable. Sideloading is not “fucking anti-property-rights loaded language” & the word existed a while before Android OS.
They’re just being uninformed drama-queens as usual.
It is a fairly loaded word, implying it’s an alternative method of loading data to the primary, more actively vendor-supported method. Those methods you previously mentioned are actively subverting the primary application install methods (Google Play) and are 1 minor software update from being completely axed. Name-calling an opposing “they” is not quite productive.
“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?