Web-Dedicated Metacard

Chipp Walters chipp at chipp.com
Tue Dec 24 01:45:01 EST 2002


Richard,

> Indeed, in the absence of a browser plug-in for Rev, everything
> that can be
> done in Rev must take place outside of a browser.

Good point.

> With all of its security technology, when it comes to downloading EXEs the
> browser still relies on the oldest mechanism available: individual
> judgement.  Before starting such a download, the browser presents a dialog
> that asks, in effect, "Do you trust the owner of this domain?"

I agree.


> And while we roll out systems based on HTTP-transferred stack files, we
> should continue to explore solutions for both categories of security
> concerns:
>
> - Client-side protection ("Can the downloaded file damage my system?")

I agree as well

>
> - Transmission protection ("Can my communications over TCP be intercepted
> and read by others?")

This one is more difficult. A simple base64encode function helps, but what
we really need is some sort of encryption for RR/MC. Again, not a trivial
task;-)

The issue of client-side protection is an interesting one. In my case, I've
decided when downloading a stack over the internet to:

1) password protect both the stack and the application source code
2) lock messages when downloading
3) check for a correct password of the downloaded stack
4) check another obscure ID (like a property set, or byte length of an img)
just in case someone hacked the property. This obscure ID can also be hashed
in some manner (you may suggest md5digest?)

Of course this wouldn't work for a generic player, but does *seem* to do the
trick for proprietary solutions.

-Chipp




More information about the metacard mailing list