[xg15]

They gave an explanation of the security issue, along with a (rather unhelpful) link to LineageOS' stance on the matter and explained which defenses they employed to keep it secure (put it behind a permission prompt that is only available for system apps)

This seems reasonable to me. How is this more dangerous than, e.g., giving an app permission to continously track your physical location?

[headmelted]

That's comparing apples to oranges.

One is replacing signed system components, the other is volunteering to share whereabouts with a third party.

The biggest concern with this is that Google has the resources (and pressure) to get something so central to the security model correct. I've no inside information on how Google develops Play Services, but I imagine they have quite stringent policies with regards to testing and peer review.

The actual functionality of Play Services is only one part of the work that goes into delivering it to your phone, and it's a lot of trust to place in anyone to get something like that right (considering the personal, security-sensitive information we keep on our phones now).

My point was that the FAQ was a big red flag for me in thinking that the developers grasp this aspect of what they're proposing here.

[lucideer]

Your comment about the petulant FAQ item was on point: it's possible to develop an alternative fork without taking such a childish attitude toward discourse with the original project.

On the other hand, I think your implicit trust in internal Play Services policies may be a little over-egged. Google definitely has some great security teams (Chrome/Chromium's security team have made some good contribs to the web, Project Zero is also cool, if a little externally-focused) but this is by no means universal. Android's been a bit of a sore spot in this regard generally (particularly in comparison to Apple).

[UncleMeat]

Is this actually still true? If you look at the public patch notes for ios and android, the number of platform bugs is similar.

[lucideer]

I'm more thinking of architectural decisions rather than outright bugs, but yes it is improving - e.g. with projects like Treble.

[ehsankia]

How is comparing the security of Android, which is a far more open and diverse platform, to Apple, a walled garden, fair at all? And let's not forget about how Apple happily gives backdoor access to apps like Uber.

[lucideer]

I'm not sure what "fairness" has to do with it.

Sure, Apple makes their own life easier in terms of security by applying draconian restrictions on the freedoms of their own users. But this and the fact that things are not as easy for Google to do effective security doesn't make it any less true that they aren't doing it.

Again, Apple's Uber backdoor isn't really relevant - I never implied Apple were benign, just that Google's security record is imperfect, and compares poorly.

The openness and diversity of Android's platform isn't a wholesale excuse for not securing users.

[s73ver_]

They're both smartphone platforms. Of course they're going to be compared to one another.

[eptcyka]

You can't use the remote APIs you need to deliver the same local APIs that are required to run modern apps without spoofing the signatures of applications - otherwise google's remote APIs would forbid access. This is where security measures are also inherently DRM-ish, and to deliver the experience typical end users expect using free software (free-er than stock android) it's necessary to circumvent it. One could argue that such circumvention is illegal. I hope no one deems it to be so.

[chasil]

What makes you think that Play Services is well-designed?

Google also designed the media system, and that leads the security patches every month - what would have rehabilitated them?

https://interviews.slashdot.org/story/16/08/26/1338246/the-s...

"Don't start me on Stagefright and Mediaserver, I could rant for 2 or 3 hours non-stop! Seriously, the code over there is crap, and has insane concepts, like aborting the whole mediaserver (and all related media decoding of all other applications running at the same time), when it parses a file with attributes it does not know, instead of skipping the file. We discovered some issues in Stagefright (busy loops, device reboots, mediaserver crashes) quite early, but we never thought about submitting them."

[cptskippy]

They're dismissing risk as a non issue since they've displaced responsibility on the user. Their system isn't more secure because it is reliant on the user. Time and time again it's been shown that the user is the weakest link which is why some many of these types of systems are in place.

People are 100% vigilant all the time.

[hedora]

Their system is explicitly for people that don’t trust Google.

With certificate spoofing, the risk is that I might accidentally click through permissions on a malicious, already installed and privileged app.

With LineageOS the risk is that I will, with 100% certainty, run code that I have deemed malicious (== any service-facing client-side Google blob).

Maybe you haven’t decided those binaries are malicious, but that doesn’t change my opinion, and what I do with my phone isn’t your business.

I don’t see why certificate spoofing is controversial at all (especially amongst the “free as in freedom” crowd).

[cptskippy]

> Their system is explicitly for people that don’t trust Google.

Yes, and LineageOS is not. LinesageOS has an interest in maintaining the ability to run Google blobs and accepting such a patch might potentially harm that interest.

Instead of accepting that, this project acts all butt hurt and whines that LinesageOS's position is inconceivable.

[dcow]

NO! LineageOS has no agreement with Google to provide Play Services. In order to do that you have to literally pirate play services and install them on LineageOS. That, IMHO is a far greater concern than allowing a SYSTEM app (one that is built into the framework) to pretend to be google play services.

[cptskippy]

No one said they have an agreement. I said they didn't want to do anything to disrupt the status quo.

[dcow]

> Yes, and LineageOS is not. LinesageOS has an interest in maintaining the ability to run Google blobs and accepting such a patch might potentially harm that interest.

Maybe I'm being a little pedantic, but my point is it's not LineageOS that makes that call. LineageOS does not distribute gapps and is not in any agreement with google that would possibly adversely impact users' ability to run gaps due to such agreement being revoked were LineageOS to act against googles interest. CM on the other hand likely would have been either directly or indirectly when it was buddied with one plus (which is when this went down).

There are a lot of subtly incorrect statements in this thread and I'm trying to help clarify because I find this discussion interesting and important.

[aaomidi]

Well this isn't a normal OS that an everyday user uses?

There are people who don't want any binary blobs from Google on their devices.

[cptskippy]

And there are people who do want those blobs. LineageOS has chosen to err on the side of caution and not allow a patch that might prompt Google to take action.

[traverseda]

So what you're saying is that you believe the real reason this patch wasn't merged is because google might take action, and the security concerns are not as relevant? One might even call them a... shield?

[cptskippy]

Why can't it be both?

[Qwertious]

>People are 100% vigilant all the time.

I think you mean the reverse?

[mschwaig]

Someone built a location API or crypto API or whatever so that apps can use that data.

If there is a permission that violates the trust between the system and an app using aforementioned APIs all bets are off. This is similar to why rooted devices are bad for security.

[gjjrfcbugxbhf]

All bets are off for the owner of the device or the author of an app? Bad for who's security?

As a device owner and user I don't care for DRM style 'security' protecting app authors from me running my software on my computer.