TREVOR: Some provocative questions...
I'll address the first question now and leave the others for a little later.
Question: Why should the real world care about PCC?
Answer: It won't.
GREG: It's true that security doesn't sell. However, if the business world changes so that someone can be sued for selling buggy or unsafe code, then businesses will need to buy insurance against litigation. Insurance companies might give them a discount if they use PCC. (There are a lot of "if"s there.)
About production quality tools: it's a young field. We'll get there.
ANDREW: George, why do you want to go head to head with Java? Doesn't your technology just do the same thing in a different way?
GEORGE: We need to specify who are the customers here. PCC doesn't do more than Java type safety, but does it better. It's more secure because it allows you to trust less. There might be niche markets in the real world where smaller is much much better -- e.g. memory- or power-limited devices.
The real competition is signed native code. (Compared with interpreted or JITed languages, the advantages of PCC are pretty clear.) Today, the advantages of PCC there have not been established, in ways that the real world cares about. Digital signatures seem to work fine in the mass market.
GREG: The device driver example may be a good one. Microsoft wants high-assurance Windows boxes that use PCC device drivers.
GEORGE: If MS thought they could get away with it, they would require PCC tomorrow for device drivers. OS crashes because of bad drivers really hurt their credibility.
Win2k now has signed device drivers. But getting a signature costs a lot of money because one or two MS engineers have to sit down with the code and go over it with a fine tooth comb. Not many drivers will be signed in this way.
Two things are needed to do a similar job with PCC:
ANDREW: Signed signatures on device drivers are a way of helping with malicious device drivers, not buggy ones.
[general disagreement]
JAMES RIELY: Two advantages are claimed for PCC
GREG: In Java, we're trusting this and the JIT or interpreter, runtime system, GC, etc., etc.
GEORGE: You could say that what we're trying to do is distill the safety policies underlying C code. Andrew and Amy's method makes the safety policy even smaller. [GREG: The corresponding typing rules in TAL are much larger, by comparison.]
GREG: Note the difference between a paper proof of type soundness for a kernel calculus and real verification of actual machine code before it runs.
Also, if we go all the way to the machine level, we can build infrastructure that is insensitive to the details of the source language (tail calls, etc.) and its type system.
TREVOR: It sounds like you're not saying anymore that the key property is safety, but rather the combination of safety and performance.
GREG: Yes, that's the real niche for PCC.
It's probably possible to eventually trust a Java interpreter, but note that there are now more lines of C native methods for Java being written than lines of actual Java!
TREVOR: If we're going to have code signing, then code producers are going to want safety from litigation -- they're going to want to be able to shift blame. [GREG: MS is going to want 3com to own up to their mistakes, and vice versa.] ...but code signing doesn't help with this.
ANDREW: Code signing doesn't have much to do with determining fault.
GREG: Of course, all this is speculation in the present legal environment.
TREVOR: ... but at least we can develop mechanisms for assigning responsibility that might be useful later.
ANDREW: Nobody cares about security. Look at Napster and GNUtella, which basically let you share pieces of your hard drive with everybody on the planet...
GREG: Corporations do get burned, by viruses and things. They are the ones that set up firewalls and enforce security policies, not individuals.
-------------------------
ANDREW: OK, let's go on to the next of Trevor's questions... What's the killer app for PCC?
A: PCC provides no new capabilities ==> no killer app.
GREG: Let me shoot that last point down...
There are alternative VM designs where PCC would help a lot. E.g. OmniWare (in conjunction with SFI) works very well. It's portable, but close to many architectures. JVM is a lousy VM design. We could do a lot better job.
We punted on portability for a while, but some of us in the PCC world are trying to consider it.
ANDREW: But you'll still need a translation from the common rep to machine code.
GEORGE: PCC doesn't mean native code -- the goal is just to push high-level facilities (type systems) down as low as possible.
GREG: For mobile devices, we could imagine that server runs the compiler. Verification could happen at the server (assuming the client trusts it). PCC allows us to choose where to put the trust boundaries.
TREVOR: About these Princeton security flaws... are we talking about the right properties of code? We do at least have a rigorous way of talking about properties -- can we use it?
GEORGE: PCC is just a principle: "It is easier to check than to prove." These properties might be outside of today's proof-generation and -represention technology, but the framework is general.
GREG: I disagree -- those browser bugs were mostly bugs in the specification of security policies (APIs). The hardest problem is writing down what you mean by "safe." Security people wrestle with this a lot, but PCC doesn't address it at all.
Amy and Andrew, e.g., start from the assumption that "safe = memory-safe." That's the only safety that they enforce. Type-safety is just a strengthened induction hypothesis that allows them to prove this.
The real policy that people want is "safe = nothing bad will happen on my machine."
When you formulate a security policy, you set up an abstraction of the world. Attackers go around poking holes in the assumptions people make in defining these abstractions. We're good at making these abstractions precise, but this is something different.
All the PCC in the world would not have stopped Melissa unless someone had written a policy that said something about what can happen after email arrives.
ANDREW: Moreover, mobile code is not the only source of browser bugs. There are DNS problems, the OS, etc.
UNIDENTIFIED AUDIENCE MEMBER: Maybe the killer app is open source [a bunch of developers around the world, communicating by e-mail, who develop software in pieces and need the pieces to fit together].
-------------------------
ANDREW: About the last question... What must the PCC community do?
PCC is a solution looking for a problem. It must find an application area without established solutions and take it over. It must be positioned to become the ubiquitous standard in this area.
One possible area: portable devices such as cell phones and PDAs, where we are just starting to see reports of viruses. The PCC community should develop a solution, including:
Or we can just keep developing in the academic world. Indeed, this may actually be appropriate: it may be too soon for PCC to succeed in the marketplace. Look at all the other good PL ideas that have taken 20 years to enter the mainstream.
GEORGE: But PCC is more than just a technology that we want to win -- it's really an attempt to push our understanding of programs beyond the compiler. In that respect, it can be successful simply by motivating researchers to understand things better at that level. If the "window of opportunity" closes, that may be OK, as long as we understand things better as a side-benefit.
Note that the biggest complaint in the KVM community is that KVM does not support native code.
GREG: Native methods might be the killer app for PCC. Even if we can only write 80% of native methods in a safe variant of C, we'd be doing great.
A good long-term goal might be to put 80% of the linux kernel in a checked framework.
Basic technology may be much more applicable to software engineering than to security.