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

[Hector Santos <[e-mail]>]

Edward,

With your follow up here and with Peter, and reading more of your 
draft, I am not sure if you are, using the proverbial, "blowing 
against the wind."

If I understand the problem statement and your concerns, which is for 
the most part XHR (AJAX) and cross-domain WWW based communications, 
then I agree with you that there is a major problem here - a serious 
major problem over security and privacy concerns of users.

Lets start with the basic definition here:

   Web 1.0  - HTML only, No Javascripting.
   Web 2.0  - HTML only, Javascripting, Ajax
   Web 3.0  - Web 2.0 + Rich Graphics

The overall problem is that the industry is no longer concern with Web 
  1.0 compatibility.  In fact, Javascript is being enforce at many web 
sites. They don't bother with allowing web 1.0 users (those who choose 
to turn off javascript in their browser).

The 2nd problem is that newer browsers are not even making it an user 
option to turn off javascript. For example, Google Chrome. This 
browser is a prime example of the problems you are concern about. 
Microsoft and others is following this lead.

The 3rd problem and alternative to the 2nd issue with users's turning 
off javascript and/or the browser doesn't support cross domain 
requests, are the client-installed pluggins are bypassing these 
restrictions, i.e., Flash and SilverLight.  However, more recent 
versions are providing certificate secured solutions here for cross 
domain requests.

Overall, we are coming to a full circle in the UI - the user frontend 
is more client side driven with the browser and plug-ins.  We have 
more persistent connections with these UIs.

I guess I am trying to see how your draft proposal using SMTP will 
help here and to solve what part of the above issue?

Take for example Peter's comment for an AJAX based suggestion box.  I 
have an example here as a jQuery Plugin example:

   http://beta.winserver.com/public/test/MultiSuggestTest.wct

This does a server side call per keystroke (although my plugin is a
lot smarter using a cache and knowing not to call the server again
when the user hits backspace).

Peter's point is that the draft proposal would conflict with the
dynamics here.  The SMTP model would be too inefficient for the
high-throughput requirements of WEB 2.0+.

Now I saw your follow-up saying in principle the DOM events would be 
prohibited in your proposal.

Well, all bets are off.  That is why I think you may be blowing 
against the wind here.  WEB 2.0+ direction is too strong. The market 
is certainly caring less for Web 1.0 only support and would rather 
(because it is less costly) just spit out a message:

     Sorry, Javascript is enabled to use this site.

than spend the resources in making sure the web site works in HTML 
only mode.

Anyway, it sounds to me that this is more about having a secured,
certificate based "SAFE" proxy that people can use AJAX or
FLASH/SilverLight with.  Flash and SilverLight already offer a new 
model based on signed certificates and encryption.

Today, if a user is concern about reaching a site with hidden cross 
domain operations, they can use the browser's No Scripting options 
like newer IE and FireFoxes with the most excellent NoScript plugin.

At the end of the day, either you allow the site to run as it was 
designed if you want to be part of it, or just ignore it if you are 
concern about its cross domain behavior.   i.e, FACEBOOK - either you 
want to be part of it or you don't because it relies are strong 
interactive behavior and TONS of cross domain communications.

-- 
Sincerely

Hector Santos
http://www.santronics.com



Cheney, Edward A SSG RES USAR USARC wrote:

> Hector,
> 
> I must have not communicated the problem and objective clearly.  The security problem only exists in the realm of the WWW.  The solution to this problem, as I propose it, only exists over SMTP.  The idea is to eventually abandon use of all client-side scripting on WWW in favor of an alternate secure solution that is only capable of existing over SMTP.
> 
> I am not actually proposing to mix or merge HTTP and SMTP transaction states.  I have not thought of such an idea, and so such might be possible but I have given no thought to how that might work.  The closet to mixing protocols that I have ever thought of is to supply a URI in a markup language over email that may be either HTTP or SMTP as defined by that URI.
> 
> Thanks,
> Austin
> 
> ----- Original Message -----
> From: Hector Santos <[e-mail]>
> Date: Friday, July 31, 2009 8:30
> Subject: Re: Requesting comments on draft-cheney-safe-02.txt
> To: "Cheney, Edward A SSG RES USAR USARC" <[e-mail]>
> Cc: "J.D. Falk" <[e-mail]>, [e-mail]
> 
> 
>> Do you have examples of these HTTP-based SMTP Client Side Script?
>>
>> I presume its a HTTP POST request on port 25 (or some other known 
>> SMTP 
>> server port) with the posted request body content containing  
>> batched 
>> SMTP commands?
>>
>> Off hand, I am not sure if the security concerns are SMTP related.
>>
>> -- 
>> Hector Santos
>> http://www.santronics.com
>>
>>
>>
>> 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.  Client-side scripting cannot be removed 
>> unless an alternative convention is proposed.
>>> It is absolutely imparitive that a solution exist as the quantity 
>> of these security problems are continually increasing and there is 
>> no possible solution available from HTTP.  If a solution is not 
>> proposed the security flaws of the system will become so 
>> significant that the commerical value of financial transactions and 
>> PII leaks will eventually result in abandoning the internet as an 
>> open platform in favor of more secure proprietary technologies.
>>> 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.  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.
>>> Thanks,
>>> Austin
>>>
>>> ----- Original Message -----
>>> From: "J.D. Falk" <
>>> Date: Friday, July 31, 2009 1:44
>>> Subject: Re: Requesting comments on draft-cheney-safe-02.txt
>>> To: "Cheney, Edward A SSG RES USAR USARC" <
>>> Cc: [e-mail]
>>>
>>>
>>>> Cheney, Edward A SSG RES USAR USARC wrote:
>>>>
>>>>> I am requesting comments on the following this internet draft.  Any
>>>>> questions, confusion, feedback, or changes would be helpful.
>>>>>
>>>>> http://tools.ietf.org/id/draft-cheney-safe-02.txt
>>>> Interesting idea.  What's the use case you have in mind?  In other 
>>>> words: 
>>>> who will use it, and why?
>>>>
>>>> -- 
>>>> J.D. Falk
>>>> Return Path Inc
>>>> http://www.returnpath.net/
>>>
>>>
>>
>>
>>
>>
> 
> 
>