Reflections - All Comments

re: Authenticated Keyboards

Doug Walter — Tue, 02 Jan 2007 04:27:00 GMT

I'm looking for a better solution. Locking the computer is, as you say, sufficient. But why should I have to? We have built-in safeguards for who we allow to touch us. That is, if you were at a hospital and another patient tried to touch your arm, you'd probably have some words. However, if your doctor did the same activity, you'd probably welcome the attention. We recognize who is doing things to us or to our surroundings. Why shouldn't the computer be equally equipped? I feel I shouldn't have to tell my computer to say no to unwanted input. It should have a way to do so automatically on my behalf. Wouldn't that be an improvement at least?

re: Authenticated Keyboards

Anon — Tue, 02 Jan 2007 03:43:00 GMT

Isnt locking the computer sufficient here?

Interesting Finds: July 28, 2006

Jason Haley — Sat, 29 Jul 2006 04:30:00 GMT

Interesting Finds: July 28, 2006

Jason Haley — Sat, 29 Jul 2006 04:27:00 GMT

re: AsyncCalls and Internet Explorer / JavaScript

Joshua Flanagan — Fri, 28 Jul 2006 21:32:00 GMT

I believe Selenium (since you mention automated testing...) has a very similar feature. Check out:
http://wiki.openqa.org/display/SEL/waitForCondition

re: Application Identity

James — Mon, 19 Dec 2005 23:26:00 GMT

Security is increased when certificates are treated as GUIDs. We need to move past the model of charging for security as this will always result in insecurity...

http://duckdown.blogspot.com/

re: Application Identity

Doug Walter — Thu, 15 Dec 2005 19:53:00 GMT

Thanks for the comments. You bring up some very good points.

I agree this is somewhat of an over-simplification.

I still hold true that software always acts on behalf of a user.

Users must be held liable for actions taken on their behalf. The burden is on the user to proove that he or she acted in good faith. I believe we need to enable users to identify faults in applications, and hold application wrtiers accountable for their negligence. This is the same in my mind as something so mundane as a car. That is, if a driver gets in an accident, it is up to the driver to prove he acted appropriately. If the driver believes that the car (aka. agent or tool) was to blame, the driver must provide evidence to support that. If the car is found to be faulty, then the burden is still on the driver to prove that the manufacturer of the car was guilty of negligence. In all these exchanges, the driver assumes liability until responsibility can be placed elsewhere.

I believe all assets, whether real or ephemeral, have an identity. In fact, anything you can identify (that is which have measurable characteristics that can uniquely distinguish the entity from others) has an identity. All software, therefore, has an identity. In fact, packages of software, also have an identity which can be established by creating a manifest of the composition of the package.

As to actions deferred in time. Imagine if we had robots which followed complex instructions from users. If the robot ended up doing something wrong, who's the first person to get blamed? Until we have systems which think for themselves, the blame of course will go to the programmer/user. Even if things happen while you're not around, if you were the instigator, then you're responsible.

As for batch jobs, I believe it's the organization that runs the service that is responsible. Take for example, if the batch processing agent, the exact same code, deployment, configuration, etc. was run by two organizations. Let's say one was run by a government recognized corporation that had been in business for several decades. The other, run by a couple of unknowns out of their basement. Remember, it's the same code. If I had the choice, of course I'd go with the more well-known company, especially if it's my finances at stake. Software itself does not define responsibility.

I know the question you posed was somewhat different. Since a batch agent is doing work on behalf of a thousand users. Which one is the agent operating under. Ultimately, it's whoever takes the fall if something goes wrong. Presumably, the agent is under contract with each of the users for which the batch agent is doing work. The items which are the agent's organization's responsibility under contract are the things under which the organization's identity should be used. Those things which are the user's responsibility are the users. In your specific example, the agent is responsible for faithfully executing transactions based on the parameters of the contracts with each user. If the transaction involves illegal transfer of funds, presumably there is some obligation on the agent itself to report to the government any activity which seems suspicious, as well the user is responsible for initiating the action. In none of these transactions is the software responsible or liable. The fact that the agent's organization has entrusted its functions to a computer, in no way relieves it of its obligations to the user under contract, or to the government(s) in whose jurisdiction these transactions are taking place.

I believe the notion of software as a principal is flawed. This applies even to the operating system and the hardware it runs on.

But then, that's just my opinion... :)

-Doug

re: Application Identity

Henk de Koning — Wed, 14 Dec 2005 21:31:00 GMT

Although I agree with you for the most part, I think you over simplified the story.

What if user actions are deferred in time. Is the program still assuming the identity of the user ? I guess so .. But what if there's more then one user ? Take an Interpay batch. That processes payments issued by thousands of people. Is it a thousand identities ? Or is its identity the bank ? Or the guy at the bank who started it ..

And what about computers. Are they identities ? They seem to think so, nowadays. But what distinguishes the program called operating system from a user application ?

In short, I think you're right. Kind of. But only for interactive on-line apps ;-).

re: PDC2005 - COM214 - What happened?

Keith Brown — Fri, 30 Sep 2005 21:37:00 GMT

7. Assume all your demos will tank, then be happily surprised when they work :-)