On a modern machine that will support Vista (ie, 2GB+ of memory)... Hibernate takes 30-40 seconds to come up and down, whereas Sleep takes 5 seconds or so in each direction.
Thats a noticeable difference in usability, and even 'ignorant Joe User' will notice.
If this is true then you (or your company) was doing something wrong, because thats just not how the process works.
My guess is that your company bought a support contract, but you were still contacting the public PSS system. You should have had a 1-800 number plus a PIN or a dedicated TAM to work with.
I'm not sure who's fault this is, but I've seen this alot. The company pays through the nose for a support contract, and then the people in the field (for various reasons, mostly miscommunication or ignorance) use the public PSS contact numbers, and jump through this rigamarole with credit cards and the 1st level tech support.
"Huh? Security is not about "software development life-cycle"."
Absolutely a software development life-cycle has alot to do with security. With this lifecycle you do things like threat assessments, determine attack vectors, plan to minimize surface area, do code reviews, use your static analysis software to find bugs that lead to security holes, train your developers in secure coding techniques and practices, etc. The SDLC in this case is 'the plan' to minimize the risk of vulnerabilities being found, and to mitigate their damage when they are found.
"That's why you have almost daily updates of anti-virus software for Microsoft products."
What do daily updates of AV products have to do with MS software development practices? AV software is signature based. So if a new piece of malware is written, even if it doesnt use a single vulnerability in any product, it just relies on social engineering and stupid users to infect, it still requires a signature update. Has nothing to do with MS' software development practices.
"Remember, you can never count on a user applying a patch. Your system has to be as secure as possible in the default, unpatched, configuration."
Correct, and that led to the design and the installer and the default configuration of SQL Server 2005 in its various flavors. For example, SQL Server 2005 Express, when it installs, it defaults to not listening on the network at all (only uses shared memory access, which is basically an IPC), and defaults to not using standard sql security (so you cant have blank passwords, no sa account, etc).
This is exactly how the Jet system works on Windows machines. There's only one version in the system, and its ubiquitous, and available to anything and everything that can consume ODBC or OLEDB. No dependency issues there.
And if you choose to install the completely free SQL Express (known as MSDE in prior versions), you still have one version for the entire system, patched centrally. You can opt to use multiple instances, but its all using the same set of binaries.
Most commercial shared hosting on IIS6 runs each site as its own user/process. That with some scripted ACL changes, effectively chroots that site's access to just the folders for them, and they're running their own individual process, so if it goes down/runsaway, it wont affect other user's processes.
So basically, you have complete control over how you do it. Anything from a completely different user for each site (on the shared hosting end), to collections of sites that use a single login with a different collection of sites using a different login (for complex corporate environments), to all sites running under a single shared user/process (for simple corporate environments).
What you're describing isnt really a fair comparison.
You're comparing one group doing *nix admin correctly, and the other group doing windows admin incorrectly.
What you'll find with competent admins on both sides is that their processes look very similar, just with different tools.
In both cases, they dont actually log into the servers GUI to do work, they do it via scripting (VBScript or Perl on windows, shell + perl on unix).
They both use automated installation and patching tools.
The people who find MS dramatically cheaper are using competent windows admins and incompetent unix admins. The people who find Unix/Linux dramatically cheaper are using competent unix admins and incompetent windows admins.
With strong competent people on both sides who can do the entry-level programming & scripting required, I think you'll find that the linux side is a little bit faster/cheaper (mostly due to reboot issues), but its really not by a huge amount.
- Hibernate
- Lock the Console
- Switch Users (without logging off the current one)
Seriously.... I'm curious. For example, is there an equivalent to Lock or Switch Users on the mac at all? I think Hibernate is there, but its combined with sleep and happens automatically after a delay in sleep/standby, or something like that.
"Memory and processor usage is actually the exact same issue. Since MS is putting a lot of IE functionality in all sorts of place other than iexplore.exe, the memory and processor footprint of the executable doesn't tell the whole story. Truth is, I don't know exactly which processes are involved, my guess would be at least "system", but I know that iexplore can not be directly compared to firefox.exe for these metrics."
Thats not really how it works. Although its true that IE uses various other libraries that are generally available in the system, they're just that: libraries, not other services.
So when IExplore.exe consumes one of the various.dll's, they are loaded into the IExplore.exe process space, and so will show up there.
It wont, in general, call out to other existing processes/services to have the work done for it, it'll just load the dll's inside its own process space to do the work.
What does their IT staff have to do with inconsistent network connections?
Undock your laptop and carry it over to the conference room, you've come off one network and up on another one.
Move from work to home with your laptop.
Change seats in the terminal while waiting for your flight.
Move from one Starbucks to another.
All of these result in your network connection being inconsistent, and coming up and down, but has nothing to do with an incompetent IT department.
This is all fairly normal stuff for a mobile IT person, and Outlook 2003 on Exchange 2003 with Cached Exchange Mode is like a Godsend if you have that kind of lifestyle.
In typical use, awstats has nothing to compromise. It just emits.html files. There is no executable, or awstats code to access or compromise.
Now if you're using a non-standard approach, and allowing people to hit the awstats cgi directly, then you suffer from this issue. But that only really works on small sites, due to performance issues.
For most people in the US, the debt comes from the house and student loans.
For some people, car loans on top of the others are optional.
There's really nothing you can do about the house... if you dont own, you get killed on income taxes, and you're building equity in someone else's assets, rather than your own.
Then figure $20,000 - $60,000 (US) for student loans, depending on where you went, how much you borrowed, how many years, etc.
I actually dont think it means that, based on TFA.
It reads to me as if they are just working with Zend to make a version of the PHP interpreter that runs will in IIS, and maybe has a multi-threading mode, etc.
"Like it or not, PHP has turned into the king of the server-side."
Are you serious? PHP is the king of the very-low-end on dynamic web platforms, I'll give you that. But its a pure web-solution. You would never build a no-UI financial processing engine, for example, on PHP. You may build the web-based front-end to the java- or.net-based financial processing engine though, if thats the skill you have in your shop.
In my experience, the most common user of PHP is the amateur web-designer who is just breaking into programming, and wants a mechanism to send email from a web-form (and usually end up creating a spam-relay in the process). Then they slowly expand their knowledge and learn how to program from there. Dont get me wrong, its great for that, much like ASP was back in the days before.NET, and provides a valuable niche. But its hardly the king of server side programming languages.
"MS must have noticed how much it's gnawing at ASPs marketshare (Just did a comment on that the other day)."
I'm not sure if you mean ASP or ASP.NET here. If the former, its not relevant as ASP is dead and has been for years. If you mean the latter, than you're talking apples and oranges. PHP and ASP.NET solve completely different problem spaces. You could overlap them, but it wouldnt be optimal.
Is this any different from what ActiveState did for Perl on Win32?
This is also no different than what MS did with the Mozilla Foundation, bringing some of their devs in for a few days to work with them and help them make FireFox work better on Vista.
This adds choice for the community, which is a good thing.
There are plenty of small and medium companies who have a homogenous windows environment (some of them are also run well and stable). For them, its just better if PHP/Perl/Python/Ruby/etc runs better on windows, as that lets them save money by having a homogenous environment. This in turn lets them focus more on their core business, rather than changing their technology platform.
You have a very legitimate complaint here. The people making the software you're using are at fault. Unfortunately, regardless of whose fault it is (ie, how much MS is to blame), this is a common problem on windows.
Any frustration in my posts is the hordes of crappy ISVs that dont bother to learn how to properly develop on their platform.
"1) Would you like to make available IE on other operating systems?
Nope, and there are reasons, but I'm not telling you what they are."
I thought he was quite clear about this, and I dont even think you have to ask. They dont make IE available on other systems because that provides no competitive advantage to their business.
"9) Why is it that MS has avoided meeting at least the ACID2 spec for CSS in order to bring some semblance of comformity for developers?
We don't care about standards. We care about the real world!"
ACID2 is not a standard nor a spec. It's an arbitrary test using one person's (albeit a fairly relevant person) interpretation of a tricky subset of CSS implementations.
"10) why is Microsoft investing so much time and effort in continuing the development of IE?
The security holes and lack of features in IE were starting to reflect badly on our claims of having the most secure and innovative products."
I think this can be simplified even more. The problems with IE were starting to hurt their business, so they moved resources onto it. It's important to customers, those people who buy their products.
"But the question remains a serious one. With a good renderer available for free for them via Gecko, why not simply base IE on that, and provide the necessary backward compatibility for developers based on wrappers? Well, the most logical answer is that they don't *wan*t to adhere to standards, because they know that'll result in websites that require IE - (i.e. Windows). It's the monopoly, stupid."
Thats more than a little bit disingenuous.
The reason why they dont base IE off of Gecko is not because of some mysterious conspiracy theory. It's because it would create an uncontrollable dependency. It would take the evolution of the core browser out of their control. They would have to either upgrade at the pace that Gecko/Firefox sets, or make a private branch and try to stick on all the IE specific stuff back onto it.
The net effect of this would be to basically give up a part of windows to the Mozilla team, and lose their ability to evolve the browser and the html rendering engines that much of the OS uses, the way they need to.
No business in their right mind would do that, there's just no benefit to anyone.
Did your file broker run as a different user process than your web app? Thats the core of the issue. Running in a separate library has nothing to do with it, unless that separate library is running under a different user process.
The real-world protection of this is significant. IE running in protected mode has significantly less rights than a non-admin user on the box. This protects from situations like future holes that let a website write arbitrary files to the user profile. This is often used as one step in an attack sequence.
This provides an additonal layer of protection even for someone running as a non-admin user. Its called defense-in-depth. If a future information-leakage vulnerability is found, this will also help prevent pulling information from your user profile. This also helps prevent cross-domain vulnerabilities from being significant.
The fixes I described dont apply to the software user, they apply to the ISV. If this is a problem, then only use applications whose source you have access to. While this isnt universally possible, it is possible in many scenarios.
But if you're still experiencing DLL hell, then the problem isnt with windows, its with the companies or open-source projects developing your software.
There are numerous mechanisms to resolve this. Here are some links:
Basically, this problem has been solved for years... there are just alot of fairly crummy ISV's that dont bother to learn their trade very well.
The dotlocal stuff in particular is fantastic, and helps you make completely local and portable applications, which will work just by dropping the flat of files, no installation necessary.
You're right though in that its not easy to solve as the application consumer. It _is_ easy to solve by a competent ISV though.
However, I dont believe that the kernel is 'from scratch'. I believe they started that way, then had to abanadon a large amount of work because it was going to take too long, and went back to the win2003 server kernel as their base.
"Faced with ongoing delays and concerns about feature creep, Microsoft announced on August 27, 2004 that it was making significant changes. "Longhorn" development basically started afresh, building on the Windows Server 2003 codebase, and re-incorporating only the features that would be intended for an actual operating system release."
"If two different programs each demand a different version of the same library...you've got problems no matter what size disk you have. There are ways around this, though none are particularly good."
This is easy to resolve in Windows. The ISV should not rely on shared libraries, unless they are core windows libraries, and then you dont tie to a specific version of the image, you tie to 'at least' a specific image. And you watch your dependent libraries, and test with new versions from MS. If they break by removing or changing the signature on a message, then you ship a patch out asap. Though in reality, this tends to happen very very infrequently. For better or worse, MS is very attentive to maintaining backwards compatibility.
Any ISV installing software that relies on an exact point version of software doesnt deserve your (or anybody's) money.
If the library isnt a windows core library, then it should ship and install in the same directory as your program's executable. This way, the path resolution always finds this library first, even if there are different versions scattered across the machine.
MS' change removed the easy way to do it. Now it gets alot harder. The pagefile attack is the one with all the publicity. And that hole has been closed (though not in the most elegant way at the moment). But now its much, much, much harder to do so than it was before.
So another attack vector is found, and then MS patches the holes that are found by the communities. And the cycle continues.
But with each iteration, it gets harder and harder to do this easily on a random remote machine.
So the net result is never perfect security, but the overall level of security goes up. And more importantly, as 'kernel patching' becomes such a PITA, people will move elsewhere to other vulnerabilities.
Everyone wins with this, except for McAfee and Symantec's broken business models. But the most important thing is that the consumer wins, as they end up with a more stable system that is harder to root and trojanize.
"Microsoft is thinking about the situation where users decide to not opt out of using the content, and instead try to get around the DRM. A Protected Audio Path where the owner of the machine able to modify the code, becomes an Unprotected Audio Path."
Thats very true. But I'm not sure there was an alternative. The companies that own the content and delivery systems have made that kind of thing a requirement for MS to get a license to decode/play content like that. Without it, your regular non-technical consumer folks wouldnt have been able to play HD-DVD.
But, no one is requiring you to support content producers/distributors that use these kinds of techniques. MS is forced to make a choice or get sued. They chose to provide for the vast majority of their users, who want stuff to 'just work' as often as possible, without being restricted for non-DRM content.
"But the broader issue is that, virus scanning aside, there are lots of good reasons someone might want to modify a kernel (read LKML on any given day) and it just got harder on Windows."
Well, it got harder to distribute software to the world that uses known-dangerous and inappropriate methods to modify kernel data structures. You can still do this all you want on your own machine, just disable patchguard. There are a number of ways to do this, including just attaching a kernel debugger.
So PG doesnt in any way stop people from experimenting with the kernel or poking and prodding it. It does make it a _lot_ harder to distribute software (legitimately or illegitimately) that modifies kernel memory structures at runtime.
And to be honest, this whole issue is a red herring. The reason MS blocked this and introduced PatchGuard is that making changes to those structures is a really bad idea. It tends to slow and destabilize the system. You can basically thing of 'kernel patching' as a security hole. It's a gaping security hole that has been in windows for the entire history of the NT line, and they were finally able to close it with the change to x64 (due to the backwards compatibility story there).
"I sincerely doubt it's going to work like that. Yes, you can get your code signing cert from Verisign. But is MS planning on signing your cert or are they planning on signing each build of your drivers after testing them for stability in their labs?"
Did you not read the links I posted above? You should before making the post, as the documents answer the questions in great detail.
For non-WindowsLogo certified drivers, Ms doesnt sign your driver at all. They created the root authority, and then created signing certs for the various certificate authorities. Once you have a code-signing cert from Verisign (or whomever you choose) and you create your.cat file, you require no further action. MS does not then in turn directly sign your driver or kernel component. They signed the root cert, and if the chain of trust isnt broken, its all good.
Now, if you're participating in the Windows Logo certification process, those drivers _are_ tested by the MS labs, and new versions get signed by MS. But participating in the Windows Logo program is optional.
And for testing, you can roll your own test cert, or temporarily turn off signed driver checking, or attach a kernel debugger.
Again, this is all in the documents linked above.
"If MS is going to just sign your cert, some questions follow. How much is it going to cost to get MS to sign your cert?"
Approx $500 per year through Verisign, which is typically the most expensive CA out there. And note that your signatures wont expire if you dont renew, you just lose the ability to sign new code.
"Why should MS trust your company to sign your own drivers? How do they know your company doesn't have malicious motives? Can you seriously see MS signing the Alcohol Soft or Daemon Tools code signing certificate so they can get their drivers running in 64-bit Vista, enabling kids to play the DRM'd video games they downloaded off a torrent somewhere? Would they sign the SlySoft certificate that makes it easier to duplicate commercial DVDs? All three of these applications do have legitimite uses, but in each case, they can be abused. What standards are they holding the developers to?"
MS doesnt sign any drivers. MS created the root authority, and delegated to the other commercial CAs.
The whole point of signed code is not to stop bad people ahead of time, its to create an audit trail, so that if someone does release bad signed code, then you know who to go after. And its also for the ability to revoke. If some black hats start releasing signed drivers that trojanize your systems, MS will release a revocation as part of automatic updates that revokes the code-signing cert that the company got.
"Consider the negatives here... One: hardware manufacturers release drivers less often. New features and capabilities of existing hardware get delayed until they've been QC'd to death. End users suffer as a result."
Again, thats why you have both the generic code signing ability as well as the Windows Logo program. The former doesnt guarantee quality, it just makes it so that you have someone to come back to if there are problems. The latter guarantees a certain level of quality, because they are QC'd by MS. So consider one a stable variant, and one a more dev level component.
"I like the idea that you get a code signing cert, MS signs it, and you can sign whatever kernel-mode drivers you build... In my opinion, it should be free... and it's only purpose should be to attach legal accountability to code installed in kernel mode."
Yes, thats exactly how it works. Of course, as I've said before, MS doesnt actually sign your cert, you get a code signing cert from a CA that is part of a chain of trust from the root authority that MS created.
The only thing that is different from what you're asking is that its not free, but its not expensive at all ($500 per year), even for a very small business.
Now the Windows Logo program is likely much more expensive, though I dont part
Slashdot Mirror
They are _not_ the same, even to Joe User.
... Hibernate takes 30-40 seconds to come up and down, whereas Sleep takes 5 seconds or so in each direction.
On a modern machine that will support Vista (ie, 2GB+ of memory)
Thats a noticeable difference in usability, and even 'ignorant Joe User' will notice.
If this is true then you (or your company) was doing something wrong, because thats just not how the process works.
My guess is that your company bought a support contract, but you were still contacting the public PSS system. You should have had a 1-800 number plus a PIN or a dedicated TAM to work with.
I'm not sure who's fault this is, but I've seen this alot. The company pays through the nose for a support contract, and then the people in the field (for various reasons, mostly miscommunication or ignorance) use the public PSS contact numbers, and jump through this rigamarole with credit cards and the 1st level tech support.
"Huh? Security is not about "software development life-cycle"."
Absolutely a software development life-cycle has alot to do with security. With this lifecycle you do things like threat assessments, determine attack vectors, plan to minimize surface area, do code reviews, use your static analysis software to find bugs that lead to security holes, train your developers in secure coding techniques and practices, etc. The SDLC in this case is 'the plan' to minimize the risk of vulnerabilities being found, and to mitigate their damage when they are found.
"That's why you have almost daily updates of anti-virus software for Microsoft products."
What do daily updates of AV products have to do with MS software development practices? AV software is signature based. So if a new piece of malware is written, even if it doesnt use a single vulnerability in any product, it just relies on social engineering and stupid users to infect, it still requires a signature update. Has nothing to do with MS' software development practices.
"Remember, you can never count on a user applying a patch. Your system has to be as secure as possible in the default, unpatched, configuration."
Correct, and that led to the design and the installer and the default configuration of SQL Server 2005 in its various flavors. For example, SQL Server 2005 Express, when it installs, it defaults to not listening on the network at all (only uses shared memory access, which is basically an IPC), and defaults to not using standard sql security (so you cant have blank passwords, no sa account, etc).
This is exactly how the Jet system works on Windows machines. There's only one version in the system, and its ubiquitous, and available to anything and everything that can consume ODBC or OLEDB. No dependency issues there.
And if you choose to install the completely free SQL Express (known as MSDE in prior versions), you still have one version for the entire system, patched centrally. You can opt to use multiple instances, but its all using the same set of binaries.
You can do it however you want.
Most commercial shared hosting on IIS6 runs each site as its own user/process. That with some scripted ACL changes, effectively chroots that site's access to just the folders for them, and they're running their own individual process, so if it goes down/runsaway, it wont affect other user's processes.
So basically, you have complete control over how you do it. Anything from a completely different user for each site (on the shared hosting end), to collections of sites that use a single login with a different collection of sites using a different login (for complex corporate environments), to all sites running under a single shared user/process (for simple corporate environments).
Hope that answers your question.
What you're describing isnt really a fair comparison.
You're comparing one group doing *nix admin correctly, and the other group doing windows admin incorrectly.
What you'll find with competent admins on both sides is that their processes look very similar, just with different tools.
In both cases, they dont actually log into the servers GUI to do work, they do it via scripting (VBScript or Perl on windows, shell + perl on unix).
They both use automated installation and patching tools.
The people who find MS dramatically cheaper are using competent windows admins and incompetent unix admins. The people who find Unix/Linux dramatically cheaper are using competent unix admins and incompetent windows admins.
With strong competent people on both sides who can do the entry-level programming & scripting required, I think you'll find that the linux side is a little bit faster/cheaper (mostly due to reboot issues), but its really not by a huge amount.
So how do you do the other options?
.... I'm curious. For example, is there an equivalent to Lock or Switch Users on the mac at all? I think Hibernate is there, but its combined with sleep and happens automatically after a delay in sleep/standby, or something like that.
- Hibernate
- Lock the Console
- Switch Users (without logging off the current one)
Seriously
"Memory and processor usage is actually the exact same issue. Since MS is putting a lot of IE functionality in all sorts of place other than iexplore.exe, the memory and processor footprint of the executable doesn't tell the whole story. Truth is, I don't know exactly which processes are involved, my guess would be at least "system", but I know that iexplore can not be directly compared to firefox.exe for these metrics."
.dll's, they are loaded into the IExplore.exe process space, and so will show up there.
Thats not really how it works. Although its true that IE uses various other libraries that are generally available in the system, they're just that: libraries, not other services.
So when IExplore.exe consumes one of the various
It wont, in general, call out to other existing processes/services to have the work done for it, it'll just load the dll's inside its own process space to do the work.
What does their IT staff have to do with inconsistent network connections?
Undock your laptop and carry it over to the conference room, you've come off one network and up on another one.
Move from work to home with your laptop.
Change seats in the terminal while waiting for your flight.
Move from one Starbucks to another.
All of these result in your network connection being inconsistent, and coming up and down, but has nothing to do with an incompetent IT department.
This is all fairly normal stuff for a mobile IT person, and Outlook 2003 on Exchange 2003 with Cached Exchange Mode is like a Godsend if you have that kind of lifestyle.
In typical use, awstats has nothing to compromise. It just emits .html files. There is no executable, or awstats code to access or compromise.
Now if you're using a non-standard approach, and allowing people to hit the awstats cgi directly, then you suffer from this issue. But that only really works on small sites, due to performance issues.
The most prominent .NET language is C#, but there are plenty of VB.NET jobs and coders out there.
.NET for IIS/Web.
.NET language) or rich-client development using winforms (using any .NET language).
ASP is not a language, its a platform. It's the way to do
Think of it as a choice between web development using ASP (using any
So you can do either in C#, VB.NET, IronPython, etc etc.
Just like with olden days Classic ASP, you could do it in VBScript or JScript.
For most people in the US, the debt comes from the house and student loans.
... if you dont own, you get killed on income taxes, and you're building equity in someone else's assets, rather than your own.
For some people, car loans on top of the others are optional.
There's really nothing you can do about the house
Then figure $20,000 - $60,000 (US) for student loans, depending on where you went, how much you borrowed, how many years, etc.
I actually dont think it means that, based on TFA.
It reads to me as if they are just working with Zend to make a version of the PHP interpreter that runs will in IIS, and maybe has a multi-threading mode, etc.
Also to improve the speed and reliability.
At least thats my read of it.
"Like it or not, PHP has turned into the king of the server-side."
.net-based financial processing engine though, if thats the skill you have in your shop.
.NET, and provides a valuable niche. But its hardly the king of server side programming languages.
Are you serious? PHP is the king of the very-low-end on dynamic web platforms, I'll give you that. But its a pure web-solution. You would never build a no-UI financial processing engine, for example, on PHP. You may build the web-based front-end to the java- or
In my experience, the most common user of PHP is the amateur web-designer who is just breaking into programming, and wants a mechanism to send email from a web-form (and usually end up creating a spam-relay in the process). Then they slowly expand their knowledge and learn how to program from there. Dont get me wrong, its great for that, much like ASP was back in the days before
"MS must have noticed how much it's gnawing at ASPs marketshare (Just did a comment on that the other day)."
I'm not sure if you mean ASP or ASP.NET here. If the former, its not relevant as ASP is dead and has been for years. If you mean the latter, than you're talking apples and oranges. PHP and ASP.NET solve completely different problem spaces. You could overlap them, but it wouldnt be optimal.
Is this any different from what ActiveState did for Perl on Win32?
This is also no different than what MS did with the Mozilla Foundation, bringing some of their devs in for a few days to work with them and help them make FireFox work better on Vista.
This adds choice for the community, which is a good thing.
There are plenty of small and medium companies who have a homogenous windows environment (some of them are also run well and stable). For them, its just better if PHP/Perl/Python/Ruby/etc runs better on windows, as that lets them save money by having a homogenous environment. This in turn lets them focus more on their core business, rather than changing their technology platform.
You have a very legitimate complaint here. The people making the software you're using are at fault. Unfortunately, regardless of whose fault it is (ie, how much MS is to blame), this is a common problem on windows.
Any frustration in my posts is the hordes of crappy ISVs that dont bother to learn how to properly develop on their platform.
"1) Would you like to make available IE on other operating systems?
Nope, and there are reasons, but I'm not telling you what they are."
I thought he was quite clear about this, and I dont even think you have to ask. They dont make IE available on other systems because that provides no competitive advantage to their business.
"9) Why is it that MS has avoided meeting at least the ACID2 spec for CSS in order to bring some semblance of comformity for developers?
We don't care about standards. We care about the real world!"
ACID2 is not a standard nor a spec. It's an arbitrary test using one person's (albeit a fairly relevant person) interpretation of a tricky subset of CSS implementations.
"10) why is Microsoft investing so much time and effort in continuing the development of IE?
The security holes and lack of features in IE were starting to reflect badly on our claims of having the most secure and innovative products."
I think this can be simplified even more. The problems with IE were starting to hurt their business, so they moved resources onto it. It's important to customers, those people who buy their products.
"But the question remains a serious one. With a good renderer available for free for them via Gecko, why not simply base IE on that, and provide the necessary backward compatibility for developers based on wrappers? Well, the most logical answer is that they don't *wan*t to adhere to standards, because they know that'll result in websites that require IE - (i.e. Windows). It's the monopoly, stupid."
Thats more than a little bit disingenuous.
The reason why they dont base IE off of Gecko is not because of some mysterious conspiracy theory. It's because it would create an uncontrollable dependency. It would take the evolution of the core browser out of their control. They would have to either upgrade at the pace that Gecko/Firefox sets, or make a private branch and try to stick on all the IE specific stuff back onto it.
The net effect of this would be to basically give up a part of windows to the Mozilla team, and lose their ability to evolve the browser and the html rendering engines that much of the OS uses, the way they need to.
No business in their right mind would do that, there's just no benefit to anyone.
Did your file broker run as a different user process than your web app? Thats the core of the issue. Running in a separate library has nothing to do with it, unless that separate library is running under a different user process.
The real-world protection of this is significant. IE running in protected mode has significantly less rights than a non-admin user on the box. This protects from situations like future holes that let a website write arbitrary files to the user profile. This is often used as one step in an attack sequence.
This provides an additonal layer of protection even for someone running as a non-admin user. Its called defense-in-depth. If a future information-leakage vulnerability is found, this will also help prevent pulling information from your user profile. This also helps prevent cross-domain vulnerabilities from being significant.
The fixes I described dont apply to the software user, they apply to the ISV. If this is a problem, then only use applications whose source you have access to. While this isnt universally possible, it is possible in many scenarios.
a se/dynamic_link_library_redirection.asp
h tml/rfacomwalk.asp
5 17221.aspx
... there are just alot of fairly crummy ISV's that dont bother to learn their trade very well.
But if you're still experiencing DLL hell, then the problem isnt with windows, its with the companies or open-source projects developing your software.
There are numerous mechanisms to resolve this. Here are some links:
DLL Redirection
http://msdn.microsoft.com/library/en-us/dllproc/b
Registration Free COM
http://msdn.microsoft.com/library/en-us/dndotnet/
Good Blog summarizing this stuff:
http://blogs.msdn.com/junfeng/archive/2006/01/24/
Basically, this problem has been solved for years
The dotlocal stuff in particular is fantastic, and helps you make completely local and portable applications, which will work just by dropping the flat of files, no installation necessary.
You're right though in that its not easy to solve as the application consumer. It _is_ easy to solve by a competent ISV though.
Good points.
p ment
However, I dont believe that the kernel is 'from scratch'. I believe they started that way, then had to abanadon a large amount of work because it was going to take too long, and went back to the win2003 server kernel as their base.
This is the only thing I could find at a quick search:
http://en.wikipedia.org/wiki/Windows_Vista#Develo
"Faced with ongoing delays and concerns about feature creep, Microsoft announced on August 27, 2004 that it was making significant changes. "Longhorn" development basically started afresh, building on the Windows Server 2003 codebase, and re-incorporating only the features that would be intended for an actual operating system release."
"If two different programs each demand a different version of the same library...you've got problems no matter what size disk you have. There are ways around this, though none are particularly good."
This is easy to resolve in Windows. The ISV should not rely on shared libraries, unless they are core windows libraries, and then you dont tie to a specific version of the image, you tie to 'at least' a specific image. And you watch your dependent libraries, and test with new versions from MS. If they break by removing or changing the signature on a message, then you ship a patch out asap. Though in reality, this tends to happen very very infrequently. For better or worse, MS is very attentive to maintaining backwards compatibility.
Any ISV installing software that relies on an exact point version of software doesnt deserve your (or anybody's) money.
If the library isnt a windows core library, then it should ship and install in the same directory as your program's executable. This way, the path resolution always finds this library first, even if there are different versions scattered across the machine.
MS' change removed the easy way to do it. Now it gets alot harder. The pagefile attack is the one with all the publicity. And that hole has been closed (though not in the most elegant way at the moment). But now its much, much, much harder to do so than it was before.
So another attack vector is found, and then MS patches the holes that are found by the communities. And the cycle continues.
But with each iteration, it gets harder and harder to do this easily on a random remote machine.
So the net result is never perfect security, but the overall level of security goes up. And more importantly, as 'kernel patching' becomes such a PITA, people will move elsewhere to other vulnerabilities.
Everyone wins with this, except for McAfee and Symantec's broken business models. But the most important thing is that the consumer wins, as they end up with a more stable system that is harder to root and trojanize.
"Microsoft is thinking about the situation where users decide to not opt out of using the content, and instead try to get around the DRM. A Protected Audio Path where the owner of the machine able to modify the code, becomes an Unprotected Audio Path."
Thats very true. But I'm not sure there was an alternative. The companies that own the content and delivery systems have made that kind of thing a requirement for MS to get a license to decode/play content like that. Without it, your regular non-technical consumer folks wouldnt have been able to play HD-DVD.
But, no one is requiring you to support content producers/distributors that use these kinds of techniques. MS is forced to make a choice or get sued. They chose to provide for the vast majority of their users, who want stuff to 'just work' as often as possible, without being restricted for non-DRM content.
"But the broader issue is that, virus scanning aside, there are lots of good reasons someone might want to modify a kernel (read LKML on any given day) and it just got harder on Windows."
Well, it got harder to distribute software to the world that uses known-dangerous and inappropriate methods to modify kernel data structures. You can still do this all you want on your own machine, just disable patchguard. There are a number of ways to do this, including just attaching a kernel debugger.
So PG doesnt in any way stop people from experimenting with the kernel or poking and prodding it. It does make it a _lot_ harder to distribute software (legitimately or illegitimately) that modifies kernel memory structures at runtime.
And to be honest, this whole issue is a red herring. The reason MS blocked this and introduced PatchGuard is that making changes to those structures is a really bad idea. It tends to slow and destabilize the system. You can basically thing of 'kernel patching' as a security hole. It's a gaping security hole that has been in windows for the entire history of the NT line, and they were finally able to close it with the change to x64 (due to the backwards compatibility story there).
"I sincerely doubt it's going to work like that. Yes, you can get your code signing cert from Verisign. But is MS planning on signing your cert or are they planning on signing each build of your drivers after testing them for stability in their labs?"
.cat file, you require no further action. MS does not then in turn directly sign your driver or kernel component. They signed the root cert, and if the chain of trust isnt broken, its all good.
Did you not read the links I posted above? You should before making the post, as the documents answer the questions in great detail.
For non-WindowsLogo certified drivers, Ms doesnt sign your driver at all. They created the root authority, and then created signing certs for the various certificate authorities. Once you have a code-signing cert from Verisign (or whomever you choose) and you create your
Now, if you're participating in the Windows Logo certification process, those drivers _are_ tested by the MS labs, and new versions get signed by MS. But participating in the Windows Logo program is optional.
And for testing, you can roll your own test cert, or temporarily turn off signed driver checking, or attach a kernel debugger.
Again, this is all in the documents linked above.
"If MS is going to just sign your cert, some questions follow. How much is it going to cost to get MS to sign your cert?"
Approx $500 per year through Verisign, which is typically the most expensive CA out there. And note that your signatures wont expire if you dont renew, you just lose the ability to sign new code.
"Why should MS trust your company to sign your own drivers? How do they know your company doesn't have malicious motives? Can you seriously see MS signing the Alcohol Soft or Daemon Tools code signing certificate so they can get their drivers running in 64-bit Vista, enabling kids to play the DRM'd video games they downloaded off a torrent somewhere? Would they sign the SlySoft certificate that makes it easier to duplicate commercial DVDs? All three of these applications do have legitimite uses, but in each case, they can be abused. What standards are they holding the developers to?"
MS doesnt sign any drivers. MS created the root authority, and delegated to the other commercial CAs.
The whole point of signed code is not to stop bad people ahead of time, its to create an audit trail, so that if someone does release bad signed code, then you know who to go after. And its also for the ability to revoke. If some black hats start releasing signed drivers that trojanize your systems, MS will release a revocation as part of automatic updates that revokes the code-signing cert that the company got.
"Consider the negatives here... One: hardware manufacturers release drivers less often. New features and capabilities of existing hardware get delayed until they've been QC'd to death. End users suffer as a result."
Again, thats why you have both the generic code signing ability as well as the Windows Logo program. The former doesnt guarantee quality, it just makes it so that you have someone to come back to if there are problems. The latter guarantees a certain level of quality, because they are QC'd by MS. So consider one a stable variant, and one a more dev level component.
"I like the idea that you get a code signing cert, MS signs it, and you can sign whatever kernel-mode drivers you build... In my opinion, it should be free... and it's only purpose should be to attach legal accountability to code installed in kernel mode."
Yes, thats exactly how it works. Of course, as I've said before, MS doesnt actually sign your cert, you get a code signing cert from a CA that is part of a chain of trust from the root authority that MS created.
The only thing that is different from what you're asking is that its not free, but its not expensive at all ($500 per year), even for a very small business.
Now the Windows Logo program is likely much more expensive, though I dont part