April 24, 2010
Fri, 23 Apr 2010 23:26:18 -0400, Nick Sabalausky wrote:

> And even if
> you really did need client-scripting (and the vast majority of the time,
> you don't), there are better ways to distribute cross-platform code
> across a network.

Really, such as? The largest problem by far has been to increase the global user base of these better technologies. The most widely used side virtual machines are for Flash and Javascript. Java had a good position, but now its dying away (on the client side). Silverlight has patent issues. What else do we have? You can't just run python or ruby in a windows box -- it doesn't have any runtime support.
April 24, 2010
On Sat, Apr 24, 2010 at 10:48:53AM +0000, retard wrote:
> What else do we have?

If I had my way, I'd just be rid of the virtual machine altogether. Simply run
native programs as a restricted user. (Indeed, I'd run the browser itself
with that restricted user, then let it create whatever processes it
wants, possibly stripping the child processes of more privileges.) The
operating system keeps it from doing anything evil.

We could define a new header in the HTTP request that lists the kind of code you'd accept, from highest priority to lowest. For example, a linux box with Wine might say:

X-Accept-Code: linux64; linux; win32

Meaning it'd prefer 64 bit linux apps, but if you don't offer that, it'll settle for a generic 32 bit linux binary, or a Windows one if that fails. The application is responsible for getting its own dependencies resolved - if a dll load fails, download it from your site automatically.

A statically built standard library could simplify this for the programmer.


This gives the programmers huge freedom by taking the code
execution out of the browser's hands. Want to use a different language? Just
compile it, or bundle an interpreter for it. The accept-code header could
list various VMs the system has installed too.


If the browser didn't send the accept-code header, you have two options: offer the binary as a download in a link or fallback on javascript. The only problem with the former is users without the right security setup probably shouldn't get used to approving binary downloads.


But, fixing the browser's create process powers are the direction I'd take instead of adding more and more to their javascript interpreters. If they can create the appropriately restricted token (which they should be running under themselves anyway!), you're in business.

Seems like a lot less work than what they've put in the javascript, and gives a lot more flexibility.

-- 
Adam D. Ruppe
http://arsdnet.net
April 24, 2010
Sat, 24 Apr 2010 11:27:27 -0400, Adam D. Ruppe wrote:

> On Sat, Apr 24, 2010 at 10:48:53AM +0000, retard wrote:
>> What else do we have?
> 
> If I had my way, I'd just be rid of the virtual machine altogether. Simply run native programs as a restricted user. (Indeed, I'd run the browser itself with that restricted user, then let it create whatever processes it wants, possibly stripping the child processes of more privileges.) The operating system keeps it from doing anything evil.
> 
> We could define a new header in the HTTP request that lists the kind of code you'd accept, from highest priority to lowest. For example, a linux box with Wine might say:
> 
> X-Accept-Code: linux64; linux; win32
> 
> Meaning it'd prefer 64 bit linux apps, but if you don't offer that, it'll settle for a generic 32 bit linux binary, or a Windows one if that fails. The application is responsible for getting its own dependencies resolved - if a dll load fails, download it from your site automatically.
> 
> A statically built standard library could simplify this for the programmer.
> 
> 
> This gives the programmers huge freedom by taking the code execution out of the browser's hands. Want to use a different language? Just compile it, or bundle an interpreter for it. The accept-code header could list various VMs the system has installed too.
> 
> 
> If the browser didn't send the accept-code header, you have two options: offer the binary as a download in a link or fallback on javascript. The only problem with the former is users without the right security setup probably shouldn't get used to approving binary downloads.
> 
> 
> But, fixing the browser's create process powers are the direction I'd take instead of adding more and more to their javascript interpreters. If they can create the appropriately restricted token (which they should be running under themselves anyway!), you're in business.
> 
> Seems like a lot less work than what they've put in the javascript, and gives a lot more flexibility.

It gives different kinds of flexibility. The advantage of Javascript is easy interfacing with the DOM, the html document and all kinds of powers the browser is providing. The hypertext widget is actually pretty good at modelling user interfaces even though it's not optimal by modern standards.

The web applications have many contradicting goals and as a systems programmer you only have a narrow view which is from the pov of the traditional local applications. It's true that you can restrict privileges on operating system level. However, there is no cross-platform way of controlling this system manually on a proper abstraction level. If you fail to see the advantages of a middleware layer, you need to think more about it.
April 24, 2010
On Sat, Apr 24, 2010 at 05:36:30PM +0000, retard wrote:
> It gives different kinds of flexibility. The advantage of Javascript is easy interfacing with the DOM, the html document and all kinds of powers the browser is providing.

Yeah, this came to mind only after I made the last post. The best solution would probably be exposing the DOM objects to the child process somehow, probably in a process similar to how browser plug-ins work.

