Rev player
Robert Brenstein
rjb at rz.uni-potsdam.de
Tue Jul 27 07:13:02 EDT 2004
>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
More information about the use-livecode
mailing list