[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: Risks of insufficient concept design
- To: xanadu@xxxxxxxxxxxxx
- Subject: Re: Risks of insufficient concept design
- From: Howard Fram <fram@xxxxxxxxxxxxx>
- Date: Thu, 6 Jun 1996 11:27:10 -0700
- Encoding: 70 TEXT
- Reply-to: xanadu@xxxxxxxxxxxxx
- Sender: avatar@xxxxxxxxxxxxxxxxx
I'm not that familiar with RISKS, so I hope this is the proper manner in
which to respond:
In response to Andrew Pam's concern regarding SiteShield from Maximized
>What it appears to do is send an intentionally corrupted image if the
>Referer: header indicates that the page from which the image was
>referenced is not on the same site as the image itself.
>There are a number of problems with this concept, but the most glaring
>is that once the image has been displayed on the screen it can easily
>be captured and saved to a file, thus completely defeating the entire
>purpose of the product.
>THE RISKS? Well, apart from the obvious risk that the product may
>well fail since it can be so easily defeated, it probably also won't
>work with older browsers that don't return the Referer: header and
>is known to have problems (as you would expect) with caches.
I think Mr. Pam did not understand the product fully and has unfairly
represented the features of SiteShield. However, we are making an effort
to improve the quality of the information on our site, so perhaps that was
the source of the confusion.
The product contains three parts: content protection, reference
protection, and content selection, only one of which was mentioned above.
Each of these parts work together to provide a better solution for image
protection and together address exactly the risks that Mr. Pam expresses.
*Content (image) Protection*: the webmaster, choosing one of either two
methods, can indicate images to be "transformed" on-the-fly before being
sent to the browser. These images can still be viewed in the browser, but
if saved, won't be re-usable unless they are "untransformed".
This, of course, steps into the area of copyright issues. However, it is
our contention, that while previously one could have stolen the image via a
simple right-click and save, this method forces a person to make a
*conscious* effort to steal the image. No longer can innocence be claimed,
should organizations choose to pursue pirates. Admittedly, risks may still
exist here, although we are examining methods to improve security.
*Reference Protection*: all outside of domain references to content are
completely blocked and the content is not served, not as indicated above
(...appears to do is send an intentionally corrupted image...). There is
no risk here since the content will not be served.
This feature works in conjunction with image protection to provide two
parts of a wall that a site may put in place. We don't claim 100% complete
protection, but by placing these two features on a site, an organization
can claim that they are at least making a good faith effort to protect
their content. Previous to this, no such claim could be made.
*Content Selection*: in reference to the risks involved with older
browsers, we've taken that into account with the content selection module.
This module allows webmasters to provide the most appropriate page for a
browser (Netscape, MSoft, others). Since the protection methods work with
later browsers, webmasters can choose to send different pages to older
browsers, perhaps ones that contain images about which they are not
concerned. Again, the risks here at reduced if not eliminated, certainly if
a webmaster makes a concerted effort.
Any thoughts or concerns are welcome to be sent to info@xxxxxxxxxxxxxx