www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - safe

reply sclytrack <sclytrack safe.com> writes:
How safe is "safe D" to run on your computer as if it is a client application.

Let's say you want something like this.

1) The source is compared to the local one on the current disk. If the remote
version
is newer the new version is downloaded.

2) The source gets compiled and then executed in safe D but with only a subset
of phobos that can not alter anything permanent on the disk. (as if it is
a javascript client application).

Like a replacement for HTML5 and javascript.

...or not suitable?

I'm going to eat now.
Jun 13 2011
next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
sclytrack Wrote:

 
 How safe is "safe D" to run on your computer as if it is a client application.
 
 Let's say you want something like this.
 
 1) The source is compared to the local one on the current disk. If the remote
 version
 is newer the new version is downloaded.
 
 2) The source gets compiled and then executed in safe D but with only a subset
 of phobos that can not alter anything permanent on the disk. (as if it is
 a javascript client application).
 
 Like a replacement for HTML5 and javascript.
 
 ...or not suitable?
 
 I'm going to eat now.

SafeD is about memory corruption and not security. You'd have to provide your own system security through a framework and system administration.
Jun 13 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-06-13 08:02, sclytrack wrote:
 How safe is "safe D" to run on your computer as if it is a client
 application.
 
 Let's say you want something like this.
 
 1) The source is compared to the local one on the current disk. If the
 remote version
 is newer the new version is downloaded.
 
 2) The source gets compiled and then executed in safe D but with only a
 subset of phobos that can not alter anything permanent on the disk. (as if
 it is a javascript client application).
 
 Like a replacement for HTML5 and javascript.
 
 ...or not suitable?
 
 I'm going to eat now.

???? D is a systems language. You can do pretty much anything with it. SafeD is a subset of D which restricts certain types of operatons which are not necessarily memory safe, thereby avoiding certain types of bugs. When it says safe, it means _memory_ safe, and that's it. It doesn't really say much about what you can or can't do with the language. Sure, it's probably impossible to make a kernel with just SafeD, but D is not sitting in a sandbox like a web browser. It can do whatever it gets told to do. If anything, D is intended to be a replacement for C++, not HTML5 and javascript. It's a _systems_ language. - Jonathan M Davis
Jun 13 2011
prev sibling next sibling parent reply bearophile < bearophileHUGS lycos.com> writes:
sclytrack:

 How safe is "safe D" to run on your computer as if it is a client application.

Walter (I think) has decided to call it "Safe D", but a better name is "memory safe D" because it describes better that it gives only a specialized kind of safety. Bye, bearophile
Jun 13 2011
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On 2011-06-13 09:57, bearophile wrote:
 sclytrack:
 How safe is "safe D" to run on your computer as if it is a client
 application.

Walter (I think) has decided to call it "Safe D", but a better name is "memory safe D" because it describes better that it gives only a specialized kind of safety.

_All_ safety is "only" a specialized kind of safety. It would be impossible to use the word safe in all of its contexts in a computer language. For instance, you could write a virus in D, and _that_ could certainly be considered unsafe. - Jonathan M Davis
Jun 13 2011
parent sclytrack <sclytrack constraint.com> writes:
Can't we have safety as in a restricted API or subset of a language
that can only do a limited amount of things that any user feels
confident executing, like only import from std.client and nothing
else is allowed. Memory safe D is already a restricted D.

----------------------------------------------

import std.client;


extern (C) routineIamNotSupposedToUse();   //eek


void handleButton1Click(   )
{
  downloadCompileAndExecute("http;//blabla.com/internetclientapplication.d");
  //Let's say D internet client application (DICA) consist of one .d file for
  //the sake of simplicity and speed.
}


void handleButton2Click(   )
{
  routineIamNotSupposedToUse(); //eek
  downloadCompileAndExecute("http://blabla.com/addressbook/page3.d");
}


----------------------------------------




== Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article
 On 2011-06-13 09:57, bearophile wrote:
 sclytrack:
 How safe is "safe D" to run on your computer as if it is a client
 application.

Walter (I think) has decided to call it "Safe D", but a better name is "memory safe D" because it describes better that it gives only a specialized kind of safety.

