No, it's you that violated the ToS, so it's you they'll hold accountable. IMO if the TOS forbid allowing a third party access to my account, my response to an employer asking for access would be "I'm sorry, the terms of service forbid me from doing that. And would you really want me if I demonstrate I'm willing to violate agreements I've made? Like for instance the confidentiality, non-disclosure and non-compete agreements you're going to ask me to sign as part of my employment?". I'd think that'd bring any HR rep up short right there. In my profession confidentiality and non-disclosure agreements are no small deals.
It needs to forbid not just asking for passwords from the candidate, but asking for any kind of access in excess of what an ordinary member of the public would have from anyone (the candidate, the social media site, associates of the candidate, etc.). No requiring the candidate to let you watch him viewing his profile. No asking the social media site to grant you behind-the-scenes access to candidate's profiles. No asking friends of the candidate to let you watch them view the candidate's profile. No special access, period. If the candidate is keeping it from public view, as an employer you don't get special privileges to bypass that.
But if the candidate's dumb enough to leave it open to the general public, it's fair game. Ditto if his friends post things about him and identify him in them. Though if you trust things other people say about him and they turn out to be false you don't get to avoid any liability that'd attach to that either, so you may not want to go trusting the unsubstantiated word of random people you find on the Internet.
I watched the video too, and it's far from clear he's joking. I'd hope he was joking, but I was expecting him to go "because there's no oxygen out there" or something. Or to cue it as a joke and give time for a reaction. If it was a joke, he needs to hire better speechwriters or stop trying to ad-lib when he's obviously got no sense of humor and zero sense of comedic timing.
When I hear the cybersecurity people talking about taking offensive action against intruders, I can't help thinking about Miles, "Brothers in Arms" and the infamous stunner tag sequence.
They're pretty direct at generating heat, yes. They don't emit any light, though, until you get them to a sufficiently high temperature. An LED, by comparison, doesn't emit much except for visible-light photons right from the start. That's why an LED bulb is cool to the touch while an incandescent bulb will burn your fingers. And that's why incandescents are inefficient: every bit of that heat you feel off them is power that's being wasted not producing light. The more efficient the process involved is, the less energy it throws off as anything except the light you want produced.
There's not a lot that can be done about efficiency in incandescents. They by definition work by heating a coil of wire until it glows, which means they're going to generate a lot more heat than light by their very nature (the light's a by-product of the heating, not a primary output). Most of the gains in efficiency are being made by shifting to processes that generate light more directly. For what you've got I'd normally go with LED bulbs for the telltales and rough-service lights. LED bulbs will actually be more reliable in rough service since they're solid and don't have a delicate coil of wire suspended between a few thin posts like an incandescent does. Shocks that'll break the coil of an incandescent and cause it to fail won't faze an LED bulb at all.
NB: how lights work:
Incandescent: heat a coil of wire until it glows.
CFL: excite mercury vapor until it gives off ultraviolet radiation. The UV hits the coating on the inside of the bulb tube and causes it to fluoresce in the visible spectrum.
LED: electrons in the diode junction emit photons as they drop to a lower-energy state. The junction is tuned so the frequency of the emitted photons falls within the visible-light portion of the spectrum.
That won't work for a lot of places. For instance, a system that uses a database where the server and login information changes from environment to environment (development uses the development database server, production will use a completely separate different database and DB server). Often the developers won't know the information for production, and they certainly can't put it in a non-production configuration. That means you'll have a git checkout to get the base code, followed by inserting environment-specific information into the configuration. Or more likely a git checkout of the software followed by applying updates to the existing configuration for new and changed settings if any (often there won't be any configuration changes for a new release). Ideally the configuration update's handled by either a script or a simple patch to update files, but sometimes the easiest and most reliable way is to simply document what needs changed and let an experienced sysadmin pick the best method to do it.
You should have at least 3 environments beyond the personal ones the developers use to develop and unit-test code: development common, QA and production. Development common should be where dev does integration tests, including installation. If developers are responsible for creating the installation tools, they should be doing the installations there so they can debug those tools. If someone else is responsible for writing them, the devs should be working with them to make sure the tools do what the software needs to install correctly. You can't get the installation tools right if you don't test and debug them, and when they interact with the software the developers are the best ones to figure out what's wrong and what's needed to fix it.
Developers should not be doing the installation into the QA environment. They should be handing the installation tools over to QA and letting them run then according to the deployment instructions. That's the only way to confirm the instructions were really complete and that everything works per the documentation, by putting it in the hands of people who didn't write it and letting them deploy it. That way when it comes time to deploy in production you've got some assurance that the deployment will work because it has worked before.
Now, if things do go wrong you need dev involvement. They wrote the software and the tools, they'll often recognize exactly what's going wrong where Ops and QA won't. They're also the ones most likely to be able to give you a quick fix to the problem that'll get production up and running without having to back out and try another day. If you've already invested the time bringing the systems down and deploying the new version, it makes no sense to revert to the old version and waste more downtime tomorrow re-doing the deployment if the only problem is a path in a config file having the version number in it in QA but not in production and a quick edit of the newly-deployed copy of the config file will clearly fix the problem.
I see a bunch of problems, including a few that'll leave the company circling the drain down the road. But one obvious one is that the whole thing depends heavily on what you're selecting for. I know my experience on the hiring side is that HR tends to filter out the best-qualified candidates and leave the ones that aren't qualified. That doesn't bode well for their ability to decide what constitutes a successful employee. It may work OK for tier-1 call-center support, but what happens when eg. you decide you want software developers who fix the most bugs the quickest and deliver the most new features the fastest? You end up with developers who write buggy code that can't be maintained or enhanced. You can't fix a lot of bugs quickly unless the code's got a lot of bugs in it, after all, so the criteria would filter out the developers who avoid creating bugs that'd need fixing. And thinking about what the system will need to do 2, 3 or 4 years down the road and coming up with ways of doing things now that'll accommodate those future needs takes more time than duct-taping together something that just about works right now, so you end up selecting for developers who'll hamstring your ability to enhance your system in the future.
In college math we called it the local-optimization problem: you get so caught up in finding the best way to find the maximum/minimum of a function that you end up missing the maximum/minimum.
#1 writes the code to display the 3x3 grid. This is a standalone program that only outputs graphics, it has no API allowing it's functionality to be called.
#2 discovers this, and works around it by running #1's program and grabbing the graphics from the screen, then modifying them and displaying the modified result. His is also a standalone program with no programming API.
#3 discovers the same thing #2 did, and responds the same way.
By the time you get to #7 you have a mess on your hands that rivals the Deepwater Horizon mess, and maintaining it and keeping it from falling over will cost you twice as much each day/month/year as hiring a single real programmer to do it correctly would have.
Probably they didn't lose the tool itself, just the radioactive source. When I did geotech work, we kept the sources separate and in a lead pig in the back of the truck and only put them on the tool when we were about to do a run. I'll bet the tech got distracted (did things in a different order and missed a step, one of the well crew wanted to know what the results were, could've been many things) and failed to put the lock on the pig before pulling out. Without the lock shank in place the door can come open and the source can rattle it's way out. But even without losing the tool, the boss is going to rip the tech a new one because even though there's no real danger to the public (or at least the non-terminally-braindead members of the public) the boss now has to fill out far too much paperwork on the incident. Plus the tech may well lose his certificate over this, which may cost him his job (no safety cert means he can't use sources, and since it's his fault he lost his cert it's grounds to let him go for cause).
The downside is that viewing those images at all requires the plug-in and the FB app. The only way for it to work reliably is to store the image on McAfee's servers and only serve up the unblurred image if the browser is running the plug-in and isn't interfering with it's operation and they have the FB app allowed on their account. If they do otherwise, then someone can get at the image without the protection present and save it. So it's going to be a fight between friends who're having problems with the plug-in or who blocked the app as malware who you want to see your pictures vs. protecting the pictures.
And of course it won't do anything to protect you from images you uploaded before you started using it, let alone images of you uploaded by other people who aren't using the app (like your friend who snapped a pic of you embarrassing yourself at that party last night and posted it from his cel-phone).
Or we think that our time costs, but it costs less than business downtime does. If you depend on the vendor and their support contract, you're impacted for however long it takes them to come out. They won't typically let you keep spares, so when a part breaks that box is impaired or off-line for whatever your contract response time it and there's nothing you can do about it. But if it's a white-box server that can be worked on in-house, you can typically keep spares on the shelf. It may cost more in admin/tech time than the support contract would, but you get the choice of paying the time and getting the box back on-line in an hour instead of anywhere from 4 hours to next-day. And you get the option of saying "Not worth messing around with. Grab a new box, spin it up and we'll figure out what's broken with this one after we're back on-line.". We techies don't think our time is free, we just don't make the common management mistake of thinking that down-time waiting for a vendor response is free. And usually our time costs a lot less than the down-time would.
It may also depend on what kind of servers companies like Google want. Dell, HP and the like produce expensive servers with high-cost maintenance contracts, which look great to conventional business-executive types. Google, OTOH, probably is taking the techie approach of generic white-box servers with no support. They're installing their own OS image on it, and it's not going to be Windows or a commercial Unix, and with all Google's custom software they probably find vendor support all but useless. Ditto hardware support, the idea is to not worry too much about failures and just replace the box, and with generic hardware replacing failed parts is probably cheaper than the support contract would've been.
You've nailed the rest, though. When you depend on "The Cloud", you're depending on someone else to prioritize solving your problem. The problem is that the most effective solution for them is far from optimal for you, and you don't have enough leverage with them to change their priorities. At least when stuff is in-house the people responsible for it answer to you and you can, if needed, go down and rearrange their to-do list in person.
Won't help much. The problem isn't that we don't have enough food, or that we can't grow enough food. It's that we can't grow enough food in the places that need it, and those places can't afford to import food from the places that have it. Growing more food in the US won't magically make more food available in Tunisia.
Whatever someone intends, the question of what they actually did is still there. If you intend a conversation to be private but conduct it shouting at the top of your lungs in a crowded restaurant, should the courts hold your intent trumped your conduct and force everyone else in that restaurant to plug their ears to avoid overhearing your conversation? Or do they say your conduct trumped your intent, you couldn't possibly have reasonably believed your conversation would be private when carried on that way, and if having all those people overhearing your conversation causes you problems that's your problem not theirs? I think the latter's more likely.
Things aren't private just because you want them to be. You have to also act in a way that keeps them private. If you don't take at least some reasonable steps, then the rest of us are free to assume you don't intend to keep it private.
They can choose to ignore DNT for whatever reasons they choose. However, I did deliberately set DNT in my browser. Any party choosing to ignore that setting will find me remarkably lacking in sympathy for them if they wind up tracking me contrary to that setting.
Orin Kerr is wrong. Intent matters, but only up to the point where it's reasonable. If you decide to discuss a sensitive private matter with your SO by yelling at each other at the top of your lungs in a crowded lobby, you can't possibly reasonably expect that conversation not to be overheard by everyone in the lobby. The same with unsecured WiFi: you're broadcasting your traffic in the clear to anyone who has a receiver and you know this. It's up to you, if you intend a communication to be private, to take at least some reasonable steps to make it private. Choosing a method that's so blatantly exposing the communication to the public is decidedly not such a reasonable step. If you don't like it, sorry but the rest of us didn't agree to plug our ears just because you find it inconvenient to go somewhere private to have a private conversation.
I lived in northern Nevada, and I saw the statistics when they increased the speed limits. Interestingly, while the number of fatalities went up, the number of accidents went down. That seems odd until you look at the most common type of accident: single-car rollover caused by driver inattention. In other words, the driver fell asleep at the wheel and ran off the road. The faster you're going, the more likely that kind of accident is to kill you. OTOH, the faster you drive the less time you spend on the road, the less tired you get and the less chance you have to fall asleep in the first place. So, fewer accidents but when one happens it's more severe.
And, should we care about these accidents? They don't involve other cars, the only person injured or killed was the cause of the accident. I can't get nearly as worked up about someone getting killed because of their own stupidity as about say a family getting killed because someone else T-boned their car. And remember, these high-speed stretches aren't surface streets, or even urban freeways. They're rural freeways. In Nevada we're talking roads where you can go 10-20 miles between bends in the road, and where you may see another car every hour or so. On 300-400 mile trips that extra speed cuts significant time off the trip (for a 300-mile no-need-to-stop stretch 75mph vs. 55mph means 4 hours vs. 5.4, or close to an hour and a half less time at the faster speed limit) which again means you spend less time driving tired.
What you describe isn't a functional system. It's a dysfunctional system based around a sociopathic mindset. You'll pardon me if I decline to favor that.
It's not that we expect things at any particular price. It's an expectation of basic fairness: that the store won't quietly double their normal prices just because I'm wearing a suit when I walk in, in the hopes of getting me to pay more than they'd normally charge.
And I've seen price discrimination backfire. When I lived up in northern Nevada, I remember the story (straight from the cowboy involved) of the scruffy cowboy who'd pulled up to the lot in a rusted-out beater truck and started looking at the expensive trucks. The new salesguy who'd "got stuck with him" tried arguing with him and pushing him towards the used cars. The cowboy was pretty adamant, and finally got mad and left. The salesguy figured no great loss, and he didn't have to deal with the stink of cowpies anymore.
Next day, the owner called all the salesguys in and called the new guy up front to congratulate him. On costing the dealership the sale of 15 brand-new pick-up trucks to a ranch's fleet. Plus loss of the maintenance on that ranch's fleet. Oh, and the loss of all business from one of the local drilling companies. Turns out, that scruffy cowboy? Was the owner of the ranch and drilling company in question. He'd just come in from helping fix a broken truck and bringing in some cows that'd gotten out, and was looking to replace all his trucks before he had more breakdowns. He was driving the beater truck because that was the one available to run out and take care of the problem, and he'd decided if that was the way he was going to be treated then he'd just take all his business somewhere where they had better manners. Oops.
Now imagine the owner of your company listening to a couple of his friends complain that when they went to buy something for their kids from his company, they were seeing prices a lot higher than what they knew other people were paying, and they weren't happy about it. Do you think the owner's going to be happy with you for getting his friends mad at him because of this new pricing scheme? Didn't think so.
It still is considered evil, at least by customers. The people interested in doing this just hope the customers won't figure out what's up. Fat chance of that in this interconnected world. It won't take long for people to compare notes and find out about variations in pricing with no explicable reason for them (no coupon or discount codes used or anything like that). And once people notice, word will spread like wildfire. As will customer dissatisfaction, and people will shift to vendors who simply offer a straight-up price without trying to play games.
The one missing part is the family of the kids. Families do things like take vacations or trips, or large projects around the home that need the kids to help with. Summer vacation isn't just a break from school for the kids, it's a large block of time where the family doesn't have to plan everything they do around the school schedule. It's when the family can take a week or two for a trip. It's when they can take a week or two to haul the furniture out of the house one room at a time to do a thorough cleaning and rearranging of everything.
And frankly, competitive with the rest of the world? I deal with a lot of outsourced IT people daily, and it wouldn't take much to be competitive with them. Not just helpdesk types, software developers and the like too. I don't want the kind of educational system that makes you better at being like them. I want the kind of educational system that led to being able to "make this <holds up a square filter> fit in that <points to a round hole> using nothing but these <dumps out a random assortment of supplies>".
For DNSChanger, you can easily spot an infection by the fact that it's making DNS queries to a known set of DNS servers owned by the malware authors. Spotting that kind of traffic accurately is trivial. For a lot of other malware once the command-and-control network is identified it's easy to spot infections by their attempts to connect to the C&C servers (an uninfected computer wouldn't have any reason to be trying that). So no need for DPI or anything, a simple Perl script parsing the firewall logs will hand you a neat list of subscriber computers grouped by the pieces of malware they're infected with. I have almost the same script running on my firewall, except it's checking inbound traffic and showing me all access attempts grouped by the service they tried to access.
As for how they're going to fix it without access, they won't. For DNSChanger for instance, given the amount of coverage it got and how long the news was out there, anyone who hadn't fixed it by the time the servers were shut down wasn't going to fix it ever. When you've got people that oblivious, the only way to get their attention is to make the net stop working. At that point they suddenly get real attentive. And since they've proven they're either unable or unwilling to fix their own computers (if they weren't, they'd've done something before now), it's probably better if they're forced to take it to someone who can clean it up.
I suspect App.net's going to crash and take all the money with it. Bluntly put, there's just not enough value in it for the end-users. There's a small core willing to pony up, but the value of something like this comes from having large numbers of people signed up and many of the people each potential user knows are on the network or are thinking about getting on. With only that small core, there's not enough people already on to make most people think it's worth setting up Yet Another Online Account and shelling out even a small amount of money per month. If App.net's lucky it'll stay below the threshold where the subscriptions are enough to pay for costs. If it's not, it'll push itself just high enough that it can't cover the bills but not high enough to start getting real economies of scale and it'll have to shut down.
Being subscription, the other path to size isn't open to it. On Twitter it's feasible to buy yourself a large audience, which makes it look attractive to everyone who wants a large audience. That hooks people in. On a subscription service you can't create large numbers of pseudo-users without bankrupting yourself in the process. That makes it harder to create even the appearance of popularity to hook people in. Note that it doesn't have to be the service itself doing this, it just has to happen. And of course being a subscription service it's not going to be attractive to the money that doesn't care about the service so much as access to all the data about the end-users. Ad-supported services it's easy to justify misuse of private data, but a subscription service where there's an explicit agreement with the end users opens up too many liability issues for their comfort.
So yeah, App.net may be a good idea but I think it's going to end up just kind of fading away.
Slashdot Mirror
No, it's you that violated the ToS, so it's you they'll hold accountable. IMO if the TOS forbid allowing a third party access to my account, my response to an employer asking for access would be "I'm sorry, the terms of service forbid me from doing that. And would you really want me if I demonstrate I'm willing to violate agreements I've made? Like for instance the confidentiality, non-disclosure and non-compete agreements you're going to ask me to sign as part of my employment?". I'd think that'd bring any HR rep up short right there. In my profession confidentiality and non-disclosure agreements are no small deals.
It needs to forbid not just asking for passwords from the candidate, but asking for any kind of access in excess of what an ordinary member of the public would have from anyone (the candidate, the social media site, associates of the candidate, etc.). No requiring the candidate to let you watch him viewing his profile. No asking the social media site to grant you behind-the-scenes access to candidate's profiles. No asking friends of the candidate to let you watch them view the candidate's profile. No special access, period. If the candidate is keeping it from public view, as an employer you don't get special privileges to bypass that.
But if the candidate's dumb enough to leave it open to the general public, it's fair game. Ditto if his friends post things about him and identify him in them. Though if you trust things other people say about him and they turn out to be false you don't get to avoid any liability that'd attach to that either, so you may not want to go trusting the unsubstantiated word of random people you find on the Internet.
I watched the video too, and it's far from clear he's joking. I'd hope he was joking, but I was expecting him to go "because there's no oxygen out there" or something. Or to cue it as a joke and give time for a reaction. If it was a joke, he needs to hire better speechwriters or stop trying to ad-lib when he's obviously got no sense of humor and zero sense of comedic timing.
When I hear the cybersecurity people talking about taking offensive action against intruders, I can't help thinking about Miles, "Brothers in Arms" and the infamous stunner tag sequence.
They're pretty direct at generating heat, yes. They don't emit any light, though, until you get them to a sufficiently high temperature. An LED, by comparison, doesn't emit much except for visible-light photons right from the start. That's why an LED bulb is cool to the touch while an incandescent bulb will burn your fingers. And that's why incandescents are inefficient: every bit of that heat you feel off them is power that's being wasted not producing light. The more efficient the process involved is, the less energy it throws off as anything except the light you want produced.
There's not a lot that can be done about efficiency in incandescents. They by definition work by heating a coil of wire until it glows, which means they're going to generate a lot more heat than light by their very nature (the light's a by-product of the heating, not a primary output). Most of the gains in efficiency are being made by shifting to processes that generate light more directly. For what you've got I'd normally go with LED bulbs for the telltales and rough-service lights. LED bulbs will actually be more reliable in rough service since they're solid and don't have a delicate coil of wire suspended between a few thin posts like an incandescent does. Shocks that'll break the coil of an incandescent and cause it to fail won't faze an LED bulb at all.
NB: how lights work:
That won't work for a lot of places. For instance, a system that uses a database where the server and login information changes from environment to environment (development uses the development database server, production will use a completely separate different database and DB server). Often the developers won't know the information for production, and they certainly can't put it in a non-production configuration. That means you'll have a git checkout to get the base code, followed by inserting environment-specific information into the configuration. Or more likely a git checkout of the software followed by applying updates to the existing configuration for new and changed settings if any (often there won't be any configuration changes for a new release). Ideally the configuration update's handled by either a script or a simple patch to update files, but sometimes the easiest and most reliable way is to simply document what needs changed and let an experienced sysadmin pick the best method to do it.
You should have at least 3 environments beyond the personal ones the developers use to develop and unit-test code: development common, QA and production. Development common should be where dev does integration tests, including installation. If developers are responsible for creating the installation tools, they should be doing the installations there so they can debug those tools. If someone else is responsible for writing them, the devs should be working with them to make sure the tools do what the software needs to install correctly. You can't get the installation tools right if you don't test and debug them, and when they interact with the software the developers are the best ones to figure out what's wrong and what's needed to fix it.
Developers should not be doing the installation into the QA environment. They should be handing the installation tools over to QA and letting them run then according to the deployment instructions. That's the only way to confirm the instructions were really complete and that everything works per the documentation, by putting it in the hands of people who didn't write it and letting them deploy it. That way when it comes time to deploy in production you've got some assurance that the deployment will work because it has worked before.
Now, if things do go wrong you need dev involvement. They wrote the software and the tools, they'll often recognize exactly what's going wrong where Ops and QA won't. They're also the ones most likely to be able to give you a quick fix to the problem that'll get production up and running without having to back out and try another day. If you've already invested the time bringing the systems down and deploying the new version, it makes no sense to revert to the old version and waste more downtime tomorrow re-doing the deployment if the only problem is a path in a config file having the version number in it in QA but not in production and a quick edit of the newly-deployed copy of the config file will clearly fix the problem.
I see a bunch of problems, including a few that'll leave the company circling the drain down the road. But one obvious one is that the whole thing depends heavily on what you're selecting for. I know my experience on the hiring side is that HR tends to filter out the best-qualified candidates and leave the ones that aren't qualified. That doesn't bode well for their ability to decide what constitutes a successful employee. It may work OK for tier-1 call-center support, but what happens when eg. you decide you want software developers who fix the most bugs the quickest and deliver the most new features the fastest? You end up with developers who write buggy code that can't be maintained or enhanced. You can't fix a lot of bugs quickly unless the code's got a lot of bugs in it, after all, so the criteria would filter out the developers who avoid creating bugs that'd need fixing. And thinking about what the system will need to do 2, 3 or 4 years down the road and coming up with ways of doing things now that'll accommodate those future needs takes more time than duct-taping together something that just about works right now, so you end up selecting for developers who'll hamstring your ability to enhance your system in the future.
In college math we called it the local-optimization problem: you get so caught up in finding the best way to find the maximum/minimum of a function that you end up missing the maximum/minimum.
#1 writes the code to display the 3x3 grid. This is a standalone program that only outputs graphics, it has no API allowing it's functionality to be called.
#2 discovers this, and works around it by running #1's program and grabbing the graphics from the screen, then modifying them and displaying the modified result. His is also a standalone program with no programming API.
#3 discovers the same thing #2 did, and responds the same way.
By the time you get to #7 you have a mess on your hands that rivals the Deepwater Horizon mess, and maintaining it and keeping it from falling over will cost you twice as much each day/month/year as hiring a single real programmer to do it correctly would have.
Probably they didn't lose the tool itself, just the radioactive source. When I did geotech work, we kept the sources separate and in a lead pig in the back of the truck and only put them on the tool when we were about to do a run. I'll bet the tech got distracted (did things in a different order and missed a step, one of the well crew wanted to know what the results were, could've been many things) and failed to put the lock on the pig before pulling out. Without the lock shank in place the door can come open and the source can rattle it's way out. But even without losing the tool, the boss is going to rip the tech a new one because even though there's no real danger to the public (or at least the non-terminally-braindead members of the public) the boss now has to fill out far too much paperwork on the incident. Plus the tech may well lose his certificate over this, which may cost him his job (no safety cert means he can't use sources, and since it's his fault he lost his cert it's grounds to let him go for cause).
The downside is that viewing those images at all requires the plug-in and the FB app. The only way for it to work reliably is to store the image on McAfee's servers and only serve up the unblurred image if the browser is running the plug-in and isn't interfering with it's operation and they have the FB app allowed on their account. If they do otherwise, then someone can get at the image without the protection present and save it. So it's going to be a fight between friends who're having problems with the plug-in or who blocked the app as malware who you want to see your pictures vs. protecting the pictures.
And of course it won't do anything to protect you from images you uploaded before you started using it, let alone images of you uploaded by other people who aren't using the app (like your friend who snapped a pic of you embarrassing yourself at that party last night and posted it from his cel-phone).
Or we think that our time costs, but it costs less than business downtime does. If you depend on the vendor and their support contract, you're impacted for however long it takes them to come out. They won't typically let you keep spares, so when a part breaks that box is impaired or off-line for whatever your contract response time it and there's nothing you can do about it. But if it's a white-box server that can be worked on in-house, you can typically keep spares on the shelf. It may cost more in admin/tech time than the support contract would, but you get the choice of paying the time and getting the box back on-line in an hour instead of anywhere from 4 hours to next-day. And you get the option of saying "Not worth messing around with. Grab a new box, spin it up and we'll figure out what's broken with this one after we're back on-line.". We techies don't think our time is free, we just don't make the common management mistake of thinking that down-time waiting for a vendor response is free. And usually our time costs a lot less than the down-time would.
It may also depend on what kind of servers companies like Google want. Dell, HP and the like produce expensive servers with high-cost maintenance contracts, which look great to conventional business-executive types. Google, OTOH, probably is taking the techie approach of generic white-box servers with no support. They're installing their own OS image on it, and it's not going to be Windows or a commercial Unix, and with all Google's custom software they probably find vendor support all but useless. Ditto hardware support, the idea is to not worry too much about failures and just replace the box, and with generic hardware replacing failed parts is probably cheaper than the support contract would've been.
You've nailed the rest, though. When you depend on "The Cloud", you're depending on someone else to prioritize solving your problem. The problem is that the most effective solution for them is far from optimal for you, and you don't have enough leverage with them to change their priorities. At least when stuff is in-house the people responsible for it answer to you and you can, if needed, go down and rearrange their to-do list in person.
Won't help much. The problem isn't that we don't have enough food, or that we can't grow enough food. It's that we can't grow enough food in the places that need it, and those places can't afford to import food from the places that have it. Growing more food in the US won't magically make more food available in Tunisia.
Whatever someone intends, the question of what they actually did is still there. If you intend a conversation to be private but conduct it shouting at the top of your lungs in a crowded restaurant, should the courts hold your intent trumped your conduct and force everyone else in that restaurant to plug their ears to avoid overhearing your conversation? Or do they say your conduct trumped your intent, you couldn't possibly have reasonably believed your conversation would be private when carried on that way, and if having all those people overhearing your conversation causes you problems that's your problem not theirs? I think the latter's more likely.
Things aren't private just because you want them to be. You have to also act in a way that keeps them private. If you don't take at least some reasonable steps, then the rest of us are free to assume you don't intend to keep it private.
They can choose to ignore DNT for whatever reasons they choose. However, I did deliberately set DNT in my browser. Any party choosing to ignore that setting will find me remarkably lacking in sympathy for them if they wind up tracking me contrary to that setting.
Orin Kerr is wrong. Intent matters, but only up to the point where it's reasonable. If you decide to discuss a sensitive private matter with your SO by yelling at each other at the top of your lungs in a crowded lobby, you can't possibly reasonably expect that conversation not to be overheard by everyone in the lobby. The same with unsecured WiFi: you're broadcasting your traffic in the clear to anyone who has a receiver and you know this. It's up to you, if you intend a communication to be private, to take at least some reasonable steps to make it private. Choosing a method that's so blatantly exposing the communication to the public is decidedly not such a reasonable step. If you don't like it, sorry but the rest of us didn't agree to plug our ears just because you find it inconvenient to go somewhere private to have a private conversation.
I lived in northern Nevada, and I saw the statistics when they increased the speed limits. Interestingly, while the number of fatalities went up, the number of accidents went down. That seems odd until you look at the most common type of accident: single-car rollover caused by driver inattention. In other words, the driver fell asleep at the wheel and ran off the road. The faster you're going, the more likely that kind of accident is to kill you. OTOH, the faster you drive the less time you spend on the road, the less tired you get and the less chance you have to fall asleep in the first place. So, fewer accidents but when one happens it's more severe.
And, should we care about these accidents? They don't involve other cars, the only person injured or killed was the cause of the accident. I can't get nearly as worked up about someone getting killed because of their own stupidity as about say a family getting killed because someone else T-boned their car. And remember, these high-speed stretches aren't surface streets, or even urban freeways. They're rural freeways. In Nevada we're talking roads where you can go 10-20 miles between bends in the road, and where you may see another car every hour or so. On 300-400 mile trips that extra speed cuts significant time off the trip (for a 300-mile no-need-to-stop stretch 75mph vs. 55mph means 4 hours vs. 5.4, or close to an hour and a half less time at the faster speed limit) which again means you spend less time driving tired.
What you describe isn't a functional system. It's a dysfunctional system based around a sociopathic mindset. You'll pardon me if I decline to favor that.
It's not that we expect things at any particular price. It's an expectation of basic fairness: that the store won't quietly double their normal prices just because I'm wearing a suit when I walk in, in the hopes of getting me to pay more than they'd normally charge.
And I've seen price discrimination backfire. When I lived up in northern Nevada, I remember the story (straight from the cowboy involved) of the scruffy cowboy who'd pulled up to the lot in a rusted-out beater truck and started looking at the expensive trucks. The new salesguy who'd "got stuck with him" tried arguing with him and pushing him towards the used cars. The cowboy was pretty adamant, and finally got mad and left. The salesguy figured no great loss, and he didn't have to deal with the stink of cowpies anymore.
Next day, the owner called all the salesguys in and called the new guy up front to congratulate him. On costing the dealership the sale of 15 brand-new pick-up trucks to a ranch's fleet. Plus loss of the maintenance on that ranch's fleet. Oh, and the loss of all business from one of the local drilling companies. Turns out, that scruffy cowboy? Was the owner of the ranch and drilling company in question. He'd just come in from helping fix a broken truck and bringing in some cows that'd gotten out, and was looking to replace all his trucks before he had more breakdowns. He was driving the beater truck because that was the one available to run out and take care of the problem, and he'd decided if that was the way he was going to be treated then he'd just take all his business somewhere where they had better manners. Oops.
Now imagine the owner of your company listening to a couple of his friends complain that when they went to buy something for their kids from his company, they were seeing prices a lot higher than what they knew other people were paying, and they weren't happy about it. Do you think the owner's going to be happy with you for getting his friends mad at him because of this new pricing scheme? Didn't think so.
It still is considered evil, at least by customers. The people interested in doing this just hope the customers won't figure out what's up. Fat chance of that in this interconnected world. It won't take long for people to compare notes and find out about variations in pricing with no explicable reason for them (no coupon or discount codes used or anything like that). And once people notice, word will spread like wildfire. As will customer dissatisfaction, and people will shift to vendors who simply offer a straight-up price without trying to play games.
The one missing part is the family of the kids. Families do things like take vacations or trips, or large projects around the home that need the kids to help with. Summer vacation isn't just a break from school for the kids, it's a large block of time where the family doesn't have to plan everything they do around the school schedule. It's when the family can take a week or two for a trip. It's when they can take a week or two to haul the furniture out of the house one room at a time to do a thorough cleaning and rearranging of everything.
And frankly, competitive with the rest of the world? I deal with a lot of outsourced IT people daily, and it wouldn't take much to be competitive with them. Not just helpdesk types, software developers and the like too. I don't want the kind of educational system that makes you better at being like them. I want the kind of educational system that led to being able to "make this <holds up a square filter> fit in that <points to a round hole> using nothing but these <dumps out a random assortment of supplies>".
For DNSChanger, you can easily spot an infection by the fact that it's making DNS queries to a known set of DNS servers owned by the malware authors. Spotting that kind of traffic accurately is trivial. For a lot of other malware once the command-and-control network is identified it's easy to spot infections by their attempts to connect to the C&C servers (an uninfected computer wouldn't have any reason to be trying that). So no need for DPI or anything, a simple Perl script parsing the firewall logs will hand you a neat list of subscriber computers grouped by the pieces of malware they're infected with. I have almost the same script running on my firewall, except it's checking inbound traffic and showing me all access attempts grouped by the service they tried to access.
As for how they're going to fix it without access, they won't. For DNSChanger for instance, given the amount of coverage it got and how long the news was out there, anyone who hadn't fixed it by the time the servers were shut down wasn't going to fix it ever. When you've got people that oblivious, the only way to get their attention is to make the net stop working. At that point they suddenly get real attentive. And since they've proven they're either unable or unwilling to fix their own computers (if they weren't, they'd've done something before now), it's probably better if they're forced to take it to someone who can clean it up.
I suspect App.net's going to crash and take all the money with it. Bluntly put, there's just not enough value in it for the end-users. There's a small core willing to pony up, but the value of something like this comes from having large numbers of people signed up and many of the people each potential user knows are on the network or are thinking about getting on. With only that small core, there's not enough people already on to make most people think it's worth setting up Yet Another Online Account and shelling out even a small amount of money per month. If App.net's lucky it'll stay below the threshold where the subscriptions are enough to pay for costs. If it's not, it'll push itself just high enough that it can't cover the bills but not high enough to start getting real economies of scale and it'll have to shut down.
Being subscription, the other path to size isn't open to it. On Twitter it's feasible to buy yourself a large audience, which makes it look attractive to everyone who wants a large audience. That hooks people in. On a subscription service you can't create large numbers of pseudo-users without bankrupting yourself in the process. That makes it harder to create even the appearance of popularity to hook people in. Note that it doesn't have to be the service itself doing this, it just has to happen. And of course being a subscription service it's not going to be attractive to the money that doesn't care about the service so much as access to all the data about the end-users. Ad-supported services it's easy to justify misuse of private data, but a subscription service where there's an explicit agreement with the end users opens up too many liability issues for their comfort.
So yeah, App.net may be a good idea but I think it's going to end up just kind of fading away.