[can you get your MUA to wrap lines at approximately 70 characters?
Single lines of 750+ characters are a bit unwieldy]
On 2009-07-31 02:36:31 +0400, Cheney, Edward A SSG RES USAR USARC wrote:
The idea is that security vulnerabilities on the internet occur most
significantly as a result of client-side scripting from documents
transmitted across HTTP. By most significant I mean as measured by
quantity and not severity. In addition to frequent immediate
vulernabilities client-side scripting can also operate as an execution
point for other additional vulernabilities not directly associated
with client-side scripting. It is my opinion that the only way to
solve this security problem is to either break HTTP or eliminate
client-side scripting. I find there is no reason to break HTTP since
it is working perfectly well and is not to blame for this problem.
I think you mix up HTTP and client-side scripting. HTTP is only a
protocol to send and request data. Some clients interpret some data
received by HTTP as code, but that has nothing to do with the HTTP
protocol itself. The same data received via FTP, or SMTP could be
interpreted just the same.
Therefore I don't think you gain anything by using SMTP instead of HTTP
as the transport protocol.
Client-side scripting cannot be removed unless an alternative
convention is proposed.
As an alerternative method of allowing interactivity from client-side
scripting I wrote this document to migrate the concept of client-side
scripting to the email architecture. The idea is that interactivity
from client-side scripting can be replaced by transaction
interactivity. Since mail servers are intermediate agents in the
transmission, opposed to an end point like an HTTP server, they can
make processing or scripting decisions upon data without that
scripting having to exist on a client system.
What is gained by adding intermediate systems? I see only added
complexity and a potential for additional security holes here.
The idea to run the scripts on the server and let them only manipulate
the DOM of a document on the client via a well-defined protocol has some
merit. But it probably makes a lot more sense to base this protocol on
HTTP or XMPP than on SMTP. (most importantly, because HTTP and XMPP allow
communication in both directions, while SMTP is unidirectional (except
for status codes))
In other words, it is basically an inverted form of AJAX that does not
execute on the client-side. The idea is easily possible using SMTP,
but is not possible over HTTP since HTTP does not have intermediate
agents between the client and server.
I don't see what purpose the intermediate servers serve in your model.
Why are they necessary?
As a sample use case, consider a typical "autofill" search form:
The browser has just loaded an HTML (or other markup language, if you
prefer) page with a search form.
With AJAX, the HTML file contains s script which will intercept each
character the user types into the input field, send (via HTTP) a search
request to the server, and then manipulate the dom to display the search
results in a dropdown menu.
With your model, how would this be handled?
_ | Peter J. Holzer | Openmoko has already embedded
|_|_) | Sysadmin WSR | voting system.
| | | hjp(_at_)hjp(_dot_)at | Named "If you want it -- write it"
__/ | http://www.hjp.at/ | -- Ilja O. on
Description: Digital signature