option of getting usb peripheral notifications to accept new devices based on type
This would be useful for cases where a user insert a device and it ends up being a different kind of device (or multiple devices) than what they expected. For example, an evil flash drive that really acts as a keyboard and monitor too.
Seeing as the USB accessories feature is going away in favor of the USB-C port control setting, is this still wanted?
It's still wanted but it's probably too complex for us to implement it fully downstream.
Arrived here from https://github.com/GrapheneOS/os-issue-tracker/issues/4424. It would be useful for USB exploit protection to allow charging and audio. When I had it configured to charging-only, with the USB-C earbuds plugged in and audio playing, the audio would often (and somewhat unpredictably) stop after the screen lock engaged, requiring an unlock to restart. No such problems after disabling the exploit protection ... which is a somewhat unfortunate outcome.
@hbchai This means you have a defective audio device or connection. You should fix that instead of wanting to remove most of the purpose of the feature. You're requesting support for not having USB-C data and USB data disabled, which means not having the feature. It does not exist to only disable USB peripherals. The whole reason we replaced our previous USB peripheral control feature with an overall USB-C port control feature is a massive portion most of the attack surface was still present via the USB-C protocol and USB protocol without permitting peripherals.
Arrived here from https://github.com/GrapheneOS/os-issue-tracker/issues/4424. It would be useful for USB exploit protection to allow charging and audio. When I had it configured to charging-only, with the USB-C earbuds plugged in and audio playing, the audio would often (and somewhat unpredictably) stop after the screen lock engaged, requiring an unlock to restart. No such problems after disabling the exploit protection ... which is a somewhat unfortunate outcome.
You have a defective USB peripheral or a defective USB connection. It won't disconnect with a reliable connection and peripheral.
For me, charging, music and data transfer to the PC are important. For the latter, there are currently too many clicks to enable data transfer. The PIN query should of course remain. However, it would be nice if I didn't have to go through all these steps to reach my goal:
- have to laboriously pull down the notification bar,
- click on "Device charging via USB" ,
- then - after expanding - click on the same item again and
- then click on data traffic
@Dan-cer That's the standard Android user interface, not anything we added or changed. We're not changing that.
In my other Android devices - tablet and smartphone - a popup window appears immediately whether I want to allow access to data of the device. I just then need to click on "Allow" and that's it. Isn't that standard? For security reasons, it is of course OK for me if there were a final PIN prompt.
In my other Android devices - tablet and smartphone - a popup window appears immediately whether I want to allow access to data of the device. I just then need to click on "Allow" and that's it. Isn't that standard?
No, it's not, and that sounds more like the Android Debug Bridge authorization prompt. GrapheneOS has the standard Android user interface for this and hasn't changed anything about it.
OK, could it be that it has become stricter and more cumbersome in newer Android versions? The tablet has Android 11. And there it is a standard popup that appears as soon as I establish the USB connection. If I deny, it is just charging or music connection (usb c adapter).
OK, could it be that it has become stricter and more cumbersome in newer Android versions?
No.
The tablet has Android 11. And there it is a standard popup that appears as soon as I establish the USB connection. If I deny, it is just charging or music connection (usb c adapter).
It sounds like a significantly changed OEM fork of Android with a different UI for this. That's not the standard Android UI and never was.
It is a Samsung Galaxy Tab S5e, Model SM-T720
Samsung massively changes the Android UI. It may also persistently remember that you authorized file transfer and allow it again which is something which can be exploited since it's not authenticated cryptographically.
Thank you for your information, which I find very valuable, especially as I am very enthusiastic about GrapheneOS. All of you really do a very good job. I will therefore content myself with the somewhat cumbersome procedure.