Friday, December 29, 2006
I've been thinking, why aren't identities tied to the input devices rather than to the process, or “session”?
Here's the problem. At home, I often leave the computer running. In fact, I don't see any reason to log off just because I'm going to get a drink from the fridge. I have a 4 year old and a 2 year old. Turns out, the 2 year old is incredibly fast at A) identifying when a computer is on, and B) when I'm not using it. I have this fear that she'll accidentally hit “format c:“, or “Delete All“, or some such.
Wouldn't it be nice of the system said “no, you don't have permission to format C: because you are not Doug“? I think it would.
I say restrict the action, not the actee. That is, it's more important to control the avenues through which actions are taken than to control the applications which execute them.
OK, how does this work? Well, for one, we could have proximity-sensing input devices that transmitted a “user“ signal along with the input signal. The proximity sensor could detect a person wearing an RFID tag inbedded in, let's say, a watch. Yes, you could go hog-wild and have a microchip implanted but hey, let's not get crazy. The point is, it's not necessarily the application that “does“ things, but rather the input devices we use to direct the them.
 |
Friday, July 28, 2006
A friend of mine asked me recently if I knew of an elegant way to handle asynchronous calls in Internet Explorer. Basically the problem starts with some event like “load a page” then “do something” after the page is done loading. With the emergence of AJAX-style applications which exploit this asynchronous behavior quite heavily, it's interesting to have some way to write code that handles async calls. This is especially true if you want to write automated test scripts.
In any case, I sat down this morning and wrote up the following. It's only the solution. I'll let you work out how to integrate it in with a real problem:
function AsyncCall(action, condition, callback, timeout) {
action();
window.setTimeout("onTimer(" + condition + ", " + callback + ", " + timeout + ")", timeout);
}
function onTimer(condition, callback, timeout) {
if (condition()) {
callback();
}
else {
window.setTimeout("onTimer(" + condition + ", " + callback + ")", timeout);
}
}
You would then introduce a call like:
AsyncCall(setUrl, checkFrame, notifyDone, 100);
This invokes the “action“ function, then periodically checks the “condition“ function. When the condition returns true, then it calls the “callback“ function.
Here's a simple web page that lets you set the SRC property of an IFrame, then notifies you when the page is completely loaded:
<html>
<head>
<title>Async Test</title>
</head>
<script language="JScript" src="asynccall.js"></script>
<script language="JScript">
function updatePage() {
AsyncCall(setUrl, checkFrame, notifyDone, 100);
}
function setUrl() {
document.all["myFrame"].src=myForm.url.value;
}
function checkFrame() {
return document.all["myFrame"].readyState == "complete";
}
function notifyDone() {
alert("Done!");
}
</script>
<body>
<form id="myForm">
<input type="text" name="url" />
<input type="button" value="Go" onClick="updatePage()" />
</form>
<iframe id="myFrame" src="about:blank" height="100%" width="100%"></iframe>
</body>
Happy async calling!
-Doug
|
Tuesday, December 13, 2005
There’s this fantasy that applications will someday be able to identify themselves. That is, they will be able to act as a “principal”, just like you or me. This doesn't make sense.
In reality, applications are agents; agents of a real user. That is, applications (aka. code) acts because a user told it to. If this was not universally true, then someone has figured out true AI (artificial intelligence) and the landscape of computer systems as we know it is forever changed. I’ve been watching the 5 O’clock news. There haven’t been any major breakthroughs in AI lately. Until that day, software is simply an agent of a user, period.
Some people think that if only you could identify the app, then you cold hold the app-writer accountable and therefore hold harmless the user who unwittingly invoked the app.
But wait a second, how dumb could a crook be to let you know who he is? Let’s say he writes this awesome worm that completely messes with everything in your system. Is he going to sign the app as “Crook”? Is he going to place a return address on his app? “Here, I’m at 1111 Stupid Lane, come and get me!” Absolutely not! Hackers have always focused on those vulnerabilities which leave no trace back to them. That’s just common sense.
Let’s say you’re a good company, conscientious in every way. What’s the first thing you’re going to place on your license agreement? I’m no lawyer, but I expect it will read something like “XXX corporation is not responsible for any damages the user might encounter while using this software…” etc. etc. etc.
Now back to application IDs. I’m not saying that signing software isn’t a good idea. On the contrary! More and more applications are being delivered online. Signing the application manifest including a digest of all binaries is just common sense. But remember the disclaimer. The signatures are just there to enable you to 1) make an informed decision about whether the package you got came from who you thought it did and 2) that any attempt to modify the application in transit can and will be detected. You can also use the manifest to ensure that the application remains unchanged over time.
What I object to is the notion that an application can act on its own. I object to the notion that an app can authenticate to a remote party. This makes no sense. On the other hand, if the user (eg. person) wants to cough up the manifest associated with the application he’s running, that’s certainly his prerogative. In fact, a relying party may require this. However, the trust, the liability, the responsibility is on the user to ensure that A) his system is functioning within parameters, B) the application he’s running is the one he wants and C) the actions taken on his behalf by the application are ultimately his responsibility.
Won’t this mean that users will be held accountable for stuff they have no control over? No. They can always choose not to run a piece of software, not to use a computer, or to use a different operating system. In fact, because software runs under the context of the user and the user most likely has the potential to do whatever it wants with the software, this actually creates a completely new problem. What’s to prevent a malicious user from intentionally modifying the software in such a way as to damage the reputation of the software publisher, or even to hold the software publisher accountable for actions taken with that software?
In short, applications are not principals. They do not act on their own. Software publishers are not responsible for the actions taken by a user. Users must always be held accountable for the actions they take, no matter the agent. Let’s make operating systems and software that enable users to make informed decisions about which agents to invoke, and allow them to control the rights and privileges afforded to the agent. This makes sense.
|
Thursday, September 29, 2005
If you attended John Shewchuck's talk COM214 - you probably remember all sorts of things going wrong with my demo. I know this is going to sound largely apologetic, but my real intent is to highlight what not to do with a demo in front of a whole bunch of people.
Here's what I learned:
1. Don't run on beta versions of the OS unless you have to!
2. Split screen demos just don't work! Craning my neck to see what the audience was seeing, pop-up dialogs appearing on the wrong screen, and finding the mouse pointer made it all but impossible to show what was going on.
3. Have a backup machine that's booted, and ready to resume your demo!
4. If your demo involves writing code, keep snapshots of all key points along the way! See #3.
5. Tech check all machines you might use, backups included!
6. Don't share demo machines! It's tempting, especially if it's a 64-bit Ferrari; nonetheless, resist!
7. Show less, not more!
I want to thank Nigel Watling who, in a moment of brilliance and forethought, reminded me that InfoCard would only draw on the primary screen of the demo machine. Had I continued running on the backup machine, along with its split screen configuration, the InfoCard part of the demo would have been a complete flop! Imagine, me holding a laptop high over my head, and pointing “See, isn't it beautiful”?
Anyways, lessons learned...
It's taken a while, but it's finally there.
http://commnet.microsoftpdc.com/downloads.aspx
Look for COM430.zip
|