Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #28200 > unrolled thread

Java vs JavaScript

Back to article view | Back to comp.lang.java.programmer

Contents

  Java vs JavaScript Roedy Green <see_website@mindprod.com.invalid> - 2014-04-23 08:39 -0700
    Re: Java vs JavaScript markspace <markspace@nospam.nospam> - 2014-04-23 09:10 -0700
    Re: Java vs JavaScript Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-04-23 15:48 -0500
    Re: Java vs JavaScript Silvio <silvio@internet.com> - 2014-04-23 23:36 +0200
      Re: Java vs JavaScript "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-04-27 12:20 +0100
        Re: Java vs JavaScript Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2014-04-27 20:05 +0800
        Re: Java vs JavaScript Joerg Meier <joergmmeier@arcor.de> - 2014-04-27 22:55 +0200
        Re: Java vs JavaScript "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-05-01 08:52 +0100
          Re: Java vs JavaScript Silvio <silvio@internet.com> - 2014-05-01 10:26 +0200
            Re: Java vs JavaScript Gene Wirchenko <genew@telus.net> - 2014-05-01 14:10 -0700
              Re: Java vs JavaScript Silvio <silvio@internet.com> - 2014-05-02 11:10 +0200
                Re: Java vs JavaScript Gene Wirchenko <genew@telus.net> - 2014-05-02 10:20 -0700
                  Re: Java vs JavaScript Joerg Meier <joergmmeier@arcor.de> - 2014-05-02 20:16 +0200
                    Re: Java vs JavaScript "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-05-04 10:38 +0100
                      Re: Java vs JavaScript Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-05-05 00:16 -0500
                        Re: Java vs JavaScript Tim Slattery <tim@risingdove.com> - 2014-05-06 13:06 -0400
                          Re: Java vs JavaScript Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-05-06 12:40 -0500
              Re: Java vs JavaScript Simon Lewis <simonlewis2001@gmail.com> - 2014-05-02 12:53 +0200
            Re: Java vs JavaScript Arne Vajhøj <arne@vajhoej.dk> - 2014-05-01 21:16 -0400
              Re: Java vs JavaScript Silvio <silvio@internet.com> - 2014-05-02 11:17 +0200
    Re: Java vs JavaScript Arne Vajhøj <arne@vajhoej.dk> - 2014-04-23 22:22 -0400
      Re: Java vs JavaScript Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2014-04-24 16:20 +0800
        Re: Java vs JavaScript Arne Vajhøj <arne@vajhoej.dk> - 2014-04-29 21:07 -0400
    Re: Java vs JavaScript Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2014-04-24 16:15 +0800
      Re: Java vs JavaScript lipska the kat <lipskathekat@example.com> - 2014-04-27 09:00 +0100
        Re: Java vs JavaScript Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2014-04-27 20:15 +0800
          Re: Java vs JavaScript lipska the kat <lipskathekat@example.com> - 2014-04-27 16:59 +0100
    Re: Java vs JavaScript Ray Osborne <rko153@gmail.com> - 2014-05-22 05:08 -0700

Page 1 of 2  [1] 2  Next page →

#28200 — Java vs JavaScript

There is something odd going on. 

I have always thought the Java sandbox was so restrictive, there was
nothing a user need worry about. There is no way an unsigned applet
could do any damage.

But Oracle and the browsers are acting like unsigned Applets are
highly dangerous, making you do override after override to run them.

On the other hand I don't think JavaScript has any sort of sandbox at
all, and everyone blissfully runs scripts that can do anything.

Why the double standard? Is JavaScript safer than I thought?
-- 
Roedy Green Canadian Mind Products http://mindprod.com
"Don't worry about people stealing an idea; if it's original, you'll
 have to shove it down their throats." 
~ Howard Aiken (born: 1900-03-08 died: 1973-03-14 at age: 73)

[toc] | [next] | [standalone]

#28202

On 4/23/2014 8:39 AM, Roedy Green wrote:
> On the other hand I don't think JavaScript has any sort of sandbox at
> all, and everyone blissfully runs scripts that can do anything.

JavaScript runs in a sandbox, but as far as I know it isn't very 
restrictive.  I think there's like a 4 megabyte limit *per site* for the 
amount of data it can store on your hard drive, for example.

