Rev player

[Robert Brenstein]

>Robert Brenstein wrote:
>>>Any changes to the behavior of secureMode must be done in the 
>>>engine. If they are handled in script then a script can change the 
>>>behavior, leaving the door open to hackers.
>>>
>>>An engine-level solution has been bandied about in Bugzilla:
>>><http://www.runrev.com/revolution/developers/bugdatabase/show_bug.cgi?id=867>
>>>Until such a change is made at the engine level, I agree with 
>>>Kevin's position of erring on the side of safety.
>>
>>While I agree with Richard, I am also somewhat concerned that this 
>>omission may become sour grapes for the player. Capability to save 
>>is so fundamental to operation of most programs that it is very 
>>likely the first thing any player user will do (will have to do) is 
>>to disable secure mode. That may thus become a support issue (why 
>>my data is not saved?) aside from making the secureMode sort of 
>>useless.
>
>But at that point it's the user's decision.  You can decide to turn 
>off your Windows firewall too, if you want your machine hijacked for 
>spamming in under 15 minutes. ;)

What I was meant is that user will likely be forced to do so because 
using many stacks will be pointless without capability to save. And 
we can't expect out users to be savvy and persistent in toggling that 
setting depending on which stack they want to use. The nature of 
player should be that it works quietly in the background.

>When the user decides to turn off secureMode, they are assuming the 
>same level of risk that they would downloading any executable from 
>Download.com, VersionTracker, etc. (and arguably less risk than 
>normal usage of any Microsoft operating system).

Well, these are wrong comparisons IMO. Firewall is a different 
category and downloading stacks is parallel to downloading other 
software. I don't see Metrowerks trying to impose i/o protection in 
CodeWarrior, although I gather the inspiration for player's security 
comes from Java Runtimes.

>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.

Robert Brenstein