Android Open Source Project
for those outside the bubble!
In March 2026, a bunch of controls were added to the Australian Government Information Security Manual[0] basically instructing people to not connect government devices to the infotainment systems of any vehicles, or to view or discuss anything sensitive in the presence of one.
> Security Control: 2099; Revision: 0; Updated: Mar-26; Marking: NC, OS, P, S, TS Mobile devices are not connected to the infotainment systems of connected vehicles.
> Security Control: 2100; Revision: 0; Updated: Mar-26; Marking: NC, OS, P, S, TS Sensitive or classified data is not viewed on mobile devices within or near connected vehicles.
> Security Control: 2101; Revision: 0; Updated: Mar-26; Marking: NC, OS, P, S, TS Sensitive or classified phone calls and conversations are not conducted within or near connected vehicles.
[0] https://www.cyber.gov.au/business-government/asds-cyber-secu...
Of course, the question explicitly being asked (related to internal mandate) was if the firmware was signed — not if the firmware update process actually checked the signature (it certainly did not).
They should have provided some mechanism for the real owner to approve updates if the updates aren't all trusted by default.
It works on more brands of cars too than just one gen of honda civics, and probably quicker to install.
I'm generally aligned with this, but it is predicated on the whole "well architected" code part.
The test can show intended use, show interesting corner cases, and I know it is up to date because it is constantly running and passing.
I think that is a huge underrated benefit of adding a lot more testing.
If I think a developer is going to ask a question of how something works, or about a corner case, isn't that deserving of a test, so they can just see proof of the answer to their question immediately rather than trying to re-derive it?
That said, if you pitched me something like a Jupyter notebook style doc where tests validating the claims of the documentation were inline, I'd totally buy into that.
Just by running them you can measure if they are in or out of sync with the code (well, if they were written correctly).
It's also a good assumption most people airing such complaints have never eaten in a restaurant fancy enough to have valet parking, let alone evil valets.
That said, are evil valets known to tote around USB drives, or would they more likely use your navigation system to drive back to your empty house and clean it out while you're eating?
Like, sure, if you're just going to use it to spy on the user, you could also rent a rental car and leave a recording device under the floormat, or hidden behind the head unit, or whatever.
But if you have an Apple Carplay exploit, where someone tethering their phone to the car can be compromised, renting a car and flashing a malicious OS to exploit the phones of people who come after you could maybe be a real attack. It's kinda hard to get people to otherwise connect to a malicious infotainment system with carplay, so if you have an exploit that requires that, this could be part of it...
Except actually, no, if you have a carplay exploit, just rent the car, and rewire the USB port to go through a flipper zero or whatever and don't bother reflashing the car's software, that's just as easy.
... So yeah, I guess I agree with you, even in the rental car scenario, where this seems like it would be worst, your attacker might as well just hide something in the car instead of flashing the software.
Another thing to consider is Honda may have signed these packages with a wink and a nudge, because it may be required, regulatory or Android or otherwise, but they're also not interested in building closed devices. Instead of thanking them we're complaining.
Edit: Looks like a Tegra 3 in this one, but my bet is meager RAM.