Their top priority is making money.

Making money and complying with the law. They are obligated to do both. In many countries laws are still enforced.

Protecting their app store revenues from competition exposes them to scrutiny from competition regulators and might be counter productive.

Many governments are moving towards requiring tech companies to enforce verification of users and limit access to some types of software and services or impose conditions requiring software to limit certain features such as end to end encryption. Some prominent people in big tech believe very strongly in a surveillance state and we are seeing a lot of buy in across the political spectrum, possibly due to industry lobbying efforts. Allowing people to install unapproved software limits the effectiveness of surveillance technologies and the revenues of those selling them. If legal compliance risks are pushing this then it is a job for voters, not Google to fix.

	▲	BrenBarn 2 hours ago \| parent [-]
		Complying with the law is just another way of protecting your money. I have no doubt if they would break laws if they judged it better for the bottom line --- in fact I have little doubt they're already doing so. On the flip side, if there were ruinous penalties for their anticompetitive behaviors (i.e., in the tens or hundreds of billions of dollars) they might change course. Certainly voters need to have their say, but often their message is muffled by the layers of political and administrative material it passes through.

▲

hekkle 4 hours ago | parent | prev [-]

BINGO! Google doesn't care at all about user security.

- Just yesterday there was a story on here about how Google found esoteric bugs in FFMPEG, and told volunteers to fix it.

- Another classic example, about how Google doesn't give a stuff about their user's security is the scam ads they allow on youtube. Google knows these are scams, but don't care because they there isn't regulation requiring oversight.

▲

gpm 3 hours ago | parent [-]

> Just yesterday there was a story on here about how Google found [a security vulnerability that anyone running `ffmpeg -i <untrusted file> ...` was vulnerable to] in FFMPEG, and told [the world about it so that everyone could take appropriate action before hackers found the same thing and exploited it, having first told the ffmpeg developers about it in case they wanted to fix it before it was announced publicly]

Fixed that for you. Google's public service was both entirely appropriate and highly appreciated.

▲

hekkle 3 hours ago | parent [-]

> and highly appreciated.

Not by the maintainers it wasn't Mr. Google.

▲

gpm 3 hours ago | parent [-]

Yes, but it was a public service not a service for the maintainers, and as a member of the public who like anyone who had run `ffmpeg -i <thing I downloaded from the internet>` was previously exposed to the vulnerability I highly appreciate their service.

I'd highly appreciate even if the maintainers never did anything with the report, because in that case I would know to stop using ffmpeg on untrusted files.

▲

hekkle 3 hours ago | parent [-]

So you were using untrusted video files that required the LucasArts Smush codec?

Again, if YOU highly appreciate their service, that's great, but FFMPEG isn't fixing a codec for a decades old game studio, so all Google has done is tell cyber criminals how to infect your Rebel Assault 2. I'm glad you find that useful.

	▲	gpm 3 hours ago \| parent [-]
		No, I was running on normal untrusted video files. The standard ffmpeg command line would happily attempt to parse those with the LucasArts Smush codec even though I'd never heard of it before. See the POC in the report by google, the command they run is just `./ffmpeg -i crash.anim -f null /dev/null -loglevel repeat+trace -threads 1` and the only relevant part of that for being vulnerable is that crash.anim is untrusted. Edit: And to be clear, it doesn't care about the extension. You can name it kittens.mp4 instead of crash.anim and the vulnerability works the same way.