[Top] [All Lists]

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:

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

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