- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
CLI on the Web
|
|
|
Comments (59)
39 earlier comments in the full thread.
Quoting: it's possible to build a sandboxed environment in which to run external code. In practice, there are always bugs and it's a recipe for disasterReally? Sandboxes have been around for decades (chroot, jails) and are used extensively. Yes there have been bugs and security issues but they are not any more bug prone than say X server (which itself has had pretty serious security issues). Do you know of any data to show that sandboxes, in general, are not safe?
In any case, as others have mentioned, getting fixated on security issues is not useful. I see the general usability of sites as a much more important criterion, so we would be better served with a critique on those parameters.
Quoting:Fortunately, that's why there's NoScript.
Which means the mono/.net (or Java) style VM based idea would also be no more of an issue.
Well, well, well, what have we here?
http://www.computerworld.com/s/article/9176373/Security_firm...
Microsoft silently fixed a bug? Say it isn't so!
http://www.computerworld.com/s/article/9176373/Security_firm...
Microsoft silently fixed a bug? Say it isn't so!
Quoting:Really? Sandboxes have been around for decades (chroot, jails) and are used extensively. Yes there have been bugs and security issues but they are not any more bug prone than say X server (which itself has had pretty serious security issues). Do you know of any data to show that sandboxes, in general, are not safe?
Well said.
Quoting:In any case, as others have mentioned, getting fixated on security issues is not useful. I see the general usability of sites as a much more important criterion, so we would be better served with a critique on those parameters.
Agreed, especially since sandboxing takes care of all the "sky is falling!" paranoia the people here are complaining about.
TA, those who forget history (starting from minutes ago) are doomed to repeat it. It is always wise to consider the source. Sure, Rob Enderle is right once in awhile, but not often enough to warrant anything but skepticism. Same with Miguel, and anyone that is that MS-happy.
You're still confusing user-control with remote-party control. VNC and SIP clients are under local user control, not some remote third party. (Skype is a pit of suckage, don't know why you keep going on about it.)
Sandboxes are irrelevant to the core problem of handing over control of your PC to some remote entity. That is a big trust problem, but not of code. The tech and entertainment industries have done wonders with proving their untrustworthiness. So they can securely use and abuse your PC, hey that makes it OK? Um no. Remember, it was Miguel who mentioned Webcams and microphones, and in the context of delivering content, not cool things users can control and do useful things with. Now why on earth would any remote site need control of those under any circumstances? And again, if sandboxing and "trusted" binaries actually work, why are Web browsers the #1 attack vector, and why is Flash such a successful malware vector? Why, if this comes to pass malware authors will be able to use their favorite programming languages. Now that's innovation.
Sandboxes are irrelevant to the core problem of handing over control of your PC to some remote entity. That is a big trust problem, but not of code. The tech and entertainment industries have done wonders with proving their untrustworthiness. So they can securely use and abuse your PC, hey that makes it OK? Um no. Remember, it was Miguel who mentioned Webcams and microphones, and in the context of delivering content, not cool things users can control and do useful things with. Now why on earth would any remote site need control of those under any circumstances? And again, if sandboxing and "trusted" binaries actually work, why are Web browsers the #1 attack vector, and why is Flash such a successful malware vector? Why, if this comes to pass malware authors will be able to use their favorite programming languages. Now that's innovation.
Quoting:Remember, it was Miguel who mentioned Webcams and microphones, and in the context of delivering content, not cool things users can control and do useful things with. Now why on earth would any remote site need control of those under any circumstances?Let's ask the administrators in the Lower Merion School District. I'm sure they could come up with all kinds of reasons why people should trust them.
gus,
You cynic. The Lower Merion School District DID come up with an answer. It was the IT that did it, so their hands are clean. Moreover, no harm was done.
See: Trusted.
YBT
You cynic. The Lower Merion School District DID come up with an answer. It was the IT that did it, so their hands are clean. Moreover, no harm was done.
See: Trusted.
YBT
Quoting:VNC and SIP clients are under local user control, not some remote third party.
Be that as it may be, the point is that with HTML5 and Javascript, the sort of control of the hardware you fear the VM based code will be capable of, is already a reality. It doesn't take much imagination to imagine that the exploits you fear, are already possible.
Quoting:(Skype is a pit of suckage, don't know why you keep going on about it.)
I mentioned it in one post, as an example. If that's going on about it, I apologise for polluting your eyes.
So what it boils down to is:
a VM like the Mono/.NET CLI is inherently dangerous, because it might be possible to control computer hardware via the browser.
But
Controlling Hardware via the Browser using HTML5 and JavaScript is acceptable, because (at the moment) the examples where this is used are all using locally installed applications. And other examples of Web enabled applications, where hardware control is possible, are either Proprietary poo (so therefore we won't use them), or are FOSS applications that are locally installed, so it's OK.
The above seems to me to be a reasonable synopsis of your argument.
FWIW, this wasn't Miguel's idea, it was Joe Hewitt's idea.
But it's already been noted that you're jealous of Miguel's success and so feel the need to badmouth him at every opportunity. You are an insignificant bug in the FOSS world compared to Miguel and that clearly upsets your ego.
Carla, have you ever wondered WHY Mark Shuttleworth & Ubuntu ignores people like you (I see it's a common complaint you seem to have)? It's because you are so quick to attack but extremely slow to bother getting a clue about what you are talking about. No one outside your small group of Mono-hating followers has any respect for your anti-Mono arguments because they've seen you for what you are - a troll. If something comes up that has the words Microsoft, Novell, or Mono involved, everyone knows before-hand that you will attack like a rabid dog without first understanding the technology in question. And anyone that disagrees with you, you'll quickly label as a "Microsoft apologist", a "Microsoft shill" or some other label with the intent of dismissing their arguments completely because you are unable to actually address their points. That is the definition of a troll.
You are the embodiment of irrationality and hatred and you let that get in the way of thinking logically whenever Microsoft, Novell, or Mono come into discussion.
Here you are going on and on about how Mono will allow evil corporations to take control of your computer without your consent via their websites. Such a statement is ridiculous FUD. Embedding Mono doesn't have to allow any such thing. There's no need to give the Mono engine in the browser any more access to the system than javascript has today. Nor do you, as a user, have to go to websites that you don't trust (I know! what an amazing concept!).
Clearly as a tech journalist, you should know these fundamental things... but somehow they've flown way over your head. Or maybe it's just your hatred of Mono that's clouding the logic center of your brain.
Exploits in Flash have nothing to do with Mono. Flash is closed-source while Mono is completely Free Software and the discussion of adding Mono to browsers is only considering the ECMA-specified portions, so you don't have to get your knickers in a twist over "omg, teh patents!" because no one is suggesting the addition of Windows.Forms or ASP.NET (which wouldn't make the slightest bit of sense to have in a browser anyway).
And let's, for a moment, assume that Mono does get added to browsers like Firefox and Chrome. If you don't want to allow C#, IronPython, IronRuby, or any of the other assortment of languages that Mono supports to run in your browser, you could disable it (Firefox is Open Source, remember) or simply not visit websites that use those languages.
Wow! It's really not the end of the world like you've been trying to make it out to be!
See what I mean? When Microsoft, Novell, or Mono enter into discussion, the logic part of your brain completely shuts down and you go into an irrational "chicken with its head cut off" mode.
Any security concerns you have can be addressed and fixed, it's really not the end of the world like you want to portray.
But it's already been noted that you're jealous of Miguel's success and so feel the need to badmouth him at every opportunity. You are an insignificant bug in the FOSS world compared to Miguel and that clearly upsets your ego.
Carla, have you ever wondered WHY Mark Shuttleworth & Ubuntu ignores people like you (I see it's a common complaint you seem to have)? It's because you are so quick to attack but extremely slow to bother getting a clue about what you are talking about. No one outside your small group of Mono-hating followers has any respect for your anti-Mono arguments because they've seen you for what you are - a troll. If something comes up that has the words Microsoft, Novell, or Mono involved, everyone knows before-hand that you will attack like a rabid dog without first understanding the technology in question. And anyone that disagrees with you, you'll quickly label as a "Microsoft apologist", a "Microsoft shill" or some other label with the intent of dismissing their arguments completely because you are unable to actually address their points. That is the definition of a troll.
You are the embodiment of irrationality and hatred and you let that get in the way of thinking logically whenever Microsoft, Novell, or Mono come into discussion.
Here you are going on and on about how Mono will allow evil corporations to take control of your computer without your consent via their websites. Such a statement is ridiculous FUD. Embedding Mono doesn't have to allow any such thing. There's no need to give the Mono engine in the browser any more access to the system than javascript has today. Nor do you, as a user, have to go to websites that you don't trust (I know! what an amazing concept!).
Clearly as a tech journalist, you should know these fundamental things... but somehow they've flown way over your head. Or maybe it's just your hatred of Mono that's clouding the logic center of your brain.
Exploits in Flash have nothing to do with Mono. Flash is closed-source while Mono is completely Free Software and the discussion of adding Mono to browsers is only considering the ECMA-specified portions, so you don't have to get your knickers in a twist over "omg, teh patents!" because no one is suggesting the addition of Windows.Forms or ASP.NET (which wouldn't make the slightest bit of sense to have in a browser anyway).
And let's, for a moment, assume that Mono does get added to browsers like Firefox and Chrome. If you don't want to allow C#, IronPython, IronRuby, or any of the other assortment of languages that Mono supports to run in your browser, you could disable it (Firefox is Open Source, remember) or simply not visit websites that use those languages.
Wow! It's really not the end of the world like you've been trying to make it out to be!
See what I mean? When Microsoft, Novell, or Mono enter into discussion, the logic part of your brain completely shuts down and you go into an irrational "chicken with its head cut off" mode.
Any security concerns you have can be addressed and fixed, it's really not the end of the world like you want to portray.
> Do you know of any data to show that sandboxes, in general, are not safe?
If the history of security problems with them doesn't convince, then no. It's enough to convince me.
> Which means the mono/.net (or Java) style VM based idea would also be no more of an issue.
So you're going to include something in the browser which will require me to add yet another plugin to manage it. And you still think it's a good idea? Javascript is a huge issue. Just look at the exploits it's enabled over the years.
> Controlling Hardware via the Browser using HTML5 and JavaScript is acceptable...
No, it's not. Which, again, is why people who know enough about the issues use NoScript.
If the history of security problems with them doesn't convince, then no. It's enough to convince me.
> Which means the mono/.net (or Java) style VM based idea would also be no more of an issue.
So you're going to include something in the browser which will require me to add yet another plugin to manage it. And you still think it's a good idea? Javascript is a huge issue. Just look at the exploits it's enabled over the years.
> Controlling Hardware via the Browser using HTML5 and JavaScript is acceptable...
No, it's not. Which, again, is why people who know enough about the issues use NoScript.
Please allow me some cautious comment in this already heated debate:
Isn't Javascript not just 'another way to deliver software?'
After all, things like CUPS, Samba and Apache once were full of bugs too. However, they are distributed to us, the 'distribution users', by people we trust. People who check these programs, and who label it 'stable', 'unstable', 'testing' or 'outright dangerous'.
Those who install the Haskell toolchain, normally also install another 'attack vector' on their system, as it comes with its own libraries with root access and its own software distribution system.
The same is true for Flash: It's 'another attack vector', comes with its own library and its own software distribution system. Nonetheless, I'm not that afraid to install Haskell apps from my repository: They seem trustworthy.
And what does it matter if some 'new programming language' is delivered to you by the distribution or through the web, apart from 'trust'? If there was a 'repository' for JavaScript scripts, the issue wouldn't be that big I guess. If those JavaScript applications had a version, were signed with some digest and could be put in some repository with a 'level of trust' associated, how would it differ from distribution using the 'powers that be' channels?
If I were to trust those who make the Mono part in Firefox and the 'apps' it runs, then there wouldn't be an issue I guess. But at this point, it seems there's no kind of 'web of trust' pertaining to web applications. Also, web applications do not have a version number, and normally no digests. Those issues need to be tackled. A 'web of trust' may be a distribution, but why not something more democratic? Something like an app-market system, where users can vote for (yea) or against (nay) an app, and it is removed if it's untrustworthy and breaches security?
If we have GPG key signing parties creating a web of trust, why not expand it to web applications?
Because after all, platform independence seems the future. In the ideal world, it shouldn't matter if you run ARM, X86, X86-64, or MIPS. It shouldn't matter if you run Firefox, IE, Safari or Chrome. It shouldn't matter if you run Linux, Windows, Mac, iPhoneOS or Android. It shouldn't matter if you use APT, portage, AppStore, Android-marketstore, .exe found on the web or anything else. An application developed once should just run everywhere. That's platform independence. That's in the spirit of Free Software: making sure you don't duplicate work already done, by rewriting your applications for different OS'es, re-compiling for different archs, porting for different platforms (phone, smartbook etc.) and stuff like that. Write once, run everywhere. An utopia, I know. But it's getting closer.
And if it is written in one programming language, you shouldn't be forced to rewrite it in another language for some other platform because it doesn't have your programming language.
That's why Linux comes with Haskell, Ruby, Python and Bash, isn't it? To make sure those who wrote something don't have to rewrite it to make it run on Linux.
It probably goes without saying I don't trust Microsoft, Google and especially not Miguel de Icaza. But nonetheless, they could have good ideas, and sometimes they do work (parts of) which benefits society.
It's up to us, the society, to make use of the work which we can use. Like DIN showed, it brings huge savings to companies (and society as well) if companies work together and things are standardized, and don't have to be adopted / tweaked / changed / redesigned for every application. Modularity is good, but to fit one module on another, one needs standards. Indeed, preferably not ECMA, but anyway: To make modules fit they need to interface.
The idea's presented by Miguel aren't all that bad, even if you don't like the guy (I don't, I don't like anyone who adverrtizes OOXML) and think Mono is a way of sponsoring Microsoft.
After all, Google is working on 'something like Miguel proposes':
http://en.wikipedia.org/wiki/Google_Native_Client
To me that reads like a way to run 'native' X86 code in Chrome.
Isn't Javascript not just 'another way to deliver software?'
After all, things like CUPS, Samba and Apache once were full of bugs too. However, they are distributed to us, the 'distribution users', by people we trust. People who check these programs, and who label it 'stable', 'unstable', 'testing' or 'outright dangerous'.
Those who install the Haskell toolchain, normally also install another 'attack vector' on their system, as it comes with its own libraries with root access and its own software distribution system.
The same is true for Flash: It's 'another attack vector', comes with its own library and its own software distribution system. Nonetheless, I'm not that afraid to install Haskell apps from my repository: They seem trustworthy.
And what does it matter if some 'new programming language' is delivered to you by the distribution or through the web, apart from 'trust'? If there was a 'repository' for JavaScript scripts, the issue wouldn't be that big I guess. If those JavaScript applications had a version, were signed with some digest and could be put in some repository with a 'level of trust' associated, how would it differ from distribution using the 'powers that be' channels?
If I were to trust those who make the Mono part in Firefox and the 'apps' it runs, then there wouldn't be an issue I guess. But at this point, it seems there's no kind of 'web of trust' pertaining to web applications. Also, web applications do not have a version number, and normally no digests. Those issues need to be tackled. A 'web of trust' may be a distribution, but why not something more democratic? Something like an app-market system, where users can vote for (yea) or against (nay) an app, and it is removed if it's untrustworthy and breaches security?
If we have GPG key signing parties creating a web of trust, why not expand it to web applications?
Because after all, platform independence seems the future. In the ideal world, it shouldn't matter if you run ARM, X86, X86-64, or MIPS. It shouldn't matter if you run Firefox, IE, Safari or Chrome. It shouldn't matter if you run Linux, Windows, Mac, iPhoneOS or Android. It shouldn't matter if you use APT, portage, AppStore, Android-marketstore, .exe found on the web or anything else. An application developed once should just run everywhere. That's platform independence. That's in the spirit of Free Software: making sure you don't duplicate work already done, by rewriting your applications for different OS'es, re-compiling for different archs, porting for different platforms (phone, smartbook etc.) and stuff like that. Write once, run everywhere. An utopia, I know. But it's getting closer.
And if it is written in one programming language, you shouldn't be forced to rewrite it in another language for some other platform because it doesn't have your programming language.
That's why Linux comes with Haskell, Ruby, Python and Bash, isn't it? To make sure those who wrote something don't have to rewrite it to make it run on Linux.
It probably goes without saying I don't trust Microsoft, Google and especially not Miguel de Icaza. But nonetheless, they could have good ideas, and sometimes they do work (parts of) which benefits society.
It's up to us, the society, to make use of the work which we can use. Like DIN showed, it brings huge savings to companies (and society as well) if companies work together and things are standardized, and don't have to be adopted / tweaked / changed / redesigned for every application. Modularity is good, but to fit one module on another, one needs standards. Indeed, preferably not ECMA, but anyway: To make modules fit they need to interface.
The idea's presented by Miguel aren't all that bad, even if you don't like the guy (I don't, I don't like anyone who adverrtizes OOXML) and think Mono is a way of sponsoring Microsoft.
After all, Google is working on 'something like Miguel proposes':
http://en.wikipedia.org/wiki/Google_Native_Client
To me that reads like a way to run 'native' X86 code in Chrome.
TA, you mentioned Skype more than once.
Well no, I didn't say that. Not even close.
**edit** I'd rather hear about why Miguel's ideas are good, than why those of us who don't see it that way are just anti-Miguel peepee heads. That's neither persuasive nor a basis for any kind of discussion. I've given specific reasons why I think his ideas on this are daft, and there are plenty of well-documented reasons to be wary. So what are the merits? How will Miguel's ideas benefit end users, including users who place a lot of importance in Free Software and what it stands for? What about security and privacy concerns? It takes extra-strength denial powers to wave those away. Try reading this: http://www.sans.org/top-cyber-security-risks/ *****
Quoting: Controlling Hardware via the Browser using HTML5 and JavaScript is acceptable, because (at the moment) the examples where this is used are all using locally installed applications. And other examples of Web enabled applications, where hardware control is possible, are either Proprietary poo (so therefore we won't use them), or are FOSS applications that are locally installed, so it's OK.
The above seems to me to be a reasonable synopsis of your argument.
Well no, I didn't say that. Not even close.
**edit** I'd rather hear about why Miguel's ideas are good, than why those of us who don't see it that way are just anti-Miguel peepee heads. That's neither persuasive nor a basis for any kind of discussion. I've given specific reasons why I think his ideas on this are daft, and there are plenty of well-documented reasons to be wary. So what are the merits? How will Miguel's ideas benefit end users, including users who place a lot of importance in Free Software and what it stands for? What about security and privacy concerns? It takes extra-strength denial powers to wave those away. Try reading this: http://www.sans.org/top-cyber-security-risks/ *****
Speaking of "The Snoop In The Machine", I thought y'all might like this talk:
Eben Moglen - Freedom in The Cloud http://www.youtube.com/watch?v=QOEMv0S8AcA
Eben Moglen - Freedom in The Cloud http://www.youtube.com/watch?v=QOEMv0S8AcA
@jdixon
> If the history of security problems with them doesn't convince, then no. It's enough to convince me.
Which ones? Again do you know of any data to show that they have had more bugs than X (or even su/sudo) for instance. Which sandboxes are you talking about in any case? Hand waving will simply not cut it.
> If the history of security problems with them doesn't convince, then no. It's enough to convince me.
Which ones? Again do you know of any data to show that they have had more bugs than X (or even su/sudo) for instance. Which sandboxes are you talking about in any case? Hand waving will simply not cut it.
Quoting:Well no, I didn't say that. Not even close.
@TC I never said you said that, I said that I condensed that as my understanding of all of your comments.
So what would be a reasonable synopsis? How would you sum up your comments?
tuxchick: Well, an obvious benefit to end users is performance. .NET languages running on Mono will outperform javascript.
But it's not always just about the end user, especially when it comes to choice in languages. It's about the developer(s) as well. Not only do many developers feel that the languages supported by .NET are vastly superior to javascript as far as style, but no one can argue that javascript debuggers and other tools are anywhere close to as good as those for .NET languages. Better tools means faster development, fewer bugs, and often better applications (another benefit to end users).
But it's not always just about the end user, especially when it comes to choice in languages. It's about the developer(s) as well. Not only do many developers feel that the languages supported by .NET are vastly superior to javascript as far as style, but no one can argue that javascript debuggers and other tools are anywhere close to as good as those for .NET languages. Better tools means faster development, fewer bugs, and often better applications (another benefit to end users).
@TC RE SANS, yes it looks like Windows id pretty damn insecure. One would indeed have to have really good powers of denial to ignore that fact.
I'd hazard that it doesn't matter what means of delivery is used to deliver web applications to Windows... HTML5 + JavaScript or the CLI style VM, Windows will get infected somehow. In fact I'd hazard that a CLI style VM might actually improve Windows security slightly, simply because the security model is better than the current model employed in the HTML + JavaScript model.
I should point out here that the fact that Windows is insecure is due to, primarily, design decisions made by Microsoft, NOT because NT is necessarily a less secure design 9in principle) than Linux/Unix, and Windows can certainly be locked down as securely as Linux/Unix. The problem is doing so makes a lot of what Microsoft wants to offer the customer almost impossible.
But we aren't talking about Windows, which is why the SAN link is somewhat irrelevant.
What we are talking about is a CLI style VM, implemented in Browsers, how microsoft implements it on Windows will likely cause security issues, but that's not my problem, how Mozilla does so in Firefox is. So I don't give a rats how insecure Microsoft make it in IE. The fact is the security model as designed for Silverlight, is a good one, probably a lot better than the security model currently employed in HTML + JavaScript... Unfortunately Microsoft have broken the security implementation of Silverlight by allowing ActiveX execution (but once again that is not my problem, it's Microsoft's and their customers, and it has no relevence to what Mozilla ot Google, for example might do).
The fact is that HTML + JavaScript enables exactly the type of hardware control you claim is an issue should a CLI style VM be employed in Browsers The proposed Security model for the CLI style VM is better than the current HTML + JavaScript security model. The ability to choose a more appropriate language than JavaScript is a bonus to developers, which is a bonus to users, as the cluges that are required to produce the same functionality with JavaScript can be done away with, leading to the elimination of one of your personal pet peeves, slow web access. Applications like GMail and Google Docs will probably reach their potential.
I'd hazard that it doesn't matter what means of delivery is used to deliver web applications to Windows... HTML5 + JavaScript or the CLI style VM, Windows will get infected somehow. In fact I'd hazard that a CLI style VM might actually improve Windows security slightly, simply because the security model is better than the current model employed in the HTML + JavaScript model.
I should point out here that the fact that Windows is insecure is due to, primarily, design decisions made by Microsoft, NOT because NT is necessarily a less secure design 9in principle) than Linux/Unix, and Windows can certainly be locked down as securely as Linux/Unix. The problem is doing so makes a lot of what Microsoft wants to offer the customer almost impossible.
But we aren't talking about Windows, which is why the SAN link is somewhat irrelevant.
What we are talking about is a CLI style VM, implemented in Browsers, how microsoft implements it on Windows will likely cause security issues, but that's not my problem, how Mozilla does so in Firefox is. So I don't give a rats how insecure Microsoft make it in IE. The fact is the security model as designed for Silverlight, is a good one, probably a lot better than the security model currently employed in HTML + JavaScript... Unfortunately Microsoft have broken the security implementation of Silverlight by allowing ActiveX execution (but once again that is not my problem, it's Microsoft's and their customers, and it has no relevence to what Mozilla ot Google, for example might do).
The fact is that HTML + JavaScript enables exactly the type of hardware control you claim is an issue should a CLI style VM be employed in Browsers The proposed Security model for the CLI style VM is better than the current HTML + JavaScript security model. The ability to choose a more appropriate language than JavaScript is a bonus to developers, which is a bonus to users, as the cluges that are required to produce the same functionality with JavaScript can be done away with, leading to the elimination of one of your personal pet peeves, slow web access. Applications like GMail and Google Docs will probably reach their potential.
> The proposed Security model for the CLI style VM is better than the current HTML + JavaScript security model.
Agreed. That still doesn't make building it into the browser a good idea. Make it an add-on, which can be installed at the user's discretion.
Agreed. That still doesn't make building it into the browser a good idea. Make it an add-on, which can be installed at the user's discretion.
@JD, I'd be happy with it either way.
and as Hans said
This is not like what Miguel is talking about, it is the same as. What Google is working on here is a CLR (Common Language Runtime), based on a CLI (Commom Language Infrastructure) like the Mono/.NET one, only it's not Mono/.NET.
The point of it is that it improves on what we have with HTML + JavaScript. It's not about embedding some sort of spy network into the browser - we have that already, in spades, with HTML + JavaScript (and the proprietary browser builders could do it anyway and not tell us), what we are not currently getting in return for the free spying is a decent web experience.
and as Hans said
Quoting:After all, Google is working on 'something like Miguel proposes':
http://en.wikipedia.org/wiki/Google_Native_Client
To me that reads like a way to run 'native' X86 code in Chrome.
This is not like what Miguel is talking about, it is the same as. What Google is working on here is a CLR (Common Language Runtime), based on a CLI (Commom Language Infrastructure) like the Mono/.NET one, only it's not Mono/.NET.
The point of it is that it improves on what we have with HTML + JavaScript. It's not about embedding some sort of spy network into the browser - we have that already, in spades, with HTML + JavaScript (and the proprietary browser builders could do it anyway and not tell us), what we are not currently getting in return for the free spying is a decent web experience.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
I know. See my comment about Javascript above. Fortunately, that's why there's NoScript.