For removable-media, hey-mail doesn’t precisely fit the current policies for removable-media. Have you read through that section?
In a lot of ways, email clients are like browsers: they typically have web renderers and they have a need for attaching documents, so I think perhaps we should extend our processes to include ‘major email clients’? @pedronis - what do you think?
I suppose they also don’t write or read from non-scratch/non-application disk parts without user confirmation usually? Do they get the same maintenance attention that browsers get? Also OTOH is it common and frequent to ingest or save attachments to removable media? it might be.
+1 from me too for auto-connect of u2f-devices and hardware-observe to support hardware security keys in hey-mail. I also tend to agree this is very similar to the web-browsers use-case for auto-connect of removable-media, so FWIW since this is being published officially by the upstream project, +1 from me too for removable-media as well.
As per @pedronis comments above, it seems fair to assume users would save / add attachments from removable media, and given that this is done with user-interaction, the same use-case as for web browsers applies in respect to removable-media auto-connect - this has now been updated in the Process for aliases, auto-connections and tracks. Also given that this is published by the official upstream, granting auto-connect of removable-media for hey-mail. This is now live.