ScopedValue: Capturing current bindings

[David Lloyd]

On Thu, Jun 1, 2023 at 12:38 PM Attila Kelemen <attila.kelemen85 at gmail.com>
wrote:

> David Lloyd <david.lloyd at redhat.com> ezt írta (időpont: 2023. jún. 1.,
> Cs, 19:02):
>
>> What would happen if there was some context which is implemented in some
>> way *other* than ScopedValue? For example, using thread locals, or a field
>> on Thread, or something like that?
>>
>>
> I understand your implication that I'm being a little bit hypocritical by
> concerning myself with SV, but not with others. And of course that is
> unfortunate, and I can't do anything about it. But the reason I care more
> about the SV scope than others is because I see scope to be more important,
> because this looks to me as a promising emerging concept. That is, we could
> have a future, where SVs are promoted properly everywhere (for example,
> StructuredTaskScope propagates it to the child tasks), What I mean by
> "promoted properly" is that at some point (there are various missing tools
> for that still) we could have what I would call a "properly scoped"
> application, where opening a new scope in `main`, whatever I set there will
> be visible to all application code, and if started so (there could be an
> implicit virtual scope for `main` as well), then the whole application
> would sit in a scope tree (even with concurrency considered) which would
> allow me to reason correctness about my code better. In such a world, a DI
> framework like I mentioned could be useful (and I believe a lot of
> other future APIs could benefit from proper scoping).
>

What I for one do *not* want is for someone other than myself to decide
what "properly scoped" means for a given piece of code that I write, nor do
I want behavior outside what is strictly required for implementing locally
scoped variables.

Let me give a real-world example of why this is a problem. We have a
security identity framework where our identities are associated in the
manner of ScopedValue. A user may query what identity is currently active,
and the user may execute some block of code with a new active identity.
However, we found early on that some existing frameworks - like the Servlet
specification for example - do not allow us to interpose a call like
identity.runAs(() -> { ... }) in the midst of handling a request, for right
or for wrong. So instead what we offer is a way to lexically scope a
"flexible identity association". The identity may be changed within the
scope of an operation, but the flexible association does not escape the
bounds of the lexical scope that it was run under.

Why is this a problem? If you have some means to capture - even just for
the purposes of verification - the "scope" as defined by all active
ScopedValues, your expectation may be that you have captured the active
identity that was present at the time of the capture. However this would
not be the case in practice, and so you'd have a wrong "answer". In other
words, the semantic meaning of what I store in an in-scope scoped value
association has a bearing on what it means to capture it, and that semantic
meaning is nobody's business but my own. Therefore, any API which broadly
captures all scoped values for *any* reason is also semantically
meaningless and therefore misleading at best, and disastrous at worst
(think CVEs).

If I control a scoped value, then I want nobody to have access to it for
any reason at any time without my explicit mediation and permission. I
think this is critical to the design, and I think that trying to impose a
greater framework on what is essentially a mechanism for locally-scoped
variables would be a mistake, and I further believe that this mistake could
result in vulnerability to exploitation. Given that any locally-scoped
variable mechanism may be used to implement any other locally-scoped
variable mechanism, my opinion is that if you want locally-scoped variables
which carry some additional meaning or behavioral constraints above those
established by ScopedValue, you can implement one yourself (see Jakarta
Context Propagation for example). ScopedValue, being the new foundational
means to achieve local scoping, would not be the correct place to do this
since any assumptions or behaviors implicit in its usage would inescapably
creep into that of everything derived from it. Which I guess you view as a
feature but I view as a potential disaster.

-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230601/e5c79ae8/attachment.htm>