<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.msdn.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx</link><description>I can't seem to log into Neowin to leave a comment on yesterday's interview but there was one post from FloatingFatMan that I wanted to comment on: I'd personally HATE to be on the IE dev team, cause you know that no matter what you do, a sizable portion</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61025.2)</generator><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#365453</link><pubDate>Wed, 02 Feb 2005 15:33:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:365453</guid><dc:creator>Berger</dc:creator><description>Hey Dave, That kind of critisism is recieved by pretty much anyone who does anything for the public, wether it be software development, musicians, politicians, etc. It must be relized that it is often completely illigitamet critisism and ignored.&lt;br&gt;&lt;br&gt;On the other hand you MUST know that IE has done some pretty obsurd things (not that they are your fault of course) that are deserving of some VERY harsh critism, such as no PNG transparency support for the longest time when it could have been implemented years ago and made webdesigning so much more fun/easy.&lt;br&gt;&lt;br&gt;By the way, this has nothing to do with this post, but what do you think are the chances that by the time Longhorn and IE 7 ships, there STILL won't be PNG alpha transparency support in the browser?</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#365473</link><pubDate>Wed, 02 Feb 2005 15:54:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:365473</guid><dc:creator>Dave Massy</dc:creator><description>Yes some criticism is justified and having a thick skin isn't the same as not listening. We are listening adn hoping to address some of the key complaints. I do want to be clear that I don't see that as a reason to hate my job.&lt;br&gt;I can't comment on specific features and schedule for future releases at the moment. We certainly understand that alpha transparency of PNG is a top issue.&lt;br&gt;&lt;br&gt;Thanks&lt;br&gt;-Dave</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#365485</link><pubDate>Wed, 02 Feb 2005 16:09:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:365485</guid><dc:creator>Peter da Silva</dc:creator><description>&amp;quot;some criticism is justified and having a thick skin isn't the same as not listening&amp;quot;&lt;br&gt;&lt;br&gt;I hope so. I'd REALLY like to talk to you guys about your basic security model, then, because I've been criticising it since, oh, about 1997... and there's been no sign that there's ever going to be any changes in the fundamental design flaws that led me to ban IE (and any 'internet-aware' app that used the HTML control) back around then.</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#365494</link><pubDate>Wed, 02 Feb 2005 16:21:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:365494</guid><dc:creator>Dave Massy</dc:creator><description>Peter,&lt;br&gt;We're always listening. Security issues however are often best discussed offline and I'd encourage you to contact me offline through this blog. I don't say that because we are trying to duck an issue but because if there is an issue we believe strongly in responsible disclosure so that the bad guys are not equipped with ideas on how to launch an attack.&lt;br&gt;Thanks&lt;br&gt;-Dave</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#365569</link><pubDate>Wed, 02 Feb 2005 17:37:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:365569</guid><dc:creator>Brady J. Frey</dc:creator><description>I think YOU'RE listening Dave... but you're the only developer for IE that I've heard openly, and whole-heartedly discuss these issues. &lt;br&gt;&lt;br&gt;Quark Xpress always listened to us designers as well, but still let it's software stagnate to the point that we were actively looking for alternatives; and Adobe, with a history of quality updates and feedback, answered the call. I view microsoft's IE much in the same way, and I think a lot of people agree. The silence works well for Apple's marketing since they usually produce enthusiastic products, and we come to expect that... I see little if any of the same buzz around IE - by definition it's more frustration than excitement.&lt;br&gt;&lt;br&gt;In the end, I think all this silence has just burned me out to the point that should IE come out improved - why should I care? Will it be another 4 years until those bugs are addressed? This atmosphere of secrecy hasn't boasted a love between consumer and company.</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#365737</link><pubDate>Wed, 02 Feb 2005 20:38:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:365737</guid><dc:creator>Tim Marman</dc:creator><description>If I join the team, can I fix the broke-ass security zone model? :)</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#365837</link><pubDate>Wed, 02 Feb 2005 22:28:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:365837</guid><dc:creator>Peter da Silva</dc:creator><description>&amp;quot;if there is an issue we believe strongly in responsible disclosure so that the bad guys are not equipped with ideas on how to launch an attack&amp;quot;&lt;br&gt;&lt;br&gt;Buddy, the bad guys already know this one. There's no secret, except maybe from Microsoft.&lt;br&gt;&lt;br&gt;The problem is that the decision about what rights an object should have, in a mandatory access control environment, need to be made at the point of entry and there must not be a mechanism to increase them without the explicit approval of a responsible party.&lt;br&gt;&lt;br&gt;In the case of a web browser, the point of entry is the browser, and the responsible party is the user. With IE, the decision as to what rights an object might have are based on the location or an externally provided certificate, because tehy're made by an object (the HTML control) that has to reverse-engineer the origin and rights of teh object based on their &amp;quot;security zone&amp;quot;.&lt;br&gt;&lt;br&gt;There are a bunch of ways to fix it. The simplest one is to split the HTML control into an HTML control (that does rendering of HTML, but that's all) and an HTTP control (that the application could use to access remote objects), and keep the application in the loop at all times (via callbacks, for example).&lt;br&gt;&lt;br&gt;For a bit more efficiency,  you could have an attribute associated with an object that says it's &amp;quot;trusted&amp;quot; or &amp;quot;untrusted&amp;quot;. This attribute would be unerasable. If a transition couldn't preserve it (say, saving to a file) then that transition would not be possible... you'd have to go back to the application and say &amp;quot;am I allowed to save this to a file&amp;quot;?&lt;br&gt;&lt;br&gt;But you can't, EVER, have the HTML control saying &amp;quot;I just read this from the local hard disk, so I'l let it run native code&amp;quot; or &amp;quot;I'll let it run a VB script&amp;quot; or &amp;quot;I'll let it save a file to %systemroot%&amp;quot; or any of the other tricks that malware has used to bypass the system.&lt;br&gt;&lt;br&gt;Security zones are inherently broken and unfixable. You have to drop back and redesign the security from scratch, or else every time someone comes up with a clever trick for stucking an untrusted object in a trusted location there'll be another &amp;quot;IE Exploit&amp;quot;.</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#365850</link><pubDate>Wed, 02 Feb 2005 22:46:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:365850</guid><dc:creator>Dave Massy</dc:creator><description>Peter,&lt;br&gt;Security zones serve a very important purpose. It is exteremly useful to have a variety of security settings based on the origin of the content. There is such a thing as a zone elevation attack that might take place if an exploit exists. A great deal of work was undertaken in Windows XP SP2 to make such attacks much more difficult if an attacker does make it past the first line of defense. Part of this work for was the local machine zone lockdown that you can read about at &lt;a target="_new" href="http://msdn.microsoft.com/security/productinfo/XPSP2/securebrowsing/lockdown_devimp.aspx"&gt;http://msdn.microsoft.com/security/productinfo/XPSP2/securebrowsing/lockdown_devimp.aspx&lt;/a&gt; which addresses your particular instance.&lt;br&gt;Thanks&lt;br&gt;-Dave&lt;br&gt;</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#365883</link><pubDate>Wed, 02 Feb 2005 23:23:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:365883</guid><dc:creator>Peter da Silva</dc:creator><description>&amp;quot;It is exteremly useful to have a variety of security settings based on the origin of the content.&amp;quot;&lt;br&gt;&lt;br&gt;I agree that it's useful, but I'm not sure it's possible to do it safely enough for the most popular browser on the net to use it, and in any case Security Zones don't do that. They base the security settings on the ASSUMED origin of the content, based on things like its current location. This heuristic is not good enough, and it can't be made good enough, because the component responsible for introducing the object into the system is the only one that really does know what the origin is.&lt;br&gt;&lt;br&gt;As soon as a file is saved to disk, for example, any tags that control its access right are lost. So the HTML control has an ever-more-complex task keeping track of what's a secure location, and what isn't. Instead, the control should be going back to the application and asking &amp;quot;hey, object 'badguy' wants to load control 'dangerous', could you give me control 'dangerous'&amp;quot;... and teh application goes &amp;quot;hell no&amp;quot;.&lt;br&gt;&lt;br&gt;Locking down Internet Explorer is helpful, but it's just another heuristic... just like every other heuristic that's been applied to this problem over the past, what, seven years... it's attacking the problem from the wrong end, *and* it's still too crude. It says &amp;quot;everything that comes from this application is untrusted&amp;quot;. That's not what you need to know... applications may have internal controls that *are* trusted, even if they also introduce untrusted objects. So now they have to explicitly embed these objects, they can't use ActiveX through the HTML control... even when it's entirely safe to do so.&lt;br&gt;&lt;br&gt;If the application were responsible for this, first... there wouldn't be a mechanism by which a &amp;quot;zone elevation attack&amp;quot; could take place except in a specific (and fixable) application, and second... a problem would only be a problem in that application, it wouldn't require examining and fixing the code that may have depended on the dangerous behaviour in every other application.&lt;br&gt;&lt;br&gt;Every other browser that supports embeddable objects does it the other way around. For example, KDE requires the application to install &amp;quot;IO slaves&amp;quot; in the control to give it more than the absolute minimal rendering functionality. The Mozilla family only run extensions that have been explicitly installed by the user... there's no mechanism for a web page to load and run untrusted code.&lt;br&gt;&lt;br&gt;And, yes, there's all kinds of neat things you *can* do with security zones, but to do it securely is so complex that (for one example) it's become harder for end users to do all the magic necessary to run signed ActiveX controls than to download and install a plugin.&lt;br&gt;&lt;br&gt;The right fix is to implement a new API that puts the responsibility on the application (IE, Outlook, Windows Media Player, Joe's Bait Finder, whatever) and progressively lock down apps that use the old API until there's nothing they can do outside a sandbox.</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#365899</link><pubDate>Wed, 02 Feb 2005 23:43:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:365899</guid><dc:creator>Dave Massy</dc:creator><description>Peter,&lt;br&gt;You bring up some interesting points. I'm not sure I follow all your arguments here about assumed origin of content. I really urge you to look very closely at the work undertaken in Windows XP SP2 to reduce the surface area of attack and addresses many or your complaints as I understand them.&lt;br&gt;Thanks&lt;br&gt;-Dave</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#366154</link><pubDate>Thu, 03 Feb 2005 09:25:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:366154</guid><dc:creator>Stephen W. Cote</dc:creator><description>I worked on the SDK for a few years (a while back), and while I was not an IE developer (however much I wanted to be one at the time; curses to that level system) I routinely interacted with a number of the developers, including Dave Massy.  In the time since, I've worked as an engineer in mostly non-MS shops, and I have to say that the group of people I met and worked with on the IE team (at the time) were some of the more motivating and inspirational.&lt;br&gt;&lt;br&gt;From the outside-in perspective, it would seem like it wouldn't be a great job to work on IE and that developers would get a lot of flack.  But, the other thing to consider is that there are a large number of developers and users who use the product and like it.  With that in mind, being able to work alongside such a good crew (assuming that's still true) and hear the positive feedback makes the more critical feedback tolerable.</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#366224</link><pubDate>Thu, 03 Feb 2005 13:13:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:366224</guid><dc:creator>Tim Marman</dc:creator><description>Dave - that was actually me that left the Zone comment, not Peter. &lt;br&gt;&lt;br&gt;&amp;quot;Security zones serve a very important purpose. It is exteremly useful to have a variety of security settings based on the origin of the content. There is such a thing as a zone elevation attack that might take place if an exploit exists.&amp;quot;&lt;br&gt;&lt;br&gt;Absolutely. I don't have a problem with the zone model. I have a problem with the implementation and consumption. &lt;br&gt;&lt;br&gt;It seems that different teams interpret the zones (and what zones are the most trusted) differently. &lt;br&gt;&lt;br&gt;All signs seem to indicate that the order in decreasing trust is local machine, local intranet, trusted sites, internet, restricted sites. The MDAC team, though, has decided that a site must explicitly be in the Trusted Sites in order to use certain features.&lt;br&gt;&lt;br&gt;I've written about this a little here: &lt;a target="_new" href="http://blogs.slashstar.com/tim/archive/2004/04/07/192.aspx"&gt;http://blogs.slashstar.com/tim/archive/2004/04/07/192.aspx&lt;/a&gt;</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#366225</link><pubDate>Thu, 03 Feb 2005 13:14:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:366225</guid><dc:creator>Tim Marman</dc:creator><description>Oh, sorry, I was wrong, he wrote about zones too.... :)</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#366296</link><pubDate>Thu, 03 Feb 2005 15:20:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:366296</guid><dc:creator>Dave Massy</dc:creator><description>Stephen, &lt;br&gt;Thanks for the kind words. Kind regards.&lt;br&gt;&lt;br&gt;Bwahahaha,&lt;br&gt;I'm leaving your comment but I do ask that people leave reasonable comments that are respectful adn on topic. I'm likely to delete such comments in the future. Since you do not know me it is probably better to avoid personal attacks.&lt;br&gt;&lt;br&gt;Tim Marman,&lt;br&gt;I'm not fully familiar with the MDAC requirements so I can't comment on this particular case. We obviously prefer that solutions do not require moving into trusted sites but there are times when this is necessary as the solution requires greater access to machine resources. I believe that we have always had trusted sites by default configured to have fewer restrictions than the intranet zone.&lt;br&gt;Thanks&lt;br&gt;-Dave</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#366376</link><pubDate>Thu, 03 Feb 2005 17:09:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:366376</guid><dc:creator>Peter da Silva</dc:creator><description>OK, let's look at this. Let's say I'm Microsoft Outlook. I'm displaying an email message. That message is untrusted, there should be no way for a control in that page to do anything outside a hard sandbox.&lt;br&gt;&lt;br&gt;But if someone can figure out where I put my temp files, and put those in a URL, that component is now in the local security zone.&lt;br&gt;&lt;br&gt;So what's the fix? Well, you coule move the temporary internit files directory and other places (like C:\TEMP) to another zone, or you could allow Outlook to tag a document as &amp;quot;Internet Zone&amp;quot; irrevocably (that last word is important), or you could let Outlook use a version of the HTML control that doesn't support anything not allowed in the Internet Zone (the approach other browsers tend to take).&lt;br&gt;&lt;br&gt;The first option does reduce the &amp;quot;surface area&amp;quot;, but it doesn't eliminate the class of attack... and it requires tight coordination between the IE people and everyone else to ensure that new exposures don't show up. When I realised that this was a problem (again, this was years ago) it never even occurred to me that Microsoft might take that approach.&lt;br&gt;&lt;br&gt;The other two options are equivalent from a security viewpoint, though the latter is inherently safer (if something does wrong it &amp;quot;fails closed&amp;quot;... the restricted HTML control has no path to higher zones in its code). I was sure that Microsoft would do one of these.&lt;br&gt;&lt;br&gt;It amazes me that you're still taking the first approach.&lt;br&gt;&lt;br&gt;</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#366386</link><pubDate>Thu, 03 Feb 2005 17:22:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:366386</guid><dc:creator>Dave Massy</dc:creator><description>Hi Peter,&lt;br&gt;I ask you once again to investigate the work we undertook in Windows XP SP2. &lt;br&gt;&lt;a target="_new" href="http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2chngs.mspx"&gt;http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2chngs.mspx&lt;/a&gt;&lt;br&gt;&lt;a target="_new" href="http://msdn.microsoft.com/security/productinfo/xpsp2/default.aspx"&gt;http://msdn.microsoft.com/security/productinfo/xpsp2/default.aspx&lt;/a&gt;&lt;br&gt;&lt;a target="_new" href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html/xpsp2web.asp"&gt;http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html/xpsp2web.asp&lt;/a&gt;&lt;br&gt;&lt;a target="_new" href="http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/overview/xpsp2compat.asp"&gt;http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/overview/xpsp2compat.asp&lt;/a&gt;&lt;br&gt;&lt;a target="_new" href="http://msdn.microsoft.com/security/productinfo/XPSP2/securebrowsing/lockdown_devimp.aspx"&gt;http://msdn.microsoft.com/security/productinfo/XPSP2/securebrowsing/lockdown_devimp.aspx&lt;/a&gt;&lt;br&gt;&lt;br&gt;The scenario you describe is simply not present. HTML emails in a host such as Outlook, Outlook Express or AOL all run in the restricted zone so no content in an HTML format email can run. Should an exploit exist and the content does find its way onto the hard disk of the computer then Local Machine Zone lockdown introduced in SP2 will prevent content from running there as well. &lt;br&gt;If we are to have a fruitful discussion then it is essential that you take the time to understand how this works. We are in the process of improving documentation in this area but I'd still like to hear feedback so that we can be sure that everything is well explained.&lt;br&gt;Thanks&lt;br&gt;-Dave&lt;br&gt;</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#366417</link><pubDate>Thu, 03 Feb 2005 18:05:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:366417</guid><dc:creator>Peter da Silva</dc:creator><description>Yes, I know that specific scenario has been fixed, I'm giving you an example of the problems caused by having the trust level of an object based on its current location rather than a strict mandatory access control model (which is, ironically, less strict and intrusive than what Microsoft currently presents users with).&lt;br&gt;&lt;br&gt;Don't focus on this specific approach, consider the underlying security model and the general case.&lt;br&gt;&lt;br&gt;&amp;quot;Should an exploit exist and the content does find its way onto the hard disk of the computer then Local Machine Zone lockdown introduced in SP2 will prevent content from running there as well.&amp;quot;&lt;br&gt;&lt;br&gt;It's still a hack, it only covers specific applications, it only handles the local security zone hole, and it doesn't follow a mandatory access control security policy. It's both more restrictive (it breaks working applications, as every approach like this is going to do) and less restrictive than necessary. Microsoft has presented hacks like these over and over again, for over half a decade, with white papers and glossy photographs with circles and arrows and a paragraph on the back of each one explaining what each one was, and every time new exploits showed up. And it's still happening.&lt;br&gt;&lt;br&gt;This whole class of attacks, &amp;quot;zone elevation&amp;quot;, only exists in applications that use the HTML control. The only way to eliminate this class of attacks is to implement a real mandatory access control mechanism, or sandbox everything.&lt;br&gt;&lt;br&gt;How does a MAC model work? When an object enters the system, that object and all other objects referred to by it have to be given no greater trust than assigned to that object when it entered the system. If you're viewing content in a web browser, then there should be no way for that content to provide a link to a zone where it has more rights, without an explicit request by the user... just as if the user was launching a helper application or downloading a file to a local disk. ALL transitions to a more trusted zone must be mediated that way, and all transitions through which it is impossible to retain the trust level of the object must be treated as if they were transitions into the highest security zone.&lt;br&gt;&lt;br&gt;If IE followed that model, you wouldn't just have reduced the &amp;quot;surface area&amp;quot;, you would have removed that surface completely, pretty all you'd need to worry about are helper applications and buffer overflow attacks like everyone else does.</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#366441</link><pubDate>Thu, 03 Feb 2005 18:30:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:366441</guid><dc:creator>Dave Massy</dc:creator><description>Peter,&lt;br&gt;I'm afraid I'm still struggling to understand your exact issue here. I do apologise. You appear to be describing what we refer to as code access security as implemented in the .net framework. This is not available in the COM model on which Internet Explorer is currently based. This is certainly an interesting model but not without its own set of issues and challenges.&lt;br&gt;-Dave</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#366501</link><pubDate>Thu, 03 Feb 2005 19:33:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:366501</guid><dc:creator>Tim Marman</dc:creator><description>Dave, &lt;br&gt;&lt;br&gt;&amp;quot;We obviously prefer that solutions do not require moving into trusted sites but there are times when this is necessary as the solution requires greater access to machine resources. I believe that we have always had trusted sites by default configured to have fewer restrictions than the intranet zone.&amp;quot;&lt;br&gt;&lt;br&gt;The real problem is that zone membership is mutually exclusive - you can't be in both Local Machine and Trusted Sites.&lt;br&gt;&lt;br&gt;This is very limiting as soon as you start explicitly requiring membership in a particular group.&lt;br&gt;&lt;br&gt;I agree with Peter in the sense that the .NET security model - based on evidence and permissions - is much better. A permission should not be tied to a particular group!&lt;br&gt;&lt;br&gt;MDAC decided that, for its purposes, Trusted Sites was the most trusted site. &lt;br&gt;&lt;br&gt;This is complicated by the fact that the &amp;quot;Automatic Login&amp;quot; stuff doesn't work as you might expect. If there are both internal and external sites that need to MDAC, you either: &lt;br&gt;1) disable Windows authentication for the entire Trusted Sites zone&lt;br&gt;2) send out your NTLM hash to any site that needs to use these MDAC features&lt;br&gt;3) bite the bullet and only allow internal sites to use MDAC functionality.&lt;br&gt;&lt;br&gt;As an aside, it's been awhile since I looked, but I'm pretty sure that Trusted Sites does NOT have fewer restrictions (that is, more permissions) than the Intranet zone.</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#366623</link><pubDate>Thu, 03 Feb 2005 22:11:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:366623</guid><dc:creator>Dave Massy</dc:creator><description>Bwahahaha,&lt;br&gt;I am removing your comments because I find them personally insulting. If you took time to read this blog you would know that I am not responsible for IE development, I am a Senior Program Manager on the Internet Explorer team and was not on the IE team during the four years that you accuse us of failing. Do take the time to read this and the other IE blogs to understand the situation. &lt;br&gt;I will remove all comments that are personally insulting, obscene and off topic. &lt;br&gt;&lt;br&gt; </description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#368015</link><pubDate>Sun, 06 Feb 2005 15:36:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:368015</guid><dc:creator>Kenneth</dc:creator><description>I believe IE does a good job with security.  Besides the previously multitudinous holes, it seems basically very simple now.  As a user, IE takes the time to explain when I'm doing something stupid, but still lets me do what I want.  The new XP SP2 firewall and popup blocker are excellent additions.&lt;br&gt;&lt;br&gt;Many of the complainants on your blogs seem to expect users to understand the security system to the same level as them, and to take the time to configure their machines all day.  &lt;br&gt;&lt;br&gt;IE is a great system for everyone, and if anyone believes it doesn't do a good job, just compare IE4 with NS4.  How many patches for NS4 were there?&lt;br&gt;&lt;br&gt;I can understand that you can't announce forthcoming features because of PR.  There are schedules, promotion and deadlines which are part of every real-world project.  However, I'd like one date out of you :)&lt;br&gt;&lt;br&gt;Is Longhorn the next significant release of IE, and must we upgrade to Longhorn to get it?&lt;br&gt;What is the current release projection for Longhorn?&lt;br&gt;&lt;br&gt;Cheers dude, nice blog.</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#371722</link><pubDate>Sun, 13 Feb 2005 00:04:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:371722</guid><dc:creator>Bastian Grupe</dc:creator><description>Hi, I'm web developer for some time now and want to rant a bit about the comments made here.&lt;br&gt;&lt;br&gt;&amp;quot;IE is a great system for everyone, and if anyone believes it doesn't do a good job, just compare IE4 with NS4. How many patches for NS4 were there?&amp;quot;&lt;br&gt;&lt;br&gt;Please don't start this discussion. First off, IE4 was way superior to NS4 at that time and secondly this time is now loooong ago.&lt;br&gt;If I wanted it to be a cat fight here I'd count every single IE fix between XP release and SP2. This is just BS.&lt;br&gt;&lt;br&gt;Zone Model:&lt;br&gt;&lt;br&gt;I also believe the .NET approach is way better (from what I understood/read). My question is why not making IE a .net application for comsumers and just keeping the old COM-IE for legacy reasons (just the control, the actual exe should point to a .net version).&lt;br&gt;&lt;br&gt;IE7 on WinXP:&lt;br&gt;&lt;br&gt;I understand that MS wants to push Longhorn as much as possible, but I think at least a feature-reduced IE7 (call it 6.5, whatever) should be made available for WinXP (ideally the proposed .NET one).&lt;br&gt;This version should only include rendering engine fixes (etc) which would leave MS all those features to praise Longhorn.&lt;br&gt;&lt;br&gt;Backwards Compatibility:&lt;br&gt;&lt;br&gt;I can fully understand the IE-developers dilemma here. They cannot break compatibility to WinXP-IE6 and without breaking it they cannot fix the various rendering issues.&lt;br&gt;&lt;br&gt;My proposal:&lt;br&gt;&lt;br&gt;There have been lots of hacks in the past and now that only IE5/6 understands, I'm talking about * html { ... } (&amp;quot;Holly Hack&amp;quot; / Star HTML hack) and conditional comments here.&lt;br&gt;&lt;br&gt;What about fixing the involved things and making IE 6.5/7 just ignoring them? The hacks would still apply to IE6 and IE7 display (alongside Gecko/KHTML/Opera) would just render fine.&lt;br&gt;&lt;br&gt;Dave, I'm also offering an extended email discussion on how to address these issues specifically if you're interested. bazzi@bazzinet.info is my address.&lt;br&gt;&lt;br&gt;I'm quite happy that there is someone from that big company that is actually listening and you can reason with.</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#372693</link><pubDate>Tue, 15 Feb 2005 00:31:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:372693</guid><dc:creator>Dave Massy</dc:creator><description>Hi Bastian,&lt;br&gt;While your proprosal of making the next version of IE just ignore the workarounds people use today sounds great it does make an assumption. That assumption is that we can identify the verious workarounds and make an intelligent decision abotu what to ignore and what is the developer's original intent. I'm not sure how we can do that when there are so many variations of workarounds in use. As I've said before we're going to be careful not to break compatibility for existing content not using the strict DOCTYPE.&lt;br&gt;Thanks&lt;br&gt;-Dave</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#372931</link><pubDate>Tue, 15 Feb 2005 12:51:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:372931</guid><dc:creator>Robin</dc:creator><description>I don't like reading into implications so could you clarify this sentence:&lt;br&gt;&lt;br&gt;&amp;quot;As I've said before we're going to be careful not to break compatibility for existing content not using the strict DOCTYPE.&amp;quot;&lt;br&gt;&lt;br&gt;Are you saying that Strict doctypes (4.01strict, xhtml1.0strict, and xhtml1.1) will be targetted with a bug-fixed and hopefully feature-added render path?</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#373061</link><pubDate>Tue, 15 Feb 2005 16:29:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:373061</guid><dc:creator>Dave Massy</dc:creator><description>Hi Robin,&lt;br&gt;I'm saying that when we address issues in standards support and the changes have an effect on compatibility then those changes will only be enabled under the strict doctype.&lt;br&gt;&lt;br&gt;Don't read any more into it than that about what we will address and when. Some issues may take longer to address than others :-)&lt;br&gt;&lt;br&gt;Thanks&lt;br&gt;-Dave</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#373064</link><pubDate>Tue, 15 Feb 2005 16:31:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:373064</guid><dc:creator>Robin</dc:creator><description>You've answered my question, I don't need to read into it any more :) </description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#374183</link><pubDate>Wed, 16 Feb 2005 09:17:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:374183</guid><dc:creator>Bastian Grupe</dc:creator><description>Hi Dave,&lt;br&gt;&amp;quot;As I've said before we're going to be careful not to break compatibility for existing content not using the strict DOCTYPE.&amp;quot;&lt;br&gt;&lt;br&gt;Well, the two hacks which I have mentioned (* html &amp;amp; conditional comments) can be easily identified I think. There IS a chance that others will break.&lt;br&gt;&lt;br&gt;But change always involves breaking old things. The amount of sites to be broken (not many use Strict doctype, not many use fully featured CSS designs either) will be very very slim. And the authors who are aware of IE hacking already can find solutions to let it work on both IE6+7 afterwards, too.&lt;br&gt;&lt;br&gt;This is a great opportunity, since I've read that Bill Gates himself has confirmed now that there will be an IE7 for non-Longhorn!&lt;br&gt;&lt;br&gt;It is YOUR chance now to allow progress on the web.</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#374967</link><pubDate>Thu, 17 Feb 2005 02:02:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:374967</guid><dc:creator>Fred.cpp</dc:creator><description>congratulations for the patience replying this feedback. As you said before, Is a Huge responsability to work with the most used program in the world. &lt;br&gt;Now a small question, Final version of IE7 will ship with the release of Longhorn? there are dates approximated dates for other beta releases?&lt;br&gt;will the final version of IE 7 be more OS Integrated or will not?&lt;br&gt;Thanks In Advance.</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#375794</link><pubDate>Fri, 18 Feb 2005 02:04:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:375794</guid><dc:creator>Dave Massy</dc:creator><description>Hi Fred,&lt;br&gt;Sorry. We're not going to discuss any dates or feature details for IE7 at this time.&lt;br&gt;I wouldn't expect any change in integration. Internet Explorer components are an essential part of the operating system on which the OS and otehr applications rely.&lt;br&gt;&lt;br&gt;Thanks&lt;br&gt;-Dave&lt;br&gt;</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#376735</link><pubDate>Sat, 19 Feb 2005 22:51:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:376735</guid><dc:creator>Excalpius</dc:creator><description>SP2 was a great step...lasted about six months of peace of mind.  But the windupdate dl toolbar now bypasses every precaution of SP2, and thereby begins downloading adtools, 180, etc. immediately.  It bypassed spybot, etc., as well.  I had to resort to the new MS/Giant anti-spyware took to block and remove this new exploit driven adware.&lt;br&gt;&lt;br&gt;I repeat, it hammered my system until it got in with no user interaction, requesters, etc....right past a fully patched and updated SP2 install.  So clearly something is still not stopping this kind of code from getting into places it should be allowed to be through IE.</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#377097</link><pubDate>Mon, 21 Feb 2005 00:51:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:377097</guid><dc:creator>ROTFLMAO</dc:creator><description>Microsoft takes responsibility seriously? LOLOL. You should be a stand up comedian.</description></item><item><title>re: Thick skins and responsibility</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#383930</link><pubDate>Wed, 02 Mar 2005 22:15:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:383930</guid><dc:creator>Jeff Parker</dc:creator><description>Hey Dave sorry for a late reply I am just getting around to reading this. But as far as thick skins, yeah you will take a lot of abuse and a beating for IE. Like I have said before on your blog I know you guys would fix it if you could. I really hate the fact that there is a deadline on beta of this summer. I would be impressed if you guys could fix all the old bugs and glitched with IE by then, but I doubt it. So my hope is down. I know it is not your fault or the IE teams fault, someone somewhere some marketing people set that deadline. &lt;br&gt;&lt;br&gt;But anyway, Aside from the thick skin I really hope you notice some of the Kudos you get as well. I will post this anytime. &lt;a target="_new" href="http://blogs.msdn.com/johnkenn/archive/2005/03/02/383736.aspx"&gt;http://blogs.msdn.com/johnkenn/archive/2005/03/02/383736.aspx&lt;/a&gt;&lt;br&gt;&lt;br&gt;DhtmlDude was first brought to my attention in a training class years ago. I still reference it and read it in a way you were the first blogger or really entertaining read, it still comes up in general conversation. So you know I kind of wish you would stop blogging about IE specifically for a while and kind of blog on some cool stuff you can do with the browser. I mean I wouldn't have known SMIL was a real language if you wouldn't have pointed it out. Your a really good writer and have a lot of info to share.</description></item><item><title> Dave Massy s Blog Thick skins and responsibility | Wood TV Stand</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#9679893</link><pubDate>Mon, 01 Jun 2009 21:28:28 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:9679893</guid><dc:creator> Dave Massy s Blog Thick skins and responsibility | Wood TV Stand</dc:creator><description>&lt;p&gt;PingBack from &lt;a rel="nofollow" target="_new" href="http://woodtvstand.info/story.php?id=10682"&gt;http://woodtvstand.info/story.php?id=10682&lt;/a&gt;&lt;/p&gt;
</description></item><item><title> Dave Massy s Blog Thick skins and responsibility | Quick Diets</title><link>http://blogs.msdn.com/dmassy/archive/2005/02/02/365435.aspx#9714806</link><pubDate>Tue, 09 Jun 2009 13:54:16 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:9714806</guid><dc:creator> Dave Massy s Blog Thick skins and responsibility | Quick Diets</dc:creator><description>&lt;p&gt;PingBack from &lt;a rel="nofollow" target="_new" href="http://quickdietsite.info/story.php?id=3035"&gt;http://quickdietsite.info/story.php?id=3035&lt;/a&gt;&lt;/p&gt;
</description></item></channel></rss>