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

[Hector Santos <[e-mail]>]

Cheney, Edward A SSG RES USAR USARC wrote:

>> 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.
> 
> Demeaning the user is not a technology solution.
> 

Unfortunately, ethical engineering considerations are no longer taught 
  to these "kids,"  too expensive, it hurts the brain! and is 
prohibitive these days.  The modus operandi is to DO IT first, and see 
where the chips fall. Any corrections would be an after thought.  Of 
course, by then it may be too late.  Triage and Pareto's Principles apply.

Since this in the SMTP forum, FaceBook, for example, is one of the 
entities that believes all MAIL is own by them and can be used to 
extracting information about both parties. So does Google and yahoo, 
but FaceBook has raised and highlighted the issue of recent by 
questioning any the idea of user email privacy. This is an issue that 
was a TABOO for nearly three decades by many who understand why it is 
an ethical issue.  Regardless of what you and I think, its being leverage.

Anyway, my engineering assessment regarding SAFE:

I think your intent is good, but I don't see how SMTP will help. You 
are extracting one good part of it (AUTH/TLS) but the rest of it is bad.

Even then, IMV, even if it is considered that an alternative should be 
considered, it would be a major revamp and thus SHOULD open the door 
to a newer more efficient protocol. One where the state machine would 
be much simpler.   Maybe something like SIP or XMPP or SOAP.

Both Microsoft and Adobe have newer client-side plug-ins that now 
offer  signed certificate authentication/authorization methods with 
their client-side "far calls."   So I don't think your draft will 
replace this part since it duplicates this resolution.

For AJAX, the SAFE consideration would produce scalability and 
performance issues.  I envision many timeout design issues.

DOM interactions is already an expensive operation.  SAFE would had a 
significant overhead to it.

SAFE restricting DOM events would be a major show stopper. Probably 
the single thing that would stop people from further consideration 
(include me, and I'm sure others).

The direction is MORE client side plug-ins, NOT LESS. Flash, 
SilverLight, APEX, Google Apps, Firefox Plug-ins are prime examples.

Here is our strategy which is a overview of the popular methods and 
how we intend to integrate it with our existing client side 
communications framework:

    http://www.winserver.com/public/vimg.wct?src=wcrpcnet7.png

There are quite a few client/server communication wirings. I don't see 
how we can use SMTP in the wiring here.  The REST method seems to be 
winning. Not the most optimal, less secured, but the easiest and it 
offers WEB 1.0 compatibility aspects, for example, it allows older web 
sites to offer "web services" per se.

Here is how I think you may get some interest:

Introduce SAFE as a new PROXY or protocol that would be more of a plug 
and play solution.  Make it a black box so that the interface (I/O 
prototype) points are the same.  The SAFE-BASE protocol only describes 
the I/O interface and leave the actual blackbox to SAFE plug-in 
developers.

If you can work that out, then the internal mechanism (SAFE plug-ins) 
would be left open for wide development.  One implementator can use a 
SAFE SMTP plug-in and another can invent another SAFE plug-in.

This would allow for example, a SAFE FireFox Plug-in for DOM to be 
written.

-- 
Hector Santos, CTO
http://www.santronics.com