If a DataBank is trusted not to disclose what data it provides copies of, it can be used in the role of a discreet proxy. Suppose that I have managed to confine some computation to a compartment. The compartment may be a physical computer or, with some operating systems, a portion of a physical computer, or with some interpreters, a confined applet. If I connect that compartment to a discreet proxy then an application in that compartment can summon extensions to itself or even other applications to serve as a sub-contractor. If that connection is secure, the proxy truly discreet and the compartment wall indeed impervious to outgoing signals, then the application is still unable to export secrets which have been given to it. The proxy, communications channel and discreet proxy have then become a larger confined compartment.
The arrangement can be made if the compartment logic maintains a set
of the public DH keys of the proxies it deems to be discreet. The application
can have its own list of proxies where suitable data may be found. If there
is an intersection then the computation can proceed.
This protocol is silent on the issue of payment for software services.
Indeed payment seems to be at odds with discretion,
but an engineering trade-off is described
here.
That scheme can be extended to cover use of the discreet proxy.
This is a special case of a more general situation that Markm describes. Using Markm's terminology, the proxy referred to above (necessarily trusted for confinement) can be subdivided into parts only some of which need be trusted. In particular we must trust: