Rev player

[Robert Brenstein]

>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