Your business network runs on Windows. MS has a monopoly here.
If you want a phone/tablet that integrates with your business network, you need to have one that runs Windows RT. Others won't be given access to what they need to integrate smoothly.
And if you want a browser on your Windows RT phone/tablet, it must be Internet Explorer. Others won't be allowed.
Whether Microsoft has a monopoly in ARM-based tablets or not is irrelevant. It has a monopoly in the desktop and business-network market, and it's using that monopoly to gain advantages in the ARM-based phone/tablet OS and browser markets.
Counterpoint: I've got a moderately severe case of neuropathy in my legs. Now, the diagnosis required some work by a specialist. But now that it's diagnosed, the actual drug work is pretty much stock. There's a standard drug prescribed for it, and the dosage is almost completely determined by how much I need to have it be effective. The prescription process amounts to me telling the doctor what's been happening and how far I think the dose needs to be adjusted, and the doctor writing the prescription for what I've asked for. I'm nowhere near the safety limits for the drug, and after 2+ years on it I've got an excellent handle on how it's working and where the dosage needs to be. There's absolutely nothing he does with it that the pharmacist can't do just as well if not better. It'd save a lot of time, insurance cost and hassle if the pharmacist could just write and adjust the prescription himself instead of having to wait on the doctor.
There's also things like spot painkillers. When I go in for a prescription for vicodin or the like, the doctor doesn't do anything special. There's no tests he can run, all he has to go on is my description of what I'm feeling. The only check he's doing is "Is this patient likely to be abusing the medication?", and the pharmacist can ask and answer that one as well as any MD. Probably better, the pharmacist is seeing what all 3 of my doctors are prescribing while none of them have any idea what the other two are handing out unless I tell them.
There seems to be some delusion going around about doctors having some magical ability to see things that mere mortals don't. This... just isn't true. Often it's the reverse. While I was hospitalized, the nurses in the ward knew more about my condition and what needed doing than the attending neurologist did. He saw me for 5 minutes once a day, they saw me constantly. He had no idea what had caused my condition, and treatment consists of controlling the pain and waiting to see if it gets better or not. A nurse or a pharmacist can do this just as well as the neurologist.
What about all the sockets implementations, including Windows, that use the Berkeley sockets API? How about every implementation of the standard C library, which uses the API from the original Unix C library?
Or how about PCs themselves? IBM holds the copyrights to the original PC BIOS API. And not a single machine today uses a BIOS that was written with a license from IBM to reimplement the BIOS API. That was the whole point of the Phoenix and other compatible BIOSes. If the old holding in the case between IBM and Compaq/Phoenix is invalidated, can IBM enjoin the production of every PC system out there (including x86-based servers) and demand the destruction of all infringing copies (ie. every single PC-compatible system including x86-based servers) as allowed under USC Title 17 Section 503?
What's really troubling, though, is the attitude towards the users' data.
The attitude towards people's data troubles me, too. The attitude that people should be entitled to any expectation of privacy for data they broadcast over the equivalent of a loudspeaker, for instance. If you have any intention of the data being private, broadcasting it to anyone listening within a block's radius is the last thing you'd be doing. And if you had to do it, you'd use encryption to insure anyone hearing it wouldn't be able to understand it. If eg. you didn't want people seeing into your living room, you'd at least pull the curtains. If you took the activity out of the living room and onto the front porch, do you really have any call to complain when people watch from the sidewalk? No. So what exactly did Google do that was unreasonable, let alone particularly wrong?
That's odd. On my machine I can open Chrome, go to Settings|Basics|Search and select from several search engines including Bing and Chrome will honor my selection. If the one you like isn't listed, you can add it yourself. Sure it starts out set to Google by default, it kind of has to be set to something, but that's hardly "shutting out the competition".
Exactly. If I'm employed at a warehouse and while on shift I'm quietly slipping boxes of goods to my friend Fred out the side door, I can't be charged with breaking-and-entering merely because the company didn't authorize me to steal stuff from them. I can still be charged with theft, because I did steal stuff from them, but that has to do with what I did while I was there not whether I was authorized to be there.
There's laws in California governing returns, and BB's policies likely violate them. But rather than fighting it out in small-claims court, it's easier to avoid the whole problem. I pay for stuff like that using my American Express card. If the item's defective and BB won't accept a return, I just call up Amex and dispute the charge, explaining that I've attempted to return the defective item to the merchant and they've refused to accept the defective item even though they're legally required to (law trumps return policy, the idea here is to cut off the merchant's "Our documented policy doesn't allow that return and the cardholder knew that." argument before they can make it). If I'm legitimately entitled to return the item, Amex will simply take the money out of BB's merchant account and put it back in mine, and then it's up to BB to fight it out with Amex.
Caveat: have the item packed and ready to return to the merchant. Amex will cut you off at the knees if you're trying to get your money back but keep the item. Also, I use this only for defective or not-as-advertised items, not cases where the item's in good working order and as advertised and I just don't like it now that I've got it.
Think about it. Google offers a lot of messaging offerings. Google Voice is the voice portion of videoconferencing. The software also supports the video part. If Google wants to offer an integrated messaging system (e-mail, IM, voice/audio, videoconference) to corporate customers, Google Voice plays a central part. And then there's Android: Google Voice is their version of the many "wireless calling" features on cel phones that let you make/receive phone calls using local wireless connectivity instead of the cel network (useful inside downtown office buildings where cel reception's poor).
Google Voice is one of those products that on it's own isn't particularly sellable, but once you have it you can build a lot of other things that are.
The problem is that there's a disconnect between Google (and most people) and the SEO industry when it comes to what SEO means.
To most people, and to Google, SEO means designing pages and metadata so it's easy for the search engine to figure out what the page is actually about so it can rank it's relevance to the search the user entered. This is good. It helps deliver search results that the user will find useful.
To the SEO industry, SEO means designing pages so that they rank highly for a specific set of searches regardless of how relevant to those searches the pages are. This is bad. It makes the search results contain things the user wasn't searching for. And frankly it's bad for a site because when I find out that xyz.com was at the top of the list for searches when it's not relevant, I'm going to remember xyz.com as a fraudulent site. And when it gets returned when it's really relevant, I'm going to see that domain and go "Oh, them again." and skip right past them.
Well, duh. Thanks to the rules (lobbied for by we-all-know-who), most government contracts are cost-plus: the contractor's paid the bid plus any additional costs that come up after the bid. With those terms the best approach is to low-ball the bid to insure you win it, do a shoddy job and then bill any time needed to fix the problems as an additional cost.
The fix is obvious: eliminate cost-plus. Make the standard terms fixed-cost: the contractor's paid the amount bid to deliver the goods as specified in the bid, and if they don't meet spec the contractor has to eat any costs needed to correct the deficiency. The only costs that're paid beyond the bid are those for changes the government requested after the bid was placed, and those costs are fixed before the changes are started. But the lobbyists for the big government contractors will fight that tooth and nail.
Except that that removes the safety and security of the system. The untraceability is what protects voters from coercion. If it was possible for any party to trace a person's vote and see what it was, it's then possible to threaten voters with repercussions if they don't vote the way you want them to (eg. "Vote for the candidate the CEO likes or we'll fire you.", although in reality it'd probably be a bit more subtle than that).
Oddly it is possible to implement an electronic voting system that's both untraceable and secure. But so far every electronic voting company has been resistant to building an independent audit trail in.
In a real election, no. But the point of this kind of exercise is to provide a situation where there's no way anybody could deny that the results are wrong (it's not just a few votes miscounted, it's every single vote set incorrectly which simply can't happen by chance or random error), yet at the same time there's absolutely no way to prove it happened and in fact trivial to prove it didn't happen (the audit trail is intact and shows that the reported count is correct and true even when it isn't). Being able to tamper with the results in a way that's blatantly obvious (eg. by changing the ballots presented) doesn't scare people. "We can swing the election any way we want, as blatantly as we want, and you can't prove a thing.", that's the kind of thing headlines and news show lead stories are made of.
To me it's fairly clear that there's two components:
1. The goods. The actual game software delivered to you, whether in a box or via download. It can be purchased and paid for, or provided for free, but it's a good delivered into the hands of the buyer.
2. The service. This would be access to the servers run by the game company and technically needed to run the game, verify account authorization and such.
You can have a mix of the two, depending on the degree to which the game does on-line play. You have completely stand-alone single-player games, completely on-line games, and ones that're a mix of the two (eg. single-player games with a multi-player on-line mode). The law ought to have no problem with this, after all it's got no problem dealing with the sale of a car (goods) that comes with a maintenance contract (a service).
Note that in the above servers not technically needed to play the game are excluded. Ie., the law shouldn't count as a "service" a DRM server whose only purpose is to block disallowed play of a game that's otherwise completely stand-alone and single-player and wouldn't need to interact with a server for any reason other than the game designer's choice to make it dependent on their server. This is distinct from eg. World of Warcraft where the whole point of the game is to interact with a world inhabited by other people, which you can't do without interacting with a game server that maintains the world.
What I want to see is a real compromise of one of these systems that can be held up as a true scare story:
1. The compromise is undetected. At the time the results are reported, the election officials are unaware that the system has been compromised and none of the systems in place for detecting a compromise has indicated any trouble. According to all evidence in the audit trail the results are undeniably correct and true.
2. There was no indication of tampering at the time of voting. As votes were being cast there was no indication of tampering with the ballots or any other visible indication that the results weren't being correctly recorded and reported.
3. The results reported are undeniably wrong. Eg., the test voting was done in a controlled manner where everyone knew what the correct results should be and that everyone saw that everyone else had voted the way they were supposed to, so if the system functioned correctly it's known exactly how many votes should be cast for which candidate.
4. The reported results are undeniably wrong. Eg., according to the reported results 100% of the votes cast were for a candidate who should've received zero votes.
Shut the surrogate control servers down. The main reason people don't take security seriously is there's never any real costs associated with not taking it seriously. Most of the users of the infected machines probably are thinking "Why should I worry about this? My machine's working just fine.". Well, when the control servers shut down and the infected machines can't access the network at all, the users won't be able to keep ignoring the problem. And maybe, just maybe, having to pay the price for complacency will make them not be quite so complacent in the future.
Thing is, P3P isn't a security solution. It's a legal/social solution: make the site declare what it promises to do, and then the user has a solid basis for complaints through the usual channels for breach of that promise. The courts may not understand the technicalities of P3P and the Internet and such, but "He made a written promise to not do X (which promise I have a copy of), I relied on that promise, he went ahead and did X anyway and I've suffered these damages because of it." is something the courts deal with every day.
As for whether that's effective or not, I simply point back to Google's response. They're playing this game precisely because of the risk they run if they openly make a false statement in their P3P header (and the only non-false options they have are things they don't want to admit to). Once the grifter has to start being openly evasive about what he's promising, it's not long before the marks start getting nervous and dropping out of the game.
Then your understanding would be incorrect. The P3P compact policy isn't a list of the "bad" things the site says it will do. It's a list of the things, both good and bad, that the site promises to abide by. An empty tag isn't a promise not to do anything bad, it's a lack of a promise either way. Think of it as deciding whether to loan money to someone or not and asking them to say whether they intend to pay the money back or take it and disappear. If they refuse to say either way, you're not going to take that as a promise to pay it back, are you?
As for a URL in the compact policy, the spec does in fact define how to parse it: you tokenize it, ignore those tokens that don't match those defined by the P3P spec and interpret what's left. If there aren't any recognizable tokens, you interpret it as if the CP had been empty. Sensible code interprets that as a lack of any firm promise about anything.
Wrong. "P3P=" isn't saying they won't use it for anything, it's not saying anything about what they'll use it for. You're supposed to be able to trust anything said in the P3P header, but nothing in the P3P spec says they have to say anything. And if they don't say anything about a specific subject, best practice is to assume the same as if they hadn't included the P3P header at all (at least regarding whatever item you're looking at at the moment).
If you need someone to drive a vehicle for you and they won't say whether they have a driver's license or not, do you assume they've got one and it's valid for the vehicle you need them to drive? No, you assume they don't.
When I was configuring P3P for Mozilla/Firefox, it distinguished between what exactly the P3P policy was stating. If the site didn't say in the P3P policy what it was doing with cookies, Firefox assumed the worst. It seems to me that if the IE devs were dumb enough to stop after seeing a P3P policy presented and didn't bother checking what it said, or if they assumed a lack of a statement indicated respect for privacy, that's a failure in IE. The code needs to start out assuming personal information is collected and used without consent, and then upgrade only if the P3P header specifically says something better. It's not like that's hard to implement.
Then again, we've seen similar problems in Microsoft software time and time again: they assume the best (input's valid, doesn't contain special characters, etc.) until they detect otherwise, even though best practices say to do the opposite (assume input's invalid until analyzed and proven correct, list the known non-special characters and filter out or escape everything not in that list).
The easiest way is to not assign priorities to projects. You do need to prioritize, but don't start with a list of priority levels and assign them to projects. Start with a list of projects, list the benefits to business if they're completed, the costs to business if they're not (including things like increased development times) and the resources needed for each one, and have business sit down with IT and sort that list into order by priority. There's no such thing as a high-priority project, only one that's higher on the priority list than another. Then, IT will work on the highest-priority projects that they've got the resources available to complete. That eliminates priority inflation, and forces business to really deal with the big picture instead of looking at each project in isolation and making it someone else's job to make it all come together.
Tools like Microsoft Project help here, if you've got the resource management tools set up properly then it just won't permit schedules that allocate more resources than are available and it won't let you reduce the fraction of a resource allocated to a project without increasing the time needed to complete that project. And you won't have to try having IT convince business that you have to follow the scheduling software's arbitrary rules, you can get outside trainers to come in and explain that as part of teaching the business people how to get the most out of the scheduling software. You just need to make sure that it's IT, not business, responsible for determining the level of effort needed on each project, and there's a fairly easy way to do that: the person responsible for determining the level of effort is also the person responsible for any schedule over-runs. It'll take a bit of politicking to do this, but in this age of increased compliance reporting it should be an easier sell.
The problem I see is the increasing number of sites (eg. Sony's online game support sites) who "for security reasons" block browsers from auto-completing password fields. Which IMO actually decreases security, it increases the number of times a keylogger could see my password and it makes it harder to use high-difficulty (and difficult to remember) passwords.
The original deal in the IBM lawsuit was that BSF would get paid in shares of SCO stock (which presumably would be worth a lot more after SCO won, making for a tidy windfall for BSF). But that turned out to be a problem for BSF: IBM pointed out that BSF weren't merely counsel but had an actual personal interest in the suit (seeing as they held or would hold an ownership interest in SCO). That scared BSF, because it meant they couldn't avoid liability for judgements if the suit went badly for SCO. That resulted in BSF dropping the equity-ownership deal for a flat-fee contract, to convince the court they weren't a party to the suit in any way.
SCO wanted to reopen the case, not IBM. But SCO wanted to reopen only their side of it, without allowing IBM to bring up any of their side. That... failed to fly with the judge, and SCO and their lawyers really had no choice. If they hadn't reopened the case, I'm fairly sure the next step would've been for IBM and others to move for the bankruptcy court to convert SCO's case over to Chapter 7 liquidation seeing as according to SCO their only asset left is the litigation and that isn't worth anything if SCO can't or won't pursue it.
Because that would leave the impression that IBM had done what SCO accued them of, and IBM was just burying the evidence. Not the sort of impression you want to give when your clients include major foreign banks, militaries and governments and they have to trust you with access to information they don't want even your government getting access to. And IBM does a lot of business. If losing customer's trust costs IBM even 1-2% a year of business, fighting SCO in court is still cheaper by an order of magnitude.
I have this picture of a notional exchange between IBM and it's lawyers:
IBM: *drops a check for $1 billion on the lawyer's desk* "That should do to start."
Lawyer: "... Are you serious?"
IBM: "Well, we figure 1%'s a good place to start, we can always add more later if you need it."
And then I remember that IBM's lawyers have been with them a long time, they're not going to be surprised by this.
Slashdot Mirror
The chain's going to go more like this:
Whether Microsoft has a monopoly in ARM-based tablets or not is irrelevant. It has a monopoly in the desktop and business-network market, and it's using that monopoly to gain advantages in the ARM-based phone/tablet OS and browser markets.
Counterpoint: I've got a moderately severe case of neuropathy in my legs. Now, the diagnosis required some work by a specialist. But now that it's diagnosed, the actual drug work is pretty much stock. There's a standard drug prescribed for it, and the dosage is almost completely determined by how much I need to have it be effective. The prescription process amounts to me telling the doctor what's been happening and how far I think the dose needs to be adjusted, and the doctor writing the prescription for what I've asked for. I'm nowhere near the safety limits for the drug, and after 2+ years on it I've got an excellent handle on how it's working and where the dosage needs to be. There's absolutely nothing he does with it that the pharmacist can't do just as well if not better. It'd save a lot of time, insurance cost and hassle if the pharmacist could just write and adjust the prescription himself instead of having to wait on the doctor.
There's also things like spot painkillers. When I go in for a prescription for vicodin or the like, the doctor doesn't do anything special. There's no tests he can run, all he has to go on is my description of what I'm feeling. The only check he's doing is "Is this patient likely to be abusing the medication?", and the pharmacist can ask and answer that one as well as any MD. Probably better, the pharmacist is seeing what all 3 of my doctors are prescribing while none of them have any idea what the other two are handing out unless I tell them.
There seems to be some delusion going around about doctors having some magical ability to see things that mere mortals don't. This... just isn't true. Often it's the reverse. While I was hospitalized, the nurses in the ward knew more about my condition and what needed doing than the attending neurologist did. He saw me for 5 minutes once a day, they saw me constantly. He had no idea what had caused my condition, and treatment consists of controlling the pain and waiting to see if it gets better or not. A nurse or a pharmacist can do this just as well as the neurologist.
What about all the sockets implementations, including Windows, that use the Berkeley sockets API? How about every implementation of the standard C library, which uses the API from the original Unix C library?
Or how about PCs themselves? IBM holds the copyrights to the original PC BIOS API. And not a single machine today uses a BIOS that was written with a license from IBM to reimplement the BIOS API. That was the whole point of the Phoenix and other compatible BIOSes. If the old holding in the case between IBM and Compaq/Phoenix is invalidated, can IBM enjoin the production of every PC system out there (including x86-based servers) and demand the destruction of all infringing copies (ie. every single PC-compatible system including x86-based servers) as allowed under USC Title 17 Section 503?
What's really troubling, though, is the attitude towards the users' data.
The attitude towards people's data troubles me, too. The attitude that people should be entitled to any expectation of privacy for data they broadcast over the equivalent of a loudspeaker, for instance. If you have any intention of the data being private, broadcasting it to anyone listening within a block's radius is the last thing you'd be doing. And if you had to do it, you'd use encryption to insure anyone hearing it wouldn't be able to understand it. If eg. you didn't want people seeing into your living room, you'd at least pull the curtains. If you took the activity out of the living room and onto the front porch, do you really have any call to complain when people watch from the sidewalk? No. So what exactly did Google do that was unreasonable, let alone particularly wrong?
davfs2 - mount a WebDAV-capable server as a filesystem. Dates back to at least 2009.
That's odd. On my machine I can open Chrome, go to Settings|Basics|Search and select from several search engines including Bing and Chrome will honor my selection. If the one you like isn't listed, you can add it yourself. Sure it starts out set to Google by default, it kind of has to be set to something, but that's hardly "shutting out the competition".
Exactly. If I'm employed at a warehouse and while on shift I'm quietly slipping boxes of goods to my friend Fred out the side door, I can't be charged with breaking-and-entering merely because the company didn't authorize me to steal stuff from them. I can still be charged with theft, because I did steal stuff from them, but that has to do with what I did while I was there not whether I was authorized to be there.
There's laws in California governing returns, and BB's policies likely violate them. But rather than fighting it out in small-claims court, it's easier to avoid the whole problem. I pay for stuff like that using my American Express card. If the item's defective and BB won't accept a return, I just call up Amex and dispute the charge, explaining that I've attempted to return the defective item to the merchant and they've refused to accept the defective item even though they're legally required to (law trumps return policy, the idea here is to cut off the merchant's "Our documented policy doesn't allow that return and the cardholder knew that." argument before they can make it). If I'm legitimately entitled to return the item, Amex will simply take the money out of BB's merchant account and put it back in mine, and then it's up to BB to fight it out with Amex.
Caveat: have the item packed and ready to return to the merchant. Amex will cut you off at the knees if you're trying to get your money back but keep the item. Also, I use this only for defective or not-as-advertised items, not cases where the item's in good working order and as advertised and I just don't like it now that I've got it.
Think about it. Google offers a lot of messaging offerings. Google Voice is the voice portion of videoconferencing. The software also supports the video part. If Google wants to offer an integrated messaging system (e-mail, IM, voice/audio, videoconference) to corporate customers, Google Voice plays a central part. And then there's Android: Google Voice is their version of the many "wireless calling" features on cel phones that let you make/receive phone calls using local wireless connectivity instead of the cel network (useful inside downtown office buildings where cel reception's poor).
Google Voice is one of those products that on it's own isn't particularly sellable, but once you have it you can build a lot of other things that are.
The problem is that there's a disconnect between Google (and most people) and the SEO industry when it comes to what SEO means.
To most people, and to Google, SEO means designing pages and metadata so it's easy for the search engine to figure out what the page is actually about so it can rank it's relevance to the search the user entered. This is good. It helps deliver search results that the user will find useful.
To the SEO industry, SEO means designing pages so that they rank highly for a specific set of searches regardless of how relevant to those searches the pages are. This is bad. It makes the search results contain things the user wasn't searching for. And frankly it's bad for a site because when I find out that xyz.com was at the top of the list for searches when it's not relevant, I'm going to remember xyz.com as a fraudulent site. And when it gets returned when it's really relevant, I'm going to see that domain and go "Oh, them again." and skip right past them.
Well, duh. Thanks to the rules (lobbied for by we-all-know-who), most government contracts are cost-plus: the contractor's paid the bid plus any additional costs that come up after the bid. With those terms the best approach is to low-ball the bid to insure you win it, do a shoddy job and then bill any time needed to fix the problems as an additional cost.
The fix is obvious: eliminate cost-plus. Make the standard terms fixed-cost: the contractor's paid the amount bid to deliver the goods as specified in the bid, and if they don't meet spec the contractor has to eat any costs needed to correct the deficiency. The only costs that're paid beyond the bid are those for changes the government requested after the bid was placed, and those costs are fixed before the changes are started. But the lobbyists for the big government contractors will fight that tooth and nail.
Except that that removes the safety and security of the system. The untraceability is what protects voters from coercion. If it was possible for any party to trace a person's vote and see what it was, it's then possible to threaten voters with repercussions if they don't vote the way you want them to (eg. "Vote for the candidate the CEO likes or we'll fire you.", although in reality it'd probably be a bit more subtle than that).
Oddly it is possible to implement an electronic voting system that's both untraceable and secure. But so far every electronic voting company has been resistant to building an independent audit trail in.
In a real election, no. But the point of this kind of exercise is to provide a situation where there's no way anybody could deny that the results are wrong (it's not just a few votes miscounted, it's every single vote set incorrectly which simply can't happen by chance or random error), yet at the same time there's absolutely no way to prove it happened and in fact trivial to prove it didn't happen (the audit trail is intact and shows that the reported count is correct and true even when it isn't). Being able to tamper with the results in a way that's blatantly obvious (eg. by changing the ballots presented) doesn't scare people. "We can swing the election any way we want, as blatantly as we want, and you can't prove a thing.", that's the kind of thing headlines and news show lead stories are made of.
To me it's fairly clear that there's two components:
1. The goods. The actual game software delivered to you, whether in a box or via download. It can be purchased and paid for, or provided for free, but it's a good delivered into the hands of the buyer.
2. The service. This would be access to the servers run by the game company and technically needed to run the game, verify account authorization and such.
You can have a mix of the two, depending on the degree to which the game does on-line play. You have completely stand-alone single-player games, completely on-line games, and ones that're a mix of the two (eg. single-player games with a multi-player on-line mode). The law ought to have no problem with this, after all it's got no problem dealing with the sale of a car (goods) that comes with a maintenance contract (a service).
Note that in the above servers not technically needed to play the game are excluded. Ie., the law shouldn't count as a "service" a DRM server whose only purpose is to block disallowed play of a game that's otherwise completely stand-alone and single-player and wouldn't need to interact with a server for any reason other than the game designer's choice to make it dependent on their server. This is distinct from eg. World of Warcraft where the whole point of the game is to interact with a world inhabited by other people, which you can't do without interacting with a game server that maintains the world.
What I want to see is a real compromise of one of these systems that can be held up as a true scare story:
1. The compromise is undetected. At the time the results are reported, the election officials are unaware that the system has been compromised and none of the systems in place for detecting a compromise has indicated any trouble. According to all evidence in the audit trail the results are undeniably correct and true.
2. There was no indication of tampering at the time of voting. As votes were being cast there was no indication of tampering with the ballots or any other visible indication that the results weren't being correctly recorded and reported.
3. The results reported are undeniably wrong. Eg., the test voting was done in a controlled manner where everyone knew what the correct results should be and that everyone saw that everyone else had voted the way they were supposed to, so if the system functioned correctly it's known exactly how many votes should be cast for which candidate.
4. The reported results are undeniably wrong. Eg., according to the reported results 100% of the votes cast were for a candidate who should've received zero votes.
Shut the surrogate control servers down. The main reason people don't take security seriously is there's never any real costs associated with not taking it seriously. Most of the users of the infected machines probably are thinking "Why should I worry about this? My machine's working just fine.". Well, when the control servers shut down and the infected machines can't access the network at all, the users won't be able to keep ignoring the problem. And maybe, just maybe, having to pay the price for complacency will make them not be quite so complacent in the future.
Thing is, P3P isn't a security solution. It's a legal/social solution: make the site declare what it promises to do, and then the user has a solid basis for complaints through the usual channels for breach of that promise. The courts may not understand the technicalities of P3P and the Internet and such, but "He made a written promise to not do X (which promise I have a copy of), I relied on that promise, he went ahead and did X anyway and I've suffered these damages because of it." is something the courts deal with every day.
As for whether that's effective or not, I simply point back to Google's response. They're playing this game precisely because of the risk they run if they openly make a false statement in their P3P header (and the only non-false options they have are things they don't want to admit to). Once the grifter has to start being openly evasive about what he's promising, it's not long before the marks start getting nervous and dropping out of the game.
Then your understanding would be incorrect. The P3P compact policy isn't a list of the "bad" things the site says it will do. It's a list of the things, both good and bad, that the site promises to abide by. An empty tag isn't a promise not to do anything bad, it's a lack of a promise either way. Think of it as deciding whether to loan money to someone or not and asking them to say whether they intend to pay the money back or take it and disappear. If they refuse to say either way, you're not going to take that as a promise to pay it back, are you?
As for a URL in the compact policy, the spec does in fact define how to parse it: you tokenize it, ignore those tokens that don't match those defined by the P3P spec and interpret what's left. If there aren't any recognizable tokens, you interpret it as if the CP had been empty. Sensible code interprets that as a lack of any firm promise about anything.
Wrong. "P3P=" isn't saying they won't use it for anything, it's not saying anything about what they'll use it for. You're supposed to be able to trust anything said in the P3P header, but nothing in the P3P spec says they have to say anything. And if they don't say anything about a specific subject, best practice is to assume the same as if they hadn't included the P3P header at all (at least regarding whatever item you're looking at at the moment).
If you need someone to drive a vehicle for you and they won't say whether they have a driver's license or not, do you assume they've got one and it's valid for the vehicle you need them to drive? No, you assume they don't.
When I was configuring P3P for Mozilla/Firefox, it distinguished between what exactly the P3P policy was stating. If the site didn't say in the P3P policy what it was doing with cookies, Firefox assumed the worst. It seems to me that if the IE devs were dumb enough to stop after seeing a P3P policy presented and didn't bother checking what it said, or if they assumed a lack of a statement indicated respect for privacy, that's a failure in IE. The code needs to start out assuming personal information is collected and used without consent, and then upgrade only if the P3P header specifically says something better. It's not like that's hard to implement.
Then again, we've seen similar problems in Microsoft software time and time again: they assume the best (input's valid, doesn't contain special characters, etc.) until they detect otherwise, even though best practices say to do the opposite (assume input's invalid until analyzed and proven correct, list the known non-special characters and filter out or escape everything not in that list).
The easiest way is to not assign priorities to projects. You do need to prioritize, but don't start with a list of priority levels and assign them to projects. Start with a list of projects, list the benefits to business if they're completed, the costs to business if they're not (including things like increased development times) and the resources needed for each one, and have business sit down with IT and sort that list into order by priority. There's no such thing as a high-priority project, only one that's higher on the priority list than another. Then, IT will work on the highest-priority projects that they've got the resources available to complete. That eliminates priority inflation, and forces business to really deal with the big picture instead of looking at each project in isolation and making it someone else's job to make it all come together.
Tools like Microsoft Project help here, if you've got the resource management tools set up properly then it just won't permit schedules that allocate more resources than are available and it won't let you reduce the fraction of a resource allocated to a project without increasing the time needed to complete that project. And you won't have to try having IT convince business that you have to follow the scheduling software's arbitrary rules, you can get outside trainers to come in and explain that as part of teaching the business people how to get the most out of the scheduling software. You just need to make sure that it's IT, not business, responsible for determining the level of effort needed on each project, and there's a fairly easy way to do that: the person responsible for determining the level of effort is also the person responsible for any schedule over-runs. It'll take a bit of politicking to do this, but in this age of increased compliance reporting it should be an easier sell.
The problem I see is the increasing number of sites (eg. Sony's online game support sites) who "for security reasons" block browsers from auto-completing password fields. Which IMO actually decreases security, it increases the number of times a keylogger could see my password and it makes it harder to use high-difficulty (and difficult to remember) passwords.
The original deal in the IBM lawsuit was that BSF would get paid in shares of SCO stock (which presumably would be worth a lot more after SCO won, making for a tidy windfall for BSF). But that turned out to be a problem for BSF: IBM pointed out that BSF weren't merely counsel but had an actual personal interest in the suit (seeing as they held or would hold an ownership interest in SCO). That scared BSF, because it meant they couldn't avoid liability for judgements if the suit went badly for SCO. That resulted in BSF dropping the equity-ownership deal for a flat-fee contract, to convince the court they weren't a party to the suit in any way.
SCO wanted to reopen the case, not IBM. But SCO wanted to reopen only their side of it, without allowing IBM to bring up any of their side. That... failed to fly with the judge, and SCO and their lawyers really had no choice. If they hadn't reopened the case, I'm fairly sure the next step would've been for IBM and others to move for the bankruptcy court to convert SCO's case over to Chapter 7 liquidation seeing as according to SCO their only asset left is the litigation and that isn't worth anything if SCO can't or won't pursue it.
Because that would leave the impression that IBM had done what SCO accued them of, and IBM was just burying the evidence. Not the sort of impression you want to give when your clients include major foreign banks, militaries and governments and they have to trust you with access to information they don't want even your government getting access to. And IBM does a lot of business. If losing customer's trust costs IBM even 1-2% a year of business, fighting SCO in court is still cheaper by an order of magnitude.
I have this picture of a notional exchange between IBM and it's lawyers:
And then I remember that IBM's lawyers have been with them a long time, they're not going to be surprised by this.