Hector,
Honestly I have been confused with your usage of the term "email."
When I use the term email I am describing SMTP protocol reliant data
intended for consumption by humans that has an end point at a
destination specified by an email address.
Since this proposition is inherently SMTP focused I do not see how it
could be applied to a radically different protocol, such as HTTP.
You honestly think the javascript 'prototype" API authors are going to
get an act of conscious and ponder "You know, what I am doing is bad?"
or the implementators are going to forgot using these methods?
No, I don't, which is all the more motivation to adopt this proposition.
From a security perspective the web is a failure. That should be more
reason, and not less reason, to support this attempt at providing a
secure alternative. Please read these white papers to see how much of a
failure it is and why an alternative to client-side scripting is the
only acceptable solution:
Symantec Internet Security Threat Report - Trends 2008
http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_internet_security_threat_report_xiv_04-2009.en-us.pdf
Symantec - Web Based Attacks
http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_web_based_attacks_03-2009.en-us.pdf
In considertaion for how Symantec describes the method and deployment of
malware infections unto user's computers from legitimate websites it is
evident there is no secure form of client-side scripting if the
legitimate website cannot be trusted.
We are a CCR contractor (and the feds use we what we have, its
flexible) and in the past, was a military (sub) contractor and yuo kow
what is done for the feds can be much different (requirements) than
what was done for commercialization. Apples and Oranges really.
The disparity here is in the cost of alteration versus the quantity of
deployment. Costs to provide disparite systems to the government vary
significantly with regards to total quantity of the products produced by
the vender in ratio to the total commerical products. For something as
minor as an enhanced security footprint in Microsoft Windows' registry
versus the number of licenses sold to the military it might be cheaper
for Microsoft to make the change universal than to provide an alternate
form of product licensing for such a significant number of licenses.
For a subcontract that produces cutting edge materials in the assembly
of a Navy submarine's nuclear reactor the model of business would vary
drastically, because of the uniquness of the product and the scarce
quantity of total products produced.
I'm just giving my opinion - prohibiting DOM events is a major show
stopper.
The current state of security failure on the web is a bigger show
stopper. After reading the mentioned whitepapers about how easy it is
to steal bank account information from the user, not the bank, accessing
a legitamite bank website I cannot possibly see how executive of events
bears a greater commercial value to either business of the end user. In
2008 the average cost per breach incident in the US was $6.7 million
with an additional $4.6 million in lost revenue. So a single breach
incident on a legitimate commerical website that intends to active code
on a user machine costs the business $11.3 million. How much more than
that can event execution possibly be worth to a business?
People won't bother to read past the abstract or the first
few pages (Why Bother?).
Because the web is a security failure and security is expensive. The
internet is not free and there is a cost to doing business. How
expesive must that cost become before failure results?
But the trend is more WEB 2.0+ and you are seeing sites that won't a)
function and display a notice or b) don't care to explain why its not
working.
That is only partially true. It is true that many websites, including
my primary employer Travelocity, is entirely reliance upon client-side
scripting. To email however client-side scripting has never been
considered and does not exist. People will not miss what they never
had. By implementing this proposal a foundation exists by which online
applications exist in an entirely different model than previously
conceived. Since this is a new face to online applications there will
be new and completely different expectations of what an application
should be and should not be. This difference will influence the
characteristics of development in a fashion that does not miss
client-side scripting if it is never a capability in the first place.
That will provide a point of transition for business migrate from
existing methods towards something like interactive email.
Using parato's principle, 80% of the user market, today, won't have a
clue about any of this.
At this moment I am not concerned about the understandability of the
current market. I am only concerned with the understandability of
persons reading the ietf-smtp mailing list. If this can become an RFC
it will bear the credibility that will encourage people to understand
this proposition.
I said that because you are seeing very popular sites not function at
all without javascript.
I am also seeing a rising problem that limits or prevents business. A
problem that has no other solution. It is more important to a business
that they continue to sell products online than requiring those sells
come from a website that is easily open to compromise.
I doubt they are going to alter their strategy for SAFE "Prohibitive
NO-DOM Policy Mandates."
They will be economically motivated if they cannot otherwise not afford
to continue doing business on the web.
So nothing else matters.
The cost of doing business and the cost providing the internet as a
service are all that matter in this case. If the web fails then
internet standards fail, because this is a technology problem and not a
problem of carelessness.
But considering SMTP, I think overall, what you are asking would be
including a "major revamp"
In hardware and bandwidth, yes. In protocol support no. This
proposition is an entirely unobtrusive plugin to the SMTP protocol. It
requires the use of a markup language, which is only a user-agent and
not a protocol concern. If a markup language for email is not present
then SAFE is completely ignored. As far a SMTP server the new software
enhancements would operate much like how PHP operates with Apache.
Apache does not care that PHP is installed. Likewise SMTP services
direct and respond to traffic completely without care that something
else on the same box is modifing that traffic. As a result SAFE would
not impact SMTP server services. A bigger impact to those SMTP services
would result in adapting the requirements of a markup language header
that would very likely compete with or obsolete RFC 5322 header
definitions.
In short, SMTP is not an optimal prootocol for this need.
SMTP is the ideal protocol for this need. It is robust, bidirectional,
universally supported, and perhaps the most adopted communications
medium in all history. SMTP has sufficient capabilities to exceed the
requests of this proposal.
Maybe I say that because I can not AVOID the idea the DOM is
prohibitive.
This proposal actively supports manipulation of the DOM at the
user-agent and even provides new capabilities to accomplish such. It
only prevents execution of programmatic decisions from within a
communication or referenced by a communication.
Just out of curiousity how much is event oriented execution worth to
you? Is it worth $11.3 million US per breach indicident? Perhaps that
is an acceptable cost of doing business, but if so how would you account
for those loses? Would you raise prices on the end user, liquify the
value of your product, or simply take a smaller pay check? Each of
those sound horribly more distateful than considering a newer and
fresher way of doing business.
Thanks,
Austin