10 ms·

This, along with Chrome Web Store, are the first major deviances from Chrome the HTML5 browser into Chrome the platform. It's exciting but also unfortunate that

by tiles 15y ago

This, along with Chrome Web Store, are the first major deviances from Chrome the HTML5 browser into Chrome the platform. It's exciting but also unfortunate that we're starting to see a divergence here, when other browsers are unlikely to pick up NaCl for some time (if at all) and the Chrome Web Store being entirely incompatible. Edit: Mozilla Rejects Native Code Approach of Chrome's NaCl http://css.dzone.com/articles/mozilla-rejects-native-code http://css.dzone.com/articles/mozilla-rejects-native-code

yid 15y ago
I think they might also see NaCl as helping drive Chrome's growth, when suddenly a browser can do cool stuff that other browsers can't. EDIT: I'm old enough to remember the browser wars, but I really like most of the trends that Google/Chrome have introduced, from auto-updates to revving the JS engine to fallback-capable SPDY.
- yuvipanda 15y ago
  Let's hope this doesn't devolve into something similar to the madness that was ActiveX.
  - yid 15y ago
    ActiveX's downfall was a lack of security and relatively high complexity (the two are often related). Google, so far, has had quite a good run in those areas.
    - drgath 15y ago
      No, ActiveX's downfall was that it wasn't part of the open-web. If ActiveX had bullet-proof security, it still would have failed because you'd still only have IE supporting it. In NaCl's case, Chrome will be the only browser to ever support it, which means it is just a nicer flavor of ActiveX, and likewise, I hope it lands flat on its face.
      - yid 15y ago
        From the official NaCl FAQ: Q. Is Native Client open? Is it a standard? Native Client is completely open: the executable format is open and the source code is open. Right now Native Client is in its early stages, so it's premature to consider Native Client for standardization. If it lives up to its promise, and Chrome is the only browser to support it, then it says more about the other browser vendors than anything.
        drgath 15y ago
        Just because something is a standard in no way means one way or another that browsers should actually support it. For example... C# is a non-proprietary approved spec by ECMA, but you don't see that inside of a web browser. If something is standardized and approved by the W3C or WHATWG, and no other browsers support it, then yeah, come back and we'll chat. But that's not going to happen anytime soon. Until that happens, it shouldn't be inside of a web browser and promoted as web technology.
        yid 15y ago
        No one's forcing you to use it...
        leoc 15y ago
        WHATWG is a sock puppet for the browser vendors. So saying 'the browser vendors ought to support something only if WHATWG approves it' would effectively be to say that 'the browser vendors should support something only if the browser vendors collectively want to support it'. That's obviously an argument one could make, but it would be better if one started by dropping the fiction that WHATWG is some sort of neutral party or independent source of legitimacy. In fairness, the argument you actually made is 'the browser vendors ought to support something only if WHATWG or W3C approves it', which expands to 'the browser vendors should support something only if the browser vendors collectively want to support it, or if W3C approves it'. But that leads to obvious questions. Why is W3C approval critical for technologies of which the browser vendors collectively disapprove, but of distinctly secondary importance for the technologies they collectively like? And when was the last time the browser vendors shown much sign of meekly accepting W3C-approved technologies of which they disapprove? It seems very much as if the WHATWG HTML coup was not only about adopting features which the browser vendors wanted but which W3C was slow to standardise, but also about stymieing features which the W3C approved of but which the brower vendors don't like (like RDFa, namespaces, and HTML modularisation). So setting the W3C up as an alternative gatekeeper here seems almost as cheeky as advancing the WHATWG.