Dynamically linking the DOM API to the application and passing opaque pointers to and from it should do the trick, while insulating the downloaded code from different browser implementations. Hopefully.

An alternative is interpreting Javascript through a pipe to manipulate the webpage, but then the native code is kinda pointless.

> However, there is no cross-platform way of controlling this system manually on a proper abstraction level.

I don't know what you mean here... for security, there are no controls on Javascript, you just get what the browser offers you and nothing more. An OS level security restriction would be the same thing.
April 24, 2010
Sat, 24 Apr 2010 14:06:19 -0400, Adam D. Ruppe wrote:

> On Sat, Apr 24, 2010 at 05:36:30PM +0000, retard wrote:
>> It gives different kinds of flexibility. The advantage of Javascript is easy interfacing with the DOM, the html document and all kinds of powers the browser is providing.
> 
> Yeah, this came to mind only after I made the last post. The best solution would probably be exposing the DOM objects to the child process somehow, probably in a process similar to how browser plug-ins work.

The problem is, the most common object code interfaces on top of the OS have been optimized for C/C++ and that won't change anytime soon. The layer isn't really language agnostic. If favors C/C++ compatible languages.

>> However, there is no cross-platform
>> way of controlling this system manually on a proper abstraction level.
> 
> I don't know what you mean here... for security, there are no controls on Javascript, you just get what the browser offers you and nothing more. An OS level security restriction would be the same thing.

The Javascript world is a bit naive today, but the middleware layer will likely become more complex later. You can see some security features in most browser plugins. Javascript will eventually replace these.
April 24, 2010
On 4/24/2010 09:27, Adam D. Ruppe wrote:
> If I had my way, I'd just be rid of the virtual machine altogether. Simply run
> native programs as a restricted user. (Indeed, I'd run the browser itself
> with that restricted user, then let it create whatever processes it
> wants, possibly stripping the child processes of more privileges.) The
> operating system keeps it from doing anything evil.

Congratulations, you just invented ActiveX.  I hope you like your platform lockdown and your security vulnerabilities.

> X-Accept-Code: linux64; linux; win32

99% of web pages will offer just the win32 version.


-- 
Rainer Deyke - rainerd@eldwood.com
April 24, 2010
On Sat, Apr 24, 2010 at 01:53:10PM -0600, Rainer Deyke wrote:
> Congratulations, you just invented ActiveX.  I hope you like your platform lockdown and your security vulnerabilities.

ActiveX controls don't run as a limited user account. That's the key here: the entire browser should be running as a restricted user, and it creates processes even more restricted than itself.

(When Google did this in Chrome, it was hailed as brilliant and innovative.
 I saw it as them finally doing what they should have been doing from the
 beginning.)

> 99% of web pages will offer just the win32 version.

Meh, works for 91% of users.
April 24, 2010
I keep posting this link here, and it keeps being ignored, despite I think it can become one important usage of D: http://code.google.com/p/nativeclient/

Bye,
bearophile
April 24, 2010
Sat, 24 Apr 2010 13:53:10 -0600, Rainer Deyke wrote:

> On 4/24/2010 09:27, Adam D. Ruppe wrote:
>> If I had my way, I'd just be rid of the virtual machine altogether. Simply run native programs as a restricted user. (Indeed, I'd run the browser itself with that restricted user, then let it create whatever processes it wants, possibly stripping the child processes of more privileges.) The operating system keeps it from doing anything evil.
> 
> Congratulations, you just invented ActiveX.  I hope you like your platform lockdown and your security vulnerabilities.
> 
>> X-Accept-Code: linux64; linux; win32
> 
> 99% of web pages will offer just the win32 version.

Indeed, it's hard to believe that a "web 3.0" application vendor would suddenly support several platforms after 25+ years of Microsoft dominance. The second platform might increase the development costs 10..50% and bring 4% more money. It doesn't make sense to support other platforms unless enforced by the law. This problem won't go away in the long run, on the contrary, as new (mobile/htpc/whatnot) platforms emerge.

A middleware is about building the infrastructure. Later (ideally) there are no platform specific costs involved. A history lesson might help Adam. Both Apple and Microsoft are afraid of middleware solutions. That's why Microsoft corrupted Java & Javascript and Apple recently banned all non-Apple middleware tools on iPhone. The web 2.0 apps were built because people got tired of Microsoft monoculture. Web 2.0 is a crappy technology, but we haven't got anything better.
April 24, 2010
On Sat, Apr 24, 2010 at 04:26:55PM -0400, bearophile wrote:
> I keep posting this link here, and it keeps being ignored, despite I think it can become one important usage of D: http://code.google.com/p/nativeclient/

It is absolutely useless; it has no market penetration and since it forces you to use their tool chain the whole way, it will never get any.

Any time spent getting D to run on it would be a complete waste of time. At least compiling to javascript would have a potential user base.

-- 
Adam D. Ruppe
http://arsdnet.net