Conversation

Unless Apple backs down on this AND makes a firm commitment to keeping ITS nose out of YOUR device, there’s no way I’ll be recommending everyday folks buy Apple to protect their privacy. Unless they make this commitment, there will no longer be any difference between Apple (1/2)

4

9

21

& Google. (Apart from the oddly surprising position I might find myself in as I recommend Google Pixel phones running GrapheneOS to some folks.) You’re fucking up, Apple. You’re fucking up big time. ar.al/2021/08/08/app (2/2)

Apple is trying to redefine what it means to violate your privacy. We must not let it.

Violation of privacy by proxy is still violation of privacy.

1

4

12

Replying to

Oh, interesting GrapheneOS as a fork of AOSP. I wonder if people is willing to go without the Play Services, which is what makes Android Phones useful. A phone without apps is mostly useless and most devs only care about Google Play / App store

2

Replying to

You can use Aurora Store. But apps that require Google Play Services will fail. GrapheneOS folks are working on a container of sorts that might fool some apps but not sure how robust that is yet.

1

1

Replying to

and

grapheneos.org/usage#sandboxe is available now so users have the option to install Play services as a fully sandboxed app in profile(s) of their choice. It's meant to be used to make a dedicated profile for apps requiring it. Doesn't give it any additional access vs. libraries in apps.

1

2

2

Replying to

and

Users need to explicitly decide to install the apps since we'll never include it in the OS. Only apps this approach needs to coerce into working are the 3 Play services apps. It teaches them how to function as regular apps by returning placeholder data, etc. so they don't crash.

1

1

Replying to

and

Anything inherently depending on privileged functionality can't work, but most of it doesn't. A lot of the core functionality already works fine. Needs more shims returning placeholder data instead of having it get SecurityExceptions it can't handle and some more fallback code.

1

1

Replying to

and

Since we're not bundling anything with the OS, it's entirely possible to support alternatives in the future. For now, we're going to focus on getting this working really well and trying to make the code as easy to maintain and port to future releases as possible. It's still new.

1

1

Replying to

and

This is a huge project. Kudos to the team. I would expect anything tied to in app purchases to not work, but a fully free and open source mobile OS is a great goal.

1

1

Replying to

and

In-app purchases, etc. should all work fine. There are certain things not working well yet such as apps using Play services APIs for location instead of OS APIs. Many apps use the OS APIs and the OS doesn't use Play services for anything even when a user installs it in a profile.

1

1

Replying to

and

Anything tied to using special access such as access to hardware without asking the user won't work without us implementing compatibility shims. All we provide is code to detect those 3 apps and provide them with the fallback code they're missing to work as fully sandboxed apps.

5:28 PM · Aug 11, 2021Twitter Web App

Replying to

and

Mostly just means intercepting their attempts to use privileged APIs and returning placeholder data rather than attempting to do it and getting a SecurityException. In some cases, we need to give them an alternate approach using unprivileged APIs, asking user for consent, etc.

1

1

Replying to

and

For example, we started teaching Play Store to use the regular install dialog for installing and updating apps. In Android 12, there's a standard API allowing an app to perform unattended updates of an app it installed. Key pinning + downgrade protection still applies of course.

1

1

Show replies