use the word safe in all of its contexts in a computer language. For instance, you could write a virus in D, and _that_ could certainly be considered unsafe. - Jonathan M Davis

Jun 16 2011
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
sclytrack wrote:
 Like a replacement for HTML5 and javascript.

You *could* make this work, but the language itself won't help you. There's two approaches: a) Run the code on your server and only output the display on the client's computer. Like an X11 application. http://en.wikipedia.org/wiki/X11 b) Have the operating system limit the D application. It's not really possible to filter out malicious D code. Someone could always call an operating system function directly, even marking it trusted so it works in safe mode. But, if you configure the operating system the right way, you can make all those potentially nasty calls unavailable. Put an operating system level limit on file access, put up a network firewall, limit it's CPU time, etc. Most the newer HTML web browsers are doing this in addition to javascript. The same principles can be used on almost any program.
Jun 13 2011
parent reply filgood <filgood somewhere.net> writes:
Hi Adam,

Were you in the past not working on a Gui lib that did an a) type of thing?

IFAIR, The app ran on the server, the gui was on the client. Someone 
could (via a client) connect to the app on the server, but have it 
displayed locally?

~ filgood


On 13/06/2011 18:15, Adam D. Ruppe wrote:
 sclytrack wrote:
 Like a replacement for HTML5 and javascript.

You *could* make this work, but the language itself won't help you. There's two approaches: a) Run the code on your server and only output the display on the client's computer. Like an X11 application. http://en.wikipedia.org/wiki/X11 b) Have the operating system limit the D application. It's not really possible to filter out malicious D code. Someone could always call an operating system function directly, even marking it trusted so it works in safe mode. But, if you configure the operating system the right way, you can make all those potentially nasty calls unavailable. Put an operating system level limit on file access, put up a network firewall, limit it's CPU time, etc. Most the newer HTML web browsers are doing this in addition to javascript. The same principles can be used on almost any program.

Jun 13 2011
next sibling parent Adam Ruppe <destructionator gmail.com> writes:
 Were you in the past not working on a Gui lib that did an a) type of
 thing?

Yes. It's still something I'm very slowly working on, but with my web app based day job taking up so much time it hasn't had any new code for months now... But yeah, it'd run on a server and you display it locally. You can also disconnect and reconnect to the application from another computer without needing to restart the app. The same api is also usable for a local desktop app or as a javascript web app. I've written a little bit for each part of it, but haven't actually *finished* any of it...
Jun 13 2011
prev sibling parent sclytrack <sclytrack salt.com> writes:
== Quote from filgood (filgood somewhere.net)'s article
 Hi Adam,
 Were you in the past not working on a Gui lib that did an a) type of thing?
 IFAIR, The app ran on the server, the gui was on the client. Someone
 could (via a client) connect to the app on the server, but have it
 displayed locally?

There is the gdk broadway backend. Applications run on the server. The result is displayed in the browser http://blogs.gnome.org/alexl/ You can even display a browser in a browser. -------------------------------------------------------- For running the javascript apps on the client side there is qooxdoo. Communicates with the server with mostly JSON RPC with the "same source policy" (I've wasted a lot of time on that one) http://qooxdoo.org/ -------------------------------------------------------- And for running binaries on the client side with some form of shielding there is Google native client. http://labs.qt.nokia.com/2010/06/25/qt-for-google-native-client-preview/
 ~ filgood
 On 13/06/2011 18:15, Adam D. Ruppe wrote:
 sclytrack wrote:
 Like a replacement for HTML5 and javascript.

You *could* make this work, but the language itself won't help you. There's two approaches: a) Run the code on your server and only output the display on the client's computer. Like an X11 application. http://en.wikipedia.org/wiki/X11 b) Have the operating system limit the D application. It's not really possible to filter out malicious D code. Someone could always call an operating system function directly, even marking it trusted so it works in safe mode. But, if you configure the operating system the right way, you can make all those potentially nasty calls unavailable. Put an operating system level limit on file access, put up a network firewall, limit it's CPU time, etc. Most the newer HTML web browsers are doing this in addition to javascript. The same principles can be used on almost any program.


Jun 13 2011