Cheney, Edward A SSG RES USAR USARC wrote:
But what about market forces?
You must be more specific. Are you suggesting negative impacts to a
commercial market will drive users to take more efforts to protect
themselves from vulnerabilities associated with technology?
No, the opposite, the vendors are hiding the options (to disable) and
are managing it themselves. Only the savy is capable of understanding
what is possible.
Do you realize we have a 15 year old that is among the decision
makers in how FireFox and Javascript is evolving?
By the way, JQuery founder and developer lead, John Resig, is 25.
JQuery is a framework of JavaScript, and so it must be considered no
less flawed than JavaScript from a security and deployment
consideration.
My keyboad is flawed (not use to my new keyboard). :-)
What I have trouble seeing is how SMTP will help.
The objective is to remove client-side scripting from a client-side
user-agent regardless of that user-agent being associated with email or
the web.
Honestly I have been confused with your usage of the term "email."
Are you concern with WEB-based EMAIL applications? Or in general web
activity?
In my opinion people, generally, do not take security seriously.
Today's generation don't even know they are suppose to.
You are not going to stop DOM events, or even get people to consider
not using it. So if that is a major part of SAFE, you already have a
major road block in getting people interested in SAFE.
I disagree.
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?
Microsoft just officially recently announced jQuery as a supported
product for their .NET framework for client side "aura" enhancements.
From solely a business perspective security mitigation is
expensive. I believe if an alternative to such problems does exist that
there would be support for adoption from large organizations to curtail
security associated expenditures. Large volume organizations direct the
strategic course of software development more any other single markup
force. One of my employers is the United States military, which is one
of the largest employers on the planet. I have seen how all sizes of
software vendors have completely revised altered their product
strategies to prevent loss of contracts from this single client.
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.
I'm just giving my opinion - prohibiting DOM events is a major show
stopper. People won't bother to read past the abstract or the first
few pages (Why Bother?). Now that doesn't mean that some vendors are
still considerate of WEB 1.0 and will offer product that work outside
of javascript. 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.
Using parato's principle, 80% of the user market, today, won't have a
clue about any of this. I said that because you are seeing very
popular sites not function at all without javascript. I doubt they
are going to alter their strategy for SAFE "Prohibitive NO-DOM Policy
Mandates."
Never mind the technical issues related to a SMTP callback system
especially one that will be based on HTTP huge redundancy in HTTP
requests.
I did not understand this final statement. Could you please clarify
this for me? The SAFE model is based solely upon SMTP and references no
features of HTTP.
Like I said, prohibiting DOM events is a show stopper for your SAFE
proposal - for me, and I 100% believe others who's survival and/or
product offering is based on DOM, will agreed. So nothing else matters.
But considering SMTP, I think overall, what you are asking would be
including a "major revamp" - lots of software changes, so therefore
whenever there is big changes it opens the door to evaluating a better
solution - like a optimized client/server handshaking protocol
specifically for this purpose. In short, SMTP is not an optimal
prootocol for this need. Maybe I say that because I can not AVOID the
idea the DOM is prohibitive. This all sort of reminds me of the
differences between (batch) job thinkers versus dynamic asynchrous UI
thinkers - the latter is prevailing and can not be avoided.
--
Sincerely
Hector Santos
http://www.santronics.com