Comment 3 for bug 1844650

Although not ideal, the behaviour currently is kinda as designed[1], although the design itself does not mention the case where a unknown device is already plugged in at boot time.

Regardless of this, the bug is filed against the wrong component because bolt itself does not provide policy, i.e. the authority to manage devices, including initially authorizing them, is not in the hands of boltd[2]. On a GNOME Desktop the policy provider is the Shell: it is listening to events and if a user (with admin rights) is currently logged in and the screen is unlocked instructs boltd to authorize the new device. In short: the act of connecting a dock to an unlocked computer is interpreted as the intention of the current user to authorize the dock. Now if the device is already connected at boot, we can not be sure that was done by the same user that boots the machine and then proceeds to log in. So automatically authorizing an unknown device would create a security thread where a different evil person could have plugged in a small spy device to the computer and then forced the computer to shut down. The puzzled normal user would reboot and the evil device would automatically authorize the device.

That being said we should probably show a notification after log-in that there are devices connected that are not authorized (and a click could bring you to the control center to manually authorize it), very much as we do already when devices were connected while the screen was locked. In any way this bug should be against the Shell, not bolt.

[1] https://wiki.gnome.org/Design/Whiteboards/ThunderboltAccess
[2] with the exception of very modern hardware that provides hardware based DMA protection, aka iommu for thunderbolt support, but there we rely in the hardware to provide the security and thus this is a special case.