A response from GrapheneOS:

Enabling the package doesn't turn it into a remote security vulnerability. It's still not active.

The overall Verizon carrier support apps get enabled when you have an active Verizon SIM and disabled when it's not active. Retail demo mode requires additional setup. The other Verizon apps implement production functionality and add attack surface that's exposed along with giving Verizon a questionable level of control. We've repeatedly talked about it and explained why we've always omitted them, which causes a loss of Verizon on Verizon's network. That includes talking about it with the CEO of Trail of Bits and others involved in this. The focus on the retail demo app in particular is strange. The claim that it was discovered by iVerify is strange. iVerify is an EDR app which runs in the app sandbox and can hardly do anything more than scan the static manifest and code for each APK. It doesn't even have anywhere close to the level of access of analyzing the firmware and software through the published code instead of from an app sandbox. Sure, it can see these, but it can't see huge parts of the OS and firmware from there despite it being publicly available. It's a very contrived way to promote iVerify and take credit for finding something they weren't the first to discover something that the Android security research community has been talking about and analyzing for many years. People who aren't security researchers have talked about these apps in quite a lot of detail years ago. Here's the Showcase app id, for doing a quick web search:

com.customermobile.preload.vzw

Using ADB doesn't just require physical access but rather physical access combined with the user's password, even if the user's device is already unlocked due to enabling developer options requiring it. Otherwise, you would need exploits. Regardless of the approach, what purpose does using this app serve? ADB gives far more access. Filesystem write vulnerability gives far more access.

Stock Pixel OS doesn't implement the same level of verified boot as GrapheneOS and it's not relevant to the way they do things. It's theoretically relevant to verified boot on GrapheneOS but the app has NEVER been included. If this app was included in GrapheneOS, it would present a very contrived example of a privilege escalation option for the verified boot threat model. In practice, it wouldn't actually matter because there are better known ways to do it. We don't claim verified boot on GrapheneOS avoids trust in persistent state to the point this would be relevant at all. We are gradually removing trust in persistent state but that's a long road.

Here's one of several places we publicly documented the fact that we don't include these apps from the stock Pixel OS (they aren't part of AOSP) with a basic explanation of why we omit them:

https://grapheneos.org/features#broad-carrier-support

We've always omitted the Showcase retail demo app but we never considered that to be a particularly relevant part of omitting these apps since it requires special setup, unlike the others which actually run and expose attack surface when using a SIM for that carrier. The Verizon apps get activated not only on Verizon itself but also the Verizon MVNOs.

We don't have an issue with talking about the security threat of the Verizon apps activated when using a Verizon SIM. It's an issue for Verizon Android users, not Pixels specifically, and not Pixel users on non-Verizon carriers. The story is framed in a highly inaccurate way where iVerify gets credit for finding a Pixel vulnerability which they present as being the inclusion of an app which isn't really part of the real issue. They didn't discover these apps, the privileged permissions they're granted and what they do including the connections they make and lack of HTTPS for the demo app. Other people just didn't try to push Verizon's retail demo app as a security vulnerability specifically on Pixels to promote their product.

Talking about this as if Google accidentally included the app or that there was no reason to include it is very strange. They're well aware of why they included the apps as part of the Verizon partnership and what they do. Google appears to have written significant parts of some of them. They know what they are.

There are vulnerabilities discovered in Android on Pixels on a monthly basis including serious ones. This doesn't even seem to qualify as Low severity. Why is it deserving of all this media coverage pushing it as an incredibly serious issue? Google already publicly removed the app as part of Android 15. Can see that from the Android 15 Beta. That's likely being released in September. The amount of time they'd have taken to fix it if they'd classified it as a valid Low or Moderate severity issue may not have been any quicker. Not really clear what the fuss is about.

It's pretty sad that news sites largely operate as a press release system for well connected companies to promote their products with incredibly dubious claims. Incredibly warped way of getting information about security people, and it's harmful too. Non-Pixel Android devices don't even ship Low/Moderate severity patches until the next major yearly release since they don't ship the monthly/quarterly releases of Android like Pixels. How it is improving things to push people to less secure Android devices? How is it improving things to blame Pixels for Verizon's Android requirements for all Android devices? The goal is promoting a dubious product claiming it can meaningfully defend devices from within the iOS and Android app sandbox. An antivirus app with a basic DNS filtering/monitoring system and APK scanning is getting portrayed as a lot more that it isn't to get lots and lots of money. They successfully pushed a largely inaccurate set of claims across most major news sites covering tech to promote a product and a surveillance company. Why does tech news work this way, and how are they going to fix it?