Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What we talk about when we talk about sideloading

f-droid.org

Post reply on HN
Print view View original

211–220 of 646 posts

Re: What we talk about when we talk about sideloading

#211

Post by MarsIronPI »

anticensor wrote: post #201
overfeed wrote: post #190

Earlier quoted context omitted.

As I understand it, the delivery mechanism won't matter: Play Store,ADB, F-Droid, Bluetooth, or website. If the APK isn't signed by a Google-approved developer, it's not going to install. If there's some ADB command that one can issue to install unsigned APKs for now, it's a temporary reprieve at best. Two Android versions later, the update from Google will read "Only 0.02% of users installed apps using adb, but the…

No, that adb command is how you test install things. They wouldn't want to force public uploads to Play just to test.

Not so. The new mandate isn't that all APKs must be uploaded anywhere, only that all APKs must be signed by approved developer keys. So to test new builds, devs will only have to sign with their approved key, then upload. No extra hassle once you already have an approved key.

Re: What we talk about when we talk about sideloading

#212

Post by lisdexan »

lisdexan wrote: post #163
Groxx wrote: post #71

Earlier quoted context omitted.

AFAICT it only works on non-rooted devices when used over USB to access another device , because without root it has no access to the adb server on the phone running termux. I'm definitely not 100% sure about that though, so someone please correct me if not.

