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

[Hector Santos <[e-mail]>]

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