Bromite: WebView stub apk to simplify installation

[SebiderSushi]

Is your feature request related to privacy?

No, but hear me out guys (i swear)

Is there a patch available for this feature somewhere?

No

Describe the solution you would like

A small (<~2MB) stub apk file signed by csagan5 and officially released. This file could be installed to the system or a magisk module folder to obtain the proper privileges and be registered in the system. As soon as the first upgrade is installed, it will bring the full WebView functionality.
This would be useful on devices with limited storage capabilities, especially under /system. For example the Nexus 4 with only 8GB of total internal storage in some devices and no sd card slot.
It should only be necessary to test, build, sign and publish such a stub apk once so the effort might just be worth it.
This would open up the possibility of compiling and publishing a single and concise Recovery flashing zip or Magisk Module (small and which does not access the internet). This could be used for a user-friendly installation, followed by a simple apk installation as done with every upgrade that will follow anyway.

Describe alternatives you have considered

Using a full SystemWebView apk and placing it in the system or magisk module folder.
This uses a mentionable amount of space which serves no more use as soon as an upgrade gets installed.
Installers like a Recovery flashing zip or a magsik module installer would need to either carry a full blown webview apk file for whatever target architecture applicable or access the internet to download them. On arm64 devices where an extracted webview library file needs to be present, such installers might not even install a working webview to begin with. In these cases the webview also just gets usable after the first upgrade or reinstall into the userdata partition.

[csagan5]

I understand what you mean, but I would not be able to develop this. You could start by developing something like this and see how it is to maintain it.

Anything related to the SystemWebView requires constant user support.

[SebiderSushi]

I could prepare and test a proof of concept. But in the end, it would have to be signed officially to allow installing official builds of Bromite SystemWebView as updates to it.

Also, an overview of the capabilities nesessary for the WebView apart from the permissions declared in its manifest and it being registered as a system web view might be good, so the stub apk would not accidentaly fail to reqest everything from the system.

Another idea i had was to fill any webview object another app might create using the stub apk would be filled with useful info. I.E. if only just the stub apk is installed, opening up my webview based browser would fill it with some notice that Bromite WebView is not yet completely installed and simply needs to be upgraded to function. As i'm, totally unfamiliar with the internals of an android webview i've got no clue how to achieve this.

As for the maintenance i think it might even be unnecessary to publish the apk for this more than once. As long as package name and signature don't change the stub apk shouldn't need to be altered. (and as long as there are no changes in any permissions or privileges that can only be declared in the original apk file - but i doubt these even exist in android)

[SebiderSushi]

Okay i just managed to get a super basic proof-of-concept work by just doing the following:

• Create a new Android Studio project without an activity from the template
• Remove generated app icons, themes and the dependencies from the gradle script
• Build & Sign that thing
• Download an official build of the Bromite System WebView and resign that with the same key
• Place the stub apk in /system/app/webview/ on an android Pie device and reboot
  At this point, no webview provider was listed in the development settings, but installing the resigned bromite webview build succeded and after that Bromite System WebView appered in the WebView list in the development settings and using webviews was possible.

Now it should be made sure that nothing is overlooked here and that the concept is applicable on android 10 onwards as well (The overlay story). But apart from making it work once i really don't see any expected maintaining burden here.

Copy of the source code i used for my test apk stub:
https://github.com/SebiderSushi/WebViewStub-ProofOfConcept
( But the only things i identified as critical so far are the package name and the signature. )

[SebiderSushi]

Okay i just tested this on a device running Lineage 17.1 and it worked as well.
What i did was alter the Magisk Installer by @linuxandria so that it would place my stub apk instead of downloading the official one.
The installer takes care of the overlay problem with android 10+.

All-in-all it went just as fine as with the Pie device - the stub did not turn up in the WevView provider list, but as soon as a re-signed complete WebView apk was installed, it appeared in the list and could be used by applications.

[csagan5]

Now it should be made sure that nothing is overlooked here and that the concept is applicable on android 10 onwards as well (The overlay story).

It could be tested on multiple Android versions using Android Virtual Devices.

But the only things i identified as critical so far are the package name and the signature.

Indeed, that's what allows to install another package with same name and signature. The version code of the stub should also be smaller.

@SebiderSushi regarding the package name: we could also use a Bromite-specific package name, however I am not sure about the breakage that would be involved. If we exclude users with an unlocked bootloader which can use pretty much any package name, what are the remaining use cases where keeping com.android.webview (as it is currently) is beneficial? Do you know what other webview developers do about it?

See also: https://github.com/bromite/bromite/wiki/Installing-SystemWebView#about-the-package-name

[SebiderSushi]

Sorry for letting this issue slide for so long.
I have recently noticed that i don't own any setup (device, stock rom, custom rom) where there are any complications installing the Bromite WebView. That is, is noticed that i was able to install and use Bromite WebView as a user app on all of my setups by simply removing the preinstalled com.android.webview apk file from the system image.
("all setups" implies everything that whitelists com.android.weview as a webview provider to begin with)

I was able to reproduce this in an AVD running Android Pie as well.

So basically i've realized that i actually don't own a use case for this, nor can i provide any testing resources that resemble any critical situation where installation to the system partition would be mandatory.

[SebiderSushi]

Otherwise, to get back to your question:
Due to the fact that System WebView providers must explicitly be whitelisted in the system Framework, choosing a bromite specific package name would be useful for anyone who is able to patch their system framework to whitelist that name. Other than that it would mostly just support use cases where keeping the system version of com.android.webview installed is desired.

The thing with the package name com.android.webview is that there are many ROMs in existence that list this package name as a webview provider WITHOUT also requiring it to be signed by a special key as done with Google Chrome or similar things. That is why using this package name is the easiest thing for people with unlocked bootloaders as well.
But as it stands by now (with AVB and stuff) it is mostly impossible to use a custom WebView implementation at all without an unlocked bootloader and things like Magisk or System partition access, since there is usually already a package preinstalled in the system for any whitelisted System WebView provider.

IIRC i might have seen com.google.android.webview whitelisted without signature pinning in one particular stock rom, but i can't quite imagine how google might react to using their package name.

Giving bromite a unique package name would be the technically correct thing to do, but unfortunately only works if users can patch their framework-res.apk or if the WebView is bundled in by the ROM maintainer or developer.

[csagan5]