But yes I agree "something is going on."  FireFox OS is what is going 
on, and anything that runs in a browser that competes with it is being 
extinguished by Brenden Eich and company.

[toc] | [prev] | [next] | [standalone]

#28205

On 4/23/2014 10:39 AM, Roedy Green wrote:
> There is something odd going on.
>
> I have always thought the Java sandbox was so restrictive, there was
> nothing a user need worry about. There is no way an unsigned applet
> could do any damage.

Unless the Java VM and/or runtime had security holes.

> On the other hand I don't think JavaScript has any sort of sandbox at
> all, and everyone blissfully runs scripts that can do anything.

"anything" is a bit of a misnomer here. The standard JavaScript runtime 
profile doesn't allow you to:

1. Access the local filesystems
2. Spawn, communicate, or interact with other processes
3. Open generic network sockets
4. Execute arbitrary native code

All of these are possible with part of the standard Java library.

In general, the security model of Java appears to me to be more of an 
afterthought, with ad-hoc securing of APIs. In contrast, the development 
of JavaScript has tended towards not admitting new APIs until after 
security reviews have been done on the APIs. Legacy APIs can be 
problematic sometimes, but the mighty hammer of things like CORS or CSP 
has reduced the scope of problems here.

Certainly, in the past several months, the browser developers appear to 
have been taking security more seriously than Oracle has with Java.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#28206

On 04/23/2014 05:39 PM, Roedy Green wrote:
> There is something odd going on.
>
> I have always thought the Java sandbox was so restrictive, there was
> nothing a user need worry about. There is no way an unsigned applet
> could do any damage.
>
> But Oracle and the browsers are acting like unsigned Applets are
> highly dangerous, making you do override after override to run them.
>
> On the other hand I don't think JavaScript has any sort of sandbox at
> all, and everyone blissfully runs scripts that can do anything.
>
> Why the double standard? Is JavaScript safer than I thought?
>

In short: yes. Java was not designed to be safe in any particular way in 
that it does not restrict you from doing anything potentially dangerous 
(accessing file systems, doing socket level IO, executing native 
code...). The runtime that executes your code is responsible for taking 
away capabilities from the code as an afterthought. This is very hard to 
do thoroughly and exhaustively.

JavaScript and it's traditional runtime profile (inside a browser 
embedded in a web page) is very limited in what it can do.No need for 
the browser to enforce much restriction (barring stuff like XSS). 
Insecurity has to be added via libraries provided by the runtime.

Of course JavaScript still sucks as a programming language...

Silvio

[toc] | [prev] | [next] | [standalone]

#28256

Silvio wrote:
> Java was not designed to be safe in any particular way in
> that it does not restrict you from doing anything potentially dangerous
> (accessing file systems, doing socket level IO, executing native
> code...). The runtime that executes your code is responsible for taking
> away capabilities from the code as an afterthought. This is very hard to
> do thoroughly and exhaustively.

Agreed that this is not the way to design a security arhutecture if you have 
the opportunity to build the thing from the ground up.  (Of course, the 
designers were in a tearing hurry at the time this stuff was set in stone).

> JavaScript and it's traditional runtime profile (inside a browser
> embedded in a web page) is very limited in what it can do.No need for
> the browser to enforce much restriction (barring stuff like XSS).
> Insecurity has to be added via libraries provided by the runtime.

Agreed that JS gains some security from the fact that it just doesn't have the 
ability to touch as much as the Java runtime (assuming the application that 
embeds the JS runtime is done right -- a very dubious assumption).  But JS 
shares the same approach to tacking security on afterwards as Java, and has a 
number of rather serious problems relating to its almost uncontrolled abillity 
to manipulate the UI.  (Of course, the designers were in a tearing hurry at the 
time this stuff was set in stone).

    -- chris 

[toc] | [prev] | [next] | [standalone]

#28258

On 4/27/2014 7:20 PM, Chris Uppal wrote:
>
> Agreed that this is not the way to design a security arhutecture if you have
> the opportunity to build the thing from the ground up.  (Of course, the
> designers were in a tearing hurry at the time this stuff was set in stone).

Really?
>
>
> Agreed that JS gains some security from the fact that it just doesn't have the
> ability to touch as much as the Java runtime

https://wiki.mozilla.org/WebAPI

[toc] | [prev] | [next] | [standalone]

#28273

On 27 Apr 2014 18:09:28 GMT, Stefan Ram wrote:

> "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> writes:
>>Agreed that JS gains some security from the fact that it just doesn't have the 
>   I believe that JavaScript was and still is the main entry
>   surface for infections via Browsers. (Some of the following
>   URIs might be outdated, because I recorded the some time ago.)

Nobody is doubting that JavaScript was a big offender ten years ago, but it
seems like it has been doing a lot better in more recent years.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#28322

Stefan Ram wrote:

>  So, JavaScript is not mentionend in the press because it is
>  a technical details of the browser, while Java is a
>  freestanding product, not part of the browser. Because of
>  this avoidance of the mentioning of JavaScript, some people
>  do believe that JavaScript today has become more secure. But
>  you can find the technical details I quoted above if you
>  search for them.

I think there's a lot of truth to that.  A few years back, JavaScript was still 
viewed with suspicion (justifiably), and as such it was a "live issue" and so, 
when it was involved in security problems, it got mentioned.  These days many 
people take it for granted, and are no more likely to think of it as 
"contributing to" an exploit where it is used than the surrounding HTML (if 
any) is.

    -- chris 

[toc] | [prev] | [next] | [standalone]

#28323

On 05/01/2014 09:52 AM, Chris Uppal wrote:
> Stefan Ram wrote:
>
>>   So, JavaScript is not mentionend in the press because it is
>>   a technical details of the browser, while Java is a
>>   freestanding product, not part of the browser. Because of
>>   this avoidance of the mentioning of JavaScript, some people
>>   do believe that JavaScript today has become more secure. But
>>   you can find the technical details I quoted above if you
>>   search for them.
>
> I think there's a lot of truth to that.  A few years back, JavaScript was still
> viewed with suspicion (justifiably), and as such it was a "live issue" and so,
> when it was involved in security problems, it got mentioned.  These days many
> people take it for granted, and are no more likely to think of it as
> "contributing to" an exploit where it is used than the surrounding HTML (if
> any) is.
>
>      -- chris
>
>

That is because JavaScript IS part of the HTML page and it can not 
contain a security hole by definition. Only the browser displaying the 
page can.

The same would hold for Java IF the browser would be the one running the 
Java code. But instead the code is run by a third party plugin which 
leaves the browser limited room to control what the code can do. Even 
stuff like the standard library (which is where all the bombs are) comes 
with the plugin so no way for the browser to take away or restrict 
things there.

It is much easier to not provide a File/URL class than to provide a 
third party one and then try to keep them constrained.

[toc] | [prev] | [next] | [standalone]

#28338

On Thu, 01 May 2014 10:26:25 +0200, Silvio <silvio@internet.com>
wrote:

[snip]

>That is because JavaScript IS part of the HTML page and it can not 
>contain a security hole by definition. Only the browser displaying the 
>page can.

     Oh, nonsense.  Put an onclick= in an <a> tag to go to a different
URL than specified in the href=, and you have a security issue due to
JavaScript.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#28352

On 05/01/2014 11:10 PM, Gene Wirchenko wrote:
> On Thu, 01 May 2014 10:26:25 +0200, Silvio <silvio@internet.com>
> wrote:
>
> [snip]
>
>> That is because JavaScript IS part of the HTML page and it can not
>> contain a security hole by definition. Only the browser displaying the
>> page can.
>
>       Oh, nonsense.  Put an onclick= in an <a> tag to go to a different
> URL than specified in the href=, and you have a security issue due to
> JavaScript.
>
> [snip]
>
> Sincerely,
>
> Gene Wirchenko
>

Now that is nonsense. Why is it a security issue if that is what the 
HTML page says it should do? It is something that can be discovered from 
the page itself and anything the JS instructs the browser to do it can 
decide to refuse.

On the other hand IE allows the loading of ActiveX controls from 
JavaScript and call native code on them which runs completely outside 
the browsers control. Depending on the users security settings and how 
correct these have been implemented in IE this is certainly an area of 
concern. But that is only because IE deliberately implements this 
functionality. That makes IE dangerous, not JS. BTW: ActiveX object can 
also be loaded with HTML only.

[toc] | [prev] | [next] | [standalone]

#28355

On Fri, 02 May 2014 11:10:07 +0200, Silvio <silvio@internet.com>
wrote:

>On 05/01/2014 11:10 PM, Gene Wirchenko wrote:
>> On Thu, 01 May 2014 10:26:25 +0200, Silvio <silvio@internet.com>
>> wrote:
>>
>> [snip]
>>
>>> That is because JavaScript IS part of the HTML page and it can not
>>> contain a security hole by definition. Only the browser displaying the
>>> page can.
>>
>>       Oh, nonsense.  Put an onclick= in an <a> tag to go to a different
>> URL than specified in the href=, and you have a security issue due to
>> JavaScript.
>>
>> [snip]

>Now that is nonsense. Why is it a security issue if that is what the 
>HTML page says it should do? It is something that can be discovered from 
>the page itself and anything the JS instructs the browser to do it can 
>decide to refuse.

     Well, if you hover on the link, Firefox, at least, will display
the link as being according to the href= phrase, but the actual
destination will be according to the onclick= phrase.

     Why should someone have to examine the page code to see what will
be done?  Does that not suggest to you that someone might be trying to
pull a fast one?  That situation is a security issue.

>On the other hand IE allows the loading of ActiveX controls from 
>JavaScript and call native code on them which runs completely outside 
>the browsers control. Depending on the users security settings and how 
>correct these have been implemented in IE this is certainly an area of 
>concern. But that is only because IE deliberately implements this 
>functionality. That makes IE dangerous, not JS. BTW: ActiveX object can 
>also be loaded with HTML only.

     This is also dangerous.

     There is more than one mine in this security minefield.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#28358

On Fri, 02 May 2014 10:20:25 -0700, Gene Wirchenko wrote:

>      Well, if you hover on the link, Firefox, at least, will display
> the link as being according to the href= phrase, but the actual
> destination will be according to the onclick= phrase.

If you don't hover, the href link might differ from the text link: <a
href="http://www.evil.org">www.google.com</a>. Have I now conclusively
proven that HTML has a giant, gaping security hole ?

If Firefox display and execution differ, then that seems to be a Firefox
issue. Neither HTML nor JavaScript somehow require Firefox to display the
href content instead of the onclick content and then execute the onclick
content instead of the href content. This disparity seems to be squarely at
the feet of whoever maintains that particular behaviour.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#28359

Joerg Meier wrote:

> If you don't hover, the href link might differ from the text link: <a
> href="http://www.evil.org">www.google.com</a>. Have I now conclusively
> proven that HTML has a giant, gaping security hole ?

Yes.  The exploit you mention was actually used (IIRC) in the early days, and 
it /was/ a security problem for users, which is /why/ the browsers started 
doing the hover-over thing.

Security is about the person using the browser, not the browser itself, nor the 
page that the browser is displaying.  /They/ aren't going to loose money, get 
infected, be advertised at unwantedly, whatever...  The person is -- or may be. 
If the whole settup (Java/Flash/JavaScript/HTML/etc) is such that an actual 
user is mislead, then that is security failure, and then it's just a matter of 
finger-pointing as to which part of the system takes how much blame.

If the problem is more theoretical, "this feature COULD be used to mislead 
users", then that feature has security issues which are anything from trivial 
to severe depending on, for instance, how easy it is to deploy, and how hard it 
is for a user to avoid it.

JavaScript has been used in way that mislead technically minded, 
security-concious users.  To that extent JavaScript has some serious security 
issues.

Java has been used in way that mislead technically minded, security-concious 
users.  To that extent Java has some serious security issues.

Flash has been used in way that mislead technically minded, security-concious 
users.  To that extent Flash has some serious security issues.

I expect I'll be able to make the same claim about HTNL5 soon, if I can't 
already.

And yes, I can make the same claim about old-skool HTML too.

HTML has problems.  JavaScript makes it easier to exploit those problems, and 
adds new ones of its own.  Java, FLash, and any other pluggin can be expected 
to add yet more problems -- it's inherent in the nature of a plugin (by which I 
mean exernal compiled code) that it may open too many doors (NACL aside, 
perhaps).

So there's a security flaw in the design of HTML (not knowing where a link 
would take you). The browser vendors add a hack in attempted mitigation of it. 
And then JavaScript comes along and undoes the mitigation.  It's not clear to 
me what the browser makers could do in respoinse, but it wouldn't be trivial.

    -- chris

