Re: Requesting comments on draft-cheney-safe-02.txt
2009-08-02 11:33:46
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
|
|