Just tested⁰, it works with WiFi ADB but it has some limitations. - The pairing process is kinda awkward, you need to split screen Termux and the Wireless debugging submenu, if you change windows the pairing IP and code are changed. - The pair survives a reboot and WiFi change. You can disable the 7day revocation, so the pairing process is a one time thing. - After a pair you still need to connect (adb connect localh…

More googling, Shizuku² does this already in a polished way and exposes an API for other apps. Some related-ish apps are SAI³ (for installing split apks) and Canta⁴ (removing system apps).

EDIT: Even more googling, the whole setup already exists in Obtainium (i.e. F-Droid but with Github Releases) apparently so apps show up as being installed via Play Store and subsequently be usable in Android Auto⁵.

So hypothetically you can install stuff day one on a stock phone after this atrocity is turned on.

[2]: https://shizuku.rikka.app/

[3]: https://f-droid.org/en/packages/com.aefyr.sai.fdroid/

[4]: https://f-droid.org/en/packages/io.github.samolego.canta/

[5]: https://github.com/ImranR98/Obtainium/issues/1859

Re: What we talk about when we talk about sideloading

#213

Post by overfeed »

anticensor wrote: post #201
overfeed wrote: post #190

Earlier quoted context omitted.

As I understand it, the delivery mechanism won't matter: Play Store,ADB, F-Droid, Bluetooth, or website. If the APK isn't signed by a Google-approved developer, it's not going to install. If there's some ADB command that one can issue to install unsigned APKs for now, it's a temporary reprieve at best. Two Android versions later, the update from Google will read "Only 0.02% of users installed apps using adb, but the…

No, that adb command is how you test install things. They wouldn't want to force public uploads to Play just to test.

Sure, you would test-install apps via any delivery method of your choice, including USB-C cable or WiFi, after Google attests that your test-app signature is whitelised[0]. After all, there is no legitimate reason[1] to not sign your app, since you want it to closely match the distributed version as much as possible, and there won't exist unsigned distributable apps.

0. Developer has valid signatures and in Google's good graces, and application hasn't been installed on more than 16 devices

1. Oh, you CI/CD signing infra won't let you? You better fix your workflows to match the Google way.

Re: What we talk about when we talk about sideloading

#214

Post by rs186 »

terminalshort wrote: post #42

I think this misses the forest for the trees here. The platforms behavior here is a symptom and not the core problem. I think the following are pretty clearly correct: 1. It's your damn phone and you should be able to install whatever the hell you want on it 2. Having an approved channel for verified app loading is a valuable security tool and greatly reduces the number of malicious apps installed on users devices Gi…

> a step so bold for an OS that even MSFT never even dared try in its worst Windows monopoly days

I don't think it's like "MSFT didn't dare to try", but rather "MSFT was too stupid to come up with the idea". They didn't have the ability to manage it either (and till this day their Windows Store app still sucks with tons of bugs). Not to mention that Windows was already wide open, never with a restriction "you can only install these approved apps" to begin with.

Basically, not that Microsoft didn't do it, but it couldn't.

Re: What we talk about when we talk about sideloading

#215

Post by makeitdouble »

Zak wrote: post #125
bpfrh wrote: post #21

Earlier quoted context omitted.

Depending on your app this is not all. If i send a golang binary to someone with a mac via signal or other mediums, apple simply displays a dialog that the app is damaged and can't be run. You need to use chmod to manually remove the quarantine flag to run it. That for me is something that should be fined ad infinitum, because it is clearly designed to disallow non technical people to run custom apps.

On the other hand, it used to be very common for malware on Windows to email itself to all your contacts using your real email client. It's probably reasonable for an OS to add a little friction to the process in the modern era, though it probably shouldn't lie and claim the binary is damaged when that's not the problem.

chmod to dequarantine doesn't sound like "a little friction" to me.

On your point about security, this kind of aggressivity from the platform owner tend to backfire.

The user was already convinced to open that mail, download that file, and try to run it. Pushing the process to the terminal just means your clueless users now run the provided incantations in the shell instead, and the attack vector now becomes huge (the initial program doesn't even need to be malware)

Re: What we talk about when we talk about sideloading

#216

Post by rpdillon »

gruez wrote: post #75
hypeatei wrote: post #58

Earlier quoted context omitted.

> Lots of people say "sideload" without trying to convey such negative meanings Sure, but they effectively do even if they're not trying to. It comes off like you're up to no good or doing something dangerous. Like GP said: deviant.

>Sure, but they effectively do even if they're not trying to. What specific acts are referring to? Is it just their recent plans to restrict sideloading? This feels circular. "Google is evil because they're trying to restrict sideloading. They're also extra evil because trying to demonize sideloading. How? By restricting sideloading!" >It comes off like you're up to no good or doing something dangerous. Like GP said:…

There's been a concerted effort by smartphone manufacturers to demonize side loading explicitly for some time now. This is actually about code signing rather than sideloading, so it's kind of funny that we have this sub thread that's explicitly about the term sideloading, but regardless, that term has been demonized by Apple.

https://www.apple.com/tr/privacy/docs/Building_a_Trusted_Eco...

Re: What we talk about when we talk about sideloading

#217

Post by lucideer »

gruez wrote: post #106
lucideer wrote: post #89

Earlier quoted context omitted.

> Can you corroborate this? I don't think this is so much a question of sources & corroboration as it is of language. Regardless of the origins of the term "sideload", the language implies a non-standard practice. The prefix "side-" may be used in some software contexts to describe normal, non-deviant software, but only in cases where the software in question is considered auxiliary. In general, anything described as…

>Regardless of the origins of the term "sideload", the language implies a non-standard practice. Because it is non-standard. Like it or not, the intended experience is that you get apps from the play/app store, and for most people that's exactly what they do. This is a descriptive statement, not a normative one. Accepting it doesn't imply you oppose the freedom to run whatever code you want. The language of "sideload…

> the intended experience is that you get apps from the play/app store

Once again, this is the point.

> it doesn't imply you oppose the freedom to run whatever code you want

But it does.

Let's first look at what's good about "intended experience" & possible legitimate reasons to have a differentiation between "vendor-approved" 3rd-party apps & non-"vendor-approved" 3rd-party apps.

The connotation of an "intended experience" is that the experience is supported by the OS vendor. If you have issues with your experience, these are issues that can be reported & the OS vendor will endeavor to fix. Leaving aside the fact that Google has no user support to speak of, even if they did, this isn't something they would every offer for 3rd-party Play Store apps regardless. So 3rd-party Play Store apps are not doing anything for users to provide them with an "intended experience" that isn't equally available sideloading.

The only other legitimate reason to have a differentiation would be to ensure the user doesn't install malware. Play Protect currently does this with sideloaded apps, so once again there is no difference in the "intended experience" from the user's perspective.

If there are no legitimate reasons to differentiate the experiences, the only reasonable conclusion remaining is that they're differentiates to dissuade user freedom.

Re: What we talk about when we talk about sideloading

#218

Post by gdulli »

fyrn_ wrote: post #182
dataflow wrote: post #166

Earlier quoted context omitted.

Hey, question. While I'm also miffed about Google's decision and see your point about the term sideloading, there is another elephant in the room you seem to not be addressing here. You write: > “Sideloading is Not Going Away” is clear, concise, and false_ But isn't Google saying that you will still be able to sideload via ADB ? Which would mean their statement is true, and that your claim that Google's statement is…

Forcing ADB may as well be a ban, if you don't see that, you're pretty out of touch with consumers. Sideloading is already hard enough for many, forcing the use of an extra computer, a dev tool in the CLI, and dev mode is way way outside what people will do

Also if the majority of sideloaders go away because it's become more difficult, what will happen to the development scene? Will it stall out from lack of developer interest because there's such a small audience compared to before? (Despite it still being possible.)

Re: What we talk about when we talk about sideloading

#219

Post by fishywang »

MarsIronPI wrote: post #211
anticensor wrote: post #201

Earlier quoted context omitted.

No, that adb command is how you test install things. They wouldn't want to force public uploads to Play just to test.

Not so. The new mandate isn't that all APKs must be uploaded anywhere, only that all APKs must be signed by approved developer keys. So to test new builds, devs will only have to sign with their approved key, then upload. No extra hassle once you already have an approved key.

I'm not sure it works that way. _In general_ before the recent announcement you are supposed to sign the debug build (what you feed into adb to install) with your debug key that's different from the release nor upload key, and the debug key is never submitted to google.

Of course _maybe_ at some point google will also force you to submit your debug key to them. But I don't believe that's the case now.

Re: What we talk about when we talk about sideloading

#220

Post by wkat4242 »

fyrn_ wrote: post #182
dataflow wrote: post #166

Earlier quoted context omitted.

Hey, question. While I'm also miffed about Google's decision and see your point about the term sideloading, there is another elephant in the room you seem to not be addressing here. You write: > “Sideloading is Not Going Away” is clear, concise, and false_ But isn't Google saying that you will still be able to sideload via ADB ? Which would mean their statement is true, and that your claim that Google's statement is…

Forcing ADB may as well be a ban, if you don't see that, you're pretty out of touch with consumers. Sideloading is already hard enough for many, forcing the use of an extra computer, a dev tool in the CLI, and dev mode is way way outside what people will do

You could make a glossy PC client around it. On the meta quest there's an app called SideQuest that does just that because meta doesn't permit apps to install other apps. It's still a fairly big thing there.
Post reply on HN