big brother watching?
|
Author | Content |
---|---|
djohnston May 04, 2010 2:24 AM EDT |
Miguel says, "Perhaps the time has come to experiment embedding the ECMA CLI inside the browser. Not as a separate plugin, and not as a plugin island, but as a first-class VM inside the browser. Running side-by-side to the Javascript engine. Such an effort would have two goals: * Access to new languages inside the browser, optionally statically typed for major performance boosts. * A new platform for innovating on the browser by providing a safe mechanism to extend the browser APIs. We could do this by linking Mono directly into the browser." then, "Trusted platform code is granted special permissions that untrusted code is not given. The runtime enforces that no untrusted code can call into any security sensitive and protected areas. This would allow browser vendor to expose new APIs that get full access to the underlying operating system (for example getting direct access to special hardware on the system like microphones and camera) while enforcing that the user code accesses them only through safe gateways." Hmmm... |
gus3 May 04, 2010 2:49 AM EDT |
"Trusted," "untrusted"... As defined by whom? Microsoft? Gag me with a five-course table setting. |
cr May 04, 2010 6:13 AM EDT |
From AHD: trust n. 9. A combination of firms or corporations for the purpose of reducing competition and controlling prices throughout a business or industry. --See Synonyms at monopoly. As long as you keep that definition in mind when reading about anything having to do with Microsoft, Windows, or Miguel, their meaning is quite clear. |
tracyanne May 04, 2010 8:20 AM EDT |
Trusted, as in known to be secure and safe to execute., existing within the sandbox. Untrusted code is code that is not executed in the sandbox, and is there fore an unknown in terms of secirity and fitness to execute. Some people... If this had been about anything other than Mono or .NET, none of you would have commented about trusted and untrusted. |
TxtEdMacs May 04, 2010 8:35 AM EDT |
You people ... you just don't get it. It's so frustrating to explain these simple concepts. So let's start with Privacy, hey if you have nothing to hide you don't need it. Get it? So for your best interests it is advisable to spy on every one, that way you reduce the overall efficiency of the process making it more likely really important breaches will go unnoticed. But fear with prevail and thus Trust will predominate. Well if you cannot trust a few good Corporations, who can you trust? Moreover, you know by law what drives them: profit at everyones' expense. No unconscious motivators to complicate the picture. So relax, you will be watched by the most trustworthy in our collective societies. YBT |
tracyanne May 04, 2010 8:41 AM EDT |
It's a real pity, Some interesting ideas, which could be discussed, will be buried by stupid knee jerk paranoid comments. |
gus3 May 04, 2010 10:07 AM EDT |
@tracyanne: I know that, taking context into account, you are correct. However, given Microsoft's track record in security matters, I'm still loath to trust their definition of "trust." EDIT: And that's hardly the only example. |
tuxchick May 04, 2010 10:09 AM EDT |
TA, MS' Trusted computing initiative is just another Newspeak smokescreen for their usual security incompetence and customer-hostile activities. Anyone who buys into it is fair game for criticism. |
tuxchick May 04, 2010 10:55 AM EDT |
And yes, I am kneejerk suspicious of extending the power of Web browsers to do stuff, because it is stuff on MY system that is not transparent, sucking up MY system resources, opening MY system to security risks and invasions, and how many lessons do we need in how unwise this is? The biggest resource hog bringing my three- core PC to its knees is not movie editing, nor photo editing, nor multi-track audio editing-- it is Web surfing. This is nuts. At least with plugins we have the option to use them or not. Miguel wants this garbage to be browser-native and unavoidable. fave quote: "Pre-emptive answer to the "view-source" crowd: you can use .NET Reflector to look at the source code of a compiled binary" |
cr May 04, 2010 11:14 AM EDT |
Quoting:Miguel wants this garbage to be browser-native and unavoidable. ...like Active-X. |
jdixon May 04, 2010 12:48 PM EDT |
> ...like Active-X. Pretty much, yes. And as with Active-X, anyone who thinks this is a good idea has serious problems understanding human nature and security. |
TxtEdMacs May 04, 2010 1:41 PM EDT |
Quoting: [...] with Active-X, anyone who thinks this is a good idea has serious problems understanding human nature and security.Proving: "Love is Blind", which proves* ... YBT * A classic knee jerker. Me not TC, I am pretty sure**. ** To TA, while writing my mini screed, I could not get Australian web filters out of my mind but that would have diluted the focus. So, instead I concentrated upon the corporate side of the Trust issue. |
Bob_Robertson May 04, 2010 2:30 PM EDT |
An old friend of mine, who was deep into the US military security, said that the military defines a "trusted" system as one which could seriously break things. It was a flag meant to show where attention had to be paid in order to prevent problems. I do not "trust" the cloud. I do not consider security "on the cloud" to be actual security. As far as I'm concerned, everything traversing "the cloud" is open and readable to everyone who wants it. I "trust" my local machine, because I have to. PGP/GPG is due for a resurgence. |
tracyanne May 04, 2010 5:22 PM EDT |
@TCQuoting:TA, MS' Trusted computing initiative is just another Newspeak smokescreen Trusted code, as mentioned in the article has N6THING, ABSOLUTELY NOTHING to do with "Trusted" computing. @CR Mono .NET CLI has nothing to do with ActiveX, it's no different than running Java in the browser. ActiveX would come under the heading of untrusted code. Mono or .NET CLI languages and Java running in a sandbox, as it's supposed to, would be considered trusted code. As I said, stupid knee jerk paranoid comments, merely because it's somehow related to Microsoft. Trusted Code has nothing to do with "Trusted" Computing Richard. Get a grip on reality, instead of what you are currently holding. |
tracyanne May 04, 2010 5:49 PM EDT |
Quoting:At least with plugins we have the option to use them or not. Miguel wants this garbage to be browser-native and unavoidable. Now that's probably a good reason to disapprove of Miguel's suggestions. But dismissing it because it's Mono/.Net, and the word Trusted, was mentioned, and equating that to "Trusted" Computing, as some commentators have, shows an incredible ignorance, and paranoia. I think I can safely state that had this not been Mono/.Net, but instead some "approved" Free Open Source languages/frameworks, we would not have seen these paranoid comments, and instead we would have seen some more reasonable discussion. |
djohnston May 04, 2010 5:53 PM EDT |
Quoting:Some people... Not true, tracyanne. I understand you may be fed up with Mono opponents. My comment wasn't aimed at Mono. It was aimed at the notion that a web browser might have unfettered access to the underlying hardware. And I agree 100% with tuxchick about the antics of Microsoft. Fool me once, shame on you. Fool me twice, ... |
tracyanne May 04, 2010 6:02 PM EDT |
Quoting: And I agree 100% with tuxchick about the antics of Microsoft. Fool me once, shame on you. Fool me twice, ... Once again you read too much into the use of the word trusted. The antics of Microsoft have nothing to do with the use of, or not, of Trusted Code. All browser add ons are by definition trusted code. BTW the browser already has full access to the computer hardware, via the OS, in exactly the same way as any other local application does. The point of Trusted code (whether it's Mono/.Net languages or Perl or PHP or C/C++ or Python etc), is that it has to request the browser to do what the browser is currently allowed to do, unlike untrusted code, like Active X, which can, and does (on Windows, anyway) access the hardware via the OS independent of the Browser. |
djohnston May 04, 2010 6:29 PM EDT |
Quoting:Once again you read too much into the use of the word trusted. I know what trusted vs. untrusted code does. I know that the Trusted Platform module has little to do with Microsoft, and is instead encoded in a chip on the motherboard. I stand by my statements. Microsoft is NOT to be trusted in any way, shape, or form. They are experts at doublespeak. No, Microsoft isn't mentioned in the context of the article. But we all know the relationship between .NET and Mono. And we all know that Microsoft's CEO keeps bandying about the accusation that Linux somehow infringes on Microsoft's patents. Let me be perfectly clear. If there is ANY hint that Microsoft is involved in software methods or development relating to FOSS, my BS detector comes into play almost immediately. Call it the survival instinct. |
tracyanne May 04, 2010 6:33 PM EDT |
@dj. I think you've just proved my point. |
tracyanne May 04, 2010 7:05 PM EDT |
Some people might find this interesting http://techcrunch.com/2010/04/30/joe-hewitt-web-development/... But i suspect most here will fixate on the Microsoft bits andd give us yet another rant about Microsoft can't be trusted. I live in hope that, instead we'll get some interesting comment on the technologies instead. |
KernelShepard May 04, 2010 8:16 PM EDT |
I have to agree with Joe Hewitt on the sad state of web development and think that adding support for .NET (or even Java) would be a huge improvement over javascript. Also awed by people's lack of understanding of what is meant by "trusted" in this context. Are people really that out of touch? (glad tracyanne was able to set things straight) |
hkwint May 04, 2010 10:13 PM EDT |
I was writing a lengthy piece, but it became too long, so I'll try to summarize. What it all boils down to is this: Standardization organizations are slow, as noted by Mr. Hewitt. But they're there for a reason: Vendor lock-in sucks. Hence why DIN was founded in 1917: Because by then people realized 'letting the market pick a winner' was not the best idea after all. But indeed, ISO is slow (apart from the fact they sold out to Microsoft), and sometimes people don't pick a winner, like with Gnome vs. KDE. The solution is 'companies working together (OpenGL ES, CD, 802.11n, Freedesktop)', not companies competing on standards and doing their own thing (BD vs. HD-DVD, WiMax vs. LTE and so on), like Mr. Hewitt promotes. He assumes 'people don't lose anything' if they need to switch browsers, but he underestimates the value of the efforts put into a platform. When that platform loses, like HD-DVD, all money and effort are down the drain. WebGL is a nice example of how life could be: Mozilla and Google are leading the way, Opera is following a bit later, Apple might be interested and Microsoft is welcome but they don't care. WebGL is development ahead of W3C, which is a good thing; here Mr. Hewitt is right. But it's not "1 party only". Because if it was Mozilla only, I wouldn't invest my time in WebGL. And there's also not much competition from other standards. Sure, some new MS Common Language Runtime would be using DirectX I suppose, and when talking about technology: DirectX is ahead of OpenGL, but DirectX doesn't work beyond Windows. Others know much more about the technologies of .NET, that's not up to me. I'd like to do web development in another language as Javascript, who doesn't? More choices of languages (developer freedom!) is a good thing, and when it comes with a good development environment: More power to MS. But here's the issue: Microsoft is trying to lock developers into one development platform, hoping they don't take the effort to learn a second platform (hence "developers bis 88x while jumping"). Also, they use their standards such as OOXML and Silverlight to make sure Windows and MS Office are leading while support for those 'cross platform technologies' on other platforms is lagging behind by one or two years. Therefore, Microsofts cross-platform standards are a way to lock people in into Windows (broken English I'm afraid?). That's almost literally (!) taken from 'genuine Microsoft Ohio-memos'. So why can't they do it like WebGL is done: If they want Common Language in browsers and the Mono-team wants to join, then do it 'together' ahead of W3C. Just ask Google, Mozilla, Opera and Apple to co-operate. Who doesn't want to, doesn't. However, if Microsoft did ask for cooperation, then Common Language on Linux and iPhoneOS might work just as good as on Windows. Then what does Microsoft gain? The interests of customers/society and the industry often conflicts. Hence why there's ECMA: It's standardization for the industries sake (rule 1 of the bylaws!) When it costs the society, the industry doesn't mind as long as they fill their pockets. That's why I'm wary of ECMA-CLI: Anything ECMA might screw customers, just in the way OOXML did. Now how can someone be called paranoid for ECMA-stuff after the whole OOXML saga? And after the Ohio-docs where Microsoft is stating cross-platform technologies are used to lock people into Windows? In the 'old-fashioned' industry, DIN and their successors have been tackling this issue for decades. Then why should we make the same 'long solved' problems again? |
gus3 May 04, 2010 11:02 PM EDT |
From the first comment, quoting M. de Icaza:Quoting:Trusted platform code is granted special permissions that untrusted code is not given. The runtime enforces that no untrusted code can call into any security sensitive and protected areas."Trusted" for Mono is like "verified" for Java. http://www.mono-project.com/MonoSandbox However, there are two strikes against Microsoft in this parallel: 1. Sun Microsystems was "older school" than Microsoft, as concerns the academic approach to computer programming/development. Sun had experience in CPU design, as well as software design. Microsoft is pretty much a "software only" company, with much less rigorous standards for proving designs correct. Their record of "ship first, fix later" demonstrates this (Windows Vista, anyone?). Sun tried playing that game later; I think it's part of what did them in. 2. Java (and support libraries/classes) first appeared in 1995; C# (and support libraries/DLL's) appeared in 2001. So let's say that C# is "approximately" six years behind Java. Even with Sun's academic rigors feeding into Java, it's still getting security fixes fifteen years later. How does Microsoft intend C# to overtake Java on this point? I'm not saying they can't; more power to them if they can. Yes, I'd like to be proven wrong on this point. Real improvement to the Windows security infrastructure would send beneficial ripples through the entire computing ecosystem. But I don't know if the task would be Herculean or Sisyphean in nature. |
KernelShepard May 05, 2010 8:29 AM EDT |
Your 2 strikes are both supposition based on your own biases. Your first assumption is that because Sun helped design some CPUs back in the day, that they somehow must have designed a better security model in Java 15+ years ago than what Microsoft could have possibly implemented much later. But you neglect that it is very possible that Microsoft had learned from Sun's implementation in Java (and possibly others). You also neglect the fact that Intel was involved in the development of .NET (so there you have your CPU design experts, "woops" goes your argument!). Your second argument assumes that Microsoft has made the same design mistakes that Java has. You might find the following paper interesting: http://www.cs.virginia.edu/~nrp3d/papers/computers_and_secur... Quoting:Both platforms share many design and implementation properties, but there are key differences between Java and .NET that have an impact on their security. This paper examines how .NET’s design avoids vulnerabilities and limitations discovered in Java and discusses lessons learned (and missed) from experience with Java security. |
Bob_Robertson May 05, 2010 8:44 AM EDT |
Hk, yes, I was thinking the same kinds of things reading that article http://techcrunch.com/2010/04/30/joe-hewitt-web-development/... What he seems to have conveniently forgotten is that some people don't run Windows. The "great innovations" of I.E. left big smoking holes in the 'Net for everyone else. The reason Microsoft (and Netscape) were both shamed into writing to standards was because not doing so was making everyone angry, one way or the other. As to "more powerful", I really could not care less how convenient it is for a developer to load down a web page with sparkling, moving, bandwidth-sucking content. In fact, the more inconvenient it is the better. Sadly, the TechCrunch comment engine choked on my Konqueror browser, so I couldn't even leave a comment. Coincidence? |
KernelShepard May 05, 2010 9:06 AM EDT |
hkwint / Bob: I agree with what you guys are saying to a degree, but I also agree with Hewitt in that I believe that allowing browser developers to innovate more freely is important to make the web a much better development platform. Since most of the browsers these days are based around an open source engine, I think that makes this more doable than back when it was Microsoft vs Netscape - but even in those days, we got great innovations that benefited everyone (DOM, XMLHttpRequest, etc). |
gus3 May 05, 2010 9:26 AM EDT |
KS, good points about my first assumption. I didn't know .NET was a product of the Wintel empire. (I'll reserve judgment on whether that's a good thing or not.) However, you're wrong about my second argument. I'm not talking about specific design mistakes, or even specific types of design mistakes. I'm considering it merely from the maturation process of any large software project, which is mostly unchanged since Fred Brooks and OS/360. http://en.wikipedia.org/wiki/The_mythical_man-month As for the paper you link, it has its own big, bad, smoking gun assumption: Quoting:The contrast with the .NET platform, in which no major security vulnerabilities have yet been found, appears striking.The assumption in this case equates "found" with "reported." One need only search Google for microsoft security "privately reported" to see this is clearly not the case. |
KernelShepard May 05, 2010 9:44 AM EDT |
gus3: Had you read the article, you'd see that Microsoft learned from Java's bad security model design mistakes and designed a much better security model for .NET. The "smoking gun assumption" that you refer to was their "huh, why is that?" moment. The article dives into the security models for both the JVM and .NET to see how the different models work. Having done your google search, I'm left wondering if you bothered to sift through them enough to figure out which ones are related to the .NET VM (as opposed to the vast majority which are not - heck, most aren't even related to .NET at all) and which of those are design problems vs implementation bugs. Implementation bugs can easily be fixed, design problems are what concern me, especially since, if this proposal were to happen, the .NET VM included in Firefox (for example) would not be the same as the one included in IE, and so exploits that exist for one runtime are less likely to exist for another. I'd also like to point out that since Firefox/Chrome+Mono are Free Software, it is likely that any exploits that target implementation bugs in those platforms could be patched a lot faster than those in IE+.NET. |
gus3 May 05, 2010 10:13 AM EDT |
Quoting:Having done your google search, I'm left wondering if you bothered to sift through them enough to figure out which ones are related to the .NET VM (as opposed to the vast majority which are notAgain, forest and trees. I was trying to show public evidence of Microsoft policy, not .NET bugs. The point is, we don't know how many bugs in .NET have been found and fixed, nor the security implications of those bugs. We only know the public statements from Microsoft. Those outside Microsoft, who have access to the code and know the nature of these patches, are under NDA. |
KernelShepard May 05, 2010 10:49 AM EDT |
gus3: I fail to see the point of your argument. You seem to be grasping at straws. We don't know how many security flaws have been in Java either, nor does it matter. What matters is that the design of the security model in .NET is good, not whether there are implementation bugs in Microsoft's version because Firefox and Chrome, for example, wouldn't be embedding Microsoft's .NET VM anyway, they'd be embedding Mono's (or DotGNU's I suppose). |
Scott_Ruecker May 05, 2010 3:06 PM EDT |
@Hans..you post above has the makings of a good editorial..;-) |
tracyanne May 05, 2010 6:15 PM EDT |
Quoting:Others know much more about the technologies of .NET, that's not up to me. I'd like to do web development in another language as Javascript, who doesn't? More choices of languages (developer freedom!) is a good thing, and when it comes with a good development environment: More choice of languages, for web development, can, I believe, only be a good thing. Perhaps javascript will improve to a point where it is really is a language that integrates really well, but from my point of view, even with Dojo and JQuery and other javascript frameworks, there is still a huge disconnect, and much left that I, at least, desire, I think there are some good points about a Standards supported VM built into browsers, and as was pointed out most rendering engines these days are Free Open Source. Yes the security model of .NET is quite good, this model, is, of course implemented in Mono as well, but, regardless of any potential shortcomings in the implementation in .NET, it's a good model to work from. In addition, most short comings in .NET's implementation are likely to be as a result of shortcomings in the base OS design. With regard to Forests and Trees, there are some people who are so fixated on a single tree in the vastness of the forest that they are unable to explore the rest of the forest, it's really sad. Thanks Hans and KS for some interesting comments. |
tuxchick May 05, 2010 11:45 PM EDT |
Thanks Hans, I think you're right on. Trust is most definitely the key word here, and the way Miguel uses it is laughable. Is it wise to trust Miguel, who adores MS and devotes his energies to replicating and perpetuating MS technologies? ECMA is an industry lapdog, a big joke in any discussion about standards. Is it wise to trust this new movement towards executing even more remote code in Web browsers? How many times must this be proven to be folly? Who knows what the #1 security hole and attack vector is these days? Raise your hands-- that's right, Web browsers, via cross-site scripting and other remote code execution attacks. Who is going to decide which code is trusted and gets to do whatever it wants on your PC, as Miguel so happily propounds? Quoting: Trusted platform code is granted special permissions...This would allow browser vendor to expose new APIs that get full access to the underlying operating system (for example getting direct access to special hardware on the system like microphones and camera) while enforcing that the user code accesses them only through safe gateways. Compounding his folly he says: Quoting: The security model exposed by Silverlight.... Right. Let's look to MS for security wisdom. And then expresses scorn for FOSS, and its principles of openness and accountability: Quoting: Pre-emptive answer to the "view-source" crowd: you can use .NET Reflector to look at the source code of a compiled binary. But didn't he say this exciting new idea allows for all different languages? Why yes he did. Does that mean the .NET Reflector is the magic Rosetta stone for de-compiling all binaries? But pshaw, Miguel thinks we don't need that anyway, just trust our friendly devs. Quoting: A wide variety of languages would have become first-class citizens on the web client. Today those languages can run, but they can run in plugin islands. They can run inside Flash or they can run inside Silverlight, but they are second class citizens: they run on separate VMs, and they are constrained on how they talk to the browser with very limited APIs.. And yet, despite being cruelly shackled and confined, Flash is still a major malware vector. I have a better idea. Let's go back to not welcoming the execution of remote code on our computers. In what universe did it suddenly become acceptable to give control of our PCs to someone else? How have they earned such trust? Why should there be any remote control given to mics and cameras, or the underlying operating system? Yes, these are features that could be valuable to users. But this guff isn't about cool features that we like and control, it's giving up control. It's bad enough they want to suck up our GPU cycles-- they're not content to bring multi-core systems to their knees with crappy runtimes and scripting, they want to fry our GPUs and have complete run of all of our computers and peripherals. Trust Miguel's schemes? No thanks. |
tracyanne May 06, 2010 12:37 AM EDT |
Quoting:But didn't he say this exciting new idea allows for all different languages? Why yes he did. Does that mean the .NET Reflector is the magic Rosetta stone for de-compiling all binaries? But pshaw, Miguel thinks we don't need that anyway, just trust our friendly devs. If such a VM LIKE (or similar to, for those fixated on Microsoft) Mono/.NET is employed, then yes the Reflector functionality would be available to all languages that run on that VM. Which means, yes such a relector would be the "magic Rosetta Stone" Quoting:I have a better idea. Let's go back to not welcoming the execution of remote code on our computers. In what universe did it suddenly become acceptable to give control of our PCs to someone else? How have they earned such trust? Why should there be any remote control given to mics and cameras, or the underlying operating system? For the exceptionally paranoid, a heads up, you have already given someone else access to the hardware on your computer, by installing software on it. Software like browsers, and other web enabled applications, all potentially give someone else access to your computer already. Applications like Skype and Sipphone and any other camera enabled FOSS application that connects to the web, are already able to control the sound system and the camera on Linux computers. Those who use such applications have already allowed such things to happen. What is really interesting to me is the potential that such a VM would give to web developers to build applications that can make the same sort of interactivity possible that is only dreamed of in the Javascript powered applications like Gmail for example. |
tuxchick May 06, 2010 12:52 AM EDT |
TA, are you really saying you don't understand the difference between locally installed software under the control of the user, and Web browsers that allow someone else to control your system? Nor do I find "Oh, it's already happening, lie back and enjoy it" a persuasive argument. |
tracyanne May 06, 2010 1:09 AM EDT |
So TC are you trying to tell me that someone with your obvious intelligence did not understand that when you started using such applications you were agreeing that the application would have that sort of control over the hardware? The point is NOT "lie back and enjoy it" but, INSTEAD, that it need not be the issue you claim it to be. But if you are that concerned, then I suggest you stop using any and all local applications that have any sort of Web or remote server capabilities, because you are already by choice using applications that at least some of the capabilities you seem so afraid of, and as far as I can tell you have not been bitten by them, and you are opting in every time you use them... I'm assuming that you use something like Lin phone or SIP phone or even, God forbid, Skype, a Browser with Javascript enabled (no wonder you web access is so slow and cludgy), Flash. I fully understand the difference between locally installed and server based applications, such as those that run in Web browsers. The point here, and what Miguel and others are attempting to do, is explore new ways of using technology, and while security concerns are justified, the exceptionally paranoid here seem to be fixated on their lack of trust for Microsoft, and seem to be missing out on being part of a potentially interesting conversation. And many of the things that are dredged up as issues are apparently not issues in other contexts of how you use the web. BTW, the sorts of things you are worried about... direct hardware control via the browser, are already possible using HTML5 and JavaScript on the client side., and I expect that a lot of people will take advantage of the possibilities that it offers, in ways other than those explored in the article... http://www.techworld.com.au/article/345260/need_desktop_acce... but neither Miguel nor Microsoft made this possible, so we can all breath easy. Quoting:Guacamole is a HTML5 and JavaScript (Ajax) VNC viewer, which makes use of a VNC-to-XML proxy server written in Java. |
KernelShepard May 06, 2010 7:58 AM EDT |
tuxchick: The article I linked to gus3 above explains how trusted code works in .NET and Java, you seem to not understand how it works. I suggest you read it and possibly other resources that explain it. The gist of it is that untrusted code (e.g. anything from the web) is not given permissions to access the system without user consent. It can take advantage of hardware resources via an abstraction that prevents it from doing nasty things, but it can't go making native calls that could compromise your system. As you may or may not be aware, VM's such as the JVM, Mono, and the .NET VM (among many others) do a number of things to verify that the code they are about to execute won't cause exploits (e.g. array bounds checking which prevents the most common attack vector). In addition, these VM's also support a sandboxing mode where they can prevent the applet from accessing areas of the filesystem and other resources that might normally be available to installed applications that run on those same runtimes. I hope that helps. |
jdixon May 06, 2010 9:23 AM EDT |
> Let's go back to not welcoming the execution of remote code on our computers. In what universe did it suddenly become acceptable to give control of our PCs to someone else? Exactly. > The point is NOT "lie back and enjoy it" but, INSTEAD, that it need not be the issue you claim it to be. It need not be, but somehow it always is, TA. In theory, 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 disaster. Yes, we've gotten better at it, but not enough better to make it a good idea. Java doesn't come preinstalled in the browser (Javascript does, unfortunately). You have to choose to add it. That's the way it should be. |
tracyanne May 06, 2010 9:42 AM EDT |
Quoting:In what universe did it suddenly become acceptable to give control of our PCs to someone else? This one... apparently. and..... Quoting:In theory, 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 disaster. see my previous comment, then of the one you responded to. No sand box, just HTML and JavaScript. holy Guacamole, we don't need a VM, Java or mono/.net. Good ol HTML + JavaScript is already capable of what you fear. |
jdixon May 06, 2010 10:48 AM EDT |
> Good ol HTML + JavaScript is already capable of what you fear. I know. See my comment about Javascript above. Fortunately, that's why there's NoScript. |
krisum May 06, 2010 5:09 PM EDT |
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. |
tracyanne May 06, 2010 5:44 PM EDT |
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. |
gus3 May 06, 2010 6:03 PM EDT |
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! |
KernelShepard May 06, 2010 6:42 PM EDT |
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. |
tuxchick May 06, 2010 6:56 PM EDT |
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. |
gus3 May 06, 2010 7:36 PM EDT |
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. |
TxtEdMacs May 06, 2010 8:11 PM EDT |
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 |
tracyanne May 06, 2010 8:44 PM EDT |
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. |
KernelShepard May 07, 2010 8:49 AM EDT |
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. |
jdixon May 07, 2010 10:50 AM EDT |
> 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. |
hkwint May 07, 2010 1:24 PM EDT |
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. |
tuxchick May 07, 2010 3:08 PM EDT |
TA, you mentioned Skype more than once.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. 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/ ***** |
Bob_Robertson May 07, 2010 3:35 PM EDT |
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 |
krisum May 07, 2010 5:05 PM EDT |
@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. |
tracyanne May 07, 2010 5:53 PM EDT |
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? |
KernelShepard May 07, 2010 5:58 PM EDT |
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). |
tracyanne May 07, 2010 6:37 PM EDT |
@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. |
jdixon May 10, 2010 8:34 AM EDT |
> 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. |
tracyanne May 10, 2010 6:08 PM EDT |
@JD, I'd be happy with it either way. and as Hans said Quoting:After all, Google is working on 'something like Miguel proposes': 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. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!