Live data from Hacker News

What we talk about when we talk about sideloading

f-droid.org

361–370 of 646 posts

Re: What we talk about when we talk about sideloading

#361
post #148
post #87

Earlier quoted context omitted.

> 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 I would instead say that having a trustworthy channel for verified app loading is a valuable security tool. F-Droid is such a channel; the Google Play Store is not. So Google is trying to take this valuable security tool away from users.

I'm unclear on why F-Droid is any safer than the playstore and not possibly worse since using it tells potential malware purveyors that you're into sideloading in the first place.

Not to be an asshole, but you must not be very familiar with F-Droid.

It’s not just a random hodgepodge of “third party” binaries. It’s all FOSS software that was actually built from source and verified.

Probably much safer than a random app on the Play Store.

Re: What we talk about when we talk about sideloading

#362
Australian users of alternative app stores should make a complaint to the ACCC: https://www.accc.gov.au/about-us/contact-us-or-report-an-iss...

In the past, they forced Steam to implement proper refund policies, and they are currently suing Microsoft about the way subscribers were duped into paying more for "AI features" they didn't want.

Re: What we talk about when we talk about sideloading

#363
post #349

I'm struck with how long the history of Apple's earliest iPhone has shaped and produced long-term damage to the concept of digital ownership. Apple originally didn't allow anybody but Apple to create software for the 1st gen iPhone, and only later was forced "opening" it my market forces. People who realized they actually owned the thing they bought wanted to do what they wanted, which required circumventing Apple's…

> The fact that mobile phones aren't yet just a standard type of portable computer with an open-ish harware/driver ecosystem that anybody can just make an OS for (and hence allow anybody to just install what they want) is kind of wild IMHO. Why hasn't the kind of ferver that created Linux driven engineers to fix their phones?

It's because each phone SoC is essentially its own bespoke architecture. You can't build one arm64 Linux ISO that will work on all phones like you can an x86_64 ISO on a PC. Each and every model of phone requires 0) unlocked bootloaders and either 1) full support from the vendor for Linux or 2) dedicated hackers willing to reverse engineer the board to get it to boot Linux in the first place & then developers willing to write missing device drivers & then maintainers willing to keep the fork up to date or mainline the changes.

It will always be cheaper for phone manufacturers to develop bespoke SoCs than it is for them to implement protocols and interfaces that make booting and hardware discovery standardized like they are on the PC. Making a phone as accessible as a PC to booting generic operating systems inherently means increasing costs at every level from the design up.

> I'm sometimes surprised at the plethora of cheap handheld gaming systems coming out of China that support either Linux, Android, or sometimes both, and seem to be based on a handful of chipsets. If anybody ever slapped an LTE module and drivers onto one of those things we'd have criminally cheap and powerful, open phone ecosystem.

On the surface it seems like that, but all of those devices suffer from the same issues I described above. There will be thousands of devices that "support" Linux, but only nominally.

What happens is, if the manufacturer even releases the kernel source, you get a git dump of a forked kernel that was never modified to be upstreamed with the vanilla mainline kernel. That essentially means you are stuck using that fork unless you have the time, knowledge and skill to port that fork over to the mainline, which is a lot of work. This applies to every SoC, and SoC modification, in gaming systems. Barely any of this work crosses over or can be standardized like it is on a PC.

None of that makes a platform a real open ecosystem.

Source: I'm involved in porting and maintaining a Linux distro for those cheap Chinese handheld gaming systems. The only reason Linux runs on them is because weird nerds spent time getting it to run on them. When they get bored, your Linux "support" ends.

The best we can hope for is for ARM servers to scale down to the point we can use them in small form factors, as ARM servers implement the same standards PCs do to run generic Linux ISOs. We aren't going to get this from the mobile hardware ecosystem, there just are no incentives to make such an investment. Maybe we'll get them if ARM PCs truly take off.

> It is interesting though how this same conversation doesn't exist in the same way in other areas of computing like video game consoles or other embedded computing devices where the controls against arbitrary applications is even stronger.

The conversation takes place all the time, there are tons of people who want to, and do, run homebrew and Linux on their consoles, same thing with embedded devices. Getting Linux or Doom to run on an embedded device is a rite of passage.

Re: What we talk about when we talk about sideloading

#364

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…

