Hector,
Before I begin I want to say any remarks or opinions towards or about
commercial media plugin software is entirely personal and hypothetical.
Issues associated with such software, even issues of a security nature,
are issues respective of a markup language, or other containing feature.
The impacts and concerns of such software is not related to or relevant
to the SAFE method until communication from such software perform in a
manner that violates the privacy inherently presumed of email. At such
a point such concerns become a matter of civil liability associated with
unsatisfactory disclosure of private communications.
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? If so, I am
not aware of any such research, and generally security vulnerabilities
tend to dramatically increase during down economies.
All of these players (including Apple, Google, AT&T, ComCast and so
on) have a major strategy to add MORE background communications in
their designs to "network" users and also build their BI for added
value services (direct marketing, social networking).
We must remember media plugins of the type you list are created entirely
for the web. The web is inherently public as a medium of communication
while email is inherently private. This alone would present some minor
alterations to product strategy and deployment for such software in
order negate civil suits regarding breaches of privacy in email, where
such privacy concerns are significantly diminished on the web.
The extremely positive thing about proprietary media plugins is that
they are managed commercial software. This means the owner of such
software is responsible for owning maintenance upon the software, which
includes security patches. While this does nothing to protect a user
from zero-day exploits, it does however provide a means by which a
security resolution to a specific application flaw that is rapidly
produced and distributed. Because the owner of the proprietary software
is potentially liable for harms inflicted by their software, where those
harms not an expectation of user interaction or execution, dire
commercial motive exists to ensure the software vendors resolve
publicized vulnerabilities as rapidly as possible.
I know of only of WMP and Flash having domain whitelist for cross
domains xtalk.
Since email is inherently private the content of a media plugin MUST
never communicate to a third party, even if that third party is the
software vendor owning the plugin. Since email is inherently private
both parties must consent to the release of communications to the public
realm before such release deemed appropriate for automated
consideration. It is potentially possible there could be some legal
remedies to prematurely escape the requirement of dual publication
authorization, but I will presume from a standards perspective that such
remedies do not and may not ever exist.
I, however, do not have a problem with media plugin software beaconing
out to its owner when that communication is entirely content independent
and does not report any information that can be regarded as private or
publicly identifiable information. If a plugin software wishes to
report anonymous usage statistics to its owner such communication MUST
be communicated to the end user and agreed upon by that end user prior
to installation. The plugin software MUST communicate, to the user, all
domains it will communicate to prior to installation.
Do you realize we have a 15 year old that is among the decision
makers in how FireFox and Javascript is evolving?
Since Firefox is a proprietary software. By proprietary software I mean
that it is owned by even if it is licensed as open source. Owners are
free to make what ever strategy decisions they wish upon their software
products. Owners of software, even if that software is open source, are
still liable for harms and exploitations that occur as a result of that
software. In other words there is nothing to prevent Mozilla from being
named in a law suit than Microsoft for product violations or
irresponsible executive decisions.
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.
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. The simple answer is to simply turn off all JavaScript,
ActiveX, and so forth from all versions of all browsers permanently.
That is an impossible decision for the web completely reliate upon
client-side scripting. An alternative must exist before reliance upon
client-side scripting from the web can be scaled back or eliminated.
The SAFE Scripting Method is an attempt to provide a degree of
interaction and processing to communications before that communication
is received by its intended destination and without that interaction
executing at a user-agent.
In my opinion people, generally, do not take security seriously. Asking
people to turn off client-side scripting on their own accord is not
acceptable since the end user cannot be expected to be aware of the
impacts of technology decisions. The software vendors are not willing
to reduce or exclude client-side scripting in any manner significant
enough to even reduce the accelerating growth rate of associated
vulnerabilities, because the value of market share is limited to a few
software vendors even if the negative impacts associated with that
software are a cost burden to us all.
As far as I am aware nobody else has presented an interactive solution
to the harms of client-side scripting and nobody else has presented a
non-proprietary alternative. That does not mean my attempt at such an
alternative is without points of disagreement or limitation, but it is
substantially more secure than anything else so far proposed. Since
this is the only suggestion to cure, opposed to mitigate, the problem it
is worthy of consideration unless its proposed technology is flawed or
ineffective to its intended objective.
- Some authorization protocol using SMTP (i think), that
is coupled with,
- Prohibition of existing Interactive methods, i.e. DOM
events.
I don't see how the two is related or why DOM events can no longer be
used.
The second point that you mentioned is the solution to the problem. The
first point is an alternative to the elimination of concept represented
by the second point. A standard is only retains value if it is adhered
to by its concerned parties. My fear in allowing execution of events at
the user-agent is that you are only the smallest step away from allowing
all forms of execution. I believe that if a hard and fast limitation is
not set that first users and then software vendors will make every
possible attempt to allow as much interactivity as possible locally with
exception to constraints upon transmission. At that point the standard
has absolutely no value and Email because just as vulnerable, if not
more, than the web. At this moment email is pristine and pure from many
of the problems associated with the web, and I don't want to be the one
violate that sanctity.
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. 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. There
are other single clients that carry almost as much market clout as well.
If only a very small few of such parties can be convinced to adopt this
methodology the path for adoption is set with a potential for adoption
growth.
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.
Thank you,
Austin