Slashdot Mirror

Okay, so this might be a bit of a ramble. Hi, I'm one of the developers of Monte https://monte.rtfd.org/, a new programming language based on E. E http://erights.org/ is a language from the 90s. Crockford worked on E. E's TermL mini-language became JSON. Another person who worked on E was Mark Miller. Miller's thesis project was formalizing and describing systems built with E. Crockford and Miller both are part of the committees that steer JS.

Now, to bring it all together: Object capability security is a security discipline based on the principle of least authority and perfect encapsulation. It allows us to build secure distributed computations with pretty good security properties; wf-stringe can prove that certain data cannot be exfiltrated, that certain I/O cannot happen, and that certain computations are arbitrarily safe to evaluate. It's not perfect, but it's a massive improvement on the state of things.

E and Monte, as well as a few other languages like Caja, Pony, and Waterken, are object-capability languages. Just like languages without manual memory management cannot misbehave in certain ways, these languages also promise that they cannot fail in certain desirable security-related ways.

Crockford, Miller, and others have been deliberately steering JS towards more capability-safe constructions. The object model has been tightened up, and tools like weakmaps, promises, and "template strings" (we call them quasiliterals in the literature) have been added. However, JS is still defined by its weak points, and those points are weak indeed.

Obviously, my bias is towards Monte. It's my preferred language and I want it to be popular. But, more importantly, I want the ideas that went into Monte to be popular. So, in that spirit, I'm going to give you a short list of questions. I want you to think, "How can I do that in my favorite language? Why would I want it?" Monte is meant to be the next Blub http://wiki.c2.com/?BlubParadox, the next language that is mediocre but built on a good foundation, and part of that is trying to see how Monte answers questions like:

• The encapsulation problem: How do I produce an object which perfectly encapsulates a value; i.e. the object refers to a value but referring to the object is not sufficient to gain reference to the value?
• The concurrency problem: How do I run two interacting plans of code at once?
• The privacy problem: How do I prove, (in)formally, that a value cannot be exfiltrated from my program except through designated channels?
• The confused deputy problem: What ambient authority is assigned to a "deputy", a program which can be fooled into misusing that authority?

...I've gotta stop writing blog posts on not-my-blog.

oops, wrong URL. It's http://www.erights.org/

If you ever wanted to learn how to code, you should check out "E" ( http://erights.org/ ). I've read through it, and really, I think their on to something.

but, just like other market economies, this depends on good or perfect information in the market to do anything like optimization. The purveyors of the cloud must all have the same good information on likely demand. Otherwise non-zero risk of unavailability turns into computing lines, or a zero risk of getting computing performed in anything like a timely manner.

I'd bet that many consumers will be unwilling and/unable to forecast their consumption growth and that statistical models will eventually fail.

Plus, wherever people build systems, others devise methods to game them. Expect people to intentionally be bursty in job submissions in order to throw your models.

Addressing another flaw brought up by others: security. As a minimum, and not addressing hardware level or virtualization-based "evil genius" problems some form of capability contract based computing is needed to enable mutually untrusting parties to transact the computation of one's algorithms on another's data without inapproriate disclosure. See http://www.erights.org/ for more.

I'm guessing that multi-user networked systems probably present the most interesting (and complicated) discussion.

If by "multi-user networked systems" you mean systems which host multiple competing interests which are mutually suspicious, then I agree. The vast majority of systems are computer programs communicating with other computer programs, some at the behest of a single user or multiple users, some based on a schedule, etc. If you can solve the problem of safe collaboration among mutually suspicious programs, then any other interaction I can think of falls out as a special case.

Part of the challenge (at least on the surface) is that in the case of an incoming network connection, the distinction between a "user" and a "program" seems a bit abstract.

Exactly, because there is no tangible distinction. Any "user" is communicating with you via some program, presumably under his control. It's programs all the way down.

I wno't try to go too far into those questions without first checking through the resources you've pointed to, which will take me some time.

A good start is Mark Miller's thesis, Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control.

I would note, though, that many industries operate under regulations that require authentication. This may partially be due to bad assumptions on the part of regulators.

Obviously I can't comment on any specifics without researching further, so you could be right. I would be disappointed if such legislation mandated a specific strategy to track information, rather than simply mandate that certain information be available should it be needed.

However, it also points toward a second reason why people use authentication: Sometimes it's not enough to know that an action is authorized; sometimes you have to keep track of who took each action.

Agreed! Delegation control and responsibility tracking are very important, which is why some capability folks designed Horton, which can be viewed as a sort of identity framework built on top of pure capabilities. Identities should only be used for reactive measures however, in case of abuse to identify the offending party and throttle or terminate abuse.

So, while you can decouple authentication from authorization to a point, I would still think you'd sometimes have to state "user has provided accurate identification" as a prerequisite of authorization (even if the authorization process isn't looking for any particular identity).

