Microsoft's Bob Muglia and Ray Ozzie on Silverlight vs. standards

With regard to the borderline between "proprietary" and "standard," there's something that has been sticking in Ray Ozzie's craw. He was well-behaved, for most of the afternoon, avoiding too much use of the "G" word. (Not "Gillmor.") But Google's recent behavior (the Chrome OS announcement event was still two days away at this point) clearly has Ozzie upset, especially with regard to how he perceives it tries to define "the Web" in its own image, moving the boundary between standards and proprietary protocols as it chooses.

"The thing that's tough is the thing in-between, and this is what really did surprise me about what Google did. The Chrome Frame thing is basically saying, 'Well, we believe in standards, but we're going to put our implementation that's beyond standards into someone else's frame.'"

Chrome Frame is the company's unsanctioned add-on to Internet Explorer that enables it to deliver designated Web pages through Chrome's browser engine rather than IE's. I asked Ozzie whether he believed Chrome Frame was just bluster on Google's part, a tactic to make folks like Ozzie upset. His answer indicated he did not believe so; he takes Chrome Frame quite seriously, as something designed to blur the line for Web developers who are legitimately trying to determine what their clients are running, and publish Web pages to that platform -- a kind of smokescreen.

The reason it's important for that dividing line to be clear, both Microsoft executives argued, is because applications need clear security boundaries, and Web applications must be more constrained about their security and permissions than "installed" apps on the user's system. "The two big differences between .NET Framework writ large and Silverlight are the execution model within which they operate, and the level of function," Ozzie explained.

Muglia took it from there: "As far as we can see, there will be a difference between the security context of running in a browser, and having a user make a decision to install (I use that word loosely) an application on their machine and provide access to physical resources...You can start to do that with Silverlight 3; you'll continue to see us do more there. For example, when we built Visual Studio 2010, almost all the new code and a very large part of the application is written in WPF. We're not to that point with Silverlight; there's no question about it, we can't build that application today with Silverlight. The day may come when we may continue to build more services and capabilities into Silverlight where you can build an application of that level of complexity, and that's true because all these environments continue to evolve."

Surprisingly, Ozzie's later comment bordered on contradicting Muglia: He sees an evolution of the development model where, in his words, "over time, both Silverlight and the browser get closer and closer to the OS.

"Whether it's the accelerometer or compass or whatever I/O devices, over time, all of these things are going to end up having to be permissioned...by the user to do extended things, and those will be used for installed apps probably first, but maybe even for Web-based apps, I have no idea. And I think therein lies some of the biggest challenge that we have moving forward. In AIR and Silverlight, you're going to see us pushing at the edge on what Web apps are just now doing with OAuth, where the user has permissioned a site to do something. Well, we're also going to have to have the application permissioning the client to do something, to have access to my local data, to my microphone or speaker; and that permissioning on the Web is done at the Web site level. I'm not sure yet what the right granularity is for the client. Is the client just a signed piece of the Web site that you're permissioning; once you permission the Web site, [does] the client have the permission to do these things? We're in new territory here."

More of our Lunch with Bob & Ray later this week in Betanews.