Mod up. Obligatory vehicle analogy: if I ordered a compact car and was given a really excellent pickup truck instead, chances are that I'd be unhappy too. It's no criticism of the truck. Another time, I might want the truck, but not right now.
What we have is a problem with vendors making condescending assumptions. Some tech support guy at Dell is a Linux enthusiast (great) but expresses a bias against Windows when dealing with this customer. Verizon, instead of providing general connectivity to its network, is biased toward Windows, putting this customer at a disadvantage. MATC likewise presents a bias toward Windows when in fact OpenOffice.org would be quite sufficient.
To put this whole computer literacy thing in perspective, something approaching 20 percent of Americans and Canadians are functionally illiterate. Similarly, many people go out and buy computers despite not knowing the first thing about using them. Let's treat these people with compassion.
Far and away the best job I've ever had, in a career spanning over thirty years, was system administration for academic computer science. Because the users were intelligent and knowledgeable, they set high but realistic expectations of the IT staff, and they financially and morally stepped up to support our efforts. The atmosphere was collegial, honest, and rewarded merit. We built a great environment which helped our users to achieve great things.
The worst job I ever had was doing sysadmin for another academic department at the same institution. The place was steeped in nepotism. Every user had root. Every user felt free to recable the network at will. There was no budget for infrastructure. The accumulated misery did not recognizably constitute a computing environment.
To a fair approximation, both user communities were comparably intelligent, and both had willing technical staff. The big differentiators were political health and relevant expertise. In my view, a truly successful IT environment will be found to have both in abundance. So, while I agree that CS researchers and IT support staff are not interchangeable, the fit is actually pretty close to ideal.
Well, I'm not sure that a lack of planning on your part is justification to violate your organization's security policy.
A developer is not responsible for making operational decisions. If you think otherwise, it would be useful to talk with your CIO about it. But I think I can already predict the outcome of that conversation.
I agree with sjames when he disputes your comments regarding similarities between Clipper and X.509. Except that they both concern cryptography, there are no similarities between them.
The Clipper fiasco was a failed attempt by US government to build a deliberate back door into a specialized crypto algorithm. It was doomed for many reasons, not least because governments such as mine pointed out that it would not be in our national interest to import products which used the Clipper chip. Realizing that the US would effectively embargo itself, the Clinton administration eventually came to its senses.
People seem to be confusing SSL with X.509 in this discussion. There is no issue with the SSL protocol. The X.509 certificate framework, which SSL uses, is based on asymmetric cryptography. You state that certificate authorities issue public key pairs. This is an elementary misunderstanding of how asymmetric crypto works. In fact the principal, that is you for example, generates the key pair, then sends the public key to the CA to be signed. This signed object is the certificate. Only the public key is ever on the wire, and there is no risk in exposing it. You can hand it out to strangers, and in fact that's the whole point of having it. Conversely, you never send the private key anywhere, so there is no back door.
You don't entirely trust your government. Well, that's fair, I guess. But take a look around. Let's be practical. Your government already collects taxes to fund its many operations. It already passes legislation and operates a police force and a penal system. It already provides the civil infrastructure we depend on for our daily lives. It already manages a massive identity infrastructure which facilitates our use of public roads and payment of taxes, not to mention voting. It already negotiates with other governments to make reciprocal arrangements regarding passports, trade, and so on. Now you're saying, whoa, that's all cool but for God's sake don't let the government sign certificates?
And it should be just the opposite. For a skilled system admininstrator, the most interesting environments to design and operate are development and research environments, certainly environments with a strong development component. Developers "get it" in ways that other users don't even know exists to be understood.
So it especially sucks when the rapport between these natural allies breaks down. Sorry that you find yourself in that situation. If the person in question is an obstinate idiot, then there's not much point in trying to reason with them directly, though sometimes if you can make sense of their methodology you'll find that it's there for legitimate reasons.
The classic example, of course, is developer wants root, sysadmin says no. But really, the dialogue should not end there. It's going to take extra time to work this out, because in fact you don't need root, you need some specific capability that comes as a side effect of having root. You won't get root. That's like inserting code changes out of version control or QA because they're "obvious". Instead you guys need to sit down and figure out how to systematically build the capability you need into the environment.
Poor sysadmins avoid this effort; good ones embrace it. If you're stuck with one of the former, maybe there is someone more competent further up the chain of command who could mediate. I'll also say that good developers understand the importants of clearly stated requirements. Be sure that you're doing your part to make your requirements understandable.
Reminds me of that old mathematicians' joke about there being no such thing as an uninteresting integer. The proof? It's evident that many small integers are intrinsically interesting. Zero is interesting because it can't be used as a denominator. One is interesting because multiplication and division by it yield the same result. Two is interesting because it's the first prime number. We can therefore state that for some n, the first n integers are interesting, and n + 1 is not interesting. But that makes n + 1 the first uninteresting integer, which makes it interesting.
And I've found that system administrators who have not developed significant programming experience also have difficulty with basic system administration concepts. The most basic of these is that any system is a particular instance of a certain class. System administration amounts to maintaining a code base written in an ultra high level object language. That's if you're competent.
Disk mirroring is a useful component of a total disk backup solution. It's not itself a total solution, as it only protects against a subset of possible data loss scenarios.
Okay, that wasn't too hard to understand. Now let's move on.
My chief concern with CFLs is that, being more complex and toxic artifacts than incandescent lamps, they may have correspondingly greater environmental impacts in manufacturing and disposal. I haven't seen any effort to quantify these in any discussion of environmental tradeoffs.
The problem is that these sorts of environmental impact don't show up in the price of a CFL as seen by the consumer. Capital costs for tooling and so on for manufacture, cost of raw materials, cost of production, cost of shipping, yes. Environmental cost, no. And since that was one of the two major advantages of using CFLs (the other being operating cost) that seems to leave us with a conspicuously large invisible elephant in the living room.
Another elephant, not quite so invisible since people are at least informally talking about it, is to what degree CFLs can be more economical than incandescent in an already conscientious household. There aren't many locations where lighting necessarily has a long duty cycle. In my apartment building, to take a typical example, communal hallways are required by law to be illuminated at all times. Building entries are also good candidates for fluorescent and CFL fixtures. Good. We did that. Anywhere else, though, the lights only need to be on in a room while it's occupied. Most of us in the building approach this ideal pretty closely already, which means that lights are power cycled somewhere between several times per day and several times per hour. Our conscientious behavior has no significant impact on incandescent lamps. It is, however, a significant cost multiplier for CFLs, and unfortunately this particular cost translates directly to increased environmental impact during manufacture and disposal.
Meanwhile, where are all the energy savings which counterbalance these factors? Let's try your approach of expressing them in terms of cost. My apartment costs about $20 per month in electricity. Of that, about $18 is due to appliances and computation. That leaves $2/month potentially to be saved in lighting. Assuming that CFLs reduced that cost by a factor of 5, and assuming that they had none of the other associated operating and environmental costs identified above, I could expect energy savings of about 8% in the best case. That's not a dramatic savings, but it's still significant.
But caveat emptor. This estimate doesn't consider environmental impact, nor the replacement cost differences between CFLs and incandescent lamps. The total noise here is probably a lot more than 8% of the signal. It's entirely possible that by using CFLs, I would in fact be increasing environmental damage and also paying more money out of pocket. For the sake of such modest benefit even in the best case, the risks don't look good.
As SHA-1 is somewhat weak also, use the SHA-2 family, for example SHA-256 or longer instead.
Be sure to test the resulting cert infrastructure before deploying it. I (vaguely) recall a couple of years ago that OpenSSL lets you specify some legal hash names which it verifies just fine, but browsers such as Firefox may obscurely fail to recognize them when verifying the certificate chain.
Jane Jacobs points out that the roles of government (guardians) and industry (traders) are difficult if not impossible to merge because they are based on different ethical premises. It's therefore not a great idea to put traders in charge of the public interest. Think of Verisign for some recent examples of how badly things can go wrong when you put the fox in charge of the henhouse.
As national governments are already responsible for identifying and defending their citizens and territories, for making and enforcing laws, for licensing, and for collecting taxes from identified individuals and corporations, it isn't such a farfetched idea to have governments function as certificate authorities for both individual and corporate requestors. They already have all of the requisite information and controls in place.
Moreover, national governments are responsible for administering their respective top level domains in the DNS. Here is a good example of how identity in the global Internet is already being managed by multiple authorities, in the form of national governments.
That's why self-signed certs aren't really more risky than CA signed certs in practice.
I made a variation of this point to management where I worked a couple of years ago. My purpose was to promote the idea of building a corporate PKI rooted in our own Certificate Authority. You can think of this as a self-signed cert with structure.
The initiative had particular value for us because we deploy and remotely manage a large population of network appliances at customer sites. It's far more efficient for a web client to install a single CA cert than to request trust for each of the hundreds of server certs individually. Moreover, if a rogue cert ever does pop up, the chain will not silently resolve to our CA cert. (It might, as the article points out, resolve to some careless CA, whose reputation, I hope, will diminish accordingly. But I wasn't trying to improve certificate practices worldwide.)
Anyway, management was fine with the part about server authentication for our internal operations. Management was much more hesitant about giving out our CA cert to customers and partners in order to connect to our portals.
Why? The answer, as best I could understand, was the risk of a perception by customers that installing our CA cert would somehow weaken the security of their browsers. And so, because of this perception, we instead sent cert requests to a commercial CA, which as far as I can tell performed no verification whatever on the requests, apart from billing for whatever that may be worth. This was for the "industrial grade" certs, no less, the ones which were supposed to trigger identity checks on the requestor.
So it seems that perception trumps reality just as commercial CAs would wish in their wildest dreams. A CA cert explicitly given to you out of band by a known entity is perceived as less strong than a preinstalled CA cert from a completely unknown entity with questionable practices. Hmm. We have a way to go.
Re:But I *know* alternative medicine is real!!!
on
Trick or Treatment
·
· Score: 4, Interesting
Reminds me of a satire in which "Psychic Friends Hotline" was compared to Microsoft tech support for resolving product issues. The two basically broke even for ability to actually fix issues (neither was successful) but Psychic Friends edged ahead in terms of responsiveness and empathy.
It's called a "demarcation point" and it's identified in the part of the service agreement which describes which parties to the agreement are responsible for what.
Not having an agreed demarc would be less than sane, since then there would be no explicit basis for determining responsibility. That would lead to endless arguments such as you've advanced, which for example either (a) blame the phone company because "it's a phone" (guilt by association) or (b) depend on questionable analogy leading to hairsplitting (reductio ad absurdum.)
According to the article, the exploit took place because of vulnerabilities in customer premises equipment. End of story.
Great historical perspective. I entirely agree. It was especially sad to watch as Sun wobbled for years around Solaris on x86.
But Sun was primarily a hardware business. The SPARC platform was supposed to dominate the market, not that bastard child of a 16-bit partitioned memory CPU called x86. I don't think that Sun engineers, or management, could really believe that x86 was worth troubling about.
Why? Because some people are used to running Solaris on the desktop. I switched to Linux a few years ago, and that's fine, for me. But prior to that I'd been using Solaris for about ten years.
In my experience, pretty much anything that traditionally compiles for Linux will also compile for Solaris. So if you can type "configure; make; make install" you'll probably survive. The main exception is window environment libraries. Best to get them precompiled.
Oh, and by the way, Linux does function as an eminently acceptable desktop.
For me, 2001 was the Year of the Linux Desktop. That's when I switched from Solaris. And why was I running Solaris? Because it had been my desktop for the previous fifteen years.
From my point of view as a working computer scientist, Microsoft was perennially late to the game, perennially full of hot air, and has never - certainly not architecturally - caught up to stuff we were routinely using decades ago.
This year I've had to work at two client sites where the desktops were running Windows XP, arguably the most stable and complete desktop OS that Microsoft has ever produced. I'm familiar with it, but I find it a constant source of frustration. It's basically a toy. Are you kidding, drive letters? Shortcuts?
Often the reason that providers seem inconsistent about enforcing cap is that their billing infrastructure wasn't designed to capture it. Sometimes the only people who see that you've gone over the cap are network tech support staff, and that's more intended to detect abuse than to generate revenue.
The democratic voting process is typically conducted by anonymous poll. In this context, we recognize the crucial importance of anonymity in allowing all citizens to have an equal voice in decisions of common interest without fear of reprisal.
For decades I have actively promoted the usefulness of strong identity to secure many conceivable uses of the Internet. But voting is one example where both identity and privacy have to be maintained. I don't consider that a "bad practice" but an essential capability.
Might be to advance the perception of fairness, nobody is immune, let the courts decide, stuff like that.
And actually, in the long run, that may bring out the best. The difference may be subtle, but I see a difference in how Google and Yahoo responded here in comparison to how Microsoft has historically responded to such moves. Google and Yahoo respectfully withdrew once it became certain that they were on a collision course with public authority. I believe the record is abundantly clear that in cases of conflict with public interest, Microsoft, historically, has pushed ahead with its agenda to the fullest extent possible, sometimes (as in the EU antitrust case for example) past the point where legal avenues have been exhausted.
Correct me if I'm wrong, and watch for changes in this distinction, but I'd like to think that in the long run a pattern will become evident in which corporations that play fair are rewarded and those which don't lose the advantage.
Slashdot Mirror
Mod up. Obligatory vehicle analogy: if I ordered a compact car and was given a really excellent pickup truck instead, chances are that I'd be unhappy too. It's no criticism of the truck. Another time, I might want the truck, but not right now.
What we have is a problem with vendors making condescending assumptions. Some tech support guy at Dell is a Linux enthusiast (great) but expresses a bias against Windows when dealing with this customer. Verizon, instead of providing general connectivity to its network, is biased toward Windows, putting this customer at a disadvantage. MATC likewise presents a bias toward Windows when in fact OpenOffice.org would be quite sufficient.
To put this whole computer literacy thing in perspective, something approaching 20 percent of Americans and Canadians are functionally illiterate. Similarly, many people go out and buy computers despite not knowing the first thing about using them. Let's treat these people with compassion.
Or gender. Don't forget gender.
Far and away the best job I've ever had, in a career spanning over thirty years, was system administration for academic computer science. Because the users were intelligent and knowledgeable, they set high but realistic expectations of the IT staff, and they financially and morally stepped up to support our efforts. The atmosphere was collegial, honest, and rewarded merit. We built a great environment which helped our users to achieve great things.
The worst job I ever had was doing sysadmin for another academic department at the same institution. The place was steeped in nepotism. Every user had root. Every user felt free to recable the network at will. There was no budget for infrastructure. The accumulated misery did not recognizably constitute a computing environment.
To a fair approximation, both user communities were comparably intelligent, and both had willing technical staff. The big differentiators were political health and relevant expertise. In my view, a truly successful IT environment will be found to have both in abundance. So, while I agree that CS researchers and IT support staff are not interchangeable, the fit is actually pretty close to ideal.
Move along, people. Nothing remotely new here.
Now if you want to actually do something to improve security performance, how about establishing some security metrics as a point of reference?
Valid point. That hadn't occurred to me, but of course you're right.
Well, I'm not sure that a lack of planning on your part is justification to violate your organization's security policy.
A developer is not responsible for making operational decisions. If you think otherwise, it would be useful to talk with your CIO about it. But I think I can already predict the outcome of that conversation.
I agree with sjames when he disputes your comments regarding similarities between Clipper and X.509. Except that they both concern cryptography, there are no similarities between them.
The Clipper fiasco was a failed attempt by US government to build a deliberate back door into a specialized crypto algorithm. It was doomed for many reasons, not least because governments such as mine pointed out that it would not be in our national interest to import products which used the Clipper chip. Realizing that the US would effectively embargo itself, the Clinton administration eventually came to its senses.
People seem to be confusing SSL with X.509 in this discussion. There is no issue with the SSL protocol. The X.509 certificate framework, which SSL uses, is based on asymmetric cryptography. You state that certificate authorities issue public key pairs. This is an elementary misunderstanding of how asymmetric crypto works. In fact the principal, that is you for example, generates the key pair, then sends the public key to the CA to be signed. This signed object is the certificate. Only the public key is ever on the wire, and there is no risk in exposing it. You can hand it out to strangers, and in fact that's the whole point of having it. Conversely, you never send the private key anywhere, so there is no back door.
You don't entirely trust your government. Well, that's fair, I guess. But take a look around. Let's be practical. Your government already collects taxes to fund its many operations. It already passes legislation and operates a police force and a penal system. It already provides the civil infrastructure we depend on for our daily lives. It already manages a massive identity infrastructure which facilitates our use of public roads and payment of taxes, not to mention voting. It already negotiates with other governments to make reciprocal arrangements regarding passports, trade, and so on. Now you're saying, whoa, that's all cool but for God's sake don't let the government sign certificates?
And it should be just the opposite. For a skilled system admininstrator, the most interesting environments to design and operate are development and research environments, certainly environments with a strong development component. Developers "get it" in ways that other users don't even know exists to be understood.
So it especially sucks when the rapport between these natural allies breaks down. Sorry that you find yourself in that situation. If the person in question is an obstinate idiot, then there's not much point in trying to reason with them directly, though sometimes if you can make sense of their methodology you'll find that it's there for legitimate reasons.
The classic example, of course, is developer wants root, sysadmin says no. But really, the dialogue should not end there. It's going to take extra time to work this out, because in fact you don't need root, you need some specific capability that comes as a side effect of having root. You won't get root. That's like inserting code changes out of version control or QA because they're "obvious". Instead you guys need to sit down and figure out how to systematically build the capability you need into the environment.
Poor sysadmins avoid this effort; good ones embrace it. If you're stuck with one of the former, maybe there is someone more competent further up the chain of command who could mediate. I'll also say that good developers understand the importants of clearly stated requirements. Be sure that you're doing your part to make your requirements understandable.
What isn't an "Interesting Computer Science Job"?
Reminds me of that old mathematicians' joke about there being no such thing as an uninteresting integer. The proof? It's evident that many small integers are intrinsically interesting. Zero is interesting because it can't be used as a denominator. One is interesting because multiplication and division by it yield the same result. Two is interesting because it's the first prime number. We can therefore state that for some n, the first n integers are interesting, and n + 1 is not interesting. But that makes n + 1 the first uninteresting integer, which makes it interesting.
And I've found that system administrators who have not developed significant programming experience also have difficulty with basic system administration concepts. The most basic of these is that any system is a particular instance of a certain class. System administration amounts to maintaining a code base written in an ultra high level object language. That's if you're competent.
Hmm, I wonder if that fall on her head did some damage after all...
Disk mirroring is a useful component of a total disk backup solution. It's not itself a total solution, as it only protects against a subset of possible data loss scenarios.
Okay, that wasn't too hard to understand. Now let's move on.
Best argument I've seen yet on this subject.
My chief concern with CFLs is that, being more complex and toxic artifacts than incandescent lamps, they may have correspondingly greater environmental impacts in manufacturing and disposal. I haven't seen any effort to quantify these in any discussion of environmental tradeoffs.
The problem is that these sorts of environmental impact don't show up in the price of a CFL as seen by the consumer. Capital costs for tooling and so on for manufacture, cost of raw materials, cost of production, cost of shipping, yes. Environmental cost, no. And since that was one of the two major advantages of using CFLs (the other being operating cost) that seems to leave us with a conspicuously large invisible elephant in the living room.
Another elephant, not quite so invisible since people are at least informally talking about it, is to what degree CFLs can be more economical than incandescent in an already conscientious household. There aren't many locations where lighting necessarily has a long duty cycle. In my apartment building, to take a typical example, communal hallways are required by law to be illuminated at all times. Building entries are also good candidates for fluorescent and CFL fixtures. Good. We did that. Anywhere else, though, the lights only need to be on in a room while it's occupied. Most of us in the building approach this ideal pretty closely already, which means that lights are power cycled somewhere between several times per day and several times per hour. Our conscientious behavior has no significant impact on incandescent lamps. It is, however, a significant cost multiplier for CFLs, and unfortunately this particular cost translates directly to increased environmental impact during manufacture and disposal.
Meanwhile, where are all the energy savings which counterbalance these factors? Let's try your approach of expressing them in terms of cost. My apartment costs about $20 per month in electricity. Of that, about $18 is due to appliances and computation. That leaves $2/month potentially to be saved in lighting. Assuming that CFLs reduced that cost by a factor of 5, and assuming that they had none of the other associated operating and environmental costs identified above, I could expect energy savings of about 8% in the best case. That's not a dramatic savings, but it's still significant.
But caveat emptor. This estimate doesn't consider environmental impact, nor the replacement cost differences between CFLs and incandescent lamps. The total noise here is probably a lot more than 8% of the signal. It's entirely possible that by using CFLs, I would in fact be increasing environmental damage and also paying more money out of pocket. For the sake of such modest benefit even in the best case, the risks don't look good.
As SHA-1 is somewhat weak also, use the SHA-2 family, for example SHA-256 or longer instead.
Be sure to test the resulting cert infrastructure before deploying it. I (vaguely) recall a couple of years ago that OpenSSL lets you specify some legal hash names which it verifies just fine, but browsers such as Firefox may obscurely fail to recognize them when verifying the certificate chain.
Jane Jacobs points out that the roles of government (guardians) and industry (traders) are difficult if not impossible to merge because they are based on different ethical premises. It's therefore not a great idea to put traders in charge of the public interest. Think of Verisign for some recent examples of how badly things can go wrong when you put the fox in charge of the henhouse.
As national governments are already responsible for identifying and defending their citizens and territories, for making and enforcing laws, for licensing, and for collecting taxes from identified individuals and corporations, it isn't such a farfetched idea to have governments function as certificate authorities for both individual and corporate requestors. They already have all of the requisite information and controls in place.
Moreover, national governments are responsible for administering their respective top level domains in the DNS. Here is a good example of how identity in the global Internet is already being managed by multiple authorities, in the form of national governments.
That's why self-signed certs aren't really more risky than CA signed certs in practice.
I made a variation of this point to management where I worked a couple of years ago. My purpose was to promote the idea of building a corporate PKI rooted in our own Certificate Authority. You can think of this as a self-signed cert with structure.
The initiative had particular value for us because we deploy and remotely manage a large population of network appliances at customer sites. It's far more efficient for a web client to install a single CA cert than to request trust for each of the hundreds of server certs individually. Moreover, if a rogue cert ever does pop up, the chain will not silently resolve to our CA cert. (It might, as the article points out, resolve to some careless CA, whose reputation, I hope, will diminish accordingly. But I wasn't trying to improve certificate practices worldwide.)
Anyway, management was fine with the part about server authentication for our internal operations. Management was much more hesitant about giving out our CA cert to customers and partners in order to connect to our portals.
Why? The answer, as best I could understand, was the risk of a perception by customers that installing our CA cert would somehow weaken the security of their browsers. And so, because of this perception, we instead sent cert requests to a commercial CA, which as far as I can tell performed no verification whatever on the requests, apart from billing for whatever that may be worth. This was for the "industrial grade" certs, no less, the ones which were supposed to trigger identity checks on the requestor.
So it seems that perception trumps reality just as commercial CAs would wish in their wildest dreams. A CA cert explicitly given to you out of band by a known entity is perceived as less strong than a preinstalled CA cert from a completely unknown entity with questionable practices. Hmm. We have a way to go.
Reminds me of a satire in which "Psychic Friends Hotline" was compared to Microsoft tech support for resolving product issues. The two basically broke even for ability to actually fix issues (neither was successful) but Psychic Friends edged ahead in terms of responsiveness and empathy.
It's called a "demarcation point" and it's identified in the part of the service agreement which describes which parties to the agreement are responsible for what.
Not having an agreed demarc would be less than sane, since then there would be no explicit basis for determining responsibility. That would lead to endless arguments such as you've advanced, which for example either (a) blame the phone company because "it's a phone" (guilt by association) or (b) depend on questionable analogy leading to hairsplitting (reductio ad absurdum.)
According to the article, the exploit took place because of vulnerabilities in customer premises equipment. End of story.
Great historical perspective. I entirely agree. It was especially sad to watch as Sun wobbled for years around Solaris on x86.
But Sun was primarily a hardware business. The SPARC platform was supposed to dominate the market, not that bastard child of a 16-bit partitioned memory CPU called x86. I don't think that Sun engineers, or management, could really believe that x86 was worth troubling about.
Why? Because some people are used to running Solaris on the desktop. I switched to Linux a few years ago, and that's fine, for me. But prior to that I'd been using Solaris for about ten years.
In my experience, pretty much anything that traditionally compiles for Linux will also compile for Solaris. So if you can type "configure; make; make install" you'll probably survive. The main exception is window environment libraries. Best to get them precompiled.
"weaned from Fisher Price" - ow!
Oh, and by the way, Linux does function as an eminently acceptable desktop.
For me, 2001 was the Year of the Linux Desktop. That's when I switched from Solaris. And why was I running Solaris? Because it had been my desktop for the previous fifteen years.
From my point of view as a working computer scientist, Microsoft was perennially late to the game, perennially full of hot air, and has never - certainly not architecturally - caught up to stuff we were routinely using decades ago.
This year I've had to work at two client sites where the desktops were running Windows XP, arguably the most stable and complete desktop OS that Microsoft has ever produced. I'm familiar with it, but I find it a constant source of frustration. It's basically a toy. Are you kidding, drive letters? Shortcuts?
Often the reason that providers seem inconsistent about enforcing cap is that their billing infrastructure wasn't designed to capture it. Sometimes the only people who see that you've gone over the cap are network tech support staff, and that's more intended to detect abuse than to generate revenue.
The democratic voting process is typically conducted by anonymous poll. In this context, we recognize the crucial importance of anonymity in allowing all citizens to have an equal voice in decisions of common interest without fear of reprisal.
For decades I have actively promoted the usefulness of strong identity to secure many conceivable uses of the Internet. But voting is one example where both identity and privacy have to be maintained. I don't consider that a "bad practice" but an essential capability.
Might be to advance the perception of fairness, nobody is immune, let the courts decide, stuff like that.
And actually, in the long run, that may bring out the best. The difference may be subtle, but I see a difference in how Google and Yahoo responded here in comparison to how Microsoft has historically responded to such moves. Google and Yahoo respectfully withdrew once it became certain that they were on a collision course with public authority. I believe the record is abundantly clear that in cases of conflict with public interest, Microsoft, historically, has pushed ahead with its agenda to the fullest extent possible, sometimes (as in the EU antitrust case for example) past the point where legal avenues have been exhausted.
Correct me if I'm wrong, and watch for changes in this distinction, but I'd like to think that in the long run a pattern will become evident in which corporations that play fair are rewarded and those which don't lose the advantage.