Whether the user/program intentionally or accidentally leaked his capability, you still have to revoke it to prevent abuse. I'm not sure what authentication gains you here. Identifying the capability is typically straightforward.

That said, I do think these make up a third category in this sense: Although they may be good candidates for a capability-based system, it remains true that I wouldn't generally "trust" a user as far as I could throw him.

Yes, there are no doubt other categories of systems. For instance, the KeyKOS capability operating system was used in early ATM systems starting in the 80s. I'm sure it had something to say on the subject. I hope you have time to research the rich literature of capability access control. :-)

I'm guessing that multi-user networked systems probably present the most interesting (and complicated) discussion.

If by "multi-user networked systems" you mean systems which host multiple competing interests which are mutually suspicious, then I agree. The vast majority of systems are computer programs communicating with other computer programs, some at the behest of a single user or multiple users, some based on a schedule, etc. If you can solve the problem of safe collaboration among mutually suspicious programs, then any other interaction I can think of falls out as a special case.

Part of the challenge (at least on the surface) is that in the case of an incoming network connection, the distinction between a "user" and a "program" seems a bit abstract.

Exactly, because there is no tangible distinction. Any "user" is communicating with you via some program, presumably under his control. It's programs all the way down.

I wno't try to go too far into those questions without first checking through the resources you've pointed to, which will take me some time.

A good start is Mark Miller's thesis, Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control.

I would note, though, that many industries operate under regulations that require authentication. This may partially be due to bad assumptions on the part of regulators.

Obviously I can't comment on any specifics without researching further, so you could be right. I would be disappointed if such legislation mandated a specific strategy to track information, rather than simply mandate that certain information be available should it be needed.

However, it also points toward a second reason why people use authentication: Sometimes it's not enough to know that an action is authorized; sometimes you have to keep track of who took each action.

Agreed! Delegation control and responsibility tracking are very important, which is why some capability folks designed Horton, which can be viewed as a sort of identity framework built on top of pure capabilities. Identities should only be used for reactive measures however, in case of abuse to identify the offending party and throttle or terminate abuse.

So, while you can decouple authentication from authorization to a point, I would still think you'd sometimes have to state "user has provided accurate identification" as a prerequisite of authorization (even if the authorization process isn't looking for any particular identity).

Whether the user/program intentionally or accidentally leaked his capability, you still have to revoke it to prevent abuse. I'm not sure what authentication gains you here. Identifying the capability is typically straightforward.

That said, I do think these make up a third category in this sense: Although they may be good candidates for a capability-based system, it remains true that I wouldn't generally "trust" a user as far as I could throw him.

Yes, there are no doubt other categories of systems. For instance, the KeyKOS capability operating system was used in early ATM systems starting in the 80s. I'm sure it had something to say on the subject. I hope you have time to research the rich literature of capability access control. :-)

A leap in security technology will take a requisite leap in human intelligence.

Not at all. A leap in security will take a requisite change in our development tools, from identity-centric abstractions, to authorization-centric abstractions so we can achieve the Principle of Least Authority (POLA) for all software. Ultimately, it's not about adding security, it's about removing insecurity; most languages have insecure abstractions baked into them, and when those are removed, the resulting software is significantly more secure, and yet, poses no significant burden on the developer; quite the opposite in fact: the software becomes more modular and maintainable. See the discussions on capabilities, and the E, and Emily capability-secure programming languages for examples. There have been numerous case-studies on the vulnerabilities of identity-centric services, and how they were rectified by refactoring the service to use authorization-centric models.

Depends on the OS really. But you're right if you mean any commercially available OS today. Singularity might solve a few problems if it was adopted. There are also some promising techniques being proposed by the people responsible for E.

Even the OS eventually terminates. I'd still put forth my paradigm works.

An OS, as mathematical function, is a recursive, non-terminating program. It MAY terminate, but it need not.

