A Gemini query uses about a kilojoule. The brain runs at 20 W (though the whole human costs 100 W). So, the human is less energy if you can get it done in under 50 seconds.
In my experience, people don't really care about rooted devices and non-stock Android -- if those devices are actually phones in the hands of human users.
The big fraud vector is running emulators in datacenters or skipping running the app entirely and talking directly to endpoints. Requiring that an entity making a request is from a real phone and is from (approximately) your app adds friction and is effective at reducing fraud.
They run Big Sleep to find security vulnerabilities in projects they care about. It seems -- mostly from reading this issue's details -- that the finding is pretty high quality. Once a vulnerability is found, there's a duty to disclose the existence of the vulnerability to the project maintainers and, eventually, to the public within a reasonable timeframe.
The alternatives here are: not searching for the vulnerabilities in the first place; keeping the knowledge of the vulnerability secret; or notifying the public without the project maintainers having the opportunity to fix the vulnerability first. All of these are worse.
It's unlikely that Google cares about a vulnerability like this -- ffmpeg is probably run sandboxed and probably with a restricted set of codecs. So they're unlikely to spend engineering resources fixing it.
The project maintainers are under no obligation to actually fix the bug. The deadline is simply that the vulnerability will eventually be made public, even if it is not fixed. That's standard responsible disclosure and, again, is better than the alternatives.
It is the latter. The app has to be signed, and the signer has to register "real" identity with Google. Approval of the app itself is not a part of the process.
Yes, sideloading will still be viable from known developers.
Probably malware developers will still be free from prosecution -- what moron is going to distribute malware with their own identity attached to it? But it means when the malware gets caught (which it does) you can't just roll a new APK with a different signature. You've burned a developer identity and need a new one. Those are harder to come by, and so it rate-limits malware distribution.
Fwiw I've been getting random email offers over the years to buy my old dev account for like $100-300. Dev accounts are going to become a prized commodity on the black market with this move.
> Given that both of these things are obviously true, it seems like a pretty obvious solution is to just have a pop up that has a install at your own risk warning whenever you install something outside of the official app store.
It is an obvious solution, and it's a good first solution. This popup already exists.
A problem in security engineering is that when people are motivated (which is easy to achieve), they will just click through warnings. That is why, for example, browsers are increasingly aggressive about SSL warnings and why modifying some of the Mac security controls make you jump through so many hoops.
The usual take on HN is take the attitude that the developer is absolved of responsibility since they provided a warning to the user. That's not helpful. Users are inundated with stupid warnings and aren't really equipped to deal with a technical message that's in between them and their current desire. They want to click the monkey or install the browser toolbar. The attitude that it's not my problem because I provided a warning they didn't understand doesn't restore the money that was stolen from them by malware.
A significant change that google implemented (announced?) for android recently was not allowing you to install software or allow "unknown sources" while on a phone call.
I think that's going to have a far more significant impact on people installing malware than developer attestation.
I guess this is a difference in philosophy then, but I think that the goal of security engineering should be to protect users from malicious actors, not to protect them from their own bad choices. If I give you a safety feature, and you turn it off, that's not my problem. There is a special level of hatred that I have reserved only for the busybodies who limit my choices and justify it as protecting me.
That said, your point about messaging is really good, and so many times I see security warnings I roll my eyes at how badly the message is written.
I agree that our choices should not be limited to protect us.
However, we need a better solution than pop-up warnings. I guarantee that you have clicked through a pop-up warning that was standing between you and the thing that you wanted to do (as have I, and everyone else who has used a computer for more than a day). We very quickly learn that most warnings aren't going to affect us, and that they're just saying "are you sure" to things that we're already sure of.
We've all selected a file, hit the delete key, got the pop-up saying "are you sure you want to delete wrong_file.txt", hit "yes" (because we always have to hit yes after hitting delete), then looked at the outcome and thought "oh, that was the wrong file" too late...
Not only will sideloading via ADB continue to work, installing from most other third-party app stores will continue to work. The developers on the Amazon, Samsung, and Epic app stores won't have a hard time with the developer verification process. F-Droid is in a uniquely inconvenient position that they have a legitimate app store, but its design causes them to have a hard time with developer verification.
> won't have a hard time with the developer verification process
Unless any government powerful enough has reason to make Google reject developers. Hell, doesn't even have to be a government. Do anything that annoys Google, goodbye rights for your app to be installed on any Android. Why would you ignore the obvious and main caveat? It doesn't matter what store it "continues to work on". Google can revoke privileges overnight with little to no recourse for the developer, regardless of the merit of such action, the usefulness of the app, or how much people want/need that app. This is literally heading in the direction of Kafkaesque.
F-Droid is also the only one that does reproducible builds which is a big security feature. One that is precisely the cause of making this hard. But it also makes it safer than even the play store. It should really be accommodated.
I realize F-droid has an understandably strong opinion here, but this writing is disingenuous.
From the post:
> Regardless, the term “sideload” was coined to insinuate that there is something dark and sinister about the process, as if the user were making an end-run around safeguards that are designed to keep you protected and secure. But if we reluctantly accept that “sideloading” is a term that has wriggled its way into common parlance, then we should at least use a consistent definition for it. Wikipedia’s summary definition is:
> the transfer of apps from web sources that are not vendor-approved
The opening two sentences of the linked-to Wikipedia page on sideloading:
> Sideloading is the process of transferring files between two local devices, in particular between a personal computer and a mobile device such as a mobile phone, smartphone, PDA, tablet, portable media player or e-reader.
> Sideloading typically refers to media file transfer to a mobile device via USB, Bluetooth, WiFi or by writing to a memory card for insertion into the mobile device, but also applies to the transfer of apps from web sources that are not vendor-approved.
The phrase after the "but" in the second sentence isn't the "summary definition". It's the part of the definition that best supports your argument. Cutting the Wikipedia definition down to that part is deceptive.
Also in the post:
> Regardless, the term “sideload” was coined to insinuate that there is something dark and sinister about the process, as if the user were making an end-run around safeguards that are designed to keep you protected and secure.
Immediately later in the same Wikipedia page is a paragraph that is literally about how the word was coined:
> The term "sideload" was coined in the late 1990s by online storage service i-drive as an alternative means of transferring and storing computer files virtually instead of physically. In 2000, i-drive applied for a trademark on the term. Rather than initiating a traditional file "download" from a website or FTP site to their computer, a user could perform a "sideload" and have the file transferred directly into their personal storage area on the service.
That's funny. The history of how the word was coined and the post's claim about how it was coined aren't similar at all. Weird.
> The phrase after the "but" in the second sentence isn't the "summary definition". It's the part of the definition that best supports your argument. Cutting the Wikipedia definition down to that part is deceptive.
Wat?
Everything after the "but" is what Google means when they use the term sideload and is the only important part of the definition for f-droid's purposes. The other definition is completely irrelevant and, I would argue, hardly ever used anymore.
You argue here that google is technically correct because they’re correctly using sideload.
But that isn’t the point people are angry about. The point is that sideload was a misnomer. Correctly Android users were able to install packages and now cannot. This is anti consumer and breaks the social contract.
Anyway this is so disingenuous that I think it’s astroturf. Here’s the meme we should’ve spreading: Chrome and Android should be broken off from Google. Apple should be forced to allow sideloading, at a minimum, same as any other computer. Phones and tablets should be valid targets for custom OS.
Android users will at some point next year not be able to install software unless the developer has paid and registered itsef with Google, and Google has approved the developer and the software (for an uncertain amount of time).
PayPal doesn't cost significantly more than what a small online place can get from other payment processors. It's something like 3% + $0.50. That's also not much more than what a small business can usually get for in person credit cards.
This site does use buymeacoffee.com, which appears to be a dedicated payment platform. Its transaction fee is apparently 5%, which is steeper, but better for these small donations because of the lack of a fixed fee.
