[Vm-dev] Request: VM support for opening browser
Camillo Bruni
camillobruni at gmail.com
Fri Jul 20 14:00:15 UTC 2012
On 2012-07-20, at 15:40, Torsten Bergmann wrote:
>
> Esteban wrote
>>> Well... I also disagree with the argument of safeness.
>>
>> Exactly, Pharo is inherently "unsafe" so to speak, you can
>> - remove arbitrary methods
>> - add arbitrary new classes
>> - change methods at will
>> - swap any two objects...
>
> We dont talk about the safeness of the image here!
> Its always easy to compromise an image with #become: and
> friends. This is clear as spring water.
>
> We talk about how "unsafe" is it to allow Smalltalk
> to harm the external platform.
>
> There are two point of views:
>
> 1. One can include FFI or other mechanisms in image/VM by
> default and allow external calling right from Smalltalk.
> I think this is the way we go for Pharo to align
> with .NET, Java and friends.
>
> 2. Others my see the virtual machine as a clear separator
> between the image and the platform.
> The VM defines the protocol/contract between the image
> and the underlying platform to make sure they work
> together seamlessly
>
> Both are valid POV's. The first option can be seen as more "unsafe"
> since you can not control (from VM side) what gets called in
> the outside platform.
>
> With option 2 the virtual machine has more control for instance
> when running in a sandbox (browser, the cloud, ...)
>
> Take netstyle.ch for example: they modified the virtual machine
> to be more restrictive (only run on specific sockets, writing
> only to relative directories) so they could run images in
> sandboxed environment on "http://seasidehosting.st".
Well you can always run it in a virtualization environment
and then you have completely shielded of the image
> So will we discuss "unsafety" or "will we support URL opening
> directly from the VM" ...
most probably we will add it, but not as a plugin
> If it is too much work then forget my request. One can circumvent
> it using ConfigurationOfExternalBrowser. But I thought it may
> be helpfull to more controlled/restricted (Option 2) environments
> too.
>
> Bye
> T.
>
>
More information about the Vm-dev
mailing list