ramanujan 15y ago
ChromeOS should be added to your list too. When Chromebooks get VPN...will be seriously tempting for a lot of businesses. Also: this is a dumb thought, perhaps, but was just thinking about why browser sandboxing is so important. Obviously (on a non-Chromebook at least) people can download and run any app locally, with the download itself often occurring through a web browser. So why is sandboxing important? I guess the issue is that you are downloading and running a full app with each page request, and often this download/execute cycle can occur on a script tag that is never explicitly approved by the user, so the frequency and invisibility of executing foreign code is much greater. This is doubly true if you're talking about a Chromebook, whose administration and security features rest upon the fact that someone can't install stuff locally. Also, the model of "trust every NaCl executable before you run it" breaks down in this environment...because Google depends on the fact that people must be able to trust clicking links they've never seen before [i.e. that they just searched for]. So it's really extremely important to their bottom line that they nail any security issues with NaCl. This may be different from MS's perception of ActiveX security as a priority. Just some musings.
- aboodman 15y ago
  Sandboxing is important on normal desktop browsers because downloading native apps off the internet and running them is incredibly unsafe for normal users. The more that can run in the browser's sandbox, the better for users. As for comparisons to ActiveX, they are completely different. ActiveX was not designed to place any restrictions on the downloaded code at all. In contrast NaCL is designed to completely restrict the downloaded code. Yes, there can be implementation bugs, just as there are implementation bugs in browsers. But it's a really important difference to say that full local privileges in NaCL is a _bug_ that will be fixed. Whereas full local privileges in ActiveX is a _feature_ that will not be fixed.
- ditojim 15y ago
  chromebooks now support VPN :) http://www.pcmag.com/article2/0,2817,2390942,00.asp http://www.pcmag.com/article2/0,2817,2390942,00.asp
yariang 15y ago
It is a bit unfortunate to see divergence only because it would mean the reversion of platform-independent development that browsers currently allow. At the same time though, sacrificing progress for standardization's sake is most unwanted. It is inevitable that some companies will make some superior innovation, and other companies might not want to adapt that right away, or perhaps they'd like to build something even better. But that's okay. This kind of leapfrog might be hard for developers because they will have to have different branches of their product, but it is a net win for users because the ones on the "superior" platforms get access to the best technology around and it therefore places pressure on the competition to adopt this new superior technology or move ahead with something better of their own.
magicalist 15y ago
Is there really a divergence though? Or is this just another way to run a program? Relatedly, I think others in this thread are forgetting why exactly ActiveX was not a good thing. To me, this is more analogous to XUL: an open-specced, open-source way to do something new in a browser that no other browser vendor ever implements. XUL didn't hurt the web (though it certainly still gives Firefox addons a competitive advantage), and -- at least as long as native client isn't adopted by other vendors -- I don't really see this hurting the web either. Meanwhile, I'm going to keep writing javascript.

by tiles 15y ago

yid 15y ago

I think they might also see NaCl as helping drive Chrome's growth, when suddenly a browser can do cool stuff that other browsers can't. EDIT: I'm old enough to remember the browser wars, but I really like most of the trends that Google/Chrome have introduced, from auto-updates to revving the JS engine to fallback-capable SPDY.

yuvipanda 15y ago
Let's hope this doesn't devolve into something similar to the madness that was ActiveX.
- yid 15y ago
  ActiveX's downfall was a lack of security and relatively high complexity (the two are often related). Google, so far, has had quite a good run in those areas.
  - drgath 15y ago
    No, ActiveX's downfall was that it wasn't part of the open-web. If ActiveX had bullet-proof security, it still would have failed because you'd still only have IE supporting it. In NaCl's case, Chrome will be the only browser to ever support it, which means it is just a nicer flavor of ActiveX, and likewise, I hope it lands flat on its face.
    - yid 15y ago
      From the official NaCl FAQ: Q. Is Native Client open? Is it a standard? Native Client is completely open: the executable format is open and the source code is open. Right now Native Client is in its early stages, so it's premature to consider Native Client for standardization. If it lives up to its promise, and Chrome is the only browser to support it, then it says more about the other browser vendors than anything.
      - drgath 15y ago
        Just because something is a standard in no way means one way or another that browsers should actually support it. For example... C# is a non-proprietary approved spec by ECMA, but you don't see that inside of a web browser. If something is standardized and approved by the W3C or WHATWG, and no other browsers support it, then yeah, come back and we'll chat. But that's not going to happen anytime soon. Until that happens, it shouldn't be inside of a web browser and promoted as web technology.
        yid 15y ago
        No one's forcing you to use it...
        leoc 15y ago
        WHATWG is a sock puppet for the browser vendors. So saying 'the browser vendors ought to support something only if WHATWG approves it' would effectively be to say that 'the browser vendors should support something only if the browser vendors collectively want to support it'. That's obviously an argument one could make, but it would be better if one started by dropping the fiction that WHATWG is some sort of neutral party or independent source of legitimacy. In fairness, the argument you actually made is 'the browser vendors ought to support something only if WHATWG or W3C approves it', which expands to 'the browser vendors should support something only if the browser vendors collectively want to support it, or if W3C approves it'. But that leads to obvious questions. Why is W3C approval critical for technologies of which the browser vendors collectively disapprove, but of distinctly secondary importance for the technologies they collectively like? And when was the last time the browser vendors shown much sign of meekly accepting W3C-approved technologies of which they disapprove? It seems very much as if the WHATWG HTML coup was not only about adopting features which the browser vendors wanted but which W3C was slow to standardise, but also about stymieing features which the W3C approved of but which the brower vendors don't like (like RDFa, namespaces, and HTML modularisation). So setting the W3C up as an alternative gatekeeper here seems almost as cheeky as advancing the WHATWG.

