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.


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