IIRC i might have seen com.google.android.webview whitelisted without signature pinning in one particular stock rom, but i can't quite imagine how google might react to using their package name.

There is no advantage to swap com.android.webview with com.google.android.webview, but anywhere you see them without signature pinning it's a serious security bug.
They would not care about this because authenticity is guaranteed by the signature, not the package name (see the quote in https://github.com/bromite/bromite/wiki/Installing-SystemWebView#installation-without-root), but as I said there is no incentive to use a different package name given that it would only work on "backdoored" installations. And if you add a backdoor manually, you might as well just add a Bromite-specific package name with the correct signature.

Giving Bromite a unique package name would be the technically correct thing to do, but unfortunately only works if users can patch their framework-res.apk or if the WebView is bundled in by the ROM maintainer or developer.

If root were necessary for any SystemWebView installation procedure, then we could just go with a Bromite-specific package name. The wiki page mentions the debloater approach but I do not have proof that it works. It would contradict the security model guarantees. Perhaps you could do some research there?

[SebiderSushi]

These approaches can only work if the Android SystemWebView is not present, since Bromite SystemWebView uses the same package name and APK signature verification would fail otherwise.

As far as i understand it, the wiki page is aware of the security model implications and the debloater approach is meant for versions prior to Android 7.0, where there was no way to manually pick the WebView implementation in the developer settings. Because of that, disabling any other WebView providers higher in priority than com.android.webview is needed to force the system to fall back to com.android.webview.

[csagan5]

@SebiderSushi what needs to be done here? As far as I know nobody is working on this.

[SebiderSushi]

I'm not sure what you mean.

As far as the WebView stub apk is concerned, the following needs to be done (to my current knowledge):

Compile an apk file that basically contains just a Manifest with the correct package name. A reference proof of concept can be found here.

This apk file just needs to be signed with the same signature as the BromiteWebView release apks and the whole thing is done until further issues are revealed.

[csagan5]

It is slightly more complex than that:

• the SystemWebView needs to be built with the current package name com.android.webview
• it needs to be built also with a new package name
• the stub needs to be built

I cannot maintain the com.android.webview forever, but at the same time I am still not sure on which cases it is important to keep that package name.

[SebiderSushi]

Sure. I was just referring to the webview stub, as i'm seeing the question about the package name as a different topic. Regarding that, did you have a look at the overview that i linked in my previous comment on the other issue? I have put together a paragraph about the package name and about all possible considerations i'm seeing there, my conclusion being to keep com.android.webview.

As it currently stands, i think the lost benefits of using com.android.webview or the cost of building with two package names outweigh the gained benefits of a unique package name.

Of course this point could be reconsidered if the team behind a widely distributed custom ROM (like LineageOS) would be willing to whitelist a unique package name for the Bromite WebView.
 I think we can all agree that no one expects Google or some OEM to ever whitelist Bromite in AOSP or their branch of android.

[SebiderSushi]

com.android.webview might be whitelisted on a bunch of ROMs out there, but definitely is it whitelisted without a signature in LineageOS and also pure AOSP, so some OEMs might keep it that way if they also include com.android.webview with their builds.

That makes a lot of ROMs where a Magisk Module with just the files system/app/webview/BromiteWebViewStub.apk and system/app/webview/replace is enough to allow installation.
The alternative without magisk would be to cat BromiteWebViewStub.apk > /system/app/webview/webview.apk or something equivalent.

And on userdebug builds (All official LineageOS builds!), the stub apk isn't even needed and an rm -fr /system/app/webview is enough to allow installation.

The point: All of this applies to older Android versions without RRO support as well.
The cases left out by this are devices that do not whitelist com.android.webview and which need an RRO if applicable to get anywhere.

 Of couse, some metrics on this would be nicer than all of my assumptions. Real world data about the number of ROMs which fall into either of the aforementioned categories.

[csagan5]

is it whitelisted without a signature in LineageOS and also pure AOSP

Isn't this a security hole? I might understand the AOSP case, as OEMs are supposed to "complete it" before release, but how can LineageOS releases go out with this issue open?

And on userdebug builds (All official LineageOS builds!)

Ok, perhaps I do not understand how these are hardened for usage. My reference for a secure non-stock Android OS is GrapheneOS.

As it currently stands, i think the lost benefits of using com.android.webview or the cost of building with two package names outweigh the gained benefits of a unique package name.

Of course this point could be reconsidered if the team behind a widely distributed custom ROM (like LineageOS) would be willing to whitelist a unique package name for the Bromite WebView.

The project does not have - nor seek - affiliation; I have to make a decision regardless of what another popular - but separate - project decides.

Let's put it in another way: if the package name were org.bromite.webview, what would be the issues to use it on LineageOS or similar? I think nothing to worry about: they are already running with permissions wide open, and your paragraph about the package name seems to confirm it.

The only remaining issues are:

1. the inconvenience of the package name change for the current users
2. some stock ROM might have an unpinned com.android.webview whitelist, and they will lose the capability to install the webview

(1) will always be there, it's not on its own a good reason to never do any change/progress
I have no evidence for (2), nor numbers as you said.

did you have a look at the overview that i linked in my previous comment on the other issue?

Yes, but I reach different conclusions: the user should be capable of choosing the webview without rebooting into a boot manager or modifying the ROM, and re-using package names is just incorrect from the perspective of how Android works.

[SebiderSushi]

Again, as per security, i don't see the issue.
According to the Chromium dev comment cited in the original wiki installation guide and which i re-cited at the home page of mine:

WebView is extremely privileged because it's loaded into the address space of other applications, and so has access to the data and permissions of every single application which uses it - therefore, it can only be replaced by someone who already has the ability to compromise the application sandbox anyway: someone with root access, or the builder of the system image.

As such, i see it as sufficient to "stuff the security hole" by delivering either "user" builds or by preinstalling a package that fills the spot. Since anyone who can still replace the WebView then will still need root access they're pretty much there already. It don't see how it gets much worse for the victim if an attacker can also replace the webview on top of having at least full access to the system partition.

And about GrapheneOS: https://github.com/GrapheneOS/platform_frameworks_base/blob/10/core/res/res/xml/config_webview_packages.xml
They either see this no different or replace this config with a strict one at build time. Yes they probably ship user build but that only means that an attacker would just have to place their malicious WebView in the system partition.

Also, as GrapheneOS or any other current ROM will run at least on android Pie, an attacker with root access would also be able to place and register an RRO and replace the WebView whitelist with anything they want.
(That is, according to a test i did i was able to register an RRO on Pie and Ten, but not on Oreo or below. I am just at the start of learning about RROs though, but the point definitely stands for android Ten.)

[SebiderSushi]

Huh. Okay, i'll go into detail about your points now and then you can maybe point out how my explanation on the wiki could be understood otherwise or be unclear on certain aspects.
One thing i already see is that i only vaguely covered RROs there: This is due to my lack of knowledge about them.

I agree: Using unique package name is the correct thing to do. Being able to choose the WebView implementation in userspace is convenient and some use cases might require it (though i don't know any of them).

I think re-using com.android.webview is a valid compromise, for one because i don't see the use cases that require constantly switching the implementation but rather where the user simply wants to use a different WebView as a daily driver.
 And then again, the optimum, i.e. a user being able to install Bromite WebView as a user app just like the google WebView and use it without ever touching their system can exclusively happen if a wide range of ROMs whitelist Bromite WebView on their own.
Since we can never expect that, i think it would be rational to go for a compromise, as explained below.

Reminder: The following considerations are invalid when RRO support is present. That is, if older android versions were to be deprecated, a unique package name should definitely be used. At this time, i am unsure on which android versions RROs could be made to work, but during my tests with Marshmallow, Nougat, Oreo, Pie and Ten i was only able to register an RRO on Pie and above. I remember that @linuxandria statet RROs could theoretically be made compatible with android versions as low as 5.1, so we'll see how far we might get with this.
But consequently, going forward it will inevitably come to the day where using com.android.webview will be deprecated.

Now, as long as android versions where we cannot successfully override the WebView whitelist shall be supported by the Bromite WebView, the following consideration applies:

Without a custom WebView whitelist, the only hope to support any device, is by using the package name com.android.webview, as it is oftentimes whitelisted without pinning a signature.

Using another package name will not work, not even on LineageOS. They solely whitelist the Google WebView & a handful of Google Chrome variants (all pinned to a signature) and com.android.webview without pinning a signature.
The only open door with LineageOS in regards to WebView is that they ship userdebug builds, thereby allowing for a WebView installation after just removing the original package from the system instead of also placing a stub or the custom package in the system partition. Which is, again, no big deal if you are already in a position to remove the original webview. It is just a little more effort to do so as a user or an attacker.

The reason why i'm constantly bringing up LineageOS

These Numbers: https://www.lineageoslog.com/statistics

I think of LineageOS and LineageOS based custom ROMs as "probably a significant part of the Bromite WebView userbase". (Of course, other Projects like OmniROM are probably viable for use with custom webviews as well.)

I do this because of the following considerations:

• To install anything custom these days, you'll need an unlocked bootloader. Devices running custom ROMs would hence be unlocked as well.
• Users who like to tinker with their devices and to customize them, might be more likely to use a custom ROM as well

• And of course, it is my personal use case.

Obviously, any actual user metrics of Bromite WebView itself would be nice. As long as we don't have access to those, i only see that we can run speculations, flip a coin or deprecate anything we can't get an RRO to run on.
On that note: Easy xkcd for example conducts user surveys from time to time via google docs. Sadly, without a user interface it will be hard to catch a good portion of the users i guess.

[SebiderSushi]

TL;DR:

My current consideration is "being able to switch the webview in userspace" versus "devices with no other way to install a custom webview than by replacing com.android.webview".

Especially since i don't see use cases requiring the former, i am convinced that the latter aspect weighs much more.

The question boils down to:
Is there a significant portion of devices running the Bromite WebView where we have no option to override the WebView whitelist?

[SebiderSushi]

And again, what i've said depends on our current know-how about replacing the WebView whitelist. If anyone where to find new and better methods to replace the whitelist on real world devices, the whole argumentation will shift towards a unique package name.

Any setup where the whitelist can be overridden can properly be supported by Bromite WebView.

[csagan5]

As such, i see it as sufficient to "stuff the security hole" by delivering either "user" builds or by preinstalling a package that fills the spot. Since anyone who can still replace the WebView then will still need root access

I thought that you do not need root access if the package is there and without a signature.

And about GrapheneOS: https://github.com/GrapheneOS/platform_frameworks_base/blob/10/core/res/res/xml/config_webview_packages.xml
They either see this no different or replace this config with a strict one at build time. Yes they probably ship user build but that only means that an attacker would just have to place their malicious WebView in the system partition.

Let's ask @thestinger: there is no possibility to install a malicious webview (matching the whitelisted package name) on GrapheneOS without root access, correct?

Without a custom WebView whitelist, the only hope to support any device, is by using the package name com.android.webview, as it is oftentimes whitelisted without pinning a signature.

You forgot to mention that the user must also have root access. What about modding the OS through framework-res.apk to allow other webviews? Can it be done with root alone (I think no)? It can always be done with recovery access though, correct?

If anyone where to find new and better methods to replace the whitelist on real world devices, the whole argumentation will shift towards a unique package name.

I think it's possible to mod any ROM to support other webviews through a custom bootloader; see https://forum.xda-developers.com/showpost.php?s=16f45eae40ceea4635e4433c72137749&p=81313655&postcount=11

These Numbers: https://www.lineageoslog.com/statistics

Sorry, Bromite is not affiliated to LineageOS.

• And of course, it is my personal use case.

This makes you biased; kudos for exposing the bias, but I still have to make a choice based on the neutral case e.g. any user using any ROM.

[thestinger]

Let's ask @thestinger: there is no possibility to install a malicious webview (matching the whitelisted package name) on GrapheneOS without root access, correct?

Correct, and it uses verified boot. The OS is verified from the root of trust.

[thestinger]

And about GrapheneOS: https://github.com/GrapheneOS/platform_frameworks_base/blob/10/core/res/res/xml/config_webview_packages.xml
They either see this no different or replace this config with a strict one at build time. Yes they probably ship user build but that only means that an attacker would just have to place their malicious WebView in the system partition.

Also, as GrapheneOS or any other current ROM will run at least on android Pie, an attacker with root access would also be able to place and register an RRO and replace the WebView whitelist with anything they want.
(That is, according to a test i did i was able to register an RRO on Pie and Ten, but not on Oreo or below. I am just at the start of learning about RROs though, but the point definitely stands for android Ten.)

This is nonsensical. How exactly is a redundant signature check going to help in any situation? If an attacker has exploited the OS successfully to gain full root access, what's the relevant of this of having a signature hard-wired here? Also, you do understand that GrapheneOS has full verified boot just like the stock OS, right? It is not particularly relevant to this though...

[thestinger]

Android uses key pinning for every single app installation. If an app is built into the system image, the key is permanently pinned via the app being built into the system image. It doesn't make sense to talk about an attack where the app is replaced in the system image. An attacker would already need to have gained full root access to remount as writable and modify it. They could also modify the whitelist... how does it make any sense to propose that as an attack vector? Also, it's just going to be detected as tampering by verified on the next boot either way. Verified boot chains trust from the firmware and verifies all of the OS images.

Specifying a signature in config_webview_packages.xml is for cases where the app isn't bundled into the OS. You either list an app that's bundled into the OS without specifying a key pin or list an app that's not included in the OS with a key pin. Listing a key pin is a way to preserve security despite it not being built into the OS. It isn't the normal way to use this configuration. It would be unnecessarily complicated for everyone to need to modify this configuration file to specify the key of the bundled WebView and isn't how it's implemented. The OS provides signature verification for every installed package already.

[thestinger]

I can't think of any case where using com.android.webview would be helpful. If there is already an app bundled, then you can't install it. If there isn't one installed, the whitelist needs to have a pinned key. Either way, you need support for Bromite built into the OS. Doing it properly with the security model and update system preserved requires doing it as part of building before generating a signed release. Hacking it into an existing release by abandoning verified boot and update system compatibility (if you make any changes, you've broken incremental updates) doesn't really change anything. You can convert the resources to xml from binary xml, modify it and convert it back. Either way you're building it into the OS.

[csagan5]

You either list an app that's bundled into the OS without specifying a key pin or list an app that's not included in the OS with a key pin.

I can't think of any case where using com.android.webview would be helpful. If there is already an app bundled, then you can't install it.

The only insecure scenario is when there are whitelisted packages and the ROM comes without such packages installed. The previous discussions here on this issue are confusing when they don't explicitly mention this condition.

There are a lot of hypothesis cast here; my rationale is more or less: if com.android.webview is beneficial to non-root users of such insecure ROMs, I have no interest in supporting them.

So @SebiderSushi I think the research can be split into two trunks:

1. options to install the WebView without root and an unlocked bootloader (e.g. non-verified boot process)
2. options to install the WebView with root

You have already done a lot of investigation, what would make sense to me is to arrange this in some sort of user guide/flow diagram; each step should also be clear about the security implications.

[SebiderSushi]

I am aware that the only way to install a webview without breaking the security model is to have it supported at build time.

Thus, i am implying unlocked bootloaders (and consequently root/full system access) at all times aince it's the only realistic way to install a custom webview on an end user device without building a full rom to achieve that.

[SebiderSushi]

As a consequence i am not talking about any use cases that preserve AVB.

I am unaware of any ROM that would bundle Bromite support. That's what i meant when i was saying

Of course this point could be reconsidered if the team behind a widely distributed custom ROM (like LineageOS) would be willing to whitelist a unique package name for the Bromite WebView.

At no point did I want to imply any affiliation but without such a thing happening, the only remaining use case is users with unlocked bootloaders patching up their system partitions or installing Magisk Modules or whatever does the job.

[SebiderSushi]

I can't think of any case where using com.android.webview would be helpful. [...] You can convert the resources to xml from binary xml, modify it and convert it back. Either way you're building it into the OS.

Counterexample:

• unlocked bootloader
• user build that whitelists com.android.webview without pinning a signature
• preinstalled webview installed as /system/app/webview/webview.apk
• no RRO support (android 6 or something)

I can install Bromite WebView by running
cat bromitewebview.apk > /system/app/webview/webview.apk in TWRP for example.
And i can boot this and use Bromite WebView.
Just because Bromite WebView currently uses com.android.webview

How would i replace the webview whitelist in this scenario to support a unique package name if patching up framework-res.apk will not work because i can't re-sign it with the platform key?

[SebiderSushi]

Let's ask @thestinger: there is no possibility to install a malicious webview (matching the whitelisted package name) on GrapheneOS without root access, correct?

This is also true for LineageOS, even if they don't support AVB.

[SebiderSushi]

How would i replace the webview whitelist in this scenario to support a unique package name if patching up framework-res.apk will not work because i can't re-sign it with the platform key?

If that statement is incorrect then yay.
Because if a custom whitelist can be applied to any android version supported by Bromite WebView i see it as an obvious go for a unique package name.

But again, that's what i was saying all along.

[SebiderSushi]

How exactly is a redundant signature check going to help in any situation? If an attacker has exploited the OS successfully to gain full root access, what's the relevant of this of having a signature hard-wired here?

That's actually my point as well and what i wanted to say to @csagan5 because of this:

is it whitelisted without a signature in LineageOS and also pure AOSP

Isn't this a security hole? I might understand the AOSP case, as OEMs are supposed to "complete it" before release, but how can LineageOS releases go out with this issue open?

[SebiderSushi]

It doesn't make sense to talk about an attack where the app is replaced in the system image. An attacker would already need to have gained full root access to remount as writable and modify it. They could also modify the whitelist...

And that as well, is something i also said a couple of times.

I am unsure how you could understand this paragaraph any different:

As such, i see it as sufficient to "stuff the security hole" by delivering either "user" builds or by preinstalling a package that fills the spot. Since anyone who can still replace the WebView then will still need root access they're pretty much there already. It don't see how it gets much worse for the victim if an attacker can also replace the webview on top of having at least full access to the system partition.

[SebiderSushi]

To get back to the topic:

It boils down to:
Is there a significant portion of devices running the Bromite WebView where we have no option to override the WebView whitelist?

To my current knowledge, there exist ROMs where the preinstalled webview apk can be replaced in the system and it works.
To my current knowledge, we have no known and reliable method of changing the WebView whitelist on these ROMs to accomodate anything other than com.android.webview if no Runtime Resource Overlay support is present.

If i am wrong with this, if patching framework-res.apk does work at least whenever webview apk replacement works (since the system could or should check the signature of that apk as well or not?) or if we find a new method of overriding the whitelist, then i see nothing more that would stand against a unique package name, which, again, i also think is the correct thing to do.

EDIT: Again, openly deprecating (from Bromiet WebViews point of view) any android version where the whitelist cannot reliably be overriden is still also an option here.

[SebiderSushi]

Hacking it into an existing release by abandoning verified boot and update system compatibility (if you make any changes, you've broken incremental updates) doesn't really change anything.

@thestinger With Magisk you can replace system files without breaking incremental updates and maybe even without breaking AVB (completely) as well. You still need an unlocked bootloader but any other partitions except boot and userdata remain untampered.

[thestinger]

The core of AVB is the verification of vbmeta and what it references via hashes.

[SebiderSushi]

There are a lot of hypothesis cast here; my rationale is more or less: if com.android.webview is beneficial to non-root users of such insecure ROMs, I have no interest in supporting them.

@csagan5 You are referring to ROMs that whitelist com android.webview without pinning a signature despite not preinstalling any com.android.webview package, thereby allowing installation of any com.android.webview WebView provider as a user app without tampering the system did i understand that right?

I also think that this is a scenario that does not need to be supported and have labeled it as "insecure" and "highly improbable" at some point.

[thestinger]

I'm not sure if it actually lets you do that.

[SebiderSushi]

On android 7 and above, this will only work on userdebug builds but it is possible.

On android 6 and below i think it is generally possible (the WebView whitelist also worked differently back then).

I actually have one device that fits this scenario:
The stock Lollipop ROM on the OnePlus X had this security issue.They did not bundle a com.android.webview package despite whitelisting it and it is possible to install bromite webview ithout tampering the system. I did not check whether they released this as a userdebug build as well, but it is and actual real world device that fits the scenario. But again, highly improbable.

[SebiderSushi]

If we are talking devices that old it might also be worth mentioning that verfied boot does not exist on these devices.
Remember that Bromite WebView is also released with minApiVersion of 19.

[SebiderSushi]

This made me realize that i misunderstood something in a previous comment, i deleted it because it was invalid and will rephrase it now:

So @SebiderSushi I think the research can be split into two trunks:

1. options to install the WebView without root and an unlocked bootloader (e.g. non-verified boot process)
2. options to install the WebView with root

I don't see how this distinction might stand up, because:

• When dealing with a verified boot process the only way would be baking bromite support into the ROM by the builder, root wouldn't help.
• When dealing with a device without verified boot support or an unlocked bootloader the system image may be tampered in any way necessary to begin with.

To sum up:

• changing the webview whitelist must be done/supported by whoever builds the system image or it violates the security model
• changing the webview whitelist requires changing the contents of the system partition, at least as they are effective at run-time
• how a user gets the ability to modify their system is out of scope of our responsibility. they might use runtime root access to place files into their physical system partition, they might flash a patched system via fastboot, use a custom recovery to tamper with their storage, other means like magisk or literally whatever, but it does not make a difference for the method of overriding the webview whitelist as far as i know

[SebiderSushi]

As long as we don't hack into the framework at runtime to allow a custom webview package as a location provider.

[SebiderSushi]

Okay i'm getting too invested in this right now, literally all i want to say is that, optimally, we should

• have a way to whitelist a custom package name on all android devices/versions supoorted by bromite webview, whatever that method may be.

OR

• openly drop bromite support (i know support for this was never official) for all android versions/devices where that is not possible. this doesn't necessarily mean that the minApiVersion be changed since users can still try to figure out whitelist overriding on their own, but this real consequence must be acknowledged if going further with a unique package name.

OR

• keep publishing the webview at least with com.android.webview as package name

A unique package name should be used as soon as possible but i think that these aspects should block the deprecation of the com.android.webview package name in Bromite WebView releases.

As soon as these blocking aspects are resolved i see nothing else that would hold back a deprecation of the com.android.webview package name.

At the and of it all, i'm seeing a tradeoff here.
As it currently stands i wasn't able to register a Runtime Resource overlay on android 7 and 8. Patching the framework-res.apk is something i haven't tried yet but doubt that it reliably works. At the very least, there is no general solution to this, a reliable installer capable of doing it would be necessary as not every user is capable of doing this manually.
On the other hand, using a unique package name will only provide a real advantage as soon as ROMs or Vendors start whitelisting Bromite WebView the right way and i don't expect this to happen on a relevant scale.
That is all the reasons why i think that for the time being it would be a valid compromise to stick to com.android.webview and effectively allow bromite webview installation without the need to patch the whitelist on a number of devices by replacing the webview apk in the system with the bromite apk. This particular process can be simplyfied by using a stub apk for this step. If the webview whitelist can be controlled, the stub apk is no longer needed.

[SebiderSushi]

each step should also be clear about the security implications.

These are the security implications i see while installing the Bromite WebView:

• Using the Bromite WebView
  -> You'll have to trust @csagan5 since any webview is loaded into the address space of the applications that use it. (isn't there a way to fix that in AOSP to begin with? I mean it's the reason for the restrictions put onto webview installation to begin with...)
• Bromite WebView with a unique package name properly supported by the ROM
  -> Do you trust your ROM?
• Changing the WebView provider whitelist
  -> The new whitelist might allow WebViews you don't trust or pin any webview without signature that is not preinstalled while also running a userdebug build of AOSP.
• Placing files into your system partition
  -> The usual implications for that which hopefully anyone who does this is aware of and which are IMO not the responsibility of a webview installation guide to cover.
• Unlocking your bootloader
  -> See previous explanation
• Using third-party software to install the Bromite WebView into your system
  -> See previous explanation

[unixandria-xda]

To get back to the topic:

It boils down to:
Is there a significant portion of devices running the Bromite WebView where we have no option to override the WebView whitelist?

To my current knowledge, there exist ROMs where the preinstalled webview apk can be replaced in the system and it works.
To my current knowledge, we have no known and reliable method of changing the WebView whitelist on these ROMs to accomodate anything other than com.android.webview if no Runtime Resource Overlay support is present.

If i am wrong with this, if patching framework-res.apk does work at least whenever webview apk replacement works (since the system could or should check the signature of that apk as well or not?) or if we find a new method of overriding the whitelist, then i see nothing more that would stand against a unique package name, which, again, i also think is the correct thing to do.

EDIT: Again, openly deprecating (from Bromiet WebViews point of view) any android version where the whitelist cannot reliably be overriden is still also an option here.

Couple things

Unless your rom is signed with test keys you can't re-sign framework-res, and if it is you still have to sign it
Android verifies framework-res and a majority of devices bootloop if signature is wrong

Currently my module tries to only enable the overlay on stock roms but I'm finding on a10 some customs also don't have the necessary whitelist, or the props I check for don't exist so I'm planning on moving to always include the whitelist override overlay.

At any rate it requires root or an unlocked bootloader in 99.9999999999999% of cases so my method would be easy to update for any package names. Other install methods not so much z albeit they have a tendency to have issues anyhow

[unixandria-xda]

You either list an app that's bundled into the OS without specifying a key pin or list an app that's not included in the OS with a key pin.

I can't think of any case where using com.android.webview would be helpful. If there is already an app bundled, then you can't install it.

The only insecure scenario is when there are whitelisted packages and the ROM comes without such packages installed. The previous discussions here on this issue are confusing when they don't explicitly mention this condition.

There are a lot of hypothesis cast here; my rationale is more or less: if com.android.webview is beneficial to non-root users of such insecure ROMs, I have no interest in supporting them.

So @SebiderSushi I think the research can be split into two trunks:

1. options to install the WebView without root and an unlocked bootloader (e.g. non-verified boot process)
2. options to install the WebView with root

You have already done a lot of investigation, what would make sense to me is to arrange this in some sort of user guide/flow diagram; each step should also be clear about the security implications.

I've yet to meet a stock rom that whitelists com.android.webview let alone without a pinned signature (I think an earlier pixel a10 build did but I can no longer verify) and stock roms would be user builds without allowing to run a webview as a user app.
Although some oems may not fully enforce AVB thereby allowing us to make modifications, it's getting harder and harder to mount a non data partition rw (see: EROFS, ext4 dedup, dynamic partitions, etc)

[unixandria-xda]

As a consequence i am not talking about any use cases that preserve AVB.

I am unaware of any ROM that would bundle Bromite support. That's what i meant when i was saying

Of course this point could be reconsidered if the team behind a widely distributed custom ROM (like LineageOS) would be willing to whitelist a unique package name for the Bromite WebView.

At no point did i want to imply any affiliation but without such a thing happening, the only remaining use case is users with unlocked bootloaders patching up their system partitions or installing Magisk Modules or whatever does the job.

Some custom roms fully support AVB and in theory if you self built you could sign the magisk patched boot with your keys and have root but locked bootloader

[unixandria-xda]

I can't think of any case where using com.android.webview would be helpful. [...] You can convert the resources to xml from binary xml, modify it and convert it back. Either way you're building it into the OS.

Counterexample:

• unlocked bootloader
• user build that whitelists com.android.webview without pinning a signature
• preinstalled webview installed as /system/app/webview/webview.apk
• no RRO support (android 6 or something)

I can install Bromite WebView by running
cat bromitewebview.apk > /system/app/webview/webview.apk in TWRP for example.
And i can boot this and use Bromite WebView.
Just because Bromite WebView currently uses com.android.webview

How would i replace the webview whitelist in this scenario to support a unique package name if patching up framework-res.apk will not work because i can't re-sign it with the platform key?

Webview below 7 is very different in how it works and I for one provide no official support, although I have reports it works on some 6.0 roms

[unixandria-xda]

This made me realize that i misunderstood something in a previous comment, i deleted it because it was invalid and will rephrase it now:

So @SebiderSushi I think the research can be split into two trunks:

1. options to install the WebView without root and an unlocked bootloader (e.g. non-verified boot process)
2. options to install the WebView with root

I don't see how this distinction might stand up, because:

• When dealing with a verified boot process the only way would be baking bromite support into the ROM by the builder, root wouldn't help.
• When dealing with a device without verified boot support or an unlocked bootloader the system image may be tampered in any way necessary to begin with.

To sum up:

• changing the webview whitelist must be done/supported by whoever builds the system image or it violates the security model
• changing the webview whitelist requires changing the contents of the system partition, at least as they are effective at run-time
• how a user gets the ability to modify their system is out of scope of our responsibility. they might use runtime root access to place files into their physical system partition, they might flash a patched system via fastboot, use a custom recovery to tamper with their storage, other means like magisk or literally whatever, but it does not make a difference for the method of overriding the webview whitelist as far as i know

We are assuming an untampered system partition, and since magisk does not tamper with system we can also assume a handful of users may have enforcing AVB if proper steps are taken

As of v5.0.1 I deprecated non-magisk support albeit if enough people need it I'll evaluate bringing it back

[csagan5]

At any rate it requires root or an unlocked bootloader in 99.9999999999999% of cases so my method would be easy to update for any package names. Other install methods not so much z albeit they have a tendency to have issues anyhow

I am interested in the other install methods.

[unixandria-xda]

At any rate it requires root or an unlocked bootloader in 99.9999999999999% of cases so my method would be easy to update for any package names. Other install methods not so much z albeit they have a tendency to have issues anyhow

I am interested in the other install methods.

I think nanodroid has an installer but it just pushes the APK into place in /system.

And of course there's the manual cut and paste method but with RO system images becoming the norm, and in interest of not tripping AVB/dm-verity unless necessary I would advise against that method :P

[SebiderSushi]

Today i found out that one way to obtain the signature string that has to be put into the webview whitelist is as follows:
keytool -printcert -rfc -jarfile arm_SystemWebView.apk

(i have updated my corresponding wiki page to include this information)

[SebiderSushi]

On another note: I just used apktool to change the package name of the bromite webview. Turns out that just changing the package & the names of the 2 providers in the manifest and then recompiling actually works and i can display websites through the package i tampered and installed this way.

If there aren't any deep issues then building with two package names could be achieved by running a few shell commands before the build - the increased effort would be limited to build time and publishing logistics only.

What do you think @csagan5 ? Would you start releasing with two package names if that theory holds up?
Or, maybe it's just enough to install bromite in parallel on local development devices...

[csagan5]

changing the package & the names of the 2 providers in the manifest and then recompiling actually works

Recompiling what? It works with what type of framework-res.apk?

Would you start releasing with two package names if that theory holds up?

I have to switch to the new package name anyways, the only unclear part is how to provide migration instructions for all the different possible installations. I can start releasing both for a while but I need to have instructions ready before that.

[unixandria-xda]

changing the package & the names of the 2 providers in the manifest and then recompiling actually works

Recompiling what? It works with what type of framework-res.apk?

I took it to mean the webview, as framework-res being modified generally causes a device to stop booting

[SebiderSushi]

changing the package & the names of the 2 providers in the manifest and then recompiling actually works

Recompiling what? It works with what type of framework-res.apk?

Recompiling the Bromite WebView. I was only referring to the possibility of changing the Bromite WebView package name without any annoying-to-maintain in-depth changes to anything other than the manifest, thereby minimizing the effort of releasing with two package names simultaneously. Sorry if this wasn't new information to you.

Would you start releasing with two package names if that theory holds up?

I have to switch to the new package name anyways, the only unclear part is how to provide migration instructions for all the different possible installations. I can start releasing both for a while but I need to have instructions ready before that.

But since there is no userdata involved it comes down to installing the new package and selecting that as the webview provider, so this is mostly about how to get the news out to every user, right?

[SebiderSushi]

How much effort would it be to compile the Bromite browser with support for being a webview provider as well?

[unixandria-xda]

How much effort would it be to compile the Bromite browser with support for being a webview provider as well?

Kinda pointless as on 10+ browser and webview are separate in upstream chromium

[thestinger]

They're not really separate but rather it's split into 3 apks: browser, WebView and a library apk providing most of the code which is shared between them.

[thestinger]

The standalone WebView target is perfectly modern and still fully supported. The standalone browser apk targets are not intended for usage on modern devices. If you wanted to avoid having the library split out while still being a modern build, you would need to make a new target.

[unixandria-xda]

They're not really separate but rather it's split into 3 apks: browser, WebView and a library apk providing most of the code which is shared between them.

For our intents separate packages separate apps, although I am aware of trichrome vs monochrome

[unixandria-xda]

We're going to assume trichrome library is available on devices that needs it, and we're only worried about webview and to an extent browser

[thestinger]

The library is used by the browser and WebView apks - nothing else. It provides the bulk of the code.

[unixandria-xda]

The library is used by the browser and WebView apks - nothing else. It provides the bulk of the code.

Well yes what's what I'm saying :)

[SebiderSushi]

How much effort would it be to compile the Bromite browser with support for being a webview provider as well?

My motivation behind that question has beed the following idea:
The Bromite browser has its own package name, so it can already be whitelisted properly. If it were able to provide webview capabilities, most users should be fine after installing it.
Also, for users of both bromite webview and the bromite browser, this would reduce storage & bandwith usage.

Granted, debugging the standalone webview in parallel to having an upstream chromium webview package installed would still be impossible.

As for Trichrome vs. Monochrome: They are just both methods of deduplicating code right? And they are both valid and work, even on android 10+?
At least that's how i read this XDA post about it, with the benefits over Monochrome being that Trichrome has "fewer weird special cases and bugs."

[thestinger]

No, it's not simply a choice between different ways to share code.

[unixandria-xda]

How much effort would it be to compile the Bromite browser with support for being a webview provider as well?

My motivation behind that question has beed the following idea:
The Bromite browser has its own package name, so it can already be whitelisted properly. If it were able to provide webview capabilities, most users should be fine after installing it.
Also, for users of both bromite webview and the bromite browser, this would reduce storage & bandwith usage.

Granted, debugging the standalone webview in parallel to having an upstream chromium webview package installed would still be impossible.

As for Trichrome vs. Monochrome: They are just both methods of deduplicating code right? And they are both valid and work, even on android 10+?
At least that's how i read this XDA post about it, with the benefits over Monochrome being that Trichrome has "fewer weird special cases and bugs."

Trichrome is Android 10+, monochrome is =< 9

[thestinger]

The upstream build system also doesn't define standalone browser targets for modern Android. If you want that, you need to define them yourself, otherwise you'll be deploying builds not fully supporting the modern platform.

For the WebView, the standalone WebView target is fully supported across all supported versions. If you want to share the code with the browser, Trichrome is used on Android 10+ and Monochrome for earlier versions (ever since it became supported). Monochrome isn't supported on Android 10+ and Trichrome isn't supported before Android 10.

[thestinger]

It's incorrect to use ChromeModernPublic on Android 7+. You need to define your own target for a standalone browser. It will work, but it won't support the modern platform features including security improvements tied to API level.

It's similarly incorrect to use Monochrome on Android 10+, and it will not work as a WebView provider at all. It will only provide a working browser with the same issue as ChromeModernPublic, with a less ancient target API level.

[csagan5]

The library is used by the browser and WebView apks - nothing else. It provides the bulk of the code.

APKs can bundle .so libraries and if they are exactly the same they will be shared in-memory (as any Linux does) thus reducing the memory footprint for both apps.

It's incorrect to use ChromeModernPublic on Android 6+. You need to define your own target for a standalone browser. It will work, but it won't support the modern platform features including privacy/security improvements tied to target API level.

@thestinger ChromeModernPublic is not the right target for a standalone browser? What do you use for Vanadium? I have always been referring to https://chromium.googlesource.com/chromium/src/+/master/docs/android_build_instructions.md#Multiple-Chrome-Targets which is a bit scarce on the use cases.

[thestinger]

APKs can bundle .so libraries and if they are exactly the same they will be shared in-memory (as any Linux does) thus reducing the memory footprint for both app

TrichromeLibrary does that with both the native library and other resources. It uses the standard infrastructure for using an apk as a library (which goes beyond just a native library) in a way that's properly authenticated.

@thestinger ChromeModernPublic is not the right target for a standalone browser? What do you use for Vanadium? I have always been referring to https://chromium.googlesource.com/chromium/src/+/master/docs/android_build_instructions.md#Multiple-Chrome-Targets which is a bit scarce on the use cases.

@csagan5 There is no modern standalone browser target because Chrome doesn't use it so they haven't defined one. Vanadium uses the Trichrome targets. TrichromeChrome + TrichromeLibrary without shipping TrichromeWebView is the only way to get a modern browser using only the upstream targets. We use the 64_32 version of the targets so that 64-bit is not only supported but also preferred over 32-bit so that all the browser processes run as 64-bit and the WebView renderers run as 64-bit.

You would need to create a modern standalone browser target yourself to have it without the TrichromeLibrary split. I'm not sure how many changes there are beyond targetSdkVersion. Using the 64_32 targets is also now the correct way to prefer 64-bit processes and that's part of the Trichrome build infrastructure. You can use Trichrome without the WebView (by just using the browser and library apk) but it's not setup to build it as a single browser apk without the library.

[thestinger]

Modern doesn't actually mean modern - it meant modern at the time it existed, compared to the older one. It was replaced by Monochrome and then Trichrome. Chrome is never shipped as a standalone browser without the WebView so there is no upstream target for something they never use. Quite possible to make it but they don't since they have no use for it.

[csagan5]

We use the 64_32 version of the targets so that 64-bit is not only supported but also preferred over 32-bit so that all the browser processes run as 64-bit and the WebView renderers run as 64-bit.

Bromite builds only the 64-bit version of the APKs so at least on this aspect I think the processes cannot run over 32-bit.

You would need to create a modern standalone browser target yourself to have it without the TrichromeLibrary split. I'm not sure how many changes there are beyond targetSdkVersion.

It could be a bloodbath, but I am compelled to try now.

Using the 64_32 targets is also now the correct way to prefer 64-bit processes and that's part of the Trichrome build infrastructure.

Sure, it would have the benefit to be compatible for both 32-bit and 64-bit architectures.

Modern doesn't actually mean modern - it meant modern at the time it existed, compared to the older one. It was replaced by Monochrome and then Trichrome.

Yes, I was aware of the relativity of "modern" - but what surprises me from your posts is that there is actually a substantial difference in the security features (and possibly not related to security alone?) when using MonoChrome < Android10 and TriChrome >= Android10. I have always been under the impression that the only advantage was the shared libraries/memory savings in conjunction with a SystemWebView, and nothing else.

Would you care to explain those differences, or otherwise point me to some official documentation for me to learn about it? I surely want to tackle this problem once I understand the entity of it.

[unixandria-xda]

We use the 64_32 version of the targets so that 64-bit is not only supported but also preferred over 32-bit so that all the browser processes run as 64-bit and the WebView renderers run as 64-bit.

Bromite builds only the 64-bit version of the APKs so at least on this aspect I think the processes cannot run over 32-bit.

You would need to create a modern standalone browser target yourself to have it without the TrichromeLibrary split. I'm not sure how many changes there are beyond targetSdkVersion.

It could be a bloodbath, but I am compelled to try now.

I remember a Google groups discussion on trichrome vs monochrome but I can't seem to find it now

[thestinger]

@csagan5 As long as targetSdkVersion is set to the proper value (29 for Android 10), it's not nearly as big of an issue as it used to be and I think they've probably changed this part for all the targets now due to the Play Store requirements.

[csagan5]

As long as targetSdkVersion is set to the proper value (29 for Android 10), it's not nearly as big of an issue as it used to be and I think they've probably changed this part for all the targets now due to the Play Store requirements.

Ok, thanks for your reply. So I could avoid using TriChrome by simply rebuilding ChromeModernPublic with a different targetSdkVersion? It makes sense that not including older bindings reduces exposure to less secure APIs.

[thestinger]

targetSdkVersion should always be 29 regardless of minSdkVersion. Trichrome has a much higher minSdkVersion and gets to avoid including legacy things and using legacy approaches like the crazy linker. I am not quite sure how to set up a proper truly modern standalone browser target at the moment though. There are a few things that need to be adjusted.

[wchen342]

@thestinger I have a question about Trichrome. The instructions here says Trichrome will produce two files, TrichromeChrome.aab and TrichromeLibrary.apk. From my understanding, TrichromeLibrary.apk is only the libary files which does not contain the main runnable, and TrichromeChrome.aab is a bundle file which cannot be installed directly on a phone like .apk. So how do you actually install the whole browser, without doing something fancy like extracting apk from aab?

[thestinger]

You can generate a universal apk from the bundle, or you can generate an apk specialized to the device that you're installing on which is what the Play Store does for developers who give their signing keys to Google. The tool for generating apks (universal or more specialized to devices) is open source (bundletool). I recommend looking at generate_release.sh in the Vanadium repository.

[00101010ASCII]

@csagan5
@SebiderSushi

I have Motorola One Power phone,
NOROOT-Locked Bootloader.
No chrome installed.
Only com.google.android.webview preinstalled which i have uninstalled using
adb shell pm uninstall --user 0 com.google.android.webview

Success

Problem- Bromite installed but not shown up in dev.settings

framework-res.apk res/xml/config_webview_packages.xml

Gives this output i.e. only one webview defined that too without signature

E: webviewproviders (line=17)
E: webviewprovider (line=19)
A: availableByDefault=(type 0x12)0xffffffff
A: description="Android WebView" (Raw: "Android WebView")
A: packageName="com.android.webview" (Raw: "com.android.webview")

adb shell dumpsys webviewupdate
Gives this Output

Current WebView Update Service state
Fallback logic enabled: false
Multiprocess enabled: true
Current WebView package (name, version): (com.google.android.webview, 77.0.3865.92)
Minimum targetSdkVersion: 29
Minimum WebView version code: 386509238
Number of relros started: 2
Number of relros finished: 2
WebView package dirty: false
Any WebView package installed: true
Preferred WebView package (name, version): (com.google.android.webview, 77.0.3865.92)
WebView packages:
Valid package com.google.android.webview (versionName: 77.0.3865.92, versionCode: 386509238, targetSdkVersion: 29) is installed/enabled for all users
com.google.android.webview.beta is NOT installed.
com.google.android.webview.dev is NOT installed.
com.google.android.webview.canary is NOT installed.
com.google.android.webview.debug is NOT installed.
Invalid package com.android.webview (versionName: 83.0.4103.119, versionCode: 1592784620, targetSdkVersion: 29), reason: Incorrect signature

it is showing incorrect signature for bromite and not for other webview like com.google.android.webview even though it is not defined in framework-res.apk

[michaelb-ae]

@csagan5
@SebiderSushi
Incorrect signature

it is showing incorrect signature for bromite and not for other webview like com.google.android.webview even though it is not defined in framework-res.apk

Actually, i have the very same problem with my Android 10 on Huawei p smart 2019.