Readit NewsThis has always struck me as a matter of checkbox compliance rather than a commonly-exploited attack vector, though I'll grant that's partially because few people actually use such devices.
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.
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.
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.
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
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. 99.9% of users would never see the warning either because almost all developers would register their apps through the official store.
But there is a reason why Apple/Google won't do that, and it's because they take a vig on all transactions done through those apps (a step so bold for an OS that even MSFT never even dared try in its worst Windows monopoly days). In a normal market there would be no incentive to side load because legitimate app owners would have no incentive not to have users load apps outside of the secure channel of the official app store, and users would have no incentive to go outside of it. But with the platforms taxing everything inside the app, now every developer has every incentive to say "sideload the unofficial version and get 10% off everything in the app". So the platforms have to make it nearly impossible to keep everything in their controlled channel. Solve the platform tax, solve the side loading issue.
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.
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?
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.
Is this browser built on Chromium, or is it a completely fresh creation?
I have to assume that because they AREN'T highlighting it that it IS built on Chromium.