I wouldn't want to change the usage of env vars, they're ergonomic and only the current user or root can see the env vars of a running process which makes it ea

I wouldn't want to change the usage of env vars, they're ergonomic and only the current user or root can see the env vars of a running process which makes it easy for us to architect secure usage patterns. But... it'd be cool if we had better support for avoiding accidental leaks. E.g. a way to identify another process as my user that ends up reading /proc/<pid>/environ unexpectedly. You could model that with SELinux but it could be a bear to own and not worth it for outside of large/important/high-value target companies. I suppose that's an apt description of SELinux generally... Maybe we could have a "light" version at the code level, maybe use the type system to throw an exception if you ever try to .toString() a secret. I'm trying to think how i would do that in Java without binding someone to an awkward type hierarchy (yuk!). This is not (currently) valid Java: interface Secret { default sealed String toString() { throw new IllegalAccessException() } } By this i mean a type that if i compose with, then it overrides (not currently supported) my toString() and blocks me changing the impl of that (sealed), then i can't accidentally log it for example. I think the way to do this in Java today would need to be via a dedicated class, i don't think i could use a composable interface. I mean that's fine-ish but i feel allergic to constraining other developers to my abstract class Secret { ... } EDIT: just blocking /proc/<pid>/environ wouldn't be enough, the other process could ptrace(2) for example.