Live data from Hacker News

What we talk about when we talk about sideloading

f-droid.org

161–170 of 646 posts

Re: What we talk about when we talk about sideloading

#161
post #83

I’m honestly very tired of this argument, everything about it is bad. Features aren’t rights, if you want a phone that let’s you run whatever you want, buy one or make it yourself. What you’re trying is to use the force of the state to make mandatory a feature that not only 99% users won’t use, it vastly increases the attack surface for most of them, specially the most vulnerable. If anyone were trying to create a wo…

It's a proper argument on its surface, complete with claim, warrant, and impact.

"Features aren't rights" > see: Consumer Rights.

"Force of the state making sideloading mandatory is bad" > ...Except we have antitrust laws? The Play Store becomes the only source of apps, all transactions are routed through Google Billing? Not a problem for you?

"99% users won't use" > Except for when Google demands that transactions happen exclusively through Google Billing, which resulted in the release of the Epic Games Launcher for the world's highest grossing games by download.

"Sideloading is too nice" > Listen, either it's the case that "sideloading" is a threat to normies or it's not. Are normies your 1% or 99% of users? I thought according to you 99% of users won't sideload.

"You don't get to decide" > That language ties in pretty well with your fear of the use of the 'force of the state'; that tells me that you support freedom. Great-- you're right, why not let corporations be corporations and do anti-consumer things, they'll be very good to us (while they lobby the state).

Re: What we talk about when we talk about sideloading

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

> Right, because those devices don't have first party stores. Windows and Mac technically do, as does some Linux distros If you find yourself making a statement only to immediately contradict it, consider whether or not that statement is worth making at all.

Maybe you should consider reading a few words beyond the passage you quoted, because the "contradiction" only exists with your selective quoting.

Re: What we talk about when we talk about sideloading

#163
post #71

Earlier quoted context omitted.

I haven't tested it myself, but as far as I know you can run ADB in the phone itself via Termux. Perhaps it's possible to make a wrapper that install apps from F-Droid with ADB? It would mean that you would only need to be tethered to the your PC once. Obviously they'll eventually remove this because Google is hostile to things like ReVanced / some spook wants this power.

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 localhost:port) and the port changes after a WiFi change or disconnect. I searched for solutions and apparently it's simple as running nmap twice¹

- It obviously doesn't work without a WiFi connection (unless is there some dark magic to connect your phone to its own hotspot).

So a wrapper seems viable if you are ok only installing apps on trusted networks.

[0]: I'm on GrapheneOS but I believe the dev menu is the same.

[1]: https://www.reddit.com/r/tasker/comments/1dqm8tq/project_sim...

Re: What we talk about when we talk about sideloading

#164

Earlier quoted context omitted.

> Right, because those devices don't have first party stores. Windows and Mac technically do, as does some Linux distros If you find yourself making a statement only to immediately contradict it, consider whether or not that statement is worth making at all.

Plus, I don't see how it is even relevant if a platform has a first party store when it comes to allowing the user to install software.

It doesn't, but that doesn't mean people can't call out disingenuous statements made by the OP. Posts can be directionally correct even if they contain errors, but the errors are still worth calling out.

Re: What we talk about when we talk about sideloading

#165
post #78
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?

> You don't want software updates? Most of the time, software updates remove features, change things around for no good reason (breaking our workflows), or add unwanted features. We really should separate pure bugfix updates (which include security updates) from feature updates. We nearly always want the former, but not necessarily the latter.

So much this. I totally want security fixes, but I only want security fixes. I don't want UI changes, features removed or altered, or anything with my usability upset.

My computing devices are tools I use to do my job and run my life. I don't want those tools changing without my consent.

Re: What we talk about when we talk about sideloading

#166

Author here. I admit I am rather startled by the tone of many comments here and the accusations of disingenuity. 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. You don't "sideload" software on your Linux, Windows, or macOS computer: you install it. You have the right to install whatever you…

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 files is itself false?

I'm so confused why you never even mention ADB or its relevance to sideloading, which they refer to rather explicitly in their blog post. At the very least, if you think ADB doesn't change anything, you could mention it and say so. Could you explain this seemingly critical omission?

Re: What we talk about when we talk about sideloading

#167
post #91

Earlier quoted context omitted.

I'm not an expert on the case law, but supposedly United States v. General Electric Co. et al., 82 F.Supp. 753 (D.N.J. 1949) indicates that whatever design trade-offs might have existed, corporate policy makers were really just trying to screw consumers [1] (which is why they probably had to agree on short lifespans as a cartel rather than just market "this line of bulbs for these preferences" vs. "this other line fo…

Leds are already awful. I already lost 4 of 10 led light bulbs I boughtast year. I hope they will be replaced. It's because every led bulb has a small transformer inside and it fails quite quickly

I think its a heat dissipation issue. I have some overhead LED lights that replaced some halogen bulbs and they have huge metal heat sinks on the back and have all lasted 10+ years. Unfortunately they are no longer sold but I did buy a few spare just in case.

Re: What we talk about when we talk about sideloading

#168

After Google implements this, will I still be able to "side-load" (install any software) on Android-derivative OSes like GrapheneOS?

Currently it seems that Google is pushing for hardware attestation, so you might be able to install Graphene/Lineage if your phone manufacturer allows you to unlock your bootloader, but many Play Store apps won't work as they'll detect your root. It's actually gotten pretty insane how every low-value app considers themselves the centre of the world and unable to run on a rooted device.

Example: the loyalty card app for a local store chain - there's no money in it, I can just get some discounts when I use it. So an attacker would have to steal my phone, somehow unlock it, and then they can use my loyalty card (btw which is free to obtain for anyone and there are no tiers) to get some discounts. And for that, they have implemented a pretty decent root checker which i had to put in some effort to overcome. And there are many more like it.

Re: What we talk about when we talk about sideloading

#169
post #75

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:…

instead of sideload you could use the more correct term "install software on a device you own without permission from Google"

Re: What we talk about when we talk about sideloading

#170
post #106

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…

> This is a descriptive statement, not a normative one.

It's both. It's not like "sideloading" is a part of natural language that just happened to evolve this way to describe the practice. The terminology was consciously chosen by the same people who designed the OS to describe it. The people who argue against using this term aren't doing it in some accusatory way, like "you use this term, therefore you're an evil brainwashed minion of the enemy", but rather by using language to not set up their argument on the enemy's terms, no matter how insignificant.

It's like how "jaywalking/jay walking" was popularized - the term itself was pretty crass for the time, the word "jay" conjuring thoughts of some kind of drooling, unintelligent yokel. Back when car infrastructure was still in its infancy, how would you argue that cars shouldn't dominate all streets and cities when the government- and industry-approved name for your action was literally "stupid walking"?

Post reply on HN