Live data from Hacker News

What we talk about when we talk about sideloading

f-droid.org

411–420 of 646 posts

Re: What we talk about when we talk about sideloading

#411
post #381

Earlier quoted context omitted.

> It is interesting though how this same conversation doesn't exist in the same way in other areas of computing like video game consoles Yes, there needs to be a lot more uproar for these cases as well. One of the most appalling cases is that of macOS. To distribute your app (as a .dmg for instance), you need to sign up and pay for a Developer ID, sign the app with a Developer ID certificate and then notarize it, EVE…

You can self sign without a developer account and self distribute and all it does is notify the user that the software is from the internet the first time they run it. They can still use the app. If it is completely unsigned, users may have to bypass gatekeeper, but that is just a setting. If you want to sign using a cert trusted by apple, and distribute on their infrastructure, you do need a paid account. This seems…

99% of users are not going to understand why they can't just double click the app to run it. And the second they see macOS gaslight them into thinking self-signed applications are radioactive biohazards via scary warnings, they aren't going to take additional complicated steps to run the app they wanted to run in the first place.

Users will just assume the app is broken, a virus or that you're a hacker, all because of the way macOS treats apps from developers who didn't pay the Apple tax or submit the app to Apple's panopticon for approval.

Users should not have to know some cursed and arcane ritual to run the apps they want to run.

Re: What we talk about when we talk about sideloading

#412
post #226

Earlier quoted context omitted.

>But isn't Google saying that you will still be able to sideload via ADB? No, it will not. Nothing will install an application without a Google approved signature on it. They will remove ad blocks from your Android and you will like it. "The beatings will continue until morale improves" sort of behavior. I'm hopeful that the mystery OEM that GrapheneOS is targeting is in fact Sony Xperia. If it isn't, I'm just going…

> No, it will not. Nothing will install an application without a Google approved signature on it. How do you interpret this then: >> You will continue to be able to build and run an app even if your identity is not verified. Android Studio is unaffected because deployments performed with adb, which Android Studio uses behind the scenes to push builds to devices, is unaffected. You can continue to develop, debug, and…

I interpret that as you will be able to install an unverified app. And you will get the annoying unverified app screen every time you launch it. And it will very likely be crippled in other ways, as it is unverified.

>Lando: But that wasn't our deal!

>Vader: I have modified our deal. Pray I do not modify it further.

Re: What we talk about when we talk about sideloading

#413
post #49

Earlier quoted context omitted.

>Splitting hairs about the origin of the term "sideload" does not change the fact that those who promote the term tend to do so in order to make it feel deviant and hacker-ish. Can you corroborate this? At least for me, the whole idea that "sideloading" has negative connotations only came up as a result of this debacle, and the only evidence I've seen are some very careful readings of blog posts from Google. The word…

Linux had "stores" long before android

I view Debian apt as helpful. I view Apple App Store as limiting and controlling.

Re: What we talk about when we talk about sideloading

#414

Earlier quoted context omitted.

I said it elsewhere in the thread, but the current model is already falling apart: it has led to random IoT devices becoming parts of widespread botnets, affecting Internet functioning, and putting unwitting consumers at risk. Fixing that problem might turn out to be cheaper for competitors by making their platforms more open and avoiding the full responsibility as a vendor. Basically, combine current and future legi…

> I said it elsewhere in the thread, but the current model is already falling apart: it has led to random IoT devices becoming parts of widespread botnets, affecting Internet functioning, and putting unwitting consumers at risk. But isn't this also exactly how the pitch will sound for what I proposed? You know, "The internet is too important and random people are allowed to upload and run random dangerous code within…

You are right, which is why I stress the time component and e-waste concerns. If combined they end up meaning that a vendor ships you a device and they need to take it back for recycling in 2-7 years when they stop providing security updates, market will force a change.

At the moment, laws are disjoint even in EU, and not strict about what happens when you stop fixing security bugs.

Re: What we talk about when we talk about sideloading

