[OT] Flash wants standalones

[Richard Gaskin]

Chipp Walters wrote:

> I've been involved in this "time has come" discussion on this list
> before...and it always seems to boil down to a security issue. As I'm sure
> you know, there are huge security holes in the current RevNet (not that any
> of us would take advantage of) which need be addressed before launching a
> standalone player. Of course, if you (like I do with ButtonGadget) control
> all the source stacks, you shouldn't have any problems, but if you want to
> create a ubiquitous player -- there are some major considerations.

The "security holes" in RevNet -- or any Rev-based app -- are no more or
less serious than with any other executable file, as addressed in the
NetApps article.  Whether an application is downloaded from a browser or
Revolution, neither the browser nor Rev control its behavior.

If these same security exposures are not present in the new Macromedia
initiative or in Konfabulator, the usefulness of such systems is potentially
quite hampered.  How often would you use Word if you had to store your data
remotely?  And would you feel safer doing so?

Download.com delivers thousands of executable files daily for years.  To the
best of my knowledge there have been no widespread abuses from Trojan
horses, etc., and zero lawsuits.  If a file is identified as a problem it is
removed and complaints go to the developer of the offending wares.

With GNUtella, Hotline, and other P2P file-sharing systems the risks are
potentially greater and with almost zero accountability, yet traffic in
executables on those systems only grows larger month after month.

Meanwhile, the biggest headlines in security news have been with so-called
"secure" systems like mail and Web servers.

So while I don't want to give the impression I have a "What, me worry?"
opinion of security issues, I think we'd all agree there seem to be two very
different sets of expectations for security of things inside and outside of
the Web browser.

Java, Flash, and JavaScript have raised expectations for security of
browser-based apps at least as effectively as they have lowered expectations
for efficiency and usability. ;)

But for reasons I can't explain, I see that no such concerns have slowed
interest in using the same HTTP to deliver desktop apps.  I'd wager that in
the time it took you to read this a few thousand executable files have been
downloaded across the Web with narry a concern that it will eat their
registry or overwrite critical files.  These apps could do so, of course,
just as we could with Rev.  But they don't, at least frequently enough to
earn a broad sense of trust in the practice, however mislaid it may be.

Thus far only one issue specific to RevNet has been cited as a potential
threat, "spoofing" (editing a file entry so it appears to be something else
or from someone other than the name used in the submission form).  This
issue was addressed shortly after the initial release with the addition of a
password to the submission form.

Aside from spoofing, all other potential risks cited to date are shared by
all downloaded desktop apps.  If any specific to RevNet are reported I'll
address them as quickly as I added the submission password, but the biggest
risks are things any app can do regardless of whether its URL is clicked in
RevNet or a browser.

With enhancements to the secureMode property we could restrict file I/O to a
specific folder, but I can think of no way to restrict the nearly infinite
range of application behaviors without compromising valuable functionality.

Even with limited file I/O, if you allow access to launch, shell(), the
registry, or AppleScript you're still exposing the system to potentially
devastating actions.  Yet if we remove all sources of potential risk, what's
left that's worth working with? It would seem simpler to just deliver a
stack as a standalone than cut it down it for distribution with a restricted
RevNet (and you'd probably have at least as many downloads).

So while I'm interested in exploring ways to enhance the engine, I see no
reason to slow development of interesting systems in the meantime.  I may
add a disclaimer that requires a one-time confirmation for my own protection
(I live in California <g>), but I have reservations about limiting the range
of possibilities beyond that.

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 Developer of WebMerge 2.2: Publish any database on any site
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc