Would a 'friendly community' welcome a new boss who supported banning inter-racial marriage? No, and the oh but it's just a personal view nonsense wouldn't fly there either.
What you're overlooking is that Proposition 8 passed. You're not talking about blacklisting people for views way outside the Overton Window. You're talking about blacklisting people for taking part in an active political controversy where you don't like their position.
According to an Oct. 1, 2013, report prepared for Home Depot by consultant FishNet Security, the retailer left its computers vulnerable by switching off Symantecâ(TM)s Network Threat Protection (NTP) firewall in favor of one packaged with Windows.
No enterprise installation should ever be relying on individual client firewall software for network security. At best, that should be a second line of defense. It is the job of the perimeter firewall to handle these kind of threats.
A week from now if someone does follow through on the threats is it still a joke? Seriously, sometimes threats do get carried out.
When was the last time an Internet threat by a stranger was actually carried out in meatspace?
Note that I'm not including cases where the victim already knew the perpetrator in the real world and the threat just happened to take place on an online service, nor am I counting instances where the entire crime took place online, such as DoS attacks or stealing personal information. I'm talking about some guy on the Internet making a threat of committing violence against someone they don't already have a personal real-life acquaintance with, and then actually carrying it out. Has this ever happened? If not, why shouldn't all such threats be disregarded as meaningless and empty?
Death threats are illegal, they don't become legal because they're On The Internet any more than an old technology should become patentable because it's done On The Internet.
The legality of death threats is actually not a cut-and-dried issue. This article discusses various U.S. court cases related to death threats, and what criteria the courts use to determine whether they are protected free speech or not.
I suspect that a death threat accompanied by "doxxing" would be considered more serious than an isolated threat out of the blue in a chat room, since posting personal information would make it more likely that "a reasonable listener would understand [it] as an actual threat of violence" and not just rhetoric. But I'm not a lawyer, so I can't be certain of this. Of course, it goes without saying that the safest (and most ethical) course of conduct is not to issue any death threats at all.
And no matter what the charter is, if they are liquidated the court will sell all of your data to the highest bidder to pay off creditors.
That is true if the user data is considered part of the bankruptcy estate. But that won't necessarily be the case. Under US law, everyone automatically has copyright for anything they write or compose. If the primary concern is to protect user privacy, the user agreement for the site could stipulate that users retain copyright to all their data, and the site has a nonexclusive, nontransferrable license to use that data so long as they adhere to the privacy terms. In the case of bankruptcy, the only "asset" would be the nontransferrable license – not the data itself, which would still belong to the end users.
I expect issues like this to come up once a few mid-size or large cloud providers go broke. I don't think the courts are going to allow the creditors to seize data assets belonging to customers in these instances.
If your process involves generating Office, documents, it's generally the easiest way. The server automation tools for generation of Office documents are basically scripts and wrappers around.... Office. So if you want to generate some report that spits out an Excel file at the end, you can bet it was generated in Excel the first time around because the reporting tool actually called Excel to fill in the fields.
This may have been correct 5 to 10 years ago, but you should never do this in a modern installation if you can possibly help it. Microsoft's official position is that "Microsoft does not recommend or support server-side Automation of Office."
You should be using the Open XML SDK to create Office documents in your web application. The default classes and methods are somewhat opaque, but fortunately, there are a lot of helper toolkits that run on top of OOXML SDK to make things much easier. I used Simple OOXML, which hasn't been updated for a while and has limited documentation, but works pretty well, and is free. These solutions are not only much more robust in a server-side situation, but you don't have to devote an Office license to the server.
This is going to be a real problem with embedded systems. At my last workplace, we had coin/bill vending units hooked up to PCs, which were connected using a FTDI serial-to-USB connection. I think the chip was legit – but how would I be able to tell? We purchased these vending units from a manufacturer, which in turn, I'm sure, bought the serial-to-USB chips (or even pre-made boards) from another vendor. What if that other vendor used clone chips without telling anyone?
And yes, we did occasionally install FTDI driver updates on these. If one of these units were to be bricked, FTDI is going to be open to some very substantial lawsuits. Arguing "unclean hands" won't work when the people getting hurt are about four steps removed from any actual culpability.
Not going to happen, the same way that it didn't happen when DirectTV (or dish, whoever) bricked all of those pirate hardware years ago
No claims were made in that case because anyone who came forward would have to admit committing a federal crime. In contrast, there are plenty of ways that someone could wind up with a bricked device that they had no knowledge was not authentic, and could not reasonably have known.
I actually like the Ribbon in Office, because the Office apps have so many features that regular menus/toolbars hinder discoverability. (I suppose I might feel differently if I had invested a lot of time into memorizing the Office 2003 menus, but I didn't.) On most other applications, Ribbon is overkill, taking up too much space (and vertical space is especially precious on widescreens).
Maybe I am wrong, but over the years I have noted an increasing condescendension of IT people over "mere users". I wonder why that is. Bear in mind that IT typically isn't the company's cash cow, but "overhead", making this condescension rather inappropriate imho.
All this is the sign of a poorly run organization with excessive siloing. IT should be working with other departments, helping to streamline and automate their processes, making other people's jobs easier and less tedious. If people think of IT as "the computer janitors", your organization is throwing away a tremendous amount of potential productivity. It's bad for morale on both sides, too.
I wonder when Microsoft will learn that a lot of us would rather use our CPU and GPU cycles for something other than eye candy? While computers can be used for fun purposes, we shouldn't all be left with the feel that what we have is little more than a technotoy.
Windows has always offered the option to turn off animations. (System Properties -> Advanced System Settings -> Performance gives a bunch of checkboxes for this on both Win7 and Win10.) Flip it around: why shouldn't those of us with good mid-range or high-end desktops be able to use a small portion of our CPU and GPU power to make things look nicer? Why should we be hamstrung to what the crappiest tablet with a half-dead battery can handle?
This is a good start (assuming you can turn these animations off if you don't like them). Hopefully they'll bring back Aero Glass-style transparency soon.
There are also a lot more substantive flaws that need to be addressed. The Start menu (which is Win10's big selling point!) doesn't currently do DPI scaling properly. It's disappointing enough to see this flaw with third-party software, but for a core part of the OS, it's inexcusable. And there is still no way to remove the obtrusive Search and Task View icons from the taskbar. (Both of these issues have hundreds of votes on Feedback; hopefully they will be addressed.)
There are also a bunch of smaller annoyances – unlike in Win7, I can't get the useless "Homegroup" option to disappear from the left panel of File Explorer, even if I leave all homegroups completely. They also shove OneDrive down your throat. And if I rename "This PC" back to "My Computer", it displays under my preferred name in most places, but not in the tile half of the Start menu – it appears fine in the left-hand list portion, but the tile always says "This PC" no matter what it has been renamed to.
There are some encouraging signs, but this is definitely an alpha-class release in my experience. Glad I installed it in a VM.
But all that means is that the user sees a yellow splat in the system tray. Not really a big deal. You can still actually access the Internet on Windows even if NCSI thinks it's down. The Belkin issue is a much bigger deal.
I know I'll get flamed for saying this, but it seems to me that the Shellshock bug represents a weakness in the Unix philosophy. On Windows, if a similar issue happened with cmd.exe or PowerShell, it would have only a limited effect, because the Windows shell is basically just an administration tool, and no one in their right mind would use it to pass untrusted input of any sort. In contrast, "the Unix way" encourages piping of shell commands to other shell commands, and the use of shelling out as a substitute for proper APIs. To me as a Windows power user, the idea that a basic feature like DHCP is using a shell script behind the scenes seems crazy. The better way to write re-usable code is to do the C/C++ API first, then build both the command line and GUI tools on top of that API. "The Unix way" is a clumsy hack in comparison – and it leaves the shell as a security-critical single point of failure.
Another way to think of it is that Linux is now dealing with an issue that Windows has been struggling with for over a decade: how to fix inherently insecure design decisions without breaking compatibility with a million different legacy applications in the process. Maybe they'll need to implement the equivalent of "UAC" whenever a program tries to shell out?
Obviously, people doing low-level systems programming do need to have the background to understand this stuff. But that doesn't really matter – there are a hundred application programmers for every systems programmer. It's like saying all programmers need to be able to write in assembly and count cycles, just because some embedded work still requires that sort of stuff.
Most coders don't actually program. They just write some lines of code that connect libraries together. They wouldn't know where to even begin if asked to write the libraries themselves, or write the networking protocols, or the operating system, or the compilers, or the GUI frameworks, or the browser, or even a simple scripting language.
Converting business requirements into executable processes that a computer can understand is programming, regardless of what language or API is used. There's nothing noble about re-inventing the wheel just to prove you can do it; it's just stupid and inefficient.
More to the point, organizations don't care about hiring well-rounded Renaissance Men. They want people who can get a specific job done. Whether that job satisfies non-customers in some far-off ivory tower is completely irrelevant.
But someone who can code AND knows the theory is better than some stupid code-only monkey anyday.
It's true that "pure" coding is becoming less valuable, but that doesn't mean that Comp Sci skills are your only way (or even the best way) out of that niche. Being able to understand business requirements and translate them into functional products is a lot more important than understanding five different sort algorithms that you'll never use (since the API handles all that crap for you).
There's plenty of blame to go around on both sides here.
The motherboard manufacturers – pretty much all of them – are to blame for developing and shipping really crappy firmware. (Unfortunately, this is pretty much par for the course – 95% of all firmware is crap, no matter what it's for. Modern hardware companies, with a few obvious exceptions like Apple, just don't do software very well at all.)
The Linux kernel devs are to blame for being stubborn about "standards-compliance" versus the real world. From what I can tell in clicking through a few links, the ACPM feature was working in the past, but the kernel devs then deliberately broke it by changing it to only work if the BIOS advertises it properly. Yes, the standard says that's what is supposed to happen. But we know from experience that manufacturers often don't follow standards. Linux needs to deal with the world as it is, not as the devs wish it would be.
Nope. A website that has to hook into a bunch of poorly maintained, poorly documented databases. That's the hard part.
This kind of crap is par for the course. I've had to figure out poorly designed databases without documentation, and it didn't cost millions of dollars to do that. Admittedly, insurance company big iron is probably much hairier to deal with than what I'm used to... but $240 million worth? Sorry, I just don't see how this adds up.
The real problem here is that Europe hasn't given the vacuum cleaners enough R&D time to make more efficient vacuums; should have been a ban for 2018+ not 2014.
Why not just use the same designs that are currently sold in the United States? As others have noted, we're pretty much limited to 1600W already, because of the maximum capacity of standard household circuits (120V/15A).
One major problem with security is that the permission model on both Windows and Unix doesn't really give you the tools you need to keep yourself safe. We're still stuck in the 1970s university mentality where the user is assumed to have written or at least compiled the program themselves, and is supposed to have a good understanding of what it does. The program is assumed to be operating as an agent of the user, so it inherits all the user's permissions. On modern systems, with semi-trusted and untrusted code downloaded from the Internet, this assumption is absurd and dangerous.
Rather than the program inheriting the user's permissions by default, a decent modern security model would instead restrict it to a sandbox unless it was explicitly given permission to get out – and even then the user should be given veto power over specific sandbox breaches. (Android used to work like this, but Google dumbed it down for reasons that are not clear.)
By default, a program should only be able to do the following:
* Get input from the keyboard and mouse (only when the application has focus)
* Get input from game controllers (even if the application doesn't have focus)
* Output video and sound using the normal system APIs
* Read/write temporary files to a scratch directory
* Open and save files only through standard system dialog boxes that are under the OS's control
Anything else – Internet access, ability to freely read and write to files/folders, ability to get keyboard input when not in focus – should require explicit user permission. And the user should have the option of unchecking any or all of these authorizations and continuing to run the app without it being able to do those things. These permissions should be as fine-grained as possible, so an application could have permission to only read certain specific folders, or could be allowed to access the Internet only through a particular API (say, for handling registration or online high scores) and only for certain domains.
It was tied to the operating system, unnecessarily. The browser has exactly zilch to do with the operating system. ActiveX controls, tying versions of the browser with versions of the OS, varying behaviour of same browser version on different OS versions etc. If IE is renamed, it should be delinked from the OS like other browsers.
I agree that tying versions of IE to specific versions of Windows was a really bad idea. Many web developers are still stuck with supporting IE8 because it is the latest version that runs on XP, and many users (and even companies) still haven't upgraded. This has clearly retarded the adoption of modern technologies like canvas and SVG support, which is a serious problem.
But at this point you really can't fully remove IE from Windows without breaking stuff. Sure, you can use the uninstall option to remove iexplore.exe (and newer versions of Windows let you do that), but if the back-end components like mshtml.dll were also removed, then a non-negligible amount of existing software would break. Since backward compatibility is really Microsoft's strongest selling point, this is a non-starter. Don't forget that Microsoft Help files also use HTML, so the Trident rendering engine is needed to view them. You could argue that this is unnecessary tying, but I'm not sure a custom proprietary format would really have been a better choice than HTML for help files – it seems a fairly sensible choice.
I never understood why drivers had to be on the kernel ring anyway. Every single peripheral (GPU, sound card, etc.) driver I've ever encountered has had a history of stability problems. You'd think the largest point of failure on the computer could be moved to userland and restarted when necessary.
Audio drivers were moved to user mode starting with Windows Vista. (That's why DirectSound 3D is no longer supported.) Video drivers, however, pretty much have to be in the kernel for performance reasons.
Slashdot Mirror
Would a 'friendly community' welcome a new boss who supported banning inter-racial marriage? No, and the oh but it's just a personal view nonsense wouldn't fly there either.
What you're overlooking is that Proposition 8 passed. You're not talking about blacklisting people for views way outside the Overton Window. You're talking about blacklisting people for taking part in an active political controversy where you don't like their position.
According to an Oct. 1, 2013, report prepared for Home Depot by consultant FishNet Security, the retailer left its computers vulnerable by switching off Symantecâ(TM)s Network Threat Protection (NTP) firewall in favor of one packaged with Windows.
No enterprise installation should ever be relying on individual client firewall software for network security. At best, that should be a second line of defense. It is the job of the perimeter firewall to handle these kind of threats.
A week from now if someone does follow through on the threats is it still a joke? Seriously, sometimes threats do get carried out.
When was the last time an Internet threat by a stranger was actually carried out in meatspace?
Note that I'm not including cases where the victim already knew the perpetrator in the real world and the threat just happened to take place on an online service, nor am I counting instances where the entire crime took place online, such as DoS attacks or stealing personal information. I'm talking about some guy on the Internet making a threat of committing violence against someone they don't already have a personal real-life acquaintance with, and then actually carrying it out. Has this ever happened? If not, why shouldn't all such threats be disregarded as meaningless and empty?
Death threats are illegal, they don't become legal because they're On The Internet any more than an old technology should become patentable because it's done On The Internet.
The legality of death threats is actually not a cut-and-dried issue. This article discusses various U.S. court cases related to death threats, and what criteria the courts use to determine whether they are protected free speech or not.
I suspect that a death threat accompanied by "doxxing" would be considered more serious than an isolated threat out of the blue in a chat room, since posting personal information would make it more likely that "a reasonable listener would understand [it] as an actual threat of violence" and not just rhetoric. But I'm not a lawyer, so I can't be certain of this. Of course, it goes without saying that the safest (and most ethical) course of conduct is not to issue any death threats at all.
And no matter what the charter is, if they are liquidated the court will sell all of your data to the highest bidder to pay off creditors.
That is true if the user data is considered part of the bankruptcy estate. But that won't necessarily be the case. Under US law, everyone automatically has copyright for anything they write or compose. If the primary concern is to protect user privacy, the user agreement for the site could stipulate that users retain copyright to all their data, and the site has a nonexclusive, nontransferrable license to use that data so long as they adhere to the privacy terms. In the case of bankruptcy, the only "asset" would be the nontransferrable license – not the data itself, which would still belong to the end users.
I expect issues like this to come up once a few mid-size or large cloud providers go broke. I don't think the courts are going to allow the creditors to seize data assets belonging to customers in these instances.
If your process involves generating Office, documents, it's generally the easiest way. The server automation tools for generation of Office documents are basically scripts and wrappers around.... Office. So if you want to generate some report that spits out an Excel file at the end, you can bet it was generated in Excel the first time around because the reporting tool actually called Excel to fill in the fields.
This may have been correct 5 to 10 years ago, but you should never do this in a modern installation if you can possibly help it. Microsoft's official position is that "Microsoft does not recommend or support server-side Automation of Office."
You should be using the Open XML SDK to create Office documents in your web application. The default classes and methods are somewhat opaque, but fortunately, there are a lot of helper toolkits that run on top of OOXML SDK to make things much easier. I used Simple OOXML, which hasn't been updated for a while and has limited documentation, but works pretty well, and is free. These solutions are not only much more robust in a server-side situation, but you don't have to devote an Office license to the server.
This is going to be a real problem with embedded systems. At my last workplace, we had coin/bill vending units hooked up to PCs, which were connected using a FTDI serial-to-USB connection. I think the chip was legit – but how would I be able to tell? We purchased these vending units from a manufacturer, which in turn, I'm sure, bought the serial-to-USB chips (or even pre-made boards) from another vendor. What if that other vendor used clone chips without telling anyone?
And yes, we did occasionally install FTDI driver updates on these. If one of these units were to be bricked, FTDI is going to be open to some very substantial lawsuits. Arguing "unclean hands" won't work when the people getting hurt are about four steps removed from any actual culpability.
Not going to happen, the same way that it didn't happen when DirectTV (or dish, whoever) bricked all of those pirate hardware years ago
No claims were made in that case because anyone who came forward would have to admit committing a federal crime. In contrast, there are plenty of ways that someone could wind up with a bricked device that they had no knowledge was not authentic, and could not reasonably have known.
I actually like the Ribbon in Office, because the Office apps have so many features that regular menus/toolbars hinder discoverability. (I suppose I might feel differently if I had invested a lot of time into memorizing the Office 2003 menus, but I didn't.) On most other applications, Ribbon is overkill, taking up too much space (and vertical space is especially precious on widescreens).
Maybe I am wrong, but over the years I have noted an increasing condescendension of IT people over "mere users". I wonder why that is. Bear in mind that IT typically isn't the company's cash cow, but "overhead", making this condescension rather inappropriate imho.
All this is the sign of a poorly run organization with excessive siloing. IT should be working with other departments, helping to streamline and automate their processes, making other people's jobs easier and less tedious. If people think of IT as "the computer janitors", your organization is throwing away a tremendous amount of potential productivity. It's bad for morale on both sides, too.
I wonder when Microsoft will learn that a lot of us would rather use our CPU and GPU cycles for something other than eye candy? While computers can be used for fun purposes, we shouldn't all be left with the feel that what we have is little more than a technotoy.
Windows has always offered the option to turn off animations. (System Properties -> Advanced System Settings -> Performance gives a bunch of checkboxes for this on both Win7 and Win10.) Flip it around: why shouldn't those of us with good mid-range or high-end desktops be able to use a small portion of our CPU and GPU power to make things look nicer? Why should we be hamstrung to what the crappiest tablet with a half-dead battery can handle?
This is a good start (assuming you can turn these animations off if you don't like them). Hopefully they'll bring back Aero Glass-style transparency soon.
There are also a lot more substantive flaws that need to be addressed. The Start menu (which is Win10's big selling point!) doesn't currently do DPI scaling properly. It's disappointing enough to see this flaw with third-party software, but for a core part of the OS, it's inexcusable. And there is still no way to remove the obtrusive Search and Task View icons from the taskbar. (Both of these issues have hundreds of votes on Feedback; hopefully they will be addressed.)
There are also a bunch of smaller annoyances – unlike in Win7, I can't get the useless "Homegroup" option to disappear from the left panel of File Explorer, even if I leave all homegroups completely. They also shove OneDrive down your throat. And if I rename "This PC" back to "My Computer", it displays under my preferred name in most places, but not in the tile half of the Start menu – it appears fine in the left-hand list portion, but the tile always says "This PC" no matter what it has been renamed to.
There are some encouraging signs, but this is definitely an alpha-class release in my experience. Glad I installed it in a VM.
But all that means is that the user sees a yellow splat in the system tray. Not really a big deal. You can still actually access the Internet on Windows even if NCSI thinks it's down. The Belkin issue is a much bigger deal.
I know I'll get flamed for saying this, but it seems to me that the Shellshock bug represents a weakness in the Unix philosophy. On Windows, if a similar issue happened with cmd.exe or PowerShell, it would have only a limited effect, because the Windows shell is basically just an administration tool, and no one in their right mind would use it to pass untrusted input of any sort. In contrast, "the Unix way" encourages piping of shell commands to other shell commands, and the use of shelling out as a substitute for proper APIs. To me as a Windows power user, the idea that a basic feature like DHCP is using a shell script behind the scenes seems crazy. The better way to write re-usable code is to do the C/C++ API first, then build both the command line and GUI tools on top of that API. "The Unix way" is a clumsy hack in comparison – and it leaves the shell as a security-critical single point of failure.
Another way to think of it is that Linux is now dealing with an issue that Windows has been struggling with for over a decade: how to fix inherently insecure design decisions without breaking compatibility with a million different legacy applications in the process. Maybe they'll need to implement the equivalent of "UAC" whenever a program tries to shell out?
I actually find myself liking google keep. I wanted a simple thing to make quick on-the-fly lists/notes.. and it delivers.
Google Keep is nice. Sucks that there's no public API, though.
Obviously, people doing low-level systems programming do need to have the background to understand this stuff. But that doesn't really matter – there are a hundred application programmers for every systems programmer. It's like saying all programmers need to be able to write in assembly and count cycles, just because some embedded work still requires that sort of stuff.
Most coders don't actually program. They just write some lines of code that connect libraries together. They wouldn't know where to even begin if asked to write the libraries themselves, or write the networking protocols, or the operating system, or the compilers, or the GUI frameworks, or the browser, or even a simple scripting language.
Converting business requirements into executable processes that a computer can understand is programming, regardless of what language or API is used. There's nothing noble about re-inventing the wheel just to prove you can do it; it's just stupid and inefficient.
More to the point, organizations don't care about hiring well-rounded Renaissance Men. They want people who can get a specific job done. Whether that job satisfies non-customers in some far-off ivory tower is completely irrelevant.
But someone who can code AND knows the theory is better than some stupid code-only monkey anyday.
It's true that "pure" coding is becoming less valuable, but that doesn't mean that Comp Sci skills are your only way (or even the best way) out of that niche. Being able to understand business requirements and translate them into functional products is a lot more important than understanding five different sort algorithms that you'll never use (since the API handles all that crap for you).
There's plenty of blame to go around on both sides here.
The motherboard manufacturers – pretty much all of them – are to blame for developing and shipping really crappy firmware. (Unfortunately, this is pretty much par for the course – 95% of all firmware is crap, no matter what it's for. Modern hardware companies, with a few obvious exceptions like Apple, just don't do software very well at all.)
The Linux kernel devs are to blame for being stubborn about "standards-compliance" versus the real world. From what I can tell in clicking through a few links, the ACPM feature was working in the past, but the kernel devs then deliberately broke it by changing it to only work if the BIOS advertises it properly. Yes, the standard says that's what is supposed to happen. But we know from experience that manufacturers often don't follow standards. Linux needs to deal with the world as it is, not as the devs wish it would be.
Nope. A website that has to hook into a bunch of poorly maintained, poorly documented databases. That's the hard part.
This kind of crap is par for the course. I've had to figure out poorly designed databases without documentation, and it didn't cost millions of dollars to do that. Admittedly, insurance company big iron is probably much hairier to deal with than what I'm used to... but $240 million worth? Sorry, I just don't see how this adds up.
The real problem here is that Europe hasn't given the vacuum cleaners enough R&D time to make more efficient vacuums; should have been a ban for 2018+ not 2014.
Why not just use the same designs that are currently sold in the United States? As others have noted, we're pretty much limited to 1600W already, because of the maximum capacity of standard household circuits (120V/15A).
You need properly trained and aware users
In other words, we're doomed.
One major problem with security is that the permission model on both Windows and Unix doesn't really give you the tools you need to keep yourself safe. We're still stuck in the 1970s university mentality where the user is assumed to have written or at least compiled the program themselves, and is supposed to have a good understanding of what it does. The program is assumed to be operating as an agent of the user, so it inherits all the user's permissions. On modern systems, with semi-trusted and untrusted code downloaded from the Internet, this assumption is absurd and dangerous.
Rather than the program inheriting the user's permissions by default, a decent modern security model would instead restrict it to a sandbox unless it was explicitly given permission to get out – and even then the user should be given veto power over specific sandbox breaches. (Android used to work like this, but Google dumbed it down for reasons that are not clear.)
By default, a program should only be able to do the following:
Anything else – Internet access, ability to freely read and write to files/folders, ability to get keyboard input when not in focus – should require explicit user permission. And the user should have the option of unchecking any or all of these authorizations and continuing to run the app without it being able to do those things. These permissions should be as fine-grained as possible, so an application could have permission to only read certain specific folders, or could be allowed to access the Internet only through a particular API (say, for handling registration or online high scores) and only for certain domains.
It was tied to the operating system, unnecessarily. The browser has exactly zilch to do with the operating system. ActiveX controls, tying versions of the browser with versions of the OS, varying behaviour of same browser version on different OS versions etc. If IE is renamed, it should be delinked from the OS like other browsers.
I agree that tying versions of IE to specific versions of Windows was a really bad idea. Many web developers are still stuck with supporting IE8 because it is the latest version that runs on XP, and many users (and even companies) still haven't upgraded. This has clearly retarded the adoption of modern technologies like canvas and SVG support, which is a serious problem.
But at this point you really can't fully remove IE from Windows without breaking stuff. Sure, you can use the uninstall option to remove iexplore.exe (and newer versions of Windows let you do that), but if the back-end components like mshtml.dll were also removed, then a non-negligible amount of existing software would break. Since backward compatibility is really Microsoft's strongest selling point, this is a non-starter. Don't forget that Microsoft Help files also use HTML, so the Trident rendering engine is needed to view them. You could argue that this is unnecessary tying, but I'm not sure a custom proprietary format would really have been a better choice than HTML for help files – it seems a fairly sensible choice.
I never understood why drivers had to be on the kernel ring anyway. Every single peripheral (GPU, sound card, etc.) driver I've ever encountered has had a history of stability problems. You'd think the largest point of failure on the computer could be moved to userland and restarted when necessary.
Audio drivers were moved to user mode starting with Windows Vista. (That's why DirectSound 3D is no longer supported.) Video drivers, however, pretty much have to be in the kernel for performance reasons.