Accounting is a part of management. However, management goes further in that it assumes responsibility for allocating and de-allocating resources.

Accounting is not done in any mainstream language in any usable manner. Regardless, I've been arguing the lifecycle of objects is better managed automatically than manually, and you have been arguing that, at least sometimes but likely often, lifecycle needs to be managed manually. The majority of security bugs found today would have been avoided if the software had been written in a memory-safe language, and many memory leaks would not exist given AMM. We can argue the performance tradeoffs of memory safety and AMM (empirical evidence suggest exec overheads around 15-20% and memory overheads around 50-100%), but that they both eliminate large classes of bugs, including security vulnerabilities, is an indisputable fact.

However, the programmer still should have a way to tell it when it is done - perhaps as the programmer I want to release memory half way through a function instead of waiting for the pointer to go out of scope when the function exits.

But why? If the region-inferencer (for example), determines that the lifecycle of a chunk of memory isn't used halfway through the function, then it will do it for you. If it's not smart enough, then you can refactor your function into two functions to ensure that regions are scoped differently. As a bonus, this results in a better design.

Further, your approach can have a pathological effect on performance due to micromanagement. Why incur all the overhead of alloc/free'ing individual objects when you can alloc/free entire regions of objects at once. This is incredibly efficient, and further, leads to more efficient bump-pointer allocation techniques. Are you aware of the searching and fragmentation overhead induced by libc's malloc/free? This has been extensively studied.

We know how to write software that is only as secure as the attack vectors that we are aware of. Claiming otherwise is foolishness.

I can legitimately claim otherwise because software written to a POLA standard is maximally defensive, and so any remaining security holes are either
a) an implementation bug which does not follow the specification, or
b) inherent to the problem being solved and thus, fundamentally unsolvable without changing the problem specification.

Stronger static types systems help reduce a) (and C/C++ have very weak type systems), and b) is essentially unsolvable without manual intervention.

We can mitigate how software is affected by unknown attack vectors through Defensive Programming methodology, but even that can only truly protect against known vectors.

Like most generalities, your statement is both true and false. It is false in the sense that a POLA design is already maximally defensive, and so the security properties can't be made any stronger without changing the entire specification.

It's true because of the human factor in any system, and what you'll quickly find is that the majority of the security research by the capability security community are human-computer interaction attacks, ie. phishing, spoofing, etc. This is because automated attack vectors are no longer viable in POLA systems. I suggest you read the security audit of the DarpaBrowser built on the capability-secure language E for a taste.

The "Defensive Programming Methodology" is actually a degenerate, specialized case of capability security.

Additionally, reliance on a "memory-safe" language does not absolve you from buffer overflow attacks. Such reliance is foolishness - and is no better than security through obscur

Check out Usable Interaction Design
Also relevant: Capability security.
E Language
Capability Security

Although SELinux is a step in the right direction it's still basically a system of ACLs. It still suffers from the problem of the confused deputy. I think proponents of object-capability based security are correct in their thinking. Some interesting stuff going on in this respect is the E programing language.

Examples exist.E-rights has some interesting stuff on reputation (albeit for ecommerce).

Parallel programming does not have to be hard. All that stuff you learn in programming basics about deadlocks and semaphores and stuff really is hard, but there are easier ways of parallel programming.
Check out the communicating event loops of the E language or the actors of Scala. Asynchronous message passing removes the deadlock problem and makes relatively easy to understand programs.

A lot of efforts are being done to simplify the parallel programming, both on micro scale and component scale. Just look through lambda-the-ultimate archives. Micro scale is mostly invisible to application programmers, and it is mostly done by compilers when they use SSE and friends, one of notable efforts of making it more explicit is OpenMP. On component scale, most of them are based on the message passing concurrency model (after you grok it, it is really really simple). The best effort that I have seen from point of view of usability is E programming language. I tried to clone its core ideas in my pet project AsyncObjects Framework, but usability is less than E's one because of the framework clutter.

I'd hardly call it english. Legalise really is its own form of code.

I think the GP's point stands, it'd be useful to have some sort of independent QA organization that would validate a bill against its intent.

• What if one of your subscribers throws an exception? That should not prevent other subscribers from being notified.
  
• What if notifying a subscriber triggers another value to be published? All the subscribers must be kept up to date on the latest published value.
  
