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 ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
