[
Lists Home |
Date Index |
Thread Index
]
On Wed, 2003-10-01 at 01:27, Chris Wilper wrote:
> > Can an innovative environment produce a trusted computing system?
depends on your goals, and indeed what a trusted system (standards
aside) really is. seems to me they're trusted until broken. and therein
lies the rub.
to paraphrase one of autralia's most successful businessmen - if doing
20% of the work produces 80% of the profit, it's pretty hard to justify
doing the other 80% of the work.
unfortunately the trusted bit is often in the last 80% of the work - and
i think windows is a preeminent example of this principle. unix/linux
demonstrates the converse.
everything today is moderated by time and cost expectations.
so if we review the statistics - probability of failure times cost of
failure is the critical number.
you can have a relatively high cost of failure if the probability of
failure is low enough - that's why we feel ok about flying.
windows' problem is that the probability of failure under certain well
known conditions approaches 1 and so even a relatively low cost of
failure produces a high expected operational cost from failures. hence
the proliferation of viruses.
in training software engineers i think we need more emphasis on this
because we need to produce a lot more operational code - in fact this is
a big part of my getting large amounts of software into operation.
eg if you run a service on a tcp port, then lots of hackers out there
will find it. does it matter? only if they can discover the protocols
and make use of them. so i can run an insecure service, that doesn't
respond, on a public port and have a high confidence that no matter how
damaging abuse of that port might be, it is very unlikely to be abused,
because noone knows how to abuse it. i don't even need encryption. ftp,
http, smtp, etc are a different story - we all know or can find the
protocols.
this is the same as the program failure problem. does a bug matter, no
matter how potentially damaging, if it's probability of occurrence
approaches zero? i think not. although calculating that probability can
sometimes be a problem in its own right.
what does this have to do with xml - lots. we're trying to produce
innovative, and productive environments, with lots of built in self
discovery technology. today's virus problem is nothing compared to what
the future may bring.
we probably need to think long and hard about good secure techniques
that we can teach at the same time as we teach standards and
technologies. engineering in general has solved this in the education
process, i just don't think we've done as good a job in software
engineering.
so the point of this rant? the question is wrong. trusted computing and
a proper understanding of it should be part of our approach to
development. full stop. like musical technique. an innovative
environment is where we work. to extend the musical analogy. in a jazz
band, rock band or symphony orchestra. orthogonal requirements if you
like.
cheers
rick
>
> If the constraints are accepted beforehand, sure.
> Great innovation happens under (and often in response to)
> the most constrained conditions.
>
> Related: http://www.useit.com/alertbox/20030908.html
> (third heading down, "[Misconception:] Usability Kills Creativity")
>
> > Can we 'do the simplest thing that will possibly work'
> > and still produce a secure system.
>
> Unlike usability, considering *trust* issues as you set out to design
> will usually preclude the simplest thing from being done.
> Where we often get into trouble is throwing such all-encompassing
> constraints onto an already-built system. No matter how low your
> "iteration cost", if you've inadvertantly carved security out of
> the final product, you're not going to pump out a secure version
> next week. Too much would have been ignored by that point.
>
> - Chris
>
> -----Original Message-----
> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
> Sent: Monday, September 29, 2003 6:18 PM
> To: xml-dev@lists.xml.org
> Subject: [xml-dev] Managing Innovation
>
>
> A little thought experiment, a bit lighter than
> the complexity thread, but also, a bit related
> in that the management of uncertainty comes into
> play.
>
> Read this:
>
> http://hbsworkingknowledge.hbs.edu/pubitem.jhtml?id=3687&t=innovation
>
> Then answer the question:
>
> Can an innovative environment produce a trusted computing system?
> In short, the market demands innovation AND security. Can we
> 'do the simplest thing that will possibly work' and still produce
> a secure system.
>
> len
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
|
