It's not hard, just involved and convoluted. Facebook's settings are many, and some of them aren't in the obvious places. These tools make it easy to do what's time-consuming to do by hand.
California isn't pushing any agenda on Texas. It's merely saying "No, we don't want it that way, and we will not buy any textbooks that try to have it that way.". In short, California is doing exactly what you want: voting on how they want it. Of course that may put Texas in a hard spot if the private companies that publish textbooks decide that they can better afford to lose the Texas market than the California one and write their books around California's requirements, but that's the way the cookie crumbles when you depend on private companies rather than having Big Government publishing it's own textbooks.:)
I think it'll take more than an alternative popping up. There's plenty of alternatives to LiveJournal, for instance, but that hasn't significantly hurt LJ's position. I think what it'll take is a number of closely-spaced nasty events where regular people got seriously hurt (fired from work, say) over things they thought they'd secured on Facebook but that were actually exposed through Facebook's new networks. When that happens you'll see a critical mass abandon Facebook, but I doubt before that.
Not really. Users are product, but unlike most industries this "product" has legs and can walk off on it's own. The more product Facebook has, the more valuable it is to it's customers. The less product, the less valuable. Now, the major reason people use Facebook is that the other people they know also use Facebook. The larger a percentage of the people they know that use something other than Facebook, the less incentive there is for them to use Facebook too. This is one thing Google gets: no matter how profitable something may seem in the short term, if it scares off or runs off your product it's not a good idea in the long term.
And it isn't just this one thing. Facebook's gotten some press lately over employers looking over people's profiles. The new forced networks based on things like employer don't help people with jobs feel comfortable, which makes them more likely to drop off Facebook. Which makes everyone they know just a little more likely to drop off too.
The whole thing isn't linear. Reach a critical mass and your product base grows exponentially. Drop below that critical mass, and your product base implodes exponentially too. I think Facebook's starting to worry that if they don't do something they may drop below critical mass.
Note what the guy said: he wrote the original code before they hired him. At least under California law the situation is clear: his employer does not own the code (the fact that he signed an agreement saying otherwise is irrelevant, see 2870(b)). His employer does own any code written after they hired him, but they only get a license to the preexisting code.
If he's not in California the situation's less clear, his state may or may not address the issue explicitly. At that point you want a qualified attorney before you proceed.
Full disclosure of vulnerabilities typically isn't done by the vendor, it's done by the party finding the vulnerability. If the vendor's the first one to find the problem they can, of course, always not say anything about it, but then they've got to fix it before anybody else finds it.
No surprise here. Sysadmins need to know exactly what bugs are being fixed in each patch so they can decide on appropriate priorities for deployment. However, vendors need to not disclose exactly what bugs are being fixed in each patch to minimize the damage to their reputations that comes from large numbers of major bugs or having to fix the same bug over and over and over. And since the vendors get to control the patch descriptions, guess who gets their way.
This is one reason I favor full disclosure of security bugs. Vendors can only hide the fact that they're fixing a bug if the world at large doesn't know the bug exists. If the bug's publicly disclosed, the vendor now takes the PR/image hit if they don't say when they've fixed it. This then encourages not only quicker fixes to high-risk vulnerabilities but full and complete disclosure of what's being fixed (so users don't keep asking "Why haven't you fixed this yet?").
Because what's in the patch determines the priority for testing/QA. If the patch apparently only addresses low-risk vulnerabilities or ones we've got other mitigation in place for, we may decide to give that patch a low priority and not test and deploy it quickly. If the patch's description doesn't disclose that the patch also addresses a severe high-risk vulnerability that we have no mitigation in place for, then we've given the deployment the wrong priority and don't know that we have. The end result won't be pretty.
These guys are probably trying to do sub-millisecond trading. They need to keep their clocks sync'd to the microsecond to keep different machines coordinated.
Me, I wonder why they're bothering. Run GPS-based stratum-1 servers at each site, and sync directly to them across the LAN. Or get a cesium-beam primary time source. End of problem. Or take heed of the current financial meltdown and acknowledge that if you try to create money out of thin air, sooner or later you're going to pay the piper and it's going to hurt so maybe it'd be better to not go there.
Yep. I make a policy of insuring, where I have root passwords or the equivalent and sole responsibility for a system, that there's a sealed envelope in the company vault with those passwords recorded (and I keep that envelope updated when passwords change). There's also an agreement in place saying that the moment anybody but me opens that envelope, they become solely responsible for the system from that point on until I get sole control back.
And I'd have multiple backups of the configuration for everything. Probably one set of CDs in my desk, one set in the NOC (appropriately sealed if needed), and a last-ditch print-out in a sealed envelope in the vault. I just went through a "hit by the bus" scenario (pneumonia that in 24 hours went from "a bit short of breath" to "in the critical-care unit on a ventilator, not sure he'll still be alive in 12 hours"), so the whole continuity-of-control thing isn't just an academic excercise for me.
IIRC the reason the city had to shut down their VPN and reissue passwords was that the city had dumped the entire list of usernames and passwords into the public-available court record as part of one of their filings. Childs had nothing to do with that, and had the city not revealed all those passwords to the world they'd've had no need to disrupt their VPN at all.
They aren't. If you read up on the complaints that trigger these laws, you'll find a common start to all of them: a parent or other adult related to the kid bought the game, took it home and gave it to the kid, usually without checking the game out themselves first. The screams of outrage came later.
IMO the law the states should pass isn't one banning the sale of those games to minors (which isn't happening), it's one mandating 1-year prison sentences for any adult who gives such a game to a minor (which is what's happening). But I doubt that'll ever happen.
Only if you're using it to send credit-card numbers, bank account numbers or other PII as defined by the law. And if you are, you should be encrypting that e-mail anyway.
If you're thinking about the coding stage, you've already guaranteed a sub-optimal setup. The absolute worst errors, the ones that'll cost you the most to correct (if you can correct them at all), are the planning errors. Good software starts with a good architecture and overall design, and that requires clear thinking about what exactly you're trying to do. Most often it requires privacy: one person working out a really good design, or two or three people hashing out ideas where their bozo moments and utterly brain-dead thoughts won't be a public embarrassment. Set your environment up for that, and the coding will take care of itself.
Generally I prefer offices off a common area. Put a big table, whiteboards and such in the common area so people can congregate when you really need everyone together (eg. meetings or troubleshooting sessions). Make the offices reasonably soundproof (so if eg. someone works better with music playing they can do that without bothering anyone else) and with doors that can be but don't have to be closed (so the developer can decide which it'll be now).
Of course it's a hit piece. Look who asked for the investigation. And look who're upset about the SEC having the temerity to file charges against Goldman Sachs for their part in the meltdown.
Not even hard. And there shouldn't be any decimals in there. The correct formula is (206*2)/3, yielding 137 and 1/3rd. So 137 votes fails (137 < 137&1/3rd), 138 passes (137&1/3rd < 138). Not all math is done in decimal notation, and they taught me how to do math with fractions way back in elementary school.
For outbound connections, what's so complicated? My Linux gateway box, not to mention every NATting router I've seen, does it automatically.
For inbound connections, again what's so complicated? I set up a firewall specifically so the outside world could not make inbound connections to my machines without my intervention to allow it. If I wanted it to be otherwise, I wouldn't've installed the firewall. You aren't asking for innovation, you're asking for the ability to completely circumvent my security. And news flash: if your game can do this, then any piece of malware out there can do it too. That's exactly why I want this to require my manual intervention.
There's always UPnP, of course. Most modern home routers with firewall capability support it. But again, many sensible users turn it off to prevent malware from opening up holes in the firewall and exposing their machines to the outside world.
If you read the article, the person who found the vulnerability doesn't work for the vendor of the software. He works for a company that bought and uses the software. He's got no special advantages.
And yes, many sensitive systems should be closed. The computers at the doctor's office, for instance, should be on a closed local network with only a single closely-controlled interface to transmit data to other doctors, hospitals etc. and receive transmissions from them. I'd put it on a bastion host in a DMZ, or at least on a dual-interface machine with a thoroughly locked-down firewall on both interfaces. Once you're in that environment, the security of the internal machines becomes much less critical.
First thing, though: the probability it's known is 100%. After all, you know about it, right? What makes you think you're so unique, so special, so much more brilliant than any other person in the world that you're the only one who's noticed it and figured it out? Nothing. In fact, given the number of people in the world it's a virtual certainty that someone smarter than you found this vulnerability before you. So the probability it's known is 1.00, the only question left is the cost to secure yourself against exploits. Not fix the vulnerability, that's only one option. You don't really care how you do it, just that you've rendered yourself safe from being exploited. That can mean putting up a firewall to prevent access to the vulnerability, or even something as simple as switching to another product that isn't (currently) vulnerable. Then you decide based on the cost to secure yourself vs. the cost to you of being exploited which options are viable (no sense spending a million dollars to fix a vulnerability that if exploited will only cost you a few thousand dollars).
As far as what I do when going on vacation, in fact I do do a few things. I make sure the doors are locked. I make sure the block-bars are down and slide-latches are in place on sliding doors and windows. I set lights on timers so it won't be so obvious there's nobody home. If I'm going to be out of town for long stretches frequently then yes it might be worth it to get bars on the windows and get an alarm system put in.
Possibly, but remember what Google also said: the speed has only a very low weight compared to relevance. So if sites A and B have almost equal relevance then speed might determine the results but if A gets 98% for relevance and B gets 90% then the fact that B is twice as fast as A will be pretty much ignored when ranking them.
If the exploit is secret, maybe they do know, maybe they don't.
If the exploit is publicly disclosed, they almost certainly do.
If the exploit is secret and maybe the bad guys know about it and maybe they don't, the only safe course is to assume they do know about it and act accordingly. It's like a door: maybe a burglar will come around trying it and maybe he won't, but you still don't go on vacation leaving the front door to your house unlocked because it's not worth the risk if he does come around.
Yes, they are. But that doesn't prevent a previous employer from threatening or actually bringing a suit to enforce them. It just means that, after spending a year or two and 20-30 thousand dollars of your own money, you'll have a piece of paper from the court ruling in your favor. And that is the problem employers have with recruiting people who might be subject to a non-compete and worked for a company that might try to enforce it.
More likely it's a consequence of the non-competes most large companies require employees to sign as a condition of employment, and the risk of getting entangled in litigation if a company hires someone who was subject to such a non-compete. Even if the company can't be liable, it costs money to deal with the matter and extract the company from the litigation. And the employees themselves are probably also touchy about the matter, they can't get themselves out of the mess if a previous employer decides to sue them for violating a non-compete. All they can do is fight it out and hope they win, and even if they win they probably can't recover the cost of winning.
If the DoJ thinks the situation is a problem, they need to address non-competes.
Slashdot Mirror
It's not hard, just involved and convoluted. Facebook's settings are many, and some of them aren't in the obvious places. These tools make it easy to do what's time-consuming to do by hand.
California isn't pushing any agenda on Texas. It's merely saying "No, we don't want it that way, and we will not buy any textbooks that try to have it that way.". In short, California is doing exactly what you want: voting on how they want it. Of course that may put Texas in a hard spot if the private companies that publish textbooks decide that they can better afford to lose the Texas market than the California one and write their books around California's requirements, but that's the way the cookie crumbles when you depend on private companies rather than having Big Government publishing it's own textbooks. :)
I think it'll take more than an alternative popping up. There's plenty of alternatives to LiveJournal, for instance, but that hasn't significantly hurt LJ's position. I think what it'll take is a number of closely-spaced nasty events where regular people got seriously hurt (fired from work, say) over things they thought they'd secured on Facebook but that were actually exposed through Facebook's new networks. When that happens you'll see a critical mass abandon Facebook, but I doubt before that.
Not really. Users are product, but unlike most industries this "product" has legs and can walk off on it's own. The more product Facebook has, the more valuable it is to it's customers. The less product, the less valuable. Now, the major reason people use Facebook is that the other people they know also use Facebook. The larger a percentage of the people they know that use something other than Facebook, the less incentive there is for them to use Facebook too. This is one thing Google gets: no matter how profitable something may seem in the short term, if it scares off or runs off your product it's not a good idea in the long term.
And it isn't just this one thing. Facebook's gotten some press lately over employers looking over people's profiles. The new forced networks based on things like employer don't help people with jobs feel comfortable, which makes them more likely to drop off Facebook. Which makes everyone they know just a little more likely to drop off too.
The whole thing isn't linear. Reach a critical mass and your product base grows exponentially. Drop below that critical mass, and your product base implodes exponentially too. I think Facebook's starting to worry that if they don't do something they may drop below critical mass.
Note what the guy said: he wrote the original code before they hired him. At least under California law the situation is clear: his employer does not own the code (the fact that he signed an agreement saying otherwise is irrelevant, see 2870(b)). His employer does own any code written after they hired him, but they only get a license to the preexisting code.
If he's not in California the situation's less clear, his state may or may not address the issue explicitly. At that point you want a qualified attorney before you proceed.
Full disclosure of vulnerabilities typically isn't done by the vendor, it's done by the party finding the vulnerability. If the vendor's the first one to find the problem they can, of course, always not say anything about it, but then they've got to fix it before anybody else finds it.
No surprise here. Sysadmins need to know exactly what bugs are being fixed in each patch so they can decide on appropriate priorities for deployment. However, vendors need to not disclose exactly what bugs are being fixed in each patch to minimize the damage to their reputations that comes from large numbers of major bugs or having to fix the same bug over and over and over. And since the vendors get to control the patch descriptions, guess who gets their way.
This is one reason I favor full disclosure of security bugs. Vendors can only hide the fact that they're fixing a bug if the world at large doesn't know the bug exists. If the bug's publicly disclosed, the vendor now takes the PR/image hit if they don't say when they've fixed it. This then encourages not only quicker fixes to high-risk vulnerabilities but full and complete disclosure of what's being fixed (so users don't keep asking "Why haven't you fixed this yet?").
Because what's in the patch determines the priority for testing/QA. If the patch apparently only addresses low-risk vulnerabilities or ones we've got other mitigation in place for, we may decide to give that patch a low priority and not test and deploy it quickly. If the patch's description doesn't disclose that the patch also addresses a severe high-risk vulnerability that we have no mitigation in place for, then we've given the deployment the wrong priority and don't know that we have. The end result won't be pretty.
Yes, because this will work just as well as RFC 3514 - The Security Flag in the IPv4 Header.
These guys are probably trying to do sub-millisecond trading. They need to keep their clocks sync'd to the microsecond to keep different machines coordinated.
Me, I wonder why they're bothering. Run GPS-based stratum-1 servers at each site, and sync directly to them across the LAN. Or get a cesium-beam primary time source. End of problem. Or take heed of the current financial meltdown and acknowledge that if you try to create money out of thin air, sooner or later you're going to pay the piper and it's going to hurt so maybe it'd be better to not go there.
Yep. I make a policy of insuring, where I have root passwords or the equivalent and sole responsibility for a system, that there's a sealed envelope in the company vault with those passwords recorded (and I keep that envelope updated when passwords change). There's also an agreement in place saying that the moment anybody but me opens that envelope, they become solely responsible for the system from that point on until I get sole control back.
And I'd have multiple backups of the configuration for everything. Probably one set of CDs in my desk, one set in the NOC (appropriately sealed if needed), and a last-ditch print-out in a sealed envelope in the vault. I just went through a "hit by the bus" scenario (pneumonia that in 24 hours went from "a bit short of breath" to "in the critical-care unit on a ventilator, not sure he'll still be alive in 12 hours"), so the whole continuity-of-control thing isn't just an academic excercise for me.
IIRC the reason the city had to shut down their VPN and reissue passwords was that the city had dumped the entire list of usernames and passwords into the public-available court record as part of one of their filings. Childs had nothing to do with that, and had the city not revealed all those passwords to the world they'd've had no need to disrupt their VPN at all.
They aren't. If you read up on the complaints that trigger these laws, you'll find a common start to all of them: a parent or other adult related to the kid bought the game, took it home and gave it to the kid, usually without checking the game out themselves first. The screams of outrage came later.
IMO the law the states should pass isn't one banning the sale of those games to minors (which isn't happening), it's one mandating 1-year prison sentences for any adult who gives such a game to a minor (which is what's happening). But I doubt that'll ever happen.
Only if you're using it to send credit-card numbers, bank account numbers or other PII as defined by the law. And if you are, you should be encrypting that e-mail anyway.
If you're thinking about the coding stage, you've already guaranteed a sub-optimal setup. The absolute worst errors, the ones that'll cost you the most to correct (if you can correct them at all), are the planning errors. Good software starts with a good architecture and overall design, and that requires clear thinking about what exactly you're trying to do. Most often it requires privacy: one person working out a really good design, or two or three people hashing out ideas where their bozo moments and utterly brain-dead thoughts won't be a public embarrassment. Set your environment up for that, and the coding will take care of itself.
Generally I prefer offices off a common area. Put a big table, whiteboards and such in the common area so people can congregate when you really need everyone together (eg. meetings or troubleshooting sessions). Make the offices reasonably soundproof (so if eg. someone works better with music playing they can do that without bothering anyone else) and with doors that can be but don't have to be closed (so the developer can decide which it'll be now).
Of course it's a hit piece. Look who asked for the investigation. And look who're upset about the SEC having the temerity to file charges against Goldman Sachs for their part in the meltdown.
Not even hard. And there shouldn't be any decimals in there. The correct formula is (206*2)/3, yielding 137 and 1/3rd. So 137 votes fails (137 < 137&1/3rd), 138 passes (137&1/3rd < 138). Not all math is done in decimal notation, and they taught me how to do math with fractions way back in elementary school.
For outbound connections, what's so complicated? My Linux gateway box, not to mention every NATting router I've seen, does it automatically.
For inbound connections, again what's so complicated? I set up a firewall specifically so the outside world could not make inbound connections to my machines without my intervention to allow it. If I wanted it to be otherwise, I wouldn't've installed the firewall. You aren't asking for innovation, you're asking for the ability to completely circumvent my security. And news flash: if your game can do this, then any piece of malware out there can do it too. That's exactly why I want this to require my manual intervention.
There's always UPnP, of course. Most modern home routers with firewall capability support it. But again, many sensible users turn it off to prevent malware from opening up holes in the firewall and exposing their machines to the outside world.
If you read the article, the person who found the vulnerability doesn't work for the vendor of the software. He works for a company that bought and uses the software. He's got no special advantages.
And yes, many sensitive systems should be closed. The computers at the doctor's office, for instance, should be on a closed local network with only a single closely-controlled interface to transmit data to other doctors, hospitals etc. and receive transmissions from them. I'd put it on a bastion host in a DMZ, or at least on a dual-interface machine with a thoroughly locked-down firewall on both interfaces. Once you're in that environment, the security of the internal machines becomes much less critical.
First thing, though: the probability it's known is 100%. After all, you know about it, right? What makes you think you're so unique, so special, so much more brilliant than any other person in the world that you're the only one who's noticed it and figured it out? Nothing. In fact, given the number of people in the world it's a virtual certainty that someone smarter than you found this vulnerability before you. So the probability it's known is 1.00, the only question left is the cost to secure yourself against exploits. Not fix the vulnerability, that's only one option. You don't really care how you do it, just that you've rendered yourself safe from being exploited. That can mean putting up a firewall to prevent access to the vulnerability, or even something as simple as switching to another product that isn't (currently) vulnerable. Then you decide based on the cost to secure yourself vs. the cost to you of being exploited which options are viable (no sense spending a million dollars to fix a vulnerability that if exploited will only cost you a few thousand dollars).
As far as what I do when going on vacation, in fact I do do a few things. I make sure the doors are locked. I make sure the block-bars are down and slide-latches are in place on sliding doors and windows. I set lights on timers so it won't be so obvious there's nobody home. If I'm going to be out of town for long stretches frequently then yes it might be worth it to get bars on the windows and get an alarm system put in.
Possibly, but remember what Google also said: the speed has only a very low weight compared to relevance. So if sites A and B have almost equal relevance then speed might determine the results but if A gets 98% for relevance and B gets 90% then the fact that B is twice as fast as A will be pretty much ignored when ranking them.
If the exploit is secret, maybe they do know, maybe they don't.
If the exploit is publicly disclosed, they almost certainly do.
If the exploit is secret and maybe the bad guys know about it and maybe they don't, the only safe course is to assume they do know about it and act accordingly. It's like a door: maybe a burglar will come around trying it and maybe he won't, but you still don't go on vacation leaving the front door to your house unlocked because it's not worth the risk if he does come around.
Yes, they are. But that doesn't prevent a previous employer from threatening or actually bringing a suit to enforce them. It just means that, after spending a year or two and 20-30 thousand dollars of your own money, you'll have a piece of paper from the court ruling in your favor. And that is the problem employers have with recruiting people who might be subject to a non-compete and worked for a company that might try to enforce it.
More likely it's a consequence of the non-competes most large companies require employees to sign as a condition of employment, and the risk of getting entangled in litigation if a company hires someone who was subject to such a non-compete. Even if the company can't be liable, it costs money to deal with the matter and extract the company from the litigation. And the employees themselves are probably also touchy about the matter, they can't get themselves out of the mess if a previous employer decides to sue them for violating a non-compete. All they can do is fight it out and hope they win, and even if they win they probably can't recover the cost of winning.
If the DoJ thinks the situation is a problem, they need to address non-competes.
Microsoft paid CCIA official as part of the antitrust settlement.