[toc] | [prev] | [next] | [standalone]

#28365

On 5/4/2014 4:38 AM, Chris Uppal wrote:
> Security is about the person using the browser, not the browser itself, nor the
> page that the browser is displaying.  /They/ aren't going to loose money, get
> infected, be advertised at unwantedly, whatever...  The person is -- or may be.
> If the whole settup (Java/Flash/JavaScript/HTML/etc) is such that an actual
> user is mislead, then that is security failure, and then it's just a matter of
> finger-pointing as to which part of the system takes how much blame.

I prefer to draw a distinction between "attacks" that rely on confusing 
the user to direct them to a fake site (I'll call this phishing for lack 
of a better name) and attacks that actively harm you (more traditional 
security exploits). To some degree, phishing attacks are unavoidable due 
to stupid users, and you can make a case that many would be better 
handled not by informing the user of the malicious page switch 
beforehand but rather by indicating that the target of the link is not 
what the link claimed it was. Although success in the latter arena isn't 
great, either.

> I expect I'll be able to make the same claim about HTNL5 soon, if I can't
> already.

One point of pedantry I want to bring up: JavaScript the language is not 
the same as the set of JavaScript libraries used in web programming 
(often known as DOM). The set of new additions to this repertoire over 
the past several years has fallen under the terminology of "HTML5" 
(although I know many web engine developers who dislike that term).

> HTML has problems.  JavaScript makes it easier to exploit those problems, and
> adds new ones of its own.  Java, FLash, and any other pluggin can be expected
> to add yet more problems -- it's inherent in the nature of a plugin (by which I
> mean exernal compiled code) that it may open too many doors (NACL aside,
> perhaps).

The source of vulnerabilities is often in libraries, not languages; most 
of the security problems in Java that I can think up are not in the core 
VM but rather in the expansive set of libraries that make up the 
standard library. Similarly, JS's core language isn't the source of most 
problems but rather the DOM. In a similar vein, Flash and NaCl have 
problems simply because they allow access to rather less well-secured 
libraries.

The only way you could get rid of these vulnerabilities would be to 
freeze the allowed access and the implementation except for bug and 
security fixes and then wait for 20 years (think TeX). And that's not 
going to happen.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#28396

Joshua Cranmer ? <Pidgeot18@verizon.invalid> wrote:


>One point of pedantry I want to bring up: JavaScript the language is not 
>the same as the set of JavaScript libraries used in web programming 
>(often known as DOM). 

The DOM (Document Object Model) is NOT a set of Javascript libraries.
It's the way the browser makes the currently loaded document (usually
an HTML page) available to the Javascript routines. 

>The set of new additions to this repertoire over 
>the past several years has fallen under the terminology of "HTML5" 
>(although I know many web engine developers who dislike that term).

HTML5 encompasses a number of things, see http://diveintohtml5.info
for a look at the whole thing. It's not more JS libraries. There are
certainly more JS commands and abilities to take advantage of the new
features in HTML5.

-- 
Tim Slattery
tim <at> risingdove <dot> com

[toc] | [prev] | [next] | [standalone]

#28398

On 5/6/2014 12:06 PM, Tim Slattery wrote:
>> One point of pedantry I want to bring up: JavaScript the language is not
>> the same as the set of JavaScript libraries used in web programming
>> (often known as DOM).
>
> The DOM (Document Object Model) is NOT a set of Javascript libraries.
> It's the way the browser makes the currently loaded document (usually
> an HTML page) available to the Javascript routines.

The DOM is not part of the core JavaScript language. Ergo, it's a 
library as far as JavaScript is concerned. It certainly includes more 
than the reflection of the document to JS; DOM promises is an example 
(although it has since moved from a DOM feature to a core JS feature).

>> The set of new additions to this repertoire over
>> the past several years has fallen under the terminology of "HTML5"
>> (although I know many web engine developers who dislike that term).
>
> HTML5 encompasses a number of things, see http://diveintohtml5.info
> for a look at the whole thing. It's not more JS libraries. There are
> certainly more JS commands and abilities to take advantage of the new
> features in HTML5.