I don't trust the Google Play Store.

Too bad. Pay up and ask big daddy google for permission if you want to use your device. /s

Re: What we talk about when we talk about sideloading

#365
post #36

Earlier quoted context omitted.

What does this even mean? You don't want software updates? Or strictly only software updates that are 100% aligned with your wishes whatever they may be at the time?

Unironically, I want finished software. I don't like it one bit how the vast majority of software products today are in an "eternal beta", so to speak. Android, in particular, is a finished product. It doesn't need yearly updates. It may need an occasional update to patch a vulnerability, but this whole "we changed the notification shade UI for tenth time because we're so out of ideas" thing has to stop.

On Google Play, it's only finished for a few years at best. If it's not updated to the latest version, eventually it gets delisted.

Re: What we talk about when we talk about sideloading

#366

Earlier quoted context omitted.

> just how Apple cannot block their developer tools from being able to transfer apps onto an iPhone. If I recall correctly (I might be wrong, because this was 10+ years ago), but Apple did exactly this when the iPhone was first released. When the iPhone first came out, Apple released its XCode devtools for free, including an iOS emulator that you could use to test your iPhone app. But you had to pay a $99 USD per yea…

You recall correctly, but that did end in 2015, when Apple ended the requirement that developers sign up for their paid developer program to be able to develop and test iPhone apps. I've written about that elsewhere: https://appfair.org/blog/gpl-and-the-app-stores#fn:3 The adb workaround for Android is essentially on par with being able to use Xcode's tooling to install apps on an iPhone: technically possible without…

Apple has actually increased the friction since: you now have to enable a scare-screened developer mode, reboot your device, install the app, get an error that the app is untrusted, then go to the part of Settings used for corporate management profiles to enable your own developer profile, and only THEN will the app actually launch and run.

Re: What we talk about when we talk about sideloading

#367

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…

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…

[deleted]

Re: What we talk about when we talk about sideloading

#368
post #158

Earlier quoted context omitted.

This comment is very uninformed and misleading. > 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 These are claims that Apple and Google make to justify their distribution monopolies, and you are repeating them as fact. I don't think it's true, and cite as evidence both major app stores and the massive amount o…

> both major app stores and the massive amount of malware in them This is true, but it's also not the main vector of attack. The primary threat is that the user is intending to download $WELL_KNOWN_APP and instead downloads a compromised binary from a malicious third party and is instantly compromised. The app stores make the probability of this essentially zero.

Question: if the OS does proper app sandboxing how is this basically any different from having unrestricted access to a web browser or email?

Oh no granny tapped a bad Google ad and got phished! I guess we should kill the open web and use the officially sanctioned “web store” from now on (where you have to apply, pay a fee, and of course a % commission to host a website). It’s much safer for us!

Re: What we talk about when we talk about sideloading

#369
post #353

Earlier quoted context omitted.

Did you consider piracy? I'd guesstimate that close to 50% of Android users know how to install an apk.

You think 50% of the 3.6 billions of android users know that?

There are countries like China, Russia, Iran, and Venezuela where installing an APK is the primary or only way to get most software, including essential bank and government apps.

Outside of the Western market, installing Android apps not from Google Play is a completely normal and regular thing. In countries like India, Brazil, Indonesia, Nigeria, and the Philippines (which represent a massive portion of global Android users) it is a standard part of using a phone.

Re: What we talk about when we talk about sideloading

#370
post #36

I think we could set the bar substantially higher. Don't even bother with discussion of sideloading. Talk about bounded transactions and device control. What is needed is: Once I have purchased a device, the transaction is over. I then have 100% control over that device and the hardware maker, the retailer, and the OS maker have a combined 0% control.

What does this even mean? You don't want software updates? Or strictly only software updates that are 100% aligned with your wishes whatever they may be at the time?

I think this is a good point, even if you're presenting it as a false dichotomy.

Obviously saying "Apple shouldn't be allowed to touch my device after I purchase it" as well as "Apple should be compelled to provide security updates" is nuts.

But I think saying, "Apple shouldn't be allowed to touch my device after I purchase it" as well as "I should be able to provide my own security updates, if Apple doesn't want to" is totally reasonable.

But Apple would never allow that. So allowing sideloading seems like a reasonable amount of pain Apple should be forced to put up with...

Post reply on HN