• What if notifying a subscriber triggers another subscription? Whether or not the newly added subscriber receives this in-progress notification is up to you, but it must be well defined and predictable.
  
• Oh, and by the way, don't deadlock.
  

It's the sandboxing. A program run by a given user doesn't automatically get the user's full permissions -- it only gets a small subset. For example, it can't open files from the user's home directory other than by calling a trusted system File Open dialog, which allows the user to select the file and returns an open file handle to the application (or in OLPC's case hardlinks the file into the chroot jail).

In terms of research projects, see the secure scripting language E and the proof of concept CapDesk.

Interestingly, in the commercial world it only seems to turn up in safe bytecode runtimes -- there's very little out there for native code. For an example of something similar in concept look at JNLP or ClickOnce deployers.

The E language has a very interesting and powerful approach to concurrency that avoids many of the trickiest problems with threads. Have a look at the paper Concurrency Among Strangers: Programming as Plan Coordination by Miller, Tribble, and Shapiro.

The E language has a very interesting and powerful approach to concurrency that avoids many of the trickiest problems with threads. Have a look at the paper Concurrency Among Strangers: Programming as Plan Coordination by Miller, Tribble, and Shapiro.

Been around a long time already ... http://erights.org/ and very good it is as well

I would advise some serious reading.

I'd advise you to do some serious thinking. The guy who's been replying to you is totally right. There is absolutely zero security when everything that matters is runnable by you. If you're running something like Firefox as your everyday user and it has a vulnerability, game is over, just like IE. What's sad is this myth that most Linux users have regarding security.

Do some reading yourself (or watch the video): The SkyNet Virus Why it is Unstoppable; How to Stop it

There is no sequence of steps that you can take that reduces the risk to zero.

Indeed, but we're so far from zero that it's not a problem. Even though I'm many times more knowledgable and cautious than the average user it still distresses me just how much implicit trust I have given to millions of lines of code and thousands of developers.

We need to MAKE THE FUCKING HORSE DRINK.

You're not going to MAKE users secure by beating them with a stick. If computer security was as simple as maintaining a car there wouldn't be the huge problems there are now. So yes, the solution will have to come from the vendors, to make security the easy default.

The right direction is Principle of Least Authority, but neither Unix nor Microsoft has done a good job with this yet. There's huge room for improvement. Take a look at The SkyNet Virus: Why it is Unstoppable; How to Stop it for a sane approach to security.

Speaking as a user who understands their computer reasonably well and doesn't click on stuff just because animated characters tell me to, would this be a good thing?

The problem isn't "lusers". The problem is the whole security model is broken. Every software application on your computer has the ability to steal your bank password and transmit it across the net. Can you vouch for the millions of lines of software for every application that you have installed? All it takes is one rogue programmer.

The SkyNet Virus: Why it is Unstoppable; How to Stop it

Yes, I do. Consider the thousands of programs and millions of lines of code that are on a typical pc. Do you want them all to have carte blanche access to your data? The ability to erase it? To send it across the internet?

[example of system asking 5 questions to edit a file]

Take a look at The SkyNet Virus: Why it is Unstoppable; How to Stop it. In particular, I recommend watching the wmv (it's a 100 meg download). At 11 minutes in the speaker addresses your exact concern.

Realized that link wasn't as helpful as I remembered. But here are some other good general links that should get you going.

http://en.wikipedia.org/wiki/Concurrent_computing
http://en.wikipedia.org/wiki/Message_passing
http://en.wikipedia.org/wiki/Actor_model

The E lang has some good documentation on concurrency, even if you don't use it.
http://www.erights.org/elib/concurrency/

As does Erlang.
http://www.erlang.org/download/erlang-book-part1.p df

You're right! It would be better to get a technology designed for multi-threaded programming. But then you go on to push Java? I'm confused.

Now, granted, Java does provide builtin support for concurrency. Although that support is an implementation of the 30-year old monitor concurrency primitive, which even one of its principal inventors (Tony Hoare) long ago abandoned in favor of better things. Not to mention that Java's implementation of monitors is known to be broken (or at least was - maybe they've fixed it now?).

Doug Lea's util.concurrent package (now part of Java 1.5) certainly helps things on the Java front, but it's hardly a panacaea. Depending on the application, you may want to take a look at JCSP instead - it provides for an almost direct translation of ideas from Tony Hoare's CSP into Java. For languages with good concurrency support out of the box, you might try Erlang, Ada, Mozart/Oz, E, or Eiffel.