When most people talk excitedly about HTML5, they often refer not to the 
additions to the declarative syntax of HTML but rather to the APIs like 
Geolocation, IndexedDB, WebWorker, etc. that are basically all JS 
library work. The document you linked to is quite guilty of this: only 4 
of its 11 chapters actually discuss HTML features. Whatever the original 
intent of the terminology, it has become a catchall term in common 
parlance for "everything added to the web platform since the demise of 
Netscape."


-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#28354

Gene Wirchenko <genew@telus.net> writes:

> On Thu, 01 May 2014 10:26:25 +0200, Silvio <silvio@internet.com>
> wrote:
>
> [snip]
>
>>That is because JavaScript IS part of the HTML page and it can not 
>>contain a security hole by definition. Only the browser displaying the 
>>page can.
>
>      Oh, nonsense.  Put an onclick= in an <a> tag to go to a different
> URL than specified in the href=, and you have a security issue due to
> JavaScript.
>
> [snip]
>
> Sincerely,
>
> Gene Wirchenko

What total and utter ignorant bullshit. 

[toc] | [prev] | [next] | [standalone]

#28348

On 5/1/2014 4:26 AM, Silvio wrote:
> On 05/01/2014 09:52 AM, Chris Uppal wrote:
>> Stefan Ram wrote:
>>>   So, JavaScript is not mentionend in the press because it is
>>>   a technical details of the browser, while Java is a
>>>   freestanding product, not part of the browser. Because of
>>>   this avoidance of the mentioning of JavaScript, some people
>>>   do believe that JavaScript today has become more secure. But
>>>   you can find the technical details I quoted above if you
>>>   search for them.
>>
>> I think there's a lot of truth to that.  A few years back, JavaScript
>> was still
>> viewed with suspicion (justifiably), and as such it was a "live issue"
>> and so,
>> when it was involved in security problems, it got mentioned.  These
>> days many
>> people take it for granted, and are no more likely to think of it as
>> "contributing to" an exploit where it is used than the surrounding
>> HTML (if
>> any) is.
>
> That is because JavaScript IS part of the HTML page and it can not
> contain a security hole by definition. Only the browser displaying the
> page can.

Today a browser typical comes with distinct:
- layout/render engine
- JavaScript engine

And the two do not necessarily come from the same source.

JS engine is still more tightly coupled with the browser, because
it cannot (as far as I know) be replaced by the user. It may even
be linked into the same executable as the rest. But somewhere
at the source code level it is distinct.

Arne

[toc] | [prev] | [next] | [standalone]

#28353

On 05/02/2014 03:16 AM, Arne Vajhøj wrote:
> On 5/1/2014 4:26 AM, Silvio wrote:
>> On 05/01/2014 09:52 AM, Chris Uppal wrote:
>>> Stefan Ram wrote:
>>>>   So, JavaScript is not mentionend in the press because it is
>>>>   a technical details of the browser, while Java is a
>>>>   freestanding product, not part of the browser. Because of
>>>>   this avoidance of the mentioning of JavaScript, some people
>>>>   do believe that JavaScript today has become more secure. But
>>>>   you can find the technical details I quoted above if you
>>>>   search for them.
>>>
>>> I think there's a lot of truth to that.  A few years back, JavaScript
>>> was still
>>> viewed with suspicion (justifiably), and as such it was a "live issue"
>>> and so,
>>> when it was involved in security problems, it got mentioned.  These
>>> days many
>>> people take it for granted, and are no more likely to think of it as
>>> "contributing to" an exploit where it is used than the surrounding
>>> HTML (if
>>> any) is.
>>
>> That is because JavaScript IS part of the HTML page and it can not
>> contain a security hole by definition. Only the browser displaying the
>> page can.
>
> Today a browser typical comes with distinct:
> - layout/render engine
> - JavaScript engine
>
> And the two do not necessarily come from the same source.
>
> JS engine is still more tightly coupled with the browser, because
> it cannot (as far as I know) be replaced by the user. It may even
> be linked into the same executable as the rest. But somewhere
> at the source code level it is distinct.
>
> Arne
>
>
>

The fact that browsers may choose to use common libraries changes 
nothing to the fact that it ultimately the browsers concern what these 
libraries do. Webkit could have a major security hole in it. Does that 
make HTML insecure?

As soon as the JS engine would become a user replaceable plugin I agree 
things could become risky.

But then we would have created exactly the same situation as we have 
with Java.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web