== A more abstract view of the generalized _open()_ issue

Part of [[the generalized _open()_ problem GeneralOpenDanger]] is that
such generalized _open()_s silently cross what I will call 'security
contexts'. Here a security context is both what you can do *and* where
the data is coming from; read versus write versus run a pipe, local
files versus remote URLs, and so on.

When something is security sensitive (and _open()_ is here), it should
either be explicit about what security context it is operating in,
or it should at least be explicit about the fact that it is crossing
them.  In other words, this is one of the places where you deliberately
want to *break* abstractions, so that there is no possibility of code
accidentally operating in the wrong security context.

As a corollary, namespaces that cross security contexts are a danger
sign. Firefox has had problems with because its internal files and
resources are partly named using URIs in the chrome:// scheme, so lots
of things that accept URLs have to be blocked from using them (and
sometimes stuff using chrome:// URLs had to be blocked from using other
sorts of URLs). And of course there's the great fun to be had because
browsers accept 'javascript:' as a scheme in URLs.

(I suspect that these things sneak into languages partly because the
language designers did not see them as crossing security boundaries, and
in part I think this may be because security boundaries sometimes only
become obvious with painful experience. After all, no one *deliberately*
puts security holes in their language or their library.)