Check out Polaris. It's a way of giving each process on XP it's own ACL. Have a look at the rest of erights too if you want to get an idea of what people who put security *first* are thinking.

http://www.erights.org/new.html

Funnily enough, if you start from a good place, security often follows on naturally without getting in the way, unlike most mainstream operating systems.

Also have a look at EROS - a pure capability operating system which allows such fine grained access control that the closest you can get to the Priniciple of Least Privilege with the most locked down system in windows is a joke when compared to it.

http://www.eros-os.org/

Security and usability are only mutually exclusive when you are stuck with old (traditional modern) security approaches. It does not have to be this way. The book contains an article by Ka-Ping Yee that points the way to resolving this apparent conflict. Software systems that demonstrate the points made by Yee include the Polaris secure desktop being developed at HP, the CapDesk secure distributed desktop developed by Combex, and the Web Calculus secure bookmark system developed by Waterken. These example systems have all been created by members of the object-capability community, you can read more about their work at http://www.erights.org./

What a mouthful huh?

We have secure, distributed programming languages, and we have multi-paradigm, distributed programming languages.

Next stop: secure, multi-paradigm, distributed programming [1],[2].

[1] The Oz-E project
[2] SCOLL: A Language for Safe Capability Based Collaboration

And when you're done with that you could move on to E and F....

Without attacks and threats we wouldn't bother developing a resilient software ecology. Heck, we're still not there despite mounting attacks. We would only have the illusion of privacy at best.

Security and software is an ecology, and we have to evolve appropriate measure to combat attacks. The techniques are here [1][2][3][4], we just have to deploy them.

[1] EROS
[2] CapROS (EROS development moving to the community)
[3] Coyotos (EROS successor in the research communits)
[4] E: secure, distributed programming language

There have been some very good research projects done on how to build a more secure system, and some of the most amazingly effective ones have been the ones that challenge the basic assumptions of "best practice".

MIT Kerberos takes the view that no machine on the network can be implicitly trusted; access to network services is controlled by tickets, mediated by a ticket distribution service with which each user and service has a pre-shared key. This works even for systems in which the local operating systems have no internal access control mechanisms whatsoever.

Capability-based systems essentially throw out the classic security model of users, roles and permissions, replacing them with a system of nonforgeable references by means of a combination of memory protection and cryptographically strong naming.

Finally, people need to come to terms with the fundamental fact that content-based security schemes are a losing proposition (1, 2). Virus scanners, adware scanners, porn blockers, spam filters, and even national customs departments all face the same problem: they can only inspect what goes by and apply a list of tests to winnow bad items. There is strong economic pressure to find ways to bypass these types of checkpoints, so new tricks are constantly being invented, only to be compensated for by the guardians; thus the guardians are always a step behind.

It is possible to replay the execution of programs that communicate with the outside world, rather than just in an isolated virtual machine: you have to log nondeterministic events. See http://www.erights.org/elang/concurrency/determini sm/overview.html.

The first language I know of that supported replay is the Abundance database language, back in 1986. Also see http://c2.com/cgi/wiki?ReversibleProgrammingLangua ge.

More info at http://erights.org.
The ACL model (based on the notion of principal) is limited because it doesn't scale (your access matrix grows fast as you need finer level access control) and still allows compromised applications to use their permissions for the wrong purpose (confused deputy problem).

Just because there is no super-user, doesn't mean that there is no way to access a person's data. Anyone with a capability to a particular resource can access that resource regardless of who they are; there is no concept of "ownership" except in that the creator of an object is the only entity holding a capability to it until he gives it to someone else.

Suppose an administrator creates a block of space he wishes to dedicate to a particular user. The act of creation returns a capability(unforgeable reference) to that object, and the admin is currently the only one holding that capability; no one else is even aware of its existence. Once he grants the capability to the user, the user now also has access to that space. The admin does not (necessarily) lose it.

One could design the system such that the admin could not access the private space in any meaningful fashion (plausible deniability/common carrier) and thus the user may use it as he wishes; or one could design it such that the admin has full access to any objects created from that space (full auditing support and higher level policy enforcement).

Capability security is simply enforced, pure object-oriented reference mechanics. Until you give B a reference to C, B cannot refer to C or induce any sort of direct changes in C (in Java and .NET VMs). Same with capabilities.

