Does USB-C isolation render data blockers irrelevant?

starglider

I've historically used data blockers (PortaPow) when using random USB outlets in places like hotels or airport charging stations. It's probably overkill for my threat model, but it seems generally prudent.

I'm considering whether it's just silly to use this given GOS's USB-C protection options. I have it set to "charging only", and I've read in the documentation that this is enabled at the hardware level with software as a fallback. I don't fully understand this, since when I think of "hardware" I think of something like literally not connecting the data cables (like the blockers do).

For those who understand more about how this works, though, is using a blocker given the GOS setting just completely redundant? Using the blockers on USB-C is also more inconvenient now, since some fast charging protocols won't work without the data lines.

GrapheneOS

starglider GrapheneOS is disabling new connections and data in the USB-C controller so it is truly disabled at a hardware level meaning the data lines are disabled. The USB-PD protocol for charging is still active since that's an entirely separate thing from USB-C data. It's up to you if you want to rely on it or if you want a more physical implementation of blocking data instead of relying on the OS and USB controller.

jwgn

Which then means that fast charging is not going to work because

starglider some fast charging protocols won't work without the data lines

starglider

GrapheneOS This is super-helpful; thanks for the insight and quick response. Distinction between OS and USB controller makes sense. Much appreciated!

GrapheneOS

USB-PD is a separate thing from data. GrapheneOS supports disabling USB-PD via disabling charging as a whole while the OS is booted using the "Off" setting for USB-C.