00:00:00
If some of you are expecting this video
00:00:02
to be a drama or a feud between me and
00:00:05
the Graphino OS community, you can run
00:00:08
along now as that is not what this is
00:00:11
about.
00:00:13
Graphine OS and previously others like
00:00:15
it like Klex OS are specific builds of
00:00:19
modified Android that were focused on
00:00:21
privacy and security.
00:00:24
And they were able to accomplish this on
00:00:26
pixels because Google allowed open
00:00:29
access to the code of a Google Pixel.
00:00:32
But as many of you have heard, Google
00:00:34
locked the source code down on Pixels
00:00:37
starting with Android 16.
00:00:40
The effect of this is to basically stop
00:00:42
the prior approach taken by Graphine OS
00:00:45
and Kix OS in building their versions of
00:00:48
Android.
00:00:50
While this is a negative milestone, it
00:00:53
doesn't stop everything and certainly
00:00:56
doesn't prevent making privacy and
00:00:58
security focused Androids. It doesn't
00:01:00
stop all custom ROMs either. Lineage OS
00:01:03
still flourishes. Graphine OS is
00:01:04
sticking to its prior methods so far,
00:01:07
but it doesn't have much of a choice
00:01:10
because of their different goals on a
00:01:12
pixel. I will take a very detailed
00:01:15
approach here and that is really the
00:01:18
distinguishing characteristic of this
00:01:20
channel. We'll do a deep dive into the
00:01:22
Android architecture and build process.
00:01:27
I will warn you that this is a very
00:01:29
technical discussion of the Android
00:01:30
architecture. If you have some knowledge
00:01:32
of flashing custom ROMs or are a user of
00:01:35
these custom ROMs or are interested in
00:01:38
graphine OS, this will be important for
00:01:40
you. But even if you're not technically
00:01:43
savvy to this level, the conclusions
00:01:46
here are extremely important as it
00:01:48
provides a road map to privacy and
00:01:50
security versions of Android for the
00:01:53
long haul. Stay right there.
00:02:02
By the way, this is such a complex topic
00:02:04
that it is possible that I got some
00:02:06
parts wrong. Unfortunately, a lot of
00:02:08
pieces here were not openly documented.
00:02:10
So there is a little bit of OENT
00:02:12
required. If so, just tell me in the
00:02:15
comments nicely and I'll make sure to
00:02:17
spread the word as this is likely going
00:02:20
to be a multi-IDE topic. Today I'm
00:02:23
specifically focusing on graphine OS
00:02:25
because unlike all other custom ROMs,
00:02:28
they took a different approach and that
00:02:30
makes them unique and allowed them to
00:02:32
make specific claims about hardening
00:02:34
Android against cyber attacks. Just to
00:02:38
state this openly, the mentally unstable
00:02:41
leader of Graphin OS has spent his time
00:02:43
attacking others and me in particular. I
00:02:47
don't care about his attacks or the lies
00:02:49
he spreads about me. But forgetting his
00:02:52
attacks and the negative cult he
00:02:54
cultivates, it is in fact a boon to the
00:02:58
privacy and security community that
00:03:00
there is a project that focuses on
00:03:02
finding ways to make our phones more
00:03:05
private and secure. Graphine OS is great
00:03:08
as a project. I've spent a lot of time
00:03:11
examining the source code changes and if
00:03:13
some other developer on some other
00:03:15
custom ROM agrees with the security or
00:03:18
privacy benefit of what has been
00:03:20
documented then those changes could be
00:03:23
easily applied to another project. This
00:03:26
is the great benefit of an open-source
00:03:29
approach. But what truly differentiates
00:03:32
Graphine OS is that instead of just
00:03:34
changing portions of Android called the
00:03:37
Android framework, which is typically
00:03:39
the only thing changed by other custom
00:03:42
ROMs, they change the actual low-level
00:03:45
code in the Android device itself. And
00:03:48
this means accessing the Linux layer and
00:03:50
deeper parts of the Android source code.
00:03:53
These modules are typically written in
00:03:55
C. And I appreciate that as I have coded
00:03:59
enterprise systems entirely in C in my
00:04:01
career. Unfortunately, Graphino has
00:04:04
relied on Google maintaining their
00:04:06
behavior of releasing the complete
00:04:08
source code of Android for the Pixel.
00:04:10
But now Google changed. Google could
00:04:13
have deliberately made this decision to
00:04:15
cut off Graphine OS and Kix OS. Maybe
00:04:18
it's because of other reasons. We don't
00:04:20
know, of course. But the end result is
00:04:23
that the Linux level source code in
00:04:25
Android is now inaccessible on pixels.
00:04:29
The effect of this on graphin OS is that
00:04:32
while it can still make changes to the
00:04:34
open source called AOSB or otherwise
00:04:37
known as the Android framework,
00:04:40
low-level device code can no longer be
00:04:42
altered on a Google Pixel. This has so
00:04:46
many effects including killing features
00:04:47
like verified boot changing the libcy
00:04:50
libraries or low-level Linux functions
00:04:53
and various other changes disabling
00:04:55
features of device drivers that graphine
00:04:58
OS utilized. Most of these features
00:05:01
relate to the hardening of Android
00:05:03
against cyber attacks but typically do
00:05:06
not affect the privacy benefits.
00:05:09
By the way, the main privacy changes to
00:05:11
Android which relate to removing Google
00:05:14
spyware are mostly in the Android
00:05:17
framework and can be changed by all
00:05:19
custom ROMs including Kix OS, EOD OS and
00:05:22
Linux OS. And this is why other privacy
00:05:25
focused OSS are not affected as much.
00:05:29
Before I get into a complete explanation
00:05:31
of that, let me tell you the basics of
00:05:33
the Android architecture and its build
00:05:36
process.
00:05:40
Android architecture.
00:05:43
This chart shows the architecture of
00:05:45
Android. The green layer encompassing
00:05:48
several modules is called the framework
00:05:50
and that is basically the source code
00:05:52
available if you look into the source
00:05:54
code of Android open-source project
00:05:57
AOSP.
00:05:58
This framework supports the Android
00:06:01
apps, those included in AOSP and those
00:06:04
created by thirdparty developers. At
00:06:07
this level, the apps are often
00:06:09
downloaded as APK files. And apps at
00:06:12
this layer are developed using Java or
00:06:15
Cotlin. The apps are divided into two
00:06:18
groups. System apps are pre-installed on
00:06:21
your device and third party apps are
00:06:23
downloaded from Google Play Store. By
00:06:27
the way, later on in the release
00:06:29
process, Google overlays those system
00:06:32
apps with its own proprietary versions
00:06:35
and that's where all the Google spyware
00:06:37
is shown in red. There's a layer called
00:06:41
the Android runtime or art that converts
00:06:44
the Android app code into fast executing
00:06:48
code that can execute functions made
00:06:50
available by the framework. So, Android
00:06:53
apps can only run code that calls the
00:06:56
framework functions. There's no direct
00:06:58
access to the hardware. Everything has
00:07:01
to go through the Android runtime. And
00:07:02
each app is granted permission by the
00:07:05
framework. In order to access hardware
00:07:08
like the screen, the touch interface,
00:07:11
the microphone, speakers, camera,
00:07:13
sensors, cell service, internet, the
00:07:16
framework connects to the low-level
00:07:18
functions provided under Linux itself.
00:07:22
The Linux section is in yellow. But
00:07:24
before the framework can talk to Linux
00:07:27
functions, there is a translation layer
00:07:30
and this is called the hardware
00:07:32
abstraction layer or HAL which I show in
00:07:35
purple. HAL's job is to communicate
00:07:38
directly with Linux drivers and Linux
00:07:40
functions to make it available to the
00:07:43
framework layer. This layer is built
00:07:45
using an interface that Google called
00:07:48
HID L interface description language or
00:07:52
now AIDL Android interface definition
00:07:57
language. The purpose of this language
00:07:59
is for an OEM or a vendor making the SOC
00:08:03
system on a chip like Qualcomm or
00:08:06
MediaTek to compile a layer to
00:08:09
communicate with Linux level drivers. By
00:08:12
standardizing this communication method
00:08:15
but allowing it to be developed
00:08:17
separately, it creates a consistent
00:08:19
translation layer but allows for
00:08:22
independent updates since this is
00:08:24
actually created by the OEM.
00:08:28
Some functions in the framework can talk
00:08:30
directly to Linux functions using HAL
00:08:34
but not connected to a vendor. And I
00:08:36
presume some framework functions can
00:08:38
call Linux directly without HAL if
00:08:40
they're stable and never change like the
00:08:43
C library functions. Now let's talk
00:08:46
about the Linux layer which I show here
00:08:48
in yellow. In essence, from here all the
00:08:51
coding is essentially standard C as used
00:08:54
in Linux. Linux is independent of
00:08:57
Android but is part of the Android
00:09:00
device build. to make Android run on an
00:09:03
Android compatible device. It has a
00:09:05
standard Linux kernel which is currently
00:09:07
Linux 6.1 and that is used on the new
00:09:11
versions of Android device
00:09:13
manufacturers. For example, those that
00:09:16
make touchscreens, fingerprint readers,
00:09:18
Bluetooth radios, GPS radios, speakers,
00:09:21
microphones, cellbased band modems and
00:09:24
so on write their device interface code
00:09:27
in C. Typically those device drivers
00:09:30
used in laptop and desktop computers are
00:09:34
submitted to Linux itself and Linux to
00:09:37
valves gets to integrate them into the
00:09:40
base Linux kernel that Linux users know
00:09:42
as mainline Linux. However, plenty of
00:09:46
device manufacturers do not mainline
00:09:48
their drivers. That's the lingo that
00:09:51
says they don't submit their drivers
00:09:53
upstream for inclusion into the Linux
00:09:56
kernel because sending it to Linux means
00:09:59
the device driver has to be in source
00:10:01
code format because of course once they
00:10:03
do that then the internals of how their
00:10:05
devices work are exposed to competitors.
00:10:08
For this reason the Linux installed in
00:10:11
Androids is actually made up of two
00:10:13
sections. First, you get the mainline
00:10:15
Linux kernel which includes standardized
00:10:17
drivers which by the way can still be
00:10:19
modified by Google with newer changes
00:10:22
called upstreaming.
00:10:24
And then the second section of Linux is
00:10:27
where the OEM proprietary drivers are
00:10:30
installed in and these are all compiled
00:10:33
modules and are closed source. This is
00:10:37
standard on all Androids. Now the
00:10:39
purpose of explaining all this to this
00:10:41
degree is to show you where the open-
00:10:44
source code is. The entire Linux
00:10:46
distribution including its libraries and
00:10:48
mainline drivers are all open source but
00:10:52
not by Google. They are open source from
00:10:54
Linux itself. And this is something that
00:10:57
Google has to abide by since it is tied
00:11:00
to their use of Linux and the GPL
00:11:03
license. The actual AOSP is also open
00:11:06
source by Google, which as I said is
00:11:09
really only the Android framework. And
00:11:12
as I said, the vendor layer includes
00:11:14
only binary executable code from the
00:11:16
OEM. And these are never open source,
00:11:20
even on current pixels. Now, the last
00:11:23
layer of the Android architecture is the
00:11:25
bootloadader, which I show in gray. The
00:11:28
bootloadader is a piece of code that
00:11:30
actually starts the OS and initializes
00:11:33
Linux. Well, this is standardized on
00:11:35
many x86 computers, for example, using
00:11:38
core boot. On Android, each OEM creates
00:11:42
their own bootloadader and this is
00:11:44
integrated into the Android ROM. The
00:11:47
bootloadader is not open source.
00:11:53
Android partitions.
00:11:55
The theoretical architecture I've just
00:11:57
described gives you a big picture of how
00:11:59
things are connected. But now let's
00:12:01
enter the real world. I will start
00:12:04
backwards here and start from the
00:12:06
knowledge base of someone flashing a
00:12:09
custom ROM. We will bring you to the
00:12:12
physical reality by showing you how
00:12:14
these translate into the actual content
00:12:16
you see on an Android storage device
00:12:19
which is made up of partitions and
00:12:22
files.
00:12:23
Though in the end everything ends up as
00:12:26
thousands of individual files on an
00:12:28
Android device. The standard way they
00:12:31
are installed are in groups of files
00:12:34
segmented by partitions and further
00:12:36
directories. Some of you have
00:12:39
experienced using the ADB, Android debug
00:12:43
tool provided by Google, which allows
00:12:45
you to replace the OS image in the
00:12:48
Android storage.
00:12:51
Typically, a person installing a custom
00:12:53
ROM would put the device in fast boot
00:12:55
mode and then you use ADB to flash the
00:12:58
image to the device. First you would
00:13:01
allow replacing of the ROM image using
00:13:03
an option OEM unlock on the current
00:13:07
version of Android. Then you would use
00:13:09
some tool provided by the bootloader or
00:13:12
you replace the bootloader with a custom
00:13:14
one like twerp. You put the device in
00:13:17
something called fast boot mode and then
00:13:19
using a compatible tool you either flash
00:13:22
a complete image onto the device or
00:13:24
depending on the device you store
00:13:26
segments of the OS as separate
00:13:27
partitions.
00:13:29
Just to give you a view of this, these
00:13:31
are the separate partition images
00:13:33
typically available when you install
00:13:35
Lineage OS.
00:13:37
I'm just giving you generic names here
00:13:40
for some of the partitions as each OEM
00:13:43
may change this. And I also show you the
00:13:45
associated flashable image associated
00:13:48
with it.
00:13:50
This kind of organization actually was
00:13:52
thought out over time and has evolved
00:13:55
from the early versions of Android. The
00:13:58
reason for this separation is to allow
00:14:00
owners of each partition to update their
00:14:04
sections independently.
00:14:06
The system partition is what actually
00:14:08
contains the Android framework. So this
00:14:11
is the actual result of compiling the
00:14:14
Android open-source project by itself.
00:14:17
Another term for this is a gsi or
00:14:20
generic system image. And this isolation
00:14:24
of all things framework related to this
00:14:26
one partition allowed a standardized
00:14:29
Android to be installed on multiple
00:14:31
devices simply by replacing a stable
00:14:35
framework image and then tweaking the
00:14:37
behavior of the framework for a specific
00:14:40
device using XML files called overlays.
00:14:43
This is actually how much of Lineage OS
00:14:46
is made. So the only thing modified by
00:14:48
Lineage OS is the framework. This is an
00:14:52
important distinction that we'll come
00:14:53
back to later. Now, just to leave theory
00:14:56
for a moment, using ADB, I will show you
00:14:59
the different directories.
00:16:56
To give you a complete big picture of
00:16:58
how one creates a complete image for an
00:17:01
Android device, I will describe what is
00:17:03
called the build process of Android.
00:17:06
Some of this is assembly of the modules
00:17:08
and binaries and some of it actually
00:17:11
creates executable code which is called
00:17:13
compiling. If I were a manufacturer of a
00:17:16
phone, I would have access to all the
00:17:18
source code needed to create a build.
00:17:21
And today this is done via Git
00:17:24
repositories. I believe there are
00:17:26
approximately 8,000 Git repositories
00:17:30
tied to Android, meaning there are 1,000
00:17:33
separate projects, some from Linux, many
00:17:36
from Google, and some from the OEM. And
00:17:39
there's a standard procedure for
00:17:40
creating a list of related projects that
00:17:43
need to be included in the build rather
00:17:45
than get complicated in identifying
00:17:48
specific agents like KAS, Sung, Ninja or
00:17:51
Make Files and BP files, etc. The
00:17:54
complex structuring of a thousand
00:17:55
projects making up Android means that
00:17:58
something assembles a complete list
00:18:01
called a manifest. And then you specify
00:18:04
what you want to build as an end
00:18:06
product. And then your device will clone
00:18:09
all the git repositories with all the
00:18:12
latest code. And then this is clone on
00:18:14
the machine that will build the project
00:18:17
using the manifest as a procedure map.
00:18:21
and several hours later you have your
00:18:23
flashable image. So in a big picture
00:18:26
sense the only people who can build a
00:18:28
complete flashable image are those that
00:18:31
have access to all the thousand or so
00:18:34
repositories.
00:18:36
And in the case of graphine OS it also
00:18:38
includes access to their own
00:18:40
repositories which are added to the
00:18:42
build process and replaces the
00:18:45
applicable repositories provided by
00:18:47
Google. The new reality is that those
00:18:50
relying on this build process needs
00:18:52
access to the pixel repositories beyond
00:18:56
just the framework. The framework is
00:18:58
always available in AOSP. For those
00:19:01
interested, the actual git repositories
00:19:03
for AOSP are in android.googles.com
00:19:07
and I can show you that here. But
00:19:09
without complete access to the entire
00:19:12
collection of repositories, graphine OS
00:19:15
cannot do a complete build of the entire
00:19:17
image. Now the reason this is not
00:19:20
important to Lineage OS is that Lineage
00:19:23
OS does not actually build the entire
00:19:26
Android for each device from source. My
00:19:29
understanding is that Lineage OS takes
00:19:32
the original flashable image files like
00:19:35
DTBO.
00:19:36
Vendor image, OEM. image and simply
00:19:40
replaces the system.image file which as
00:19:43
I already said is the Android framework
00:19:46
or Android generic system image gsi.
00:19:49
They just extract these images from an
00:19:52
existing phone without rebuilding them.
00:19:54
So those files are original from the
00:19:57
manufacturer and then when the OEM
00:19:59
updates them, Lineage OS just updates
00:20:02
their copy and then they flash it back
00:20:04
to the device. However, in order to
00:20:07
allow this, depending on the OEM, they
00:20:10
may need to replace the bootloadader or
00:20:12
boot. With some open version like twerp,
00:20:16
T twwrp
00:20:18
and the device boots like normal. Those
00:20:21
using EOD OS, Kalex OS and even Ubuntu
00:20:24
touch are taking all the image files
00:20:26
from Linage OS and basically are
00:20:29
reconstructing all the standard images
00:20:31
coming from the OEM and then replacing
00:20:35
system.image.
00:20:37
This approach by lineage OS creates some
00:20:39
differences from the graphine OS
00:20:42
solution. First, the vendor or Linux
00:20:44
portions are never modified on Lineage
00:20:46
OS. Second, because it is not built
00:20:49
together, the signatures of each image
00:20:52
will not match what is originally noted
00:20:54
by the vendor and this leads to the
00:20:57
problem of verified boot.
00:21:00
Thus, Android devices using this method
00:21:02
cannot be bootloader locked since the
00:21:05
modules are no longer original and those
00:21:08
using Linux OS will encounter some scary
00:21:10
message to that effect which we all have
00:21:13
ignored. This is not a problem of any
00:21:15
build process that has the entire source
00:21:18
code repositories since the signatures
00:21:20
are part of the build. But the Linux OS
00:21:23
hack will not allow this. And as I
00:21:26
already said, Linux OS and other oses
00:21:28
based on it are just modifying the
00:21:30
Android framework and not the underlying
00:21:33
Linux code or HAL.
00:21:36
Assuming a bootloader is unlocked, Linux
00:21:39
OS will work using the method I
00:21:42
described. Many phone models of course
00:21:44
never unlock their bootloader and an
00:21:47
example of that is Samsung.
00:21:52
What it means for low-level code
00:21:54
changes.
00:21:56
This has profound implications for
00:21:58
Graphen OS. I believe it is the only
00:22:01
open-source project currently in
00:22:02
existence that modifies code outside of
00:22:06
the Android framework.
00:22:08
Graphino has modified Linux libraries
00:22:11
directly by changing the standard C
00:22:13
library functions with the intent of
00:22:15
hardening the tools against buffer
00:22:17
overruns and so forth or clearing memory
00:22:20
every so often. Graphin OS could modify
00:22:23
the drivers provided by the vendor in
00:22:26
vendor related partitions but it was for
00:22:28
example possible for certain drivers to
00:22:31
be intercepted and disabled at the Linux
00:22:34
level so that those drivers are not
00:22:36
active. For example, Graphine OS
00:22:38
modified the build so that the USBC port
00:22:42
only enables charging when the phone is
00:22:44
locked or if some new sensor is added to
00:22:48
the phone, it would be possible to
00:22:50
disable that sensor at the Linux level.
00:22:53
So, Graphinobuilt features would be
00:22:56
important for high security level
00:22:58
individuals like Snowden types and
00:23:01
honestly I commend them for it. Tal OS
00:23:05
though they use the same full build
00:23:07
process as graphine OS did not in my
00:23:10
observation modify low-level Linux code.
00:23:13
So it doesn't affect them much to go
00:23:15
with the Lineage OS approach of just
00:23:17
modifying the framework. So it sounds
00:23:19
like Klex switched to integrating Linux
00:23:21
OS in their build process to fill in the
00:23:23
blanks on pixels.
00:23:25
This appears to be their solution as
00:23:27
Linage OS is now referenced as a source
00:23:30
on their website, though it will affect
00:23:33
their previous verified boot claim,
00:23:35
which I presume will be removed for
00:23:38
Android 16 and up. This is also what was
00:23:42
originally done by EOD OS, so it matches
00:23:44
what Kix OS appears to be doing now.
00:23:48
Since the hardening claims of graphine
00:23:50
OS are tied to modifying Linux source
00:23:52
code for Android, then that claim can no
00:23:55
longer be possible moving forward, at
00:23:57
least not on a Pixel. It would seem that
00:24:01
those interested in Android hardening
00:24:03
will have lost a choice.
00:24:09
All is not lost.
00:24:11
Well, some may describe this situation
00:24:13
as an obituary not just for graphine OS
00:24:16
but any other phone project that may
00:24:18
believe in hardening the phone software
00:24:20
beyond just the Android framework. Let
00:24:24
me reveal why the doors are just opening
00:24:27
if people want to do it. To demonstrate
00:24:29
this, I will describe our relationship
00:24:32
with EOD OS and also currently with
00:24:35
Ubuntu touch.
00:24:37
The difference here is that we have the
00:24:40
source code for the complete Android
00:24:42
compile of a Bra 3 phone.
00:24:46
And the final OS image we create for
00:24:49
this is called Lunar OS. For some of you
00:24:52
with a BR 2 phone, this was called Bra
00:24:55
OS, which was just a fork of Lunar OS.
00:24:58
EOD OS made modifications to AOSP or the
00:25:02
framework. But instead of using the
00:25:04
Linux OS method of taking files from the
00:25:08
OEM and adding a framework, our dev team
00:25:11
actually takes the EOD OS repository and
00:25:14
adds it to the build process, thus
00:25:17
combining Lunar OS and EOD OS. Let me
00:25:21
repeat that. The Lunar OS and EOD OS are
00:25:26
merged with EODS replacing the entire
00:25:30
system partition during build. This
00:25:33
means that the final result is a
00:25:35
complete EOD image for flashing Android
00:25:38
on Brax 3 and appears as a manufacturer
00:25:41
authentic code complete with verified
00:25:44
boot and lockable bootloadader. We will
00:25:46
be doing the same with Ubuntu touch as
00:25:48
well and whoever else wants to port
00:25:50
their AOSB variant to BR 3. So the base
00:25:54
code which has the Linux kernel and all
00:25:57
the associated code that was available
00:26:00
on pixels is also available on Lunar OS.
00:26:04
The dev team is organizing this now, but
00:26:06
the end result should be that other
00:26:09
parties could integrate hardening code
00:26:11
in the Lunar OS repository which is open
00:26:14
source and as I said has all the code
00:26:16
previously available to graphine OS and
00:26:20
then these hardening changes can then
00:26:22
benefit a larger community and it will
00:26:25
not be a dead end.
00:26:28
Obviously any hardening of the
00:26:30
non-framework related code on Lunar OS
00:26:32
gets automatically integrated into
00:26:34
builds of EOD OS, Ubuntu touch and so
00:26:36
on. Now the days of graphine OS for
00:26:39
pixels may be numbered. They can keep
00:26:41
going with the source code available
00:26:43
from Android 15
00:26:45
but going forward it becomes more
00:26:47
difficult. Community developers though
00:26:50
who are interested in helping a larger
00:26:52
pool of people can still be able to
00:26:54
contribute to an Android hardening
00:26:55
project just on a different device. So
00:26:58
the future is still open.
00:27:01
If you want to port your AOSB based
00:27:03
project to a Bra 3 or any other future
00:27:06
device we make then you are welcome and
00:27:09
feel free to contact the team at
00:27:11
bratec.net.
00:27:14
I expect that there will be more devices
00:27:16
available to this project in the future.
00:27:18
So stay tuned
00:27:24
folks. While other channels sustain
00:27:26
themselves via sponsorships, we are
00:27:28
actively sustained solely by this
00:27:31
community.
00:27:33
Thank you to those who provide financial
00:27:35
support directly to us through Patreon,
00:27:38
locals, and YouTube memberships. We have
00:27:41
also taken the approach of actually
00:27:42
creating an organization you can trust
00:27:44
by creating products that support your
00:27:47
goal and ours of achieving privacy and
00:27:50
offering it with the best possible
00:27:51
service at a reasonable price. And this
00:27:54
is how we chose to sustain this channel.
00:27:58
For those interested in the Bra 3
00:28:00
project that is handled by the site
00:28:02
brac.net and you can see the current
00:28:05
status of the project there which
00:28:07
currently started shipping. We have
00:28:09
other products that you will find in our
00:28:11
community area on Brax May. There are
00:28:14
over 120,000 users that are part of our
00:28:17
community that discuss security and
00:28:19
privacy issues in a safe environment.
00:28:22
Many of you believe in us and so this
00:28:24
community is growing. Some have been
00:28:26
involved for more than 10 years. In our
00:28:28
store though, you will find products
00:28:30
like Doogle Pixel phones, Bra Virtual
00:28:32
Phone, Brax Mail, and BiceVPN. These are
00:28:35
an essential base to building your
00:28:37
personal privacy and of course support
00:28:40
the creation of content on this channel.
00:28:43
Thank you for watching and see you next
00:28:45
time.