There is no direct historical relation between Multics and EROS. See The Path to Coyotos. Multics is not even capability-based, and doesn't even appear on the map of capability computation which shows the development history proceeding from Hydra, to Gnosis/KeyKOS and ending at EROS.

It seems some people are desperate to do anything to avoid actual implementation (work?)

People are avoiding not just work but also the effort of learning anything substantial (and therefore difficult). It is easy to learn this sort of fluff; it is not quite so easy to learn some interesting languages designed to solve real problems.

The current security model, based on the concept of principal and permissions/ACL, forces the trade-off between being able to do powerful things and raising the security risk.
The capability-based security model (see http://erights.org for more details) is a way to break this paradigm and allow for power AND safety (and usability, from the existing prototypes). Still lots of open issues, but seems like a very interesting direction for safer computing.

http://www.erights.org/talks/index.html Check out the SkyNet talk there.

Hello folks.
I was thinking about implementing the SPKI system, at least the verifier, in PHP for webmasters and people convinence.

If any of you are intrested please reply to this post/comment.

If you are intrested in computer security chek out erights.org and Introduction To Capability Based Security

-Zarutian
ps. I hope this isnt modded down.
---
sha1 hash of message (excluding the line whith ---): f944e109ee67a9622d60d7e2611a85d021c8fbb8

You mean this E?

It can be done better, by building - from the ground up - a capability-based system. It has been done as well: see EROS and The E Programming Language for example. Like other good ideas, however, it just doesn't take off because of the inertia built into the market. However, with the current rate of worms, viruses, spams, and whatnot, it won't be long before moving to a new and secure OS becomes an attractive proposal.

Err...I think there's only 5 left. Don't forget about D and E now.

Now combine that with E ?

I wish someone would code a OS with this (E, the secure distributed pure-object platform and p2p scripting language)... could this potentially save us from Palladium etc?

Shouldn't we provide good, free, open security, before the money-grubbers do it?

But once your obfuscated URL is discovered - and discovering it is trivial - then the secret is out, and what little protection it did provide is lost until you can change the obfuscation.

So in other words, locking down the system is a URL change away, which exactly parallels the password situation. In fact, if you do it right (cryptographically secure random hash strings), a URL is more secure than a password. A secure scheme: an encryption layer so it's impossible to snoop the URLs, (at least) 128-bit crypto-secure URLs and you have yourself a capability-secure system.

See these for more info on capability-based security:
E rights
EROS

Discovering the URL is not trivial if you do it right. It becomes a problem of guessing a 128-bit string, or cracking the connection encryption keys. MUCH more secure than passwords which are typically no longer than 64-bits and alpha-numeric limited (effectively limiting them to around 32-bits - much less if you factor in how much people use english words).

I'm such a doofus. link to the E Language here

With that screwed up childhood, it's no wonder that C++ turned out to be complex and having a lot of issues. And -- let me tell you -- a chick with problems gets around town really fast. It wasn't long before C++ gave birth to Java (father unknown), C# (with the brother of Java's father, hence the family resemblance), and a bunch of other minor and niche dialects.

It hardly ends there. The old philanderer, C, is still bar-hopping and skirt-chasing to this day. Having recently received a facelift and a Viagra prescription from ISO, C's been hitting the hardware and has sired a couple of shader languages, C--, SpecC, and God only knows what else...

C refuses, however, to claim responsibility for the E programming language. While the similarity is at times striking, C insists that it would never give rise to an expression-based language.

... hello, shakkur :) ...

No, the solution is to give up on ACL-based security, and integrate proper capabilities-based security right into the operating system. Of course, the programming language must be safe as well, and preferably friendly to capabilities.

In fact security and usability are natural friends if you can think outside the box Microsoft and Unix have locked us inside. Check out the capability secure desktop included with the E capability secure programming language at http://www.erights.org . There you will find a system with no funny security dialog boxes, no stupid passwords, no complicated firewalls, but which is effectively invulnerable to computer viruses and trojan horses. Their secure desktop follows many of Ping's guidelines. You can find descriptions of the approach at http://www.skyhunter.com/narratedIntros.html. The description there is too much like an advertisement for my taste, but it's pretty good for a quick introduction to a serious alternative to the 2 most popular security attitudes out there, namely despair and stupidity.