Robert Brenstein wrote:
But as Kevin said, adding limited file I/O to secure modes it being worked on, so any inconvenience should be short-lived.
I read that but it sounded that this will happen some time in the future, well after player's introduction. As someone interested in its success, I am just concerned that this may come a tad late, as in spoiling the impression made by the player and thus its broad acceptance. I'd love to be wrong, though.
PS A malicious person can include an external which I don't think can be prevented from accessing disks and system.
SecureMode shuts down not just file I/O, but also shell, AppleScript, and registry access. I agree that if it doesn't currently shut down the externals API it should. Is that the case?
If it shuts down externals, then, for example, it would not be possible to access databases.
I'm not clear on what you're after, as your post raises good arguments in both directions. Are you advocating more security, less, or something altogether different?
-- Richard Gaskin Fourth World Media Corporation
Exactly that, I am raising issues. I don't have a clear enough picture of what RunRev envisions for the player in their product strategy; it will surely be the runtime environment for stacks produced in DreamCard, but I suspect that a number of people using Rev will also opt to distribute their products as stacks, like it used to be with HyperCard player. As we know from past, players are funky beasts, solving many problems but creating a number of new ones.
In terms of saving, the issue is whether implementing it can be really postponed. In terms of externals, RR must decide between full security and functionality. I'd like just to know what the sandbox is. I gather we will be able to distinguish at runtime whether we are in the player or in a standalone, and in the former case, whether secureMode is on.
Robert _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
