Protecting Things from prying eyes....

[Michael Crawford]

I recently ask the list for suggestions about the best method for
protecting images that are stored on an web server but accessed from within
Metacard. Thanks to everyone who responded. Here are a couple of follow up
notes...

Dave Cragg suggested.....

>One way would be to store the images as custom properties in a
>metacard stack (one or more images per stack).  This would stop them
>being viewed by a browser or other application. (But the image data
>could be retrieved by anyone with Metacard.)
>
>Then download the "image stack", open it invisibly, put the custom
>property that holds the image into the image object in your Metacard
>application.

I did think about doing that. What I liked about having each image seperate
(if encoded and compressed) is the fact that I can get Metacard to start
downloading the images individually and storing them in the cache. In some
cases there may be lots of pictures in some sections (may be 50 -60) other
sections will only have a few (perhaps 5 or so). Only one picture will be
shown at a time. By individually downloading each picture the app should
seem much more responsive.


Dar Scott thought....

> 1) I could either encrypt the images using some other method than
>> base64 I
>> am open to suggestions about how I could do this.
>
>Any simple method I give you would hardly be better than the
>obfuscation that you already have.
>
>If you must do more, the next step is serious encryption.
>
>One approach is to have the stack run a command line PGP
>application.  Since NAI dropped the PGP line, your choices are
>limited if this is a commercial application.  I'd consider GnuPG.
>It is available on several platforms.  It is a little rough around
>the edges but should work for your narrow need.  (If you find a
>shrink wrapped legal copy of PGP 6.5.8 command line commercial and
>don't need it, contact me.)

I did consider a better form of encryption and even started doing some
preliminary investigations into it. I concluded that while doing this would
be very interesting and very useful for me and other people (I don't think
I will be the only person interested in encryption of material for use in
Metacard :-) )It kind of turns a small project into a big one.

>Alternately, if you have control over all computers involved, turn
>on IPSec for the applicable connections.

Unfortunately the requirements of the app mean this won't be possible.
Users will need to be able to access the suff from home as well.

>> 2) I could build a better password protected site with cgi's or
>> ASP or some
>> such thing though then I have issues with server hosting etc.
>
>Same problems

What I was thinking of doing was something along the lines of....

Metacard app contacts server.
Server sends out the password for the day, hour or minute for example..."Bob"

Metacard then compares the password, "Bob" with an internal list, which
could be very long...
-- "Bob" ="Eachway"
-- "Fred" ="ies_back"
-- "Jack" ="Upped"

Metacard logs on as "Eachway" with a post type of action and gets the
images etc required.

A bit of time passes. An internall function on the server changes the
required password for access to "Jack"

So while the passwords will be visible it will takle a resonable amount of
effort to get all of the required passwords. Basically you will have to
monitor what the Metacard app is up to over a period of time. That could be
quite a considerable period of time.

Not that I am actaully going to do this. Just an idea

>> 3) I am just being to paranoid about the whole thing. If anyone get's
>> through all of the road blocks I have created perhaps I should
>> just give
>> them a chocolate fish  and a certificate and not worry about it...
>
>Simple obfuscation is appropriate in some cases and it may be in
>this case.  You have to look at the economic factors for the spy
>and use that to assess the probabilities in assessing your risk
>(prob and cost).  You also should look at other factors such as the
>cost of the stack getting bogus pictures.
>
>If these are pictures of a new product and you don't want Ford,
>Microsoft or France to see them, then you may need strong
>encryption.  On the other hand, if you don't want people to see
>your maps of NZ that you worked so hard to make unless they pay for
>it, then encryption is less important.
>
>My wild guess is that you can probably get by with even simpler
>obfuscation and then forget about it.

You are correct. I think Ken Ray's response says it all...


>> 1) I could either encrypt the images using some other method than base64 I
>> am open to suggestions about how I could do this.
>>
>> 2) I could build a better password protected site with cgi's or ASP or
>some
>> such thing though then I have issues with server hosting etc.
>>
>> 3) I am just being to paranoid about the whole thing. If anyone get's
>> through all of the road blocks I have created perhaps I should just give
>> them a chocolate fish  and a certificate and not worry about it...
>
>3.
>
>:-)
>
>Ken Ray



Thanks to all of you


Michael Crawford..