[cap-talk] when is the end of copy and paste from the web browser
David Barbour
dmbarbour at gmail.com
Mon Dec 5 16:48:45 PST 2011
On Sun, Dec 4, 2011 at 8:01 PM, John Carlson <john.carlson3 at sbcglobal.net>wrote:
> Right now, we have to copy lists of instruction from a web page to
> explorer, or shell. When will be the day when we can safely directly
> execute list of instructions found in a web browser on our local machine.
> For example, perhaps I want to install all the drivers to make Kinect work
> with Skype on Windows from a forum? What do we we need to do to make this
> a reality?
When the human obtains code and executes it, whether that code is
obfuscated binary or visible script, there are intrinsic problems:
* the code loses its security context; i.e. authority comes from the human
* to read and grok all code you use is unproductive, unscalable, and
unlikely in practice; i.e. faith replaces audit
* the code cannot be securely upgraded; i.e. relationship between code and
maintainer is lost
We cannot fix these problems you describe without also fixing the code/app
distribution model. Here are a few patterns of code distribution that are
securable:
1. As part of using a remote service, we download code that implements part
of the service on our machine. This requires separation of location and
authority, i.e. no sensitive authority just for executing code on client
machine. Authority flows instead from server to client, due to capabilities
embedded in code. Server developer is responsible for deciding how much
authority to give client, with goals such as improving performance and
latency.
2. Conversely, client uploads code to service to act as ambassador on
client's behalf. Client can then talk to ambassador, rather than directly
to remote service. Client's ambassador can make local decisions and queue
or filter output from service. Similarly, there must be separation of
authority and location. Also importantly, the programming language must
offer either effective control over performance costs, or good market
integration (pay-for-service), such that there is no risk of
denial-of-service attacks by this vector.
3. We can `discover` code and modules through trusted registries. We
control who has access to publish to each registry. Registries can be
securely composed, i.e. create a new registry that involves a union,
filter, etc. on other registries. Module systems must provide a clean
separation of interface vs. implementation, such that there can be multiple
competing implementations for a given interface. Developers work in terms
of interfaces rather than choosing a specific implementation.
The last is similar to a `trusted` app-store, though at the sub-app
granularity.
In any case, I think you must ultimately re-envision the scenario, such
that the user is never directly involved with downloading code.
Regards,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20111205/3b888810/attachment.html
More information about the cap-talk
mailing list