> That users won't be able to install what they want and that they would need a google account to install apps

It was split up because "need a Google account to install apps" is strictly untrue, but "won't be able to install what they want" is more nuanced.

I did clearly say, "it won't work if the APK isn't signed by someone in the Google developer registry".

So, it depends on what the user wants.

If they're running certified Android; otherwise it doesn't matter.

It is only for registered developers, so of course that very much depends on the registration system.

> I guess it means the Play store will be the only way to install an app

No, non-Play stores will still work, but developers will need to register a developer account with Google that is tied to some real identity. They already need to do this to distribute through the Play store, but now it'll apply regardless.

This is to make it harder for scam apps to churn app signatures. Kind of like requiring code-signing, but with only one CA.

> That users won't be able to install what they want

No, sideloading will still work, but it won't work if the APK isn't signed by someone in the Google developer registry.

> and that they would need a google account to install apps

Nope.

> That app developers have to go through google to distribute their apps, with identity verification etc.

They don't need to distribute through Google, but they will need to be involved with Google and do identity verification.

> However, I'm also reading here and there that it is a threat to alternative ROMs. To me it sounds at the contrary as an amazing opportunity, as they can strip this verification and be the only truly open Android, or am I missing something?

You're being misinformed. They won't even need to strip the verification. The verification is only for certified Android -- OEMs that partner with Google. Custom ROMs and the OEMs that aren't certified (Amazon, some Chinese manufacturers) won't have verification.

The target audience for verification and who would ever use a custom ROM has basically zero overlap.

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.

Not only has nothing happened yet, but this is also untrue.

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.

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.

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.

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.

There were other, less-available prototypes prior to that.

Not sure how they're doing post-layoffs.