Kevin Gillette (Mar 09 2022 at 15:08): Kevin Gillette (Mar 09 2022 at 15:08):An intriguing idea I've seen elsewhere, and which may or may not be a good fit for Roc, is to use _provenance_ (where a value comes from) to enforce security or other constraints.
For example, sensitive values (like passwords or private keys) should generally not be leaked via logging or various other forms of output. Similarly, untrusted input should not be directly interpolated into database queries.
We certainly could use opaque types to control this, but only to a limited extent: if a function is provided to unwrap a SecureString into a Str, there's absolutely no accounting for where or how that Str is used afterward. We could also prevent a SecureStr from being unwrapped at all, but that prevents deliberate, well-informed uses of the data, when preventing accidental uses is the most important outcome.
My loose understanding of the concept of provenance is that it would allow a Str to behave like a Str (or any other type), but with some implicit properties based on where the string was constructed: user input might produce an "untrusted" Str, for example, and a cryptographic hash function might produce a trusted value regardless of input. A sanitizer function might pass an untrusted Str through (in a Result), but without the untrusted property.
It's unclear to me if such a mechanism could be handled entirely at compile time, but in any case, how would others solve these needs within the Roc language today? Parameterized tags? What measures/techniques would be used to ensure such values are not used in a dangerous way?
Derek Gustafson (Mar 09 2022 at 15:17):I've seen this idea before, and I like it. Where I've seen it, it is handled via types in user space.
Roc could handle it with opaque types (once they're finished) or private tags (right now)
Derek Gustafson (Mar 09 2022 at 15:18):Here's where I've seen it: https://www.yesodweb.com
It's a server side webframework written in Haskell
Derek Gustafson (Mar 09 2022 at 15:21):Basically it provides an Html type that wraps strings. If you try to use a string where Html is expected, it gives a type error. You can either call the function to encode the string to safe Html, or you knowingly circumvent it; Can't really do it accidentally.
Zeljko Nesic (Mar 09 2022 at 17:30):Could you provide some pseudo-Roc example where you see that working?
SecureStr : [ SecureStr Str ]
unwrapStr : Credentials , SecureStr -> Str
Is this good enough? If Credentials are hard to get by, _enforced by the type system_ then you are pretty much sure that only right people can unwrap SecureStr
Derek Gustafson (Mar 09 2022 at 17:37):Something like
SecureStr := [ SecureStr Str ] # Note the Opaque Type
encodeStr : Str -> SecureStr # Performs encoding of untrusted characters
functionThatTalksToDB : SecureStr -> ...
I don't actuall know the syntax for functions that interact with the outside world
Last updated: Jun 16 2026 at 16:19 UTC