i never thinked about ot so i would like to ask in this case.

lets assume that instead od loading javascript code into a browsers

you download a binary compiled c/asm modules (in the form of

dlls or something like that) such dll should be restricted only to

modify client area of web browser but could use full processor and

gpu abilities

can it be done safe (on windows especially) or there are some basic

problems to do it safe that disqualify this tehnology?

I'm not sure what you're asking, but you can't run a binary and you can't access the whole file system with JavaScript.

If you meant replacing the content of .js file with the content of an executable file, the browser won't recognize the file as valid JavaScript code and will throw it away immediatelly. And even if somehow the file is not discarded, the file won't be executed as "starting a new proccess in the OS", it will be interpreted as JavaScript code and it will run contained by the security rules of JavaScript.

If you meant downloading a file from a page like you do everyday, Javascript is not concerned about that, and the browser won't put any restriction on it. If you downloaded a file you did it manually, if you run that file from the download list of the broswer you're doing it manually. The best thing the browser can do is warn you about possible problems of runing an executable file that you just downloaded.

If you configure the browser to download and open everything automatically and you download and run malicious software you're kinda doing it manually.

When the user does something is his/her fault and the security problem is much bigger than the browser aspects of security.

Microsoft did it with ActiveX, which was... bad, very bad.

Not only is it a huge security risk but on top of that you'd have to provide different executables, at least for x86 and ARM

I'm not sure what you're asking, but you can't run a binary and you can't access the whole file system with JavaScript.

If you meant replacing the content of .js file with the content of an executable file, the browser won't recognize the file as valid JavaScript code and will throw it away immediatelly. And even if somehow the file is not discarded, the file won't be executed as "starting a new proccess in the OS", it will be interpreted as JavaScript code and it will run contained by the security rules of JavaScript.

If you meant downloading a file from a page like you do everyday, Javascript is not concerned about that, and the browser won't put any restriction on it. If you downloaded a file you did it manually, if you run that file from the download list of the broswer you're doing it manually. The best thing the browser can do is warn you about possible problems of runing an executable file that you just downloaded.

If you configure the browser to download and open everything automatically and you download and run malicious software you're kinda doing it manually.

When the user does something is his/her fault and the security problem is much bigger than the browser aspects of security.

im asking about different thing - some solution when you would use native binary plugins (some kind of dlls) though restricted instead of ineterpreted

or at least not native things like js or hava plugins -

im curious if it could work safely or if not for what reasons

Microsoft did it with ActiveX, which was... bad, very bad.

Not only is it a huge security risk but on top of that you'd have to provide different executables, at least for x86 and ARM

ye a heard about that (though never interested with that as it was already obsolete)- but asking here if such reasons for beaing not safe are fundamental or it could be done safely

other thing if this is worth doing from the reason you said for example, as it is major unconvenience

Apart from the ancient ActiveX, there have been some more modern attempts to bring something like that, but I don't think they were widely accepted: Chrome NaCl (Native Client). http://en.wikipedia.org/wiki/Google_Native_Client

I think it does exactly what you are asking and has decent security.

The major problems with this approach are: different architectures (at least arm and x86 is a must) and the fact that people write terrible code. For javascript it took decades until it became something usable and not so buggy (arguable), so for a native technology to be implemented correctly by more than one vendor it will take comparable time.

Of course out of necessity there emerged some techniques such as ASM.js, in which javascript is used in low-level way, such that JITs can actually compile it to good performance native code.

@up

I was not asking about js (though it is interesting to)

more im interesyed if such native code module can be done

safely, i mean safely restricted - For example when you run

asembly code you have adressing abilities of assembly

language you can read any adresa and write to any adress

so you possibly can break the whole system - though probably

you can disable this reading and writing apilities in such plugin

by setting the properties of virtual pages of ram or something

- I dont know

the other question is if it is worth doing , the advantage would be

that surfers could safely run and test some codes like desktop games with no need to unsafely run it in the system - bit useful but oberal im not sure if this would be worth it

Apart from the ancient ActiveX, there have been some more modern attempts to bring something like that, but I don't think they were widely accepted: Chrome NaCl (Native Client). http://en.wikipedia.org/wiki/Google_Native_Client

Interesting, ye this is something like im talking about

curious if games made in JS or as java applets are much more slow than that? I heard tahat Js is about 5 times slower than native code, java should be faster probably.. still dont know those things though they are probably well known

Depending on how you define 'safe' I would argue that neither can be done safely.

As was pointed out, plugins are bad from a security perspective, creative attackers can find and exploit something given enough time and incentive. Plugins are usually treated with more visible security warnings since they have a very high risk for a successful attack. The assumption is that if the user is willing to run the plugin they trust it

Javascript theoretically runs in a sandbox, but in practice every browser has had some severe security exploits when creative attackers found a way outside the sandbox. Even when it is allowed to play within the sandbox, a malicious script can then redirect the browser to do something that is within bounds, such as pulling a request from another web page or redirecting content from one DOM object to another, which results in an undesirable effect. Malicious scripts are common in XSS attacks which run inside the established sandbox. That also boils down to trust. Either you trust a web page to run in your browser, or you don't.


The security bulletins, the big browser bugs, a large number are from when attackers find ways to bypass the user notification. If you get a big red warning that says "This site is probably fraud" but then enter your credit card number, that is your fault. But when the attacker finds a way to bypass the sandbox, to install a plugin or run a script without your permission, that is normally a bug in the browser. It becomes a bit of a gray area when web sites pull in resources from twenty other sources, which in turn pull from more sources, spreading out like a cancer where loading a web site pulls on web requests from a bunch of unknown sources, similar to what many advertisement scripts do today. You request the page, and unless you block it directly it is assumed that you wanted the content...