[Top] [All Lists]

Re: Requesting comments on draft-cheney-safe-02.txt

2009-08-08 22:59:45

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

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

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.


Hector Santos

<Prev in Thread] Current Thread [Next in Thread>