March 14, 2022 • 37 mins
On this week's episode, we discuss how to overcome some of the challenges in building your own image of Android to use on any device, particularly where security is a concern. We're excited to be joined by one of the developers behind one such project that's made headlines recently, Gabriel of GrapheneOS.
- 01:02 - Are we talking about custom ROMs?
- 02:51 - What does GrapheneOS do that AOSP doesn't?
- 12:04 - Why can't I install a custom OS on my existing Android device?
- 19:15 - How can I get apps to work on my custom Android-based OS?
- 28:26 - Why are Android update guarantees still so lackluster?
You can learn more about GrapheneOS at grapheneos.org, and you can try it out on your Pixel device with their easy-to-use web installer.
Android Bytes is hosted by Mishaal Rahman, Senior Technical Editor, and David Ruddock, Editor in Chief, of Esper.
Esper enables next-gen device management for company-owned and managed tablets, kiosks, smart phones, IoT edge devices, and more.
For more about Esper:
- Esper Blog
- Mobile Device Management (MDM) Guide
- Android MDM Guide
- iOS MDM Guide
- MDM Solutions
- MDM APIs & SDK
New from the Esper blog:
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
David (00:00):
Hello everyone.
And welcome to another episode ofthe Android bites podcast powered
by Esper I'm David Ruddock.
And every week I'm joined by mycohost Mishaal Rahman to explore
the wide world of Android and a lotof topics in the Android universe.
You probably wouldn't ordinarilysee discussed this week.
We've got a very special guest.
And with that, I'll letMichelle introduce him.
Mishaal (00:21):
Thanks David.
So this week I'd like to talk aboutgraphing and S so if you are at all
security or privacy minded, you mayhave heard of this project before it's
been brought up by some very influentialmembers of the InfoSec community as one
of the preferred alternative Androidbased operating systems for devices that
you can install that, people that aremore secure and more private things.
(00:46):
AOSP and joining us today, wehave one of the developers who
works on the project full time.
Gabe from graphene O Swelcome to the show either.
Gabe (00:56):
I'm very happy to join you guys today.
hopefully we can get into thenitty-gritty details of graphing.
Mishaal (01:02):
Yeah, definitely.
before we actually dive intothose details, I really wanted
to clarify one thing with you.
So you've probably are veryfamiliar with the term custom wrong.
It's a term that the vastmajority of people use to refer to
Android based operating systems.
Aren't offered by Google or OEMs.
there are projects like lineage iOS, whichis one of the most popular ones that's
(01:24):
referred to as a custom rom, there aremany other projects that are referred to
as custom ROMs, but I wanted to know, whatdo you think of this term is graphene S
something we should call a custom rom oris there a better term we should be using?
Gabe (01:37):
I personally don't really consider it to make much sense.
my rationale for that being that.
The operating system isn'tinstalled to rom chip anymore.
And mobile phones, maybe youhave the exception of some older
feature phones don't really use awrong for their operating system.
And the only real rom that's presenton a modern smartphone is going to be
the boot rom, which is highly amenableand just starts the boot chain.
(02:02):
And I would describe craftiness and anyother derivative of AOSP as operating
systems, because, that is what the.
Mishaal (02:09):
Yeah.
And also , in my view, custom romas a connotation of being like a
hobbyist project that you woulddownload off the XDA forums, just to,
try out some new features or tweakthe user interface, or maybe extend
the longevity of your old device.
It has that hobbyist, indiedeveloper connotation associated
with it, in my opinion, at least.
(02:31):
And it feels like graphing.
This is different than that.
It feels like it's more.
Aimed at professionals and, peoplein the InfoSec community or people
who care about security in general.
I think yes, operating system wouldbe a better term for any Android
based operating system, but grapheneiOS in particular would be, a
great project to use that term for.
(02:51):
I mentioned just now that grapheneS is it feels a bit different than
other Android based derivatives.
Aimed at people who care about privacysecurity, it advertises that it's more
private and secure than AOSP so manypeople who aren't familiar with graphing
OSTP may be wondering what are someof the privacy features that offers
(03:11):
that aren't available and it wispy.
And what are some of the changesthat you guys made to make your
derivative more secure than AOSP.
Gabe (03:21):
So graphing us is intended as a security and privacy research projects,
which focuses on incremental and systemicimprovements rather than just picking
apart minor issues and low-hanging fruit.
Although obviously that is anythingthat would be present in a project.
Focusing on systemic improvementsrather than individual issues.
(03:43):
One of the things that we have is ahardened Lipsy and hardened memory
allocator, which we know as heart Malak.
And that helps deal with a specifictype of class of vulnerability, which
is referred to as memory corruptionand memory corruption makes up.
I would say the overall majority of.
Of high end critical vulnerabilitiespresent within the AOSP and chromium.
(04:07):
we have found and fixed issues inthe wild, and it also will actively
prevent vulnerabilities that wouldotherwise affect AOSP normally.
If you want an example of that, weactually found a real world issue
and that's currently being trackedas if anyone wants to look up the
CVE number, CDE 20 21 0 7 0 3.
(04:28):
And that was a use after freevulnerability found by hardened.
Obviously in addition to that, Graffinaour ships have no tracking whatsoever
built into the operating system.
And we also have the auditor andattestation server projects and
those help to verify that yourinstallation of graphene is the
real, genuine graphing of us project.
(04:48):
And that, works by usinghardware attestation, which is
backed by the secure element.
And that verifies the authenticity andintegrity of all the code on the device.
You also add the network and censuspermissions so that they are user facing.
Say you install, Idunno, PDF viewing app.
For example, the user can revoke thenetworking permission or the census
(05:10):
permission just as if they were to revokethe context or messaging permissions.
Additionally, we close off any access to.
to say device identifiers toAndroid, hasn't already done.
For example, legacy apps on AOSPcan currently access the serial
number, but we closed that office.
So it can't be used for tracking.
We also build upon AOSP security features.
(05:31):
For example, Andrew 12 brought intoproduction, the camera and microphone
indicators, and we enable thelocation indicators, which aren't
actually enabled on production.
Andrew 12 operating systems.
Similarly, we also enabled thembefore they were actually enabled
in production on Android 12.
And I believe they've been a featuresince Android nine, if I recall properly.
(05:54):
And that's just a very brief summaryof just the incremental systemic
privacy and security improvementsthat we do at graphing us.
And we have a full featureslist on our website.
Mishaal (06:04):
thank you for high level rundown of.
Many of the security and privacy benefitsthat crafty nos offers on top of AOSP.
One thing I wanted to ask you to follow upon, these extensions that you guys offer
over AOSP is , why do you think AOSP.
Doesn't offer hardened Malik by default.
And what are the downsides ofenabling it the way graphing OSS.
(06:26):
And are there any performance,downsides to enabling it?
, Gabe (06:30):
ISP currently is using the scooter allocator instead of hardened Malak.
Now we're completely open toAOSP using hardened Mellon.
If they were to adopt it, it'spermissively licensed and is inherently
compatible with the licensing of AOSP.
harden, Malak, compared to scooter,we'll use more memory and that's due
to the mitigations, which it deploys.
(06:50):
And also it can potentially lead to issuesin applications, which do have memory
corruption, which simply isn't beingexposed by traditional memory allocators.
. And honestly, that decisionreally lies with them.
bionic is inherently designed so thatyou can essentially swap in memory.
Allocators is I wouldproperly crudely word.
(07:13):
Hot metal compared to school, though,when it comes to performance device
resource usage performance shouldnot really be affected much from
a user's perspective, but it willinvolve in increased memory usage.
That's due to the mitigations,which pardon Malik deploys.
And obviously Google could potentiallydisabled some of the mitigations of
(07:34):
enharmonic if they wish to deploy it.
And that would still be an improvement,but obviously it remains to be seen
as it is ultimately a Google choice.
And we can't really show it.
Mishaal (07:44):
So just taking a step back and trying to summarize, I think
you'll find is that, because Googleis such a massive corporation that
develops, all of Android, which isused by billions of devices and they're
responsible to thousands of companies.
Tens of thousands of developers outthere, any change that they have to make,
(08:05):
any performance impacting change thataffects things on the millisecond scale is
something that they have to be aware of.
And because, such changes arescrutinized so heavily and they have
to be benchmarked and they have tobe observed for changes, will this
negatively, in fact, 1% of our devices.
And if so, how badly will it impact them?
These kinds of considerations?
(08:26):
you know, hardening decisions, moredifficult for Google to do, whereas
with a project like graph, it's possibleto take more experimental approaches
that may impact performance a bitnegatively, but would theoretically and
practically improve the security overall.
So just to give one example ofthis consideration that I'm aware
of personally, The applicationspawning process used by
(08:49):
Android, which is called zygote.
I believe graphene O us disablesthat traditional spawning model.
And, what happens normally is thatAndroid creates a, if you go back
to like high school biology createsa psycho and then from there.
Application process or split off fromthat psycho and the benefit of having that
psycho processes, that it's able to startup some of the libraries and some of the
(09:10):
tools and et cetera, that are needed byapplications when they're being spawned.
, this is not as secure as spawning everyapplication freshly, but the benefit of
using Android traditional spot processis that it speeds up app launch times.
By disabling it, you get better security,but you also get slower app launches.
So that's an example of a, trade-off thekind of trade-off that graphene OSTP makes
(09:33):
to trade security, security above else.
Security is the most important aspectwhen it comes to designing and building
features for graphene graphing.
S would you say that's an accuratedepiction of the design philosophy?
Gabe?
Gabe (09:47):
I would say that usability is something that we very heavily connect.
Which is why we've built thingslike assemble, assembles, legal
place services, and we're currentlyworking on extensively documenting
its usage and we're making iteven easier for users to use it.
And we've renounced to exact spawning.
, it is generally on newer hardware,very imperceptible, I would say.
(10:10):
Probably one device generation downthe line, or honestly, even on modern
devices, like the pixel five and the pixelsix, it's barely noticeable whatsoever
to the average user on legacy devices.
Like the third generation pickup.
Especially the free andfree XL, which use EMMC.
It did lead to exec spawning,having a much higher impact compared
(10:31):
to newer generation devices.
And I think over time, , asdevices get moved to more powerful
hardware, . It'll completelyprevent being an issue completely.
David (10:41):
Yeah.
And I think that . If you want to goeven wider, you can say that this is
just computing at work it's Moore's law.
We're getting more powerful hardware,sequentially over the years here.
And as that hardware becomes morecapable of executing within the
thermal or wattage envelope ofyour smartphone, you're able to do.
I think a good example of that.
(11:02):
If we're going to talk about EMMC andstorage speed would be Androids move
to full disk encryption, which waspainful and took a number of years.
I forget when it wasintroduced as mandatory.
Was that new get maybe when FDE became.
I don't specifically recall, but Google'sreasoning was well, we're going to
impact performance so badly, and I thinkeverybody can intuitively understand why
(11:24):
disc encryption can impact performance.
We saw that fight for a long time.
I think some phones allowedyou to turn on encryption.
as an option when they receivedan iOS upgrade and it absolutely
destroyed performance.
So yeah, it's something thatGoogle probably has to weigh
pretty frequently given diversityof devices in the ecosystem.
Mishaal (11:44):
So just a up on encryption aspect, I believe your full disk
encryption was introduced in 5.0.
And then it was eventuallyreplaced with file based in.
if you just Google those two terms,you'll find the, documentation
by Google on what they are.
I don't think they're really necessaryfor us to dive into right now.
so I just want it to.
Next, you mentioned a lot of differentaspects scape that elevate graphing
(12:08):
OSTP as a privacy and securityoriented operating system over AOSP.
so if I were, listening to this podcastand I want it to go and install a graph,
you know, us onto my own device and Ivisited graphene ios.org and visited
the releases section, I would noticethat the operating system is only
available for Google pixel devices.
Can you tell me why.
Gabe (12:27):
the unfortunate reality is, and I'm going to be pretty blunt
about this, the vast majority ofOEMs, they're pretty terrible.
The great thing about pixel devicesis that they are essentially
the de facto reference devicesfor Android, and they are full
support within AOSP and they have.
Probably the best hardware securityyou can get on an Android device.
(12:50):
they rivaled that of an iPhonewhen it comes to security things
like having a proper IMU andhaving a proper secure element.
So the pixels, they have the Titan,em, on the new generation, a base
pixels, the tighten, em too.
So that's the pixel six and sixpro and those secure elements
does support the Weaver API, whichmassively improves this encryption.
(13:14):
just things like this.
Most other OEMs don't implement and mostcritically, most OEMs do not implement
support for alternative operating systems.
Google pixel devices, they allowyou to unlock the bootloader
without any trouble from the OEM.
You don't need to ask for an unlockcode, like some OEMs, they don't
need any special fancy software.
(13:34):
It's just use fast bit whenyou can unlock the bootloader.
And it also allows you todefine , a user defined route of.
what that means is that you can preservethe verified big frat model and actually,
use verified a bit and lock the bootloaderwith your own operating system, with
your own keys on a pixel device.
And generally pixels havebeen only devices to properly
(13:57):
implement support for that.
There's a few manufacturers out there,which I won't name while they do have
support, they don't implement it properly.
And there are serious security issueswith the alternative operating systems.
Mishaal (14:10):
So just for a bit of background, for those of you who aren't familiar,
the bootloader is a special piece ofsoftware that basically loads up, all of
the other components that are necessaryto load up the operating system,
including the kernel and everything else.
Literally loading up.
Everything needed to boot the device.
And when we say you unlock thebootloader, basically that allows, the
(14:34):
user to install images that were notoriginally signed by the manufacturer.
And, if you were to lock the bootloader.
Then those images would have to berecognized by, the verified boot system
on Android and most devices do not allowyou to, insert your own verified boot
(14:55):
keys into that process so that if youwere to lock the bootloader, your phone
will be completely braked after installingin alternative operating system.
And with few exceptions, likethe Google pixel series, you can.
I'm not the bootloader flashaccustom operating system
and then lock the bootloader.
, that is probably one of the most importantthings that blocks graphene, iOS and other
(15:16):
security minded operating systems frombeing supported on non pixel devices.
one thing I noticed though, is thateven if you were to go through this
process of unlocking the bootloader.
Installing graphene O S and then,flashing a custom verified boot key,
and then re locking the bootloaderis that the bootloader will
still show you a warning message.
(15:36):
It displayed in yellow thattells you that you're running
in alternative operating system.
If you were the user who wentthrough the process of installing
graphene OSTP and did all this.
You probably, dismiss thismessage is no big deal.
Cause you know exactly whatyou did to your own advice.
But if you were to purchase a devicewith graphene iOS pre installed, or
maybe you had a friend or someone elseinstall it onto your device for you and
(15:59):
you put up your device and you see thismessage, you might be a little concerned.
So I wanted to ask you . whatwould it take to have this message,
not show, what would it take tohave graphene S be treated like
a first party operating system?
Like the pre-install firmware on devices.
Gabe (16:15):
Going to keep it since.
Android has multiple states withinwhich verified boot will operate in.
So when you buy a device fromthe shops, say I bought a brand
new pixel six or whatever.
The latest Samsung is that devicewill boot in the green verified boot
state, which means that the device isbooting and operating system, which
(16:36):
has been approved and certified.
And, Basically the OEM said,yeah, we're shipping it with this.
We're approving this operating system.
It will be without any warning,no friction whatsoever.
Now say for example, I were to buya pixel, unlock the bootloader,
and it's still graphing.
Then device will be booting ina yellow verified boot state.
(16:58):
What that means is that device isusing a user defined root of trust.
Your device is using the graffitinow as keys in order to preserve
the verified boot threat model.
And it's running on a locked bootloader with a custom operating system.
So that means quite literally anywhere.
Combined pixel clone down AOSP andbuild their own fork of the operating
(17:20):
system of all their things that theywant in bear operating system, flush
it to the phone with their own keys andlock the bootloader, and they will be
able to completely maintain the frontmodel of the Android security model.
Mishaal (17:33):
And so if say an OEM wanted to implement first party support for
graphing OS, what exactly would they haveto do to get the device to boot with a
green verified boot state with graphene O
Gabe (17:45):
S so an OEM would have to waitlist on keys in order for the
phone to boot in the green state.
Within the bootloader andOEM, essentially, It has a
key pinned within the farmer.
and if that key does not match whatis in essentially the approved list,
the phone will kick and scream andsay, all right, is it using a use
(18:08):
of the finder of trust or is it not?
if it's not, and it's on a lot,bootloader, it'll give a red screen
because something has gone terribly wrong.
If it is using a user defined rootof trust of a lot bootloader, then
it will say, okay, you are in thelist, but the user has defined you.
So that means that it willbe in a yellow verified.
(18:29):
With graphene us on potentiallyour own hardware or a partner
manufacturer's hardware.
We aim to have it so thatour keys will be wait-listed.
And you'll be able to skip that screen
David (18:41):
quick tactical question.
can this list be changed after the factby flashing a new boot loader to the
device, or is that break the trust?
Gabe (18:49):
only the OEM can build and sign the bootloader.
all the farmers of thedevice is signature enforced.
So you can't just swap outthe bootloader with your own.
You'd have to use thepre-production device to do that.
And that's just not going to happen.
David (19:03):
I guess my example would be in the case of an OEM, actually,
doing this and partnering and wantingto update a phone to support, the
green status, would that be possible?
Gabe (19:12):
That could absolutely be possible.
Mishaal (19:14):
Awesome.
I want to focus on the postinstallation aspect of graphing LS.
Once you actually have properlyinstalled it and have set it up, you're
going to actually be using this asyour operating system on your daily
driver device, which means do you haveto have applications anyone who has
installed in AOSP bill probably knowsthat it's incredibly bare bones and
(19:34):
the basic apps that are there are old.
Incredibly unmaintained by Google.
Unless you want basically a dumbphone, you're going to have to
install apps from somewhere else.
Most OEMs decide to include GMs, whichis Google mobile services, as well
as a suite of their own applications.
But for smaller teams like graphing us,it's just not feasible to develop an
(19:55):
entire GMs alternative suite of apps.
And it's also nottechnically legally okay.
To ship GMs alongside these grapheneiOS belts, although many, I'd say other
operating system projects do so anyways.
but I think philosophicallygraphene, O S doesn't really like
the concept of GMs and has been.
(20:16):
working on alternatives because widelyrecognized at GMs and, Google play
services and Google play store inparticular are incredibly important
applications for the average user.
You know, most users probably won't botherwith alternative operating systems that
don't have those applications becausejust so many things aren't unavailable.
And so many applications just refused.
(20:36):
gave actually alluded to this earlier, butgraphing OS has been developing something
called the sandbox play services,compatibility layer, and this, I think,
tries to bridge the gap between okay.
we value privacy andsecurity above all else.
Google apps are closed.
Source binaries.
They collect a whole bunch of data.
But, we know users wantto use them regardless.
(20:59):
So I wanted to ask you Gabe, can you tellus a bit about how sandbox play services,
compatibility layer works and how doesit, deliver access to Google apps while
preserving graphene OSS privacy model?
Gabe (21:13):
Sure.
So ? say for example, you were to justcompile an all AOSP build or just simply
buy a phone, which didn't come with GMs.
You don't have Google play storethen of Gill play services, general
legal services framework, et cetera.
You won't be able to justinstall the APKs onto the phone.
And everything will train crashbecause by default they expect to
(21:35):
be in a special se the annex policy.
They expect to be built into the OS.
So they actually privileged apps andthey expect to have all sorts of extra
permissions, which aren't user-facingand only privileged apps can get.
And because of that'swhy they chain crash.
On graphing of us, what we'vedone is instead of running
in the own se the next time.
(21:57):
They run in the normal untrusted app.
I see an X domain, which means they runin the same application sandbox, just
as any other APK you are to install.
We don't ship them at allwithin the operating system.
On top of that, we have essentiallytaught them how to run like this.
we do that using shimswithin the operating system.
(22:19):
So say for example, Google play servicesmight try and access the privileged API
to , get the serial number of the phone.
Yeah.
Instead of what we'll do iswe'll just say, oh, there's no
serial number, but that's okay.
You can just use thisstub, API that we made.
And then it would just think,oh, there's no serial number.
Guess there's none.
And it'll just continue on.
that's essentially what it doesthroughout the application.
(22:43):
And we've got to a point where.
The vast majority of functionality offeredby Google play services and the whole GMs
stack work almost perfectly on graphing.
we have, for example, the new,no down advertising identifier,
you can enable that within Googleplay services, we also have.
The location, redirection support,which means say,, you install an
(23:06):
application that exclusively relieson Google play API APIs for location.
Instead of the Android operating system,location, API APIs, you can read the.
Those APIs system-wide to go throughour compatibility layer and then
redirected to the operating systeminstead of them essentially being
proxied through Google play services.
(23:26):
So that means Google play servicescan run without location access.
The apps that depend on itslocation API can still use it
through the operating system APIsand with regards to functionality.
I did mention earlier that almosteverything works and recently we've
got quite literally almost everything.
Things like casting to a Chromecast orapps that don't have their own costing,
(23:48):
implementation, and aligning the placeservices implementation that works.
Things like Fido and security keys.
Those work now, since thereis no AOSP implementation for
security keys, for example.
And it's one of many things whichyou can see has been moved into place
services in order to either be backport.
It took all Android devices,since you can't really back
(24:09):
port a feature like that to.
Over a billion devices, which are runningon multiple different Android versions.
So security, key support isn't inAOSP, but if were in place services
for everything, it's just an exampleof many features like that, which are
highly integrated into place services.
Like even if you were to compilechromium, premium's going to use
that for security, key support.
(24:31):
If you want to use safebrowsing on chromium, it
relies on the Google play APIs.
And the most common use case, whichI'm sure everyone has encountered
when they've tried to install customoperating system on their phone without
Google apps is Firebase notifications.
So the Firebase back-end is essentiallywhere , I was to install, I don't know.
(24:51):
Let's say Snapchat, forexample, their backend servers
would communicate to Firebase.
Hey, you've got a notificationand your phone with Google play
services on it would constantly out.
Towards Firebase and say, okay,there are any notifications.
And then Firebase would say, yeah, yougot on your Snapchat message and Google
play would then tell that to Snapchat.
(25:13):
And then Snapchat would pop upsaying, Hey, you have a notification.
But none of that functionality bydefault would be on the operating
system without Google play services.
And generally at leastin the Western world.
Pretty much everything uses firebased notifications that deliver
notifications for a backend to the client.
if you look in China, there's all sortsof different homegrown implementations.
(25:36):
I don't remember all of them off byheart, but I know Huawei has one.
I think Tencent has one as well, and I'msure there's numerous others as well, but
when it comes to the west, pretty mucheveryone uses Google play services and
the find may CPI to get notification.
And that, of course it's fullyfunctional and graphing us.
When you use some books, Google places.
Mishaal (25:55):
Yeah, so , I think this is a very fascinating and novel approach to
solving the issue of, that I'm sure manycompanies who are looking at building an
Android device of hat, do I have to shipGoogle mobile services with my device?
And if the answer is you're sellinga smartphone to a consumer, then
the answer is probably very likely.
And there's really been no way to getaround that because if you don't ship
(26:15):
GMs, then your users won't have apps.
When I've access to apps on theGoogle play store, many of their
applications will refuse to run orjust simply be broken without access
to play services, API APIs, and, justwithout access, do you lose so much
if you don't have include GMs and, by.
Accepting GMs into your bill.
Do you have to bundle it asprivileged set of applications?
(26:35):
You have to grant it so many permissions.
You're allowing Google to accessso many privileged APIs that aren't
available to other applications.
They can, collect a lot of data.
They run in the background persistently.
There's just so much control you'regiving up to enable GMs on your bills.
I think this is a reallynovel approach that basically.
Allows users to install GMs appsas if they were just regular
(26:59):
applications without giving up toomuch of your privacy in the process.
And I think basically any company that'slooking at, building AOSP and shipping
an AOSP device that actually functionsacceptably for an average user might
want to take a look at this sandbox playservices, compatibility layer approach,
because it is very interesting in my.
David (27:19):
I guess that my big question about that to UK would be, do you see Google
trying to shut some of these doors?
because these are work aroundsand, Google obviously also has its
own, kind of trust model for playservices that it wants to preserve.
So I'd be curious of yourview of where this puts that.
And, how you see their response to date.
Gabe (27:42):
I don't really consider this to be an issue because , , we
made shims for everything.
We can always add more shims.
and I highly doubt it's withinthe interest to intentionally
break anything, which we do.
So I don't really consider itto be an issue for the longterm.
Mishaal (27:57):
Right.
It is, a bit of a cat and mouse gamethere because, Google play services
and a lot of apps and GMs are ablack box to outside developers.
We don't have the sourcecode to the applications.
So we don't know what API APIsand features Google are planning,
or if anything breaks, wecan't really anticipate that.
But as Gabe mentioned, if anythingchanges, it's always possible
to account for that change.
They might just take some time anda bit of development effort, but
(28:20):
changes can be made to reintroducesupport and compatibility with
the latest place services updates.
one of the last questions I wantedto ask you, Gabe is, recently
there's been a lot of talk aboutsoftware update LUNGevity and Who
is to blame for the, in my opinion,mediocre support that most Android
devices get from their manufacturers.
(28:41):
On average, you'll findthat , most flagship devices get
three years of OSTP updates andthree years of security updates.
Recently, Samsung has extendedthat to four years of OSTP updates
and five years security updates.
they're finally startingto approach apple levels.
But apple has always beenthe gold standard for years.
And for years, Android haslagged behind that gold standard.
(29:03):
So , what do you think of this issue?
Do you think, this can be solved.
Do you think there is a particularentity that we would blame for, poor
software support, length, or do youthink it's more complicated and how does
this affect your work on grafting LS?
Gabe (29:19):
When it comes to solving this, I do quite firmly believe that it's
a huge combination of issues wherebySOC vendors and OEMs, both have caused
it to be a little bit of a headacheI think Google has acknowledged this.
And I think since the introductionof initiatives like treble
project, main line, and GKI sogeneric Colonel images, I'd say.
(29:43):
Possibly in the far future, potentiallyeven near a future or get to a point
where Google would end up maintaining thevast amount of the base operating system
that's unified across all Android devicesand they would update it and maintain.
And we'll get to a point where OEMsjust simply maintain their device
specific bits and SOC vendors withcollaborate with OEMs to make sure
(30:06):
that's getting pushed out quickly.
So we'll get to a point where.
Google might do the entireunderlying OS and they might
do the generic kind of women.
And they might just do thatautomatically for everyone.
And that would leave OEMs of havingto manage firmware updates and
kernel module updates and any otherparts of the operating systems.
So say they have a fancy skin, orthey might have some novel features.
(30:31):
They would maintain that, but Googlewould maintain the core Android OSTP.
And I think that will most likelybe the future we end up going into,
but of course either really knowwhat will happen in the future.
That's just my personal speculation.
I don't think there's a clear solutionto it, but I do think the work Google is
putting into trying to mitigate thingsand ultimately solving it is going
(30:57):
to be highly beneficial in the long.
I do quite firmly believe thatsupport periods are far too short.
And I think that, a question that isbrought up often is why are we coming
together to essentially make e-waste?
And the reality is as a project,we can't really do much about it.
the truth is that we can only be.
I have devices for security coverage.
(31:19):
So long as an OEM is providing support.
The pixel two, for example, that's beenend of life work quite a long time.
Now there is no way you can havea secure pixel turnout because
the OEM, IE, Google is not pushingup any security updates for it.
Say you're on a pixel free.
You need to move.
If you're on a free freer, you needto think about moving later this year,
(31:42):
it's not necessarily a great reality.
And people do often frequentlycompare this ecosystem to the desktop
side where they're saying, oh, butI can use my desktop for years.
I can just install an expert.
I think the awareness of.
In mobile, secure is far more heightenedcompared to that of desktops where
people don't really understand thatthings like their UEFI from where their
(32:05):
GPU from where they're trusted platform,module, firmware, all of that culminates
in the whole security of your system.
And the reality is most OEMs neglect that.
we are already seeing in the wildexploitation of these things.
And I do think in the future, it will bea far bigger issue than it is currently.
(32:26):
It's a time bomb waiting to happen.
And in that same regard, users should bevery well aware that they should really
avoid using hardware that doesn't havefull OEM support because they're not
going to be getting security coverage.
And of course, there's notgoing to be any bug fixes, but.
that's probably the least ofyour concerns when anyone can
just, get into your system.
yeah, I don't think there's a very clearanswer on what we can do to tackle that.
(32:48):
, that's all I really haveto say on the matter.
David (32:51):
And I think that's a very fair assessment and that's
what we hear from everyone.
And this is becoming our bit everyweek where we ask about the state
of the Android update ecosystem.
And the complexity of it, as you've said,makes it really hard to pin anyone to the
wall and not necessarily that they deserveto be there also consumer preferences to
take into account, which in many ways.
(33:14):
The aforementioned e-waste problem.
People want the new thing, andthey've been conditioned by a lot
of companies to want the new thing.
For Google's part.
I think that your assessment that,they're going to keep making the OSTP more
modular as relates to the OEM involvement.
That rings true based on everything we'veseen with trouble and mainline and GKI
(33:36):
and all of these other initiatives thatare just designed GRF is another one
that we've talked about on a episode ofthe show that will probably be going up.
And the Google requirements freeze thatwill essentially make it easier for
OEMs to be worse about certain kinds ofupdates, but in service to getting them
up to date on newer platform versions andmore security patches extensively as well.
(34:00):
So you do see Google have to balance thatthose considerations against each other.
the, OEM.
their kind of economic situationand then also the security of the
whole platform, which is obviouslyreally important to Google.
think that a greatexample is play services.
Google has increasinglyused that as the carrot.
And the stick being, not having playservices because everybody wants them.
(34:23):
Right.
So I think that we'll continueto see them use GMs in that
way to advance that interest.
And I think it's a credible way to do it.
It's also one of the few toolsthey have in their belt , to
enforce that sort of thing.
yeah, it's, going to be slow.
Like you said, Gabe, it's goingto take time, but I think we're
watching the pieces come together.
I think this year, I would sayMichelle, would you agree that
(34:45):
especially with 12 L or excuse me,12 and 13, we've seen Google's plans.
They are become much more clear.
Mishaal (34:52):
Yes.
Especially with the introduction of GRF,which many developers that I've spoken to.
Pet basically describe it as thecompletion of project trample.
Treble is, finally here with GRF andif you're not familiar with GRF then as
David mentioned, go back and listen to thepodcast episode where we talked about that
or the blog posts that I published on it.
but in general, to answer your question.
Yes, I do believe finally, we're goingto see the fruits of all of those
(35:17):
initiatives . coming to fruition, may takea few years because we have to actually
wait to see , how quickly OEMs now rollout updates based on these improvements.
But I do think it will have anoticeable impact on the frequency
and the speed at which Androidupdates are pushed out to users.
David (35:34):
All right.
thank you for joining us, Gabe.
where can people learn more about graphingand see what you're working on over there?
Gabe (35:40):
So we have a highly in-depth documentation and feature
overview, which you can find thatgraph, s.org and we are also.
Highly active on our Twitter page.
And we also have a very interactive andactive community, which you can find
also in graphing the rest of all by justhitting the contact button in the top.
(36:01):
And you'll be more than welcome to talkabout it and ask any questions you have.
David (36:06):
Thanks Gabe.
And actually I'm one of the thingsyou brought up earlier did remind
me of Asper a little bit, becausewe do support verified boot, for our
own distro based on Android, becausework with a couple of OEMs, one of
them, most prominently being Lenovo.
So that actually clicked for me.
So thank you for bringingthat up because I wasn't a.
(36:26):
Of how that was architected and nowit makes a lot more sense to me.
and that gets to who's powering the show.
It's Esper, Michelle andI both work at Esper.
You can find our work@blogdotesper.io.
If you're listening to this episodeand you're wondering, okay, like I'm
here because I want to understandhow Android devices get built.
what goes into putting on yourown OSTP distro on an Android.
(36:48):
Come talk to us at Esper.
We do this every day.
We're building our own custom.
Do we have, excuse me, not buildinghalf built our own custom disrobe
Android that works for a variety ofdevices, including X 86 Intel computers,
which we're actively flipping inthe wild with customers right now.
And we can give them security patches too.
Yeah, you should get in touch with us.
(37:08):
That's esper.io.
If you want to book a demo, or ifyou just want to see what Michelle
and I are up to that's blog.esper.io,or you can find us both on Twitter.
Our links are in the show notes below.
Thank you for listening everybody.
And we will catch you next time.
Hello everyone.
And welcome to another episode ofthe Android bites podcast powered
by Esper I'm David Ruddock.
And every week I'm joined by mycohost Mishaal Rahman to explore
the wide world of Android and a lotof topics in the Android universe.
You probably wouldn't ordinarilysee discussed this week.
We've got a very special guest.
And with that, I'll letMichelle introduce him.
Mishaal (00:21):
Thanks David.
So this week I'd like to talk aboutgraphing and S so if you are at all
security or privacy minded, you mayhave heard of this project before it's
been brought up by some very influentialmembers of the InfoSec community as one
of the preferred alternative Androidbased operating systems for devices that
you can install that, people that aremore secure and more private things.
(00:46):
AOSP and joining us today, wehave one of the developers who
works on the project full time.
Gabe from graphene O Swelcome to the show either.
Gabe (00:56):
I'm very happy to join you guys today.
hopefully we can get into thenitty-gritty details of graphing.
Mishaal (01:02):
Yeah, definitely.
before we actually dive intothose details, I really wanted
to clarify one thing with you.
So you've probably are veryfamiliar with the term custom wrong.
It's a term that the vastmajority of people use to refer to
Android based operating systems.
Aren't offered by Google or OEMs.
there are projects like lineage iOS, whichis one of the most popular ones that's
(01:24):
referred to as a custom rom, there aremany other projects that are referred to
as custom ROMs, but I wanted to know, whatdo you think of this term is graphene S
something we should call a custom rom oris there a better term we should be using?
Gabe (01:37):
I personally don't really consider it to make much sense.
my rationale for that being that.
The operating system isn'tinstalled to rom chip anymore.
And mobile phones, maybe youhave the exception of some older
feature phones don't really use awrong for their operating system.
And the only real rom that's presenton a modern smartphone is going to be
the boot rom, which is highly amenableand just starts the boot chain.
(02:02):
And I would describe craftiness and anyother derivative of AOSP as operating
systems, because, that is what the.
Mishaal (02:09):
Yeah.
And also , in my view, custom romas a connotation of being like a
hobbyist project that you woulddownload off the XDA forums, just to,
try out some new features or tweakthe user interface, or maybe extend
the longevity of your old device.
It has that hobbyist, indiedeveloper connotation associated
with it, in my opinion, at least.
(02:31):
And it feels like graphing.
This is different than that.
It feels like it's more.
Aimed at professionals and, peoplein the InfoSec community or people
who care about security in general.
I think yes, operating system wouldbe a better term for any Android
based operating system, but grapheneiOS in particular would be, a
great project to use that term for.
(02:51):
I mentioned just now that grapheneS is it feels a bit different than
other Android based derivatives.
Aimed at people who care about privacysecurity, it advertises that it's more
private and secure than AOSP so manypeople who aren't familiar with graphing
OSTP may be wondering what are someof the privacy features that offers
(03:11):
that aren't available and it wispy.
And what are some of the changesthat you guys made to make your
derivative more secure than AOSP.
Gabe (03:21):
So graphing us is intended as a security and privacy research projects,
which focuses on incremental and systemicimprovements rather than just picking
apart minor issues and low-hanging fruit.
Although obviously that is anythingthat would be present in a project.
Focusing on systemic improvementsrather than individual issues.
(03:43):
One of the things that we have is ahardened Lipsy and hardened memory
allocator, which we know as heart Malak.
And that helps deal with a specifictype of class of vulnerability, which
is referred to as memory corruptionand memory corruption makes up.
I would say the overall majority of.
Of high end critical vulnerabilitiespresent within the AOSP and chromium.
(04:07):
we have found and fixed issues inthe wild, and it also will actively
prevent vulnerabilities that wouldotherwise affect AOSP normally.
If you want an example of that, weactually found a real world issue
and that's currently being trackedas if anyone wants to look up the
CVE number, CDE 20 21 0 7 0 3.
(04:28):
And that was a use after freevulnerability found by hardened.
Obviously in addition to that, Graffinaour ships have no tracking whatsoever
built into the operating system.
And we also have the auditor andattestation server projects and
those help to verify that yourinstallation of graphene is the
real, genuine graphing of us project.
(04:48):
And that, works by usinghardware attestation, which is
backed by the secure element.
And that verifies the authenticity andintegrity of all the code on the device.
You also add the network and censuspermissions so that they are user facing.
Say you install, Idunno, PDF viewing app.
For example, the user can revoke thenetworking permission or the census
(05:10):
permission just as if they were to revokethe context or messaging permissions.
Additionally, we close off any access to.
to say device identifiers toAndroid, hasn't already done.
For example, legacy apps on AOSPcan currently access the serial
number, but we closed that office.
So it can't be used for tracking.
We also build upon AOSP security features.
(05:31):
For example, Andrew 12 brought intoproduction, the camera and microphone
indicators, and we enable thelocation indicators, which aren't
actually enabled on production.
Andrew 12 operating systems.
Similarly, we also enabled thembefore they were actually enabled
in production on Android 12.
And I believe they've been a featuresince Android nine, if I recall properly.
(05:54):
And that's just a very brief summaryof just the incremental systemic
privacy and security improvementsthat we do at graphing us.
And we have a full featureslist on our website.
Mishaal (06:04):
thank you for high level rundown of.
Many of the security and privacy benefitsthat crafty nos offers on top of AOSP.
One thing I wanted to ask you to follow upon, these extensions that you guys offer
over AOSP is , why do you think AOSP.
Doesn't offer hardened Malik by default.
And what are the downsides ofenabling it the way graphing OSS.
(06:26):
And are there any performance,downsides to enabling it?
, Gabe (06:30):
ISP currently is using the scooter allocator instead of hardened Malak.
Now we're completely open toAOSP using hardened Mellon.
If they were to adopt it, it'spermissively licensed and is inherently
compatible with the licensing of AOSP.
harden, Malak, compared to scooter,we'll use more memory and that's due
to the mitigations, which it deploys.
(06:50):
And also it can potentially lead to issuesin applications, which do have memory
corruption, which simply isn't beingexposed by traditional memory allocators.
. And honestly, that decisionreally lies with them.
bionic is inherently designed so thatyou can essentially swap in memory.
Allocators is I wouldproperly crudely word.
(07:13):
Hot metal compared to school, though,when it comes to performance device
resource usage performance shouldnot really be affected much from
a user's perspective, but it willinvolve in increased memory usage.
That's due to the mitigations,which pardon Malik deploys.
And obviously Google could potentiallydisabled some of the mitigations of
(07:34):
enharmonic if they wish to deploy it.
And that would still be an improvement,but obviously it remains to be seen
as it is ultimately a Google choice.
And we can't really show it.
Mishaal (07:44):
So just taking a step back and trying to summarize, I think
you'll find is that, because Googleis such a massive corporation that
develops, all of Android, which isused by billions of devices and they're
responsible to thousands of companies.
Tens of thousands of developers outthere, any change that they have to make,
(08:05):
any performance impacting change thataffects things on the millisecond scale is
something that they have to be aware of.
And because, such changes arescrutinized so heavily and they have
to be benchmarked and they have tobe observed for changes, will this
negatively, in fact, 1% of our devices.
And if so, how badly will it impact them?
These kinds of considerations?
(08:26):
you know, hardening decisions, moredifficult for Google to do, whereas
with a project like graph, it's possibleto take more experimental approaches
that may impact performance a bitnegatively, but would theoretically and
practically improve the security overall.
So just to give one example ofthis consideration that I'm aware
of personally, The applicationspawning process used by
(08:49):
Android, which is called zygote.
I believe graphene O us disablesthat traditional spawning model.
And, what happens normally is thatAndroid creates a, if you go back
to like high school biology createsa psycho and then from there.
Application process or split off fromthat psycho and the benefit of having that
psycho processes, that it's able to startup some of the libraries and some of the
(09:10):
tools and et cetera, that are needed byapplications when they're being spawned.
, this is not as secure as spawning everyapplication freshly, but the benefit of
using Android traditional spot processis that it speeds up app launch times.
By disabling it, you get better security,but you also get slower app launches.
So that's an example of a, trade-off thekind of trade-off that graphene OSTP makes
(09:33):
to trade security, security above else.
Security is the most important aspectwhen it comes to designing and building
features for graphene graphing.
S would you say that's an accuratedepiction of the design philosophy?
Gabe?
Gabe (09:47):
I would say that usability is something that we very heavily connect.
Which is why we've built thingslike assemble, assembles, legal
place services, and we're currentlyworking on extensively documenting
its usage and we're making iteven easier for users to use it.
And we've renounced to exact spawning.
, it is generally on newer hardware,very imperceptible, I would say.
(10:10):
Probably one device generation downthe line, or honestly, even on modern
devices, like the pixel five and the pixelsix, it's barely noticeable whatsoever
to the average user on legacy devices.
Like the third generation pickup.
Especially the free andfree XL, which use EMMC.
It did lead to exec spawning,having a much higher impact compared
(10:31):
to newer generation devices.
And I think over time, , asdevices get moved to more powerful
hardware, . It'll completelyprevent being an issue completely.
David (10:41):
Yeah.
And I think that . If you want to goeven wider, you can say that this is
just computing at work it's Moore's law.
We're getting more powerful hardware,sequentially over the years here.
And as that hardware becomes morecapable of executing within the
thermal or wattage envelope ofyour smartphone, you're able to do.
I think a good example of that.
(11:02):
If we're going to talk about EMMC andstorage speed would be Androids move
to full disk encryption, which waspainful and took a number of years.
I forget when it wasintroduced as mandatory.
Was that new get maybe when FDE became.
I don't specifically recall, but Google'sreasoning was well, we're going to
impact performance so badly, and I thinkeverybody can intuitively understand why
(11:24):
disc encryption can impact performance.
We saw that fight for a long time.
I think some phones allowedyou to turn on encryption.
as an option when they receivedan iOS upgrade and it absolutely
destroyed performance.
So yeah, it's something thatGoogle probably has to weigh
pretty frequently given diversityof devices in the ecosystem.
Mishaal (11:44):
So just a up on encryption aspect, I believe your full disk
encryption was introduced in 5.0.
And then it was eventuallyreplaced with file based in.
if you just Google those two terms,you'll find the, documentation
by Google on what they are.
I don't think they're really necessaryfor us to dive into right now.
so I just want it to.
Next, you mentioned a lot of differentaspects scape that elevate graphing
(12:08):
OSTP as a privacy and securityoriented operating system over AOSP.
so if I were, listening to this podcastand I want it to go and install a graph,
you know, us onto my own device and Ivisited graphene ios.org and visited
the releases section, I would noticethat the operating system is only
available for Google pixel devices.
Can you tell me why.
Gabe (12:27):
the unfortunate reality is, and I'm going to be pretty blunt
about this, the vast majority ofOEMs, they're pretty terrible.
The great thing about pixel devicesis that they are essentially
the de facto reference devicesfor Android, and they are full
support within AOSP and they have.
Probably the best hardware securityyou can get on an Android device.
(12:50):
they rivaled that of an iPhonewhen it comes to security things
like having a proper IMU andhaving a proper secure element.
So the pixels, they have the Titan,em, on the new generation, a base
pixels, the tighten, em too.
So that's the pixel six and sixpro and those secure elements
does support the Weaver API, whichmassively improves this encryption.
(13:14):
just things like this.
Most other OEMs don't implement and mostcritically, most OEMs do not implement
support for alternative operating systems.
Google pixel devices, they allowyou to unlock the bootloader
without any trouble from the OEM.
You don't need to ask for an unlockcode, like some OEMs, they don't
need any special fancy software.
(13:34):
It's just use fast bit whenyou can unlock the bootloader.
And it also allows you todefine , a user defined route of.
what that means is that you can preservethe verified big frat model and actually,
use verified a bit and lock the bootloaderwith your own operating system, with
your own keys on a pixel device.
And generally pixels havebeen only devices to properly
(13:57):
implement support for that.
There's a few manufacturers out there,which I won't name while they do have
support, they don't implement it properly.
And there are serious security issueswith the alternative operating systems.
Mishaal (14:10):
So just for a bit of background, for those of you who aren't familiar,
the bootloader is a special piece ofsoftware that basically loads up, all of
the other components that are necessaryto load up the operating system,
including the kernel and everything else.
Literally loading up.
Everything needed to boot the device.
And when we say you unlock thebootloader, basically that allows, the
(14:34):
user to install images that were notoriginally signed by the manufacturer.
And, if you were to lock the bootloader.
Then those images would have to berecognized by, the verified boot system
on Android and most devices do not allowyou to, insert your own verified boot
(14:55):
keys into that process so that if youwere to lock the bootloader, your phone
will be completely braked after installingin alternative operating system.
And with few exceptions, likethe Google pixel series, you can.
I'm not the bootloader flashaccustom operating system
and then lock the bootloader.
, that is probably one of the most importantthings that blocks graphene, iOS and other
(15:16):
security minded operating systems frombeing supported on non pixel devices.
one thing I noticed though, is thateven if you were to go through this
process of unlocking the bootloader.
Installing graphene O S and then,flashing a custom verified boot key,
and then re locking the bootloaderis that the bootloader will
still show you a warning message.
(15:36):
It displayed in yellow thattells you that you're running
in alternative operating system.
If you were the user who wentthrough the process of installing
graphene OSTP and did all this.
You probably, dismiss thismessage is no big deal.
Cause you know exactly whatyou did to your own advice.
But if you were to purchase a devicewith graphene iOS pre installed, or
maybe you had a friend or someone elseinstall it onto your device for you and
(15:59):
you put up your device and you see thismessage, you might be a little concerned.
So I wanted to ask you . whatwould it take to have this message,
not show, what would it take tohave graphene S be treated like
a first party operating system?
Like the pre-install firmware on devices.
Gabe (16:15):
Going to keep it since.
Android has multiple states withinwhich verified boot will operate in.
So when you buy a device fromthe shops, say I bought a brand
new pixel six or whatever.
The latest Samsung is that devicewill boot in the green verified boot
state, which means that the device isbooting and operating system, which
(16:36):
has been approved and certified.
And, Basically the OEM said,yeah, we're shipping it with this.
We're approving this operating system.
It will be without any warning,no friction whatsoever.
Now say for example, I were to buya pixel, unlock the bootloader,
and it's still graphing.
Then device will be booting ina yellow verified boot state.
(16:58):
What that means is that device isusing a user defined root of trust.
Your device is using the graffitinow as keys in order to preserve
the verified boot threat model.
And it's running on a locked bootloader with a custom operating system.
So that means quite literally anywhere.
Combined pixel clone down AOSP andbuild their own fork of the operating
(17:20):
system of all their things that theywant in bear operating system, flush
it to the phone with their own keys andlock the bootloader, and they will be
able to completely maintain the frontmodel of the Android security model.
Mishaal (17:33):
And so if say an OEM wanted to implement first party support for
graphing OS, what exactly would they haveto do to get the device to boot with a
green verified boot state with graphene O
Gabe (17:45):
S so an OEM would have to waitlist on keys in order for the
phone to boot in the green state.
Within the bootloader andOEM, essentially, It has a
key pinned within the farmer.
and if that key does not match whatis in essentially the approved list,
the phone will kick and scream andsay, all right, is it using a use
(18:08):
of the finder of trust or is it not?
if it's not, and it's on a lot,bootloader, it'll give a red screen
because something has gone terribly wrong.
If it is using a user defined rootof trust of a lot bootloader, then
it will say, okay, you are in thelist, but the user has defined you.
So that means that it willbe in a yellow verified.
(18:29):
With graphene us on potentiallyour own hardware or a partner
manufacturer's hardware.
We aim to have it so thatour keys will be wait-listed.
And you'll be able to skip that screen
David (18:41):
quick tactical question.
can this list be changed after the factby flashing a new boot loader to the
device, or is that break the trust?
Gabe (18:49):
only the OEM can build and sign the bootloader.
all the farmers of thedevice is signature enforced.
So you can't just swap outthe bootloader with your own.
You'd have to use thepre-production device to do that.
And that's just not going to happen.
David (19:03):
I guess my example would be in the case of an OEM, actually,
doing this and partnering and wantingto update a phone to support, the
green status, would that be possible?
Gabe (19:12):
That could absolutely be possible.
Mishaal (19:14):
Awesome.
I want to focus on the postinstallation aspect of graphing LS.
Once you actually have properlyinstalled it and have set it up, you're
going to actually be using this asyour operating system on your daily
driver device, which means do you haveto have applications anyone who has
installed in AOSP bill probably knowsthat it's incredibly bare bones and
(19:34):
the basic apps that are there are old.
Incredibly unmaintained by Google.
Unless you want basically a dumbphone, you're going to have to
install apps from somewhere else.
Most OEMs decide to include GMs, whichis Google mobile services, as well
as a suite of their own applications.
But for smaller teams like graphing us,it's just not feasible to develop an
(19:55):
entire GMs alternative suite of apps.
And it's also nottechnically legally okay.
To ship GMs alongside these grapheneiOS belts, although many, I'd say other
operating system projects do so anyways.
but I think philosophicallygraphene, O S doesn't really like
the concept of GMs and has been.
(20:16):
working on alternatives because widelyrecognized at GMs and, Google play
services and Google play store inparticular are incredibly important
applications for the average user.
You know, most users probably won't botherwith alternative operating systems that
don't have those applications becausejust so many things aren't unavailable.
And so many applications just refused.
(20:36):
gave actually alluded to this earlier, butgraphing OS has been developing something
called the sandbox play services,compatibility layer, and this, I think,
tries to bridge the gap between okay.
we value privacy andsecurity above all else.
Google apps are closed.
Source binaries.
They collect a whole bunch of data.
But, we know users wantto use them regardless.
(20:59):
So I wanted to ask you Gabe, can you tellus a bit about how sandbox play services,
compatibility layer works and how doesit, deliver access to Google apps while
preserving graphene OSS privacy model?
Gabe (21:13):
Sure.
So ? say for example, you were to justcompile an all AOSP build or just simply
buy a phone, which didn't come with GMs.
You don't have Google play storethen of Gill play services, general
legal services framework, et cetera.
You won't be able to justinstall the APKs onto the phone.
And everything will train crashbecause by default they expect to
(21:35):
be in a special se the annex policy.
They expect to be built into the OS.
So they actually privileged apps andthey expect to have all sorts of extra
permissions, which aren't user-facingand only privileged apps can get.
And because of that'swhy they chain crash.
On graphing of us, what we'vedone is instead of running
in the own se the next time.
(21:57):
They run in the normal untrusted app.
I see an X domain, which means they runin the same application sandbox, just
as any other APK you are to install.
We don't ship them at allwithin the operating system.
On top of that, we have essentiallytaught them how to run like this.
we do that using shimswithin the operating system.
(22:19):
So say for example, Google play servicesmight try and access the privileged API
to , get the serial number of the phone.
Yeah.
Instead of what we'll do iswe'll just say, oh, there's no
serial number, but that's okay.
You can just use thisstub, API that we made.
And then it would just think,oh, there's no serial number.
Guess there's none.
And it'll just continue on.
that's essentially what it doesthroughout the application.
(22:43):
And we've got to a point where.
The vast majority of functionality offeredby Google play services and the whole GMs
stack work almost perfectly on graphing.
we have, for example, the new,no down advertising identifier,
you can enable that within Googleplay services, we also have.
The location, redirection support,which means say,, you install an
(23:06):
application that exclusively relieson Google play API APIs for location.
Instead of the Android operating system,location, API APIs, you can read the.
Those APIs system-wide to go throughour compatibility layer and then
redirected to the operating systeminstead of them essentially being
proxied through Google play services.
(23:26):
So that means Google play servicescan run without location access.
The apps that depend on itslocation API can still use it
through the operating system APIsand with regards to functionality.
I did mention earlier that almosteverything works and recently we've
got quite literally almost everything.
Things like casting to a Chromecast orapps that don't have their own costing,
(23:48):
implementation, and aligning the placeservices implementation that works.
Things like Fido and security keys.
Those work now, since thereis no AOSP implementation for
security keys, for example.
And it's one of many things whichyou can see has been moved into place
services in order to either be backport.
It took all Android devices,since you can't really back
(24:09):
port a feature like that to.
Over a billion devices, which are runningon multiple different Android versions.
So security, key support isn't inAOSP, but if were in place services
for everything, it's just an exampleof many features like that, which are
highly integrated into place services.
Like even if you were to compilechromium, premium's going to use
that for security, key support.
(24:31):
If you want to use safebrowsing on chromium, it
relies on the Google play APIs.
And the most common use case, whichI'm sure everyone has encountered
when they've tried to install customoperating system on their phone without
Google apps is Firebase notifications.
So the Firebase back-end is essentiallywhere , I was to install, I don't know.
(24:51):
Let's say Snapchat, forexample, their backend servers
would communicate to Firebase.
Hey, you've got a notificationand your phone with Google play
services on it would constantly out.
Towards Firebase and say, okay,there are any notifications.
And then Firebase would say, yeah, yougot on your Snapchat message and Google
play would then tell that to Snapchat.
(25:13):
And then Snapchat would pop upsaying, Hey, you have a notification.
But none of that functionality bydefault would be on the operating
system without Google play services.
And generally at leastin the Western world.
Pretty much everything uses firebased notifications that deliver
notifications for a backend to the client.
if you look in China, there's all sortsof different homegrown implementations.
(25:36):
I don't remember all of them off byheart, but I know Huawei has one.
I think Tencent has one as well, and I'msure there's numerous others as well, but
when it comes to the west, pretty mucheveryone uses Google play services and
the find may CPI to get notification.
And that, of course it's fullyfunctional and graphing us.
When you use some books, Google places.
Mishaal (25:55):
Yeah, so , I think this is a very fascinating and novel approach to
solving the issue of, that I'm sure manycompanies who are looking at building an
Android device of hat, do I have to shipGoogle mobile services with my device?
And if the answer is you're sellinga smartphone to a consumer, then
the answer is probably very likely.
And there's really been no way to getaround that because if you don't ship
(26:15):
GMs, then your users won't have apps.
When I've access to apps on theGoogle play store, many of their
applications will refuse to run orjust simply be broken without access
to play services, API APIs, and, justwithout access, do you lose so much
if you don't have include GMs and, by.
Accepting GMs into your bill.
Do you have to bundle it asprivileged set of applications?
(26:35):
You have to grant it so many permissions.
You're allowing Google to accessso many privileged APIs that aren't
available to other applications.
They can, collect a lot of data.
They run in the background persistently.
There's just so much control you'regiving up to enable GMs on your bills.
I think this is a reallynovel approach that basically.
Allows users to install GMs appsas if they were just regular
(26:59):
applications without giving up toomuch of your privacy in the process.
And I think basically any company that'slooking at, building AOSP and shipping
an AOSP device that actually functionsacceptably for an average user might
want to take a look at this sandbox playservices, compatibility layer approach,
because it is very interesting in my.
David (27:19):
I guess that my big question about that to UK would be, do you see Google
trying to shut some of these doors?
because these are work aroundsand, Google obviously also has its
own, kind of trust model for playservices that it wants to preserve.
So I'd be curious of yourview of where this puts that.
And, how you see their response to date.
Gabe (27:42):
I don't really consider this to be an issue because , , we
made shims for everything.
We can always add more shims.
and I highly doubt it's withinthe interest to intentionally
break anything, which we do.
So I don't really consider itto be an issue for the longterm.
Mishaal (27:57):
Right.
It is, a bit of a cat and mouse gamethere because, Google play services
and a lot of apps and GMs are ablack box to outside developers.
We don't have the sourcecode to the applications.
So we don't know what API APIsand features Google are planning,
or if anything breaks, wecan't really anticipate that.
But as Gabe mentioned, if anythingchanges, it's always possible
to account for that change.
They might just take some time anda bit of development effort, but
(28:20):
changes can be made to reintroducesupport and compatibility with
the latest place services updates.
one of the last questions I wantedto ask you, Gabe is, recently
there's been a lot of talk aboutsoftware update LUNGevity and Who
is to blame for the, in my opinion,mediocre support that most Android
devices get from their manufacturers.
(28:41):
On average, you'll findthat , most flagship devices get
three years of OSTP updates andthree years of security updates.
Recently, Samsung has extendedthat to four years of OSTP updates
and five years security updates.
they're finally startingto approach apple levels.
But apple has always beenthe gold standard for years.
And for years, Android haslagged behind that gold standard.
(29:03):
So , what do you think of this issue?
Do you think, this can be solved.
Do you think there is a particularentity that we would blame for, poor
software support, length, or do youthink it's more complicated and how does
this affect your work on grafting LS?
Gabe (29:19):
When it comes to solving this, I do quite firmly believe that it's
a huge combination of issues wherebySOC vendors and OEMs, both have caused
it to be a little bit of a headacheI think Google has acknowledged this.
And I think since the introductionof initiatives like treble
project, main line, and GKI sogeneric Colonel images, I'd say.
(29:43):
Possibly in the far future, potentiallyeven near a future or get to a point
where Google would end up maintaining thevast amount of the base operating system
that's unified across all Android devicesand they would update it and maintain.
And we'll get to a point where OEMsjust simply maintain their device
specific bits and SOC vendors withcollaborate with OEMs to make sure
(30:06):
that's getting pushed out quickly.
So we'll get to a point where.
Google might do the entireunderlying OS and they might
do the generic kind of women.
And they might just do thatautomatically for everyone.
And that would leave OEMs of havingto manage firmware updates and
kernel module updates and any otherparts of the operating systems.
So say they have a fancy skin, orthey might have some novel features.
(30:31):
They would maintain that, but Googlewould maintain the core Android OSTP.
And I think that will most likelybe the future we end up going into,
but of course either really knowwhat will happen in the future.
That's just my personal speculation.
I don't think there's a clear solutionto it, but I do think the work Google is
putting into trying to mitigate thingsand ultimately solving it is going
(30:57):
to be highly beneficial in the long.
I do quite firmly believe thatsupport periods are far too short.
And I think that, a question that isbrought up often is why are we coming
together to essentially make e-waste?
And the reality is as a project,we can't really do much about it.
the truth is that we can only be.
I have devices for security coverage.
(31:19):
So long as an OEM is providing support.
The pixel two, for example, that's beenend of life work quite a long time.
Now there is no way you can havea secure pixel turnout because
the OEM, IE, Google is not pushingup any security updates for it.
Say you're on a pixel free.
You need to move.
If you're on a free freer, you needto think about moving later this year,
(31:42):
it's not necessarily a great reality.
And people do often frequentlycompare this ecosystem to the desktop
side where they're saying, oh, butI can use my desktop for years.
I can just install an expert.
I think the awareness of.
In mobile, secure is far more heightenedcompared to that of desktops where
people don't really understand thatthings like their UEFI from where their
(32:05):
GPU from where they're trusted platform,module, firmware, all of that culminates
in the whole security of your system.
And the reality is most OEMs neglect that.
we are already seeing in the wildexploitation of these things.
And I do think in the future, it will bea far bigger issue than it is currently.
(32:26):
It's a time bomb waiting to happen.
And in that same regard, users should bevery well aware that they should really
avoid using hardware that doesn't havefull OEM support because they're not
going to be getting security coverage.
And of course, there's notgoing to be any bug fixes, but.
that's probably the least ofyour concerns when anyone can
just, get into your system.
yeah, I don't think there's a very clearanswer on what we can do to tackle that.
(32:48):
, that's all I really haveto say on the matter.
David (32:51):
And I think that's a very fair assessment and that's
what we hear from everyone.
And this is becoming our bit everyweek where we ask about the state
of the Android update ecosystem.
And the complexity of it, as you've said,makes it really hard to pin anyone to the
wall and not necessarily that they deserveto be there also consumer preferences to
take into account, which in many ways.
(33:14):
The aforementioned e-waste problem.
People want the new thing, andthey've been conditioned by a lot
of companies to want the new thing.
For Google's part.
I think that your assessment that,they're going to keep making the OSTP more
modular as relates to the OEM involvement.
That rings true based on everything we'veseen with trouble and mainline and GKI
(33:36):
and all of these other initiatives thatare just designed GRF is another one
that we've talked about on a episode ofthe show that will probably be going up.
And the Google requirements freeze thatwill essentially make it easier for
OEMs to be worse about certain kinds ofupdates, but in service to getting them
up to date on newer platform versions andmore security patches extensively as well.
(34:00):
So you do see Google have to balance thatthose considerations against each other.
the, OEM.
their kind of economic situationand then also the security of the
whole platform, which is obviouslyreally important to Google.
think that a greatexample is play services.
Google has increasinglyused that as the carrot.
And the stick being, not having playservices because everybody wants them.
(34:23):
Right.
So I think that we'll continueto see them use GMs in that
way to advance that interest.
And I think it's a credible way to do it.
It's also one of the few toolsthey have in their belt , to
enforce that sort of thing.
yeah, it's, going to be slow.
Like you said, Gabe, it's goingto take time, but I think we're
watching the pieces come together.
I think this year, I would sayMichelle, would you agree that
(34:45):
especially with 12 L or excuse me,12 and 13, we've seen Google's plans.
They are become much more clear.
Mishaal (34:52):
Yes.
Especially with the introduction of GRF,which many developers that I've spoken to.
Pet basically describe it as thecompletion of project trample.
Treble is, finally here with GRF andif you're not familiar with GRF then as
David mentioned, go back and listen to thepodcast episode where we talked about that
or the blog posts that I published on it.
but in general, to answer your question.
Yes, I do believe finally, we're goingto see the fruits of all of those
(35:17):
initiatives . coming to fruition, may takea few years because we have to actually
wait to see , how quickly OEMs now rollout updates based on these improvements.
But I do think it will have anoticeable impact on the frequency
and the speed at which Androidupdates are pushed out to users.
David (35:34):
All right.
thank you for joining us, Gabe.
where can people learn more about graphingand see what you're working on over there?
Gabe (35:40):
So we have a highly in-depth documentation and feature
overview, which you can find thatgraph, s.org and we are also.
Highly active on our Twitter page.
And we also have a very interactive andactive community, which you can find
also in graphing the rest of all by justhitting the contact button in the top.
(36:01):
And you'll be more than welcome to talkabout it and ask any questions you have.
David (36:06):
Thanks Gabe.
And actually I'm one of the thingsyou brought up earlier did remind
me of Asper a little bit, becausewe do support verified boot, for our
own distro based on Android, becausework with a couple of OEMs, one of
them, most prominently being Lenovo.
So that actually clicked for me.
So thank you for bringingthat up because I wasn't a.
(36:26):
Of how that was architected and nowit makes a lot more sense to me.
and that gets to who's powering the show.
It's Esper, Michelle andI both work at Esper.
You can find our work@blogdotesper.io.
If you're listening to this episodeand you're wondering, okay, like I'm
here because I want to understandhow Android devices get built.
what goes into putting on yourown OSTP distro on an Android.
(36:48):
Come talk to us at Esper.
We do this every day.
We're building our own custom.
Do we have, excuse me, not buildinghalf built our own custom disrobe
Android that works for a variety ofdevices, including X 86 Intel computers,
which we're actively flipping inthe wild with customers right now.
And we can give them security patches too.
Yeah, you should get in touch with us.
(37:08):
That's esper.io.
If you want to book a demo, or ifyou just want to see what Michelle
and I are up to that's blog.esper.io,or you can find us both on Twitter.
Our links are in the show notes below.
Thank you for listening everybody.
And we will catch you next time.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!