ramanujan 15y ago

ChromeOS should be added to your list too. When Chromebooks get VPN...will be seriously tempting for a lot of businesses. Also: this is a dumb thought, perhaps, but was just thinking about why browser sandboxing is so important. Obviously (on a non-Chromebook at least) people can download and run any app locally, with the download itself often occurring through a web browser. So why is sandboxing important? I guess the issue is that you are downloading and running a full app with each page request, and often this download/execute cycle can occur on a script tag that is never explicitly approved by the user, so the frequency and invisibility of executing foreign code is much greater. This is doubly true if you're talking about a Chromebook, whose administration and security features rest upon the fact that someone can't install stuff locally. Also, the model of "trust every NaCl executable before you run it" breaks down in this environment...because Google depends on the fact that people must be able to trust clicking links they've never seen before [i.e. that they just searched for]. So it's really extremely important to their bottom line that they nail any security issues with NaCl. This may be different from MS's perception of ActiveX security as a priority. Just some musings.

aboodman 15y ago
Sandboxing is important on normal desktop browsers because downloading native apps off the internet and running them is incredibly unsafe for normal users. The more that can run in the browser's sandbox, the better for users. As for comparisons to ActiveX, they are completely different. ActiveX was not designed to place any restrictions on the downloaded code at all. In contrast NaCL is designed to completely restrict the downloaded code. Yes, there can be implementation bugs, just as there are implementation bugs in browsers. But it's a really important difference to say that full local privileges in NaCL is a _bug_ that will be fixed. Whereas full local privileges in ActiveX is a _feature_ that will not be fixed.
ditojim 15y ago
chromebooks now support VPN :) http://www.pcmag.com/article2/0,2817,2390942,00.asp http://www.pcmag.com/article2/0,2817,2390942,00.asp

yariang 15y ago

It is a bit unfortunate to see divergence only because it would mean the reversion of platform-independent development that browsers currently allow. At the same time though, sacrificing progress for standardization's sake is most unwanted. It is inevitable that some companies will make some superior innovation, and other companies might not want to adapt that right away, or perhaps they'd like to build something even better. But that's okay. This kind of leapfrog might be hard for developers because they will have to have different branches of their product, but it is a net win for users because the ones on the "superior" platforms get access to the best technology around and it therefore places pressure on the competition to adopt this new superior technology or move ahead with something better of their own.

magicalist 15y ago

Is there really a divergence though? Or is this just another way to run a program? Relatedly, I think others in this thread are forgetting why exactly ActiveX was not a good thing. To me, this is more analogous to XUL: an open-specced, open-source way to do something new in a browser that no other browser vendor ever implements. XUL didn't hurt the web (though it certainly still gives Firefox addons a competitive advantage), and -- at least as long as native client isn't adopted by other vendors -- I don't really see this hurting the web either. Meanwhile, I'm going to keep writing javascript.