#415
post #381

Earlier quoted context omitted.

> It is interesting though how this same conversation doesn't exist in the same way in other areas of computing like video game consoles Yes, there needs to be a lot more uproar for these cases as well. One of the most appalling cases is that of macOS. To distribute your app (as a .dmg for instance), you need to sign up and pay for a Developer ID, sign the app with a Developer ID certificate and then notarize it, EVE…

Wait, do you need to do that? I've never attempted distribution, but I've created multiple local apps with Electron and Tauri for myself, and they are just a .app on my Applications folder. Wouldn't it be as easy as sharing this file with anyone else if I wanted to distribute them?

No, macOS treats your machine's self-signed certificates in a special way so that running apps signed with them is transparent to you, but a nightmare to anyone you dare to distribute the apps to without Apple's approval.

Re: What we talk about when we talk about sideloading

#416

Earlier quoted context omitted.

Quarantine is for any executable downloaded from the Internet. It doesn't prevent it from being opened, it only marks it to be checked for malware.

It definitely adds hurdles to running it.

Usually the hurdle is just a pop-up informing you that it's been downloaded from the Internet. Sometimes the malware checks go wrong though and try to prevent you from opening it at all.

Re: What we talk about when we talk about sideloading

#417
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…

> It's because each phone SoC is essentially its own bespoke architecture.

Right, but that's a choice from manufacturers, not a requirement of building a mobile platform.

> 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.

This... seems suspect? I'm not doubting you, but I do wonder if it's a question of robbing Peter to pay Paul; perhaps it is cheaper to design a bespoke chip than it is to develop a standard for it, but over the course of many generations the benefits of standardizing would kick in?

I do know that RISC-V can support UEFI, so perhaps that's where we need to look to see how developments work out in the long run.

Re: What we talk about when we talk about sideloading

#418
post #381

Earlier quoted context omitted.

> It is interesting though how this same conversation doesn't exist in the same way in other areas of computing like video game consoles Yes, there needs to be a lot more uproar for these cases as well. One of the most appalling cases is that of macOS. To distribute your app (as a .dmg for instance), you need to sign up and pay for a Developer ID, sign the app with a Developer ID certificate and then notarize it, EVE…

Wait, do you need to do that? I've never attempted distribution, but I've created multiple local apps with Electron and Tauri for myself, and they are just a .app on my Applications folder. Wouldn't it be as easy as sharing this file with anyone else if I wanted to distribute them?

They need to try to open it, visit Settings > Privacy & Security, scroll down quite a bit, hit Open Anyway, try to open it again, and confirm one last time.

(Might be quicker for some in Terminal if supported.)

I think it used to be Right Click > Open, then confirm.

Re: What we talk about when we talk about sideloading

#419

Earlier quoted context omitted.

You can self sign without a developer account and self distribute and all it does is notify the user that the software is from the internet the first time they run it. They can still use the app. If it is completely unsigned, users may have to bypass gatekeeper, but that is just a setting. If you want to sign using a cert trusted by apple, and distribute on their infrastructure, you do need a paid account. This seems…

99% of users are not going to understand why they can't just double click the app to run it. And the second they see macOS gaslight them into thinking self-signed applications are radioactive biohazards via scary warnings, they aren't going to take additional complicated steps to run the app they wanted to run in the first place. Users will just assume the app is broken, a virus or that you're a hacker, all because o…

I think a little informative friction letting novice users know they are choosing to load/launch without Apple Store protections is reasonable.

However, any attempt by Apple to scare vs. just inform/confirm would be a dark pattern we don’t need.

Re: What we talk about when we talk about sideloading

#420
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.

Yeah, that's the problem. As soon as it became feasible to push upgrades over the wire, software companies started relying on it. And unfortunately that mentality is viral, because as soon as one thing starts doing that, anything that else that interoperates with that other thing winds up having to do it to some extent. It's a tragedy of the commons.
Post reply on HN