So, let me get this straight. He didn't surreptitiously gain access to any area any random member of the public wouldn't have access to. He didn't plant any recording device to record in his absence. He stood outside a door and with a cel phone recorded what any passerby would have heard had they stopped to listen. Is that correct?
That doesn't even sound particularly unethical to me. A bit sleazy, but then if McConnell's careless enough to have that kind of discussion where anyone in the hallway can overhear the problem doesn't lie with the people in the hallway listening.
The camera is continuously active and the video stream uploaded and stored for a minimum of 90 days.
The complete, unedited recording shall be made available to the defense no less than 14 days before trial is scheduled and in any event no more than 14 days after charges are filed. Failure to supply the video shall be grounds for immediate dismissal of all charges against all defendants.
Absence of any video recording of relevant events for any non-trivial part of the time period in question is automatic grounds for the dismissal of all charges against all defendants in the case in question. It's also grounds for felony destruction of evidence charges against the officers whose cameras failed to record events and the officers responsible for monitoring and preserving the recordings. The burden shall be on the police to show that the failure was due to failure of the camera hardware or the network link.
First problem is that sure, not every black hat will have the details, but any black hat may. In this age of automated toolsets for attackers, once one black hat figures it out and includes it in a toolset it's only one update away from being in the arsenal of any attacker using that toolset. In that environment you can't wait for them to prove they have the information, by the time that happens you're compromised and cleaning up and suffering all the financial, legal and PR liabilities that come with being breached. You have to assume that if a vulnerability exists then the guy attacking you has the tools to exploit it, and if it turns out after the fact that he didn't then you're still secure.
As far as not everyone being a competent admin and organizations having policies that prevent doing the right thing, tough. This was all well-understood 30 years ago when I was starting out, and I find as I grow older that I've less and less patience for people who expect me to leave myself vulnerable just because some people lack common sense.
As far as disclosing only to vendor's customers, down that path leads "We'll inform you of vulnerabilities, but only if you subscribe to our Ultra Platinum Plus support package for only $YOURFIRSTBORN per year. Oh, and the terms are that you can't say anything that might show us or our products in a bad light.". As far as I'm concerned, once the vulnerability's in the wild and actively being exploited the vendor's a side-show. Whatever they do is nice and all, but priority #1 is making sure that the people who'll be targets of the black hats know what they need to know to protect themselves. If the vendor wants to exercise any control, they need to start being proactive and finding the vulnerabilities before they get into the wild. 'cause frankly most of the vulnerabilities I'm seeing these days are from basic stuff that should have been dealt with before the code ever went to QA. Things like "All externally-supplied data is presumed hostile until proven otherwise." or "If a service is physically accessible, someone will attempt to access it. See preceding about externally-supplied data.".
The bit that you're ignoring is that by telling you about the vulnerability they're also telling all the black hats about it.
Except that the black hats already know about it, and are actively using it to compromise systems. Telling me about it doesn't give the black hats any information they didn't already have. The only way keeping the information confidential helps me is if it's something the black hats can't possibly figure out without being told, and the track record says there's no such thing. I have yet to see a vulnerability that wasn't known and at least a proof-of-concept exploit in circulation for before the vendor disclosed it, I've seen plenty where the vendor only disclosed after major compromises attributable to that vulnerability became public knowledge.
As far as not everyone being able to protect a system goes, if you're unable to do basic system administration then you shouldn't be administering a system. You hire people who are qualified to do it for you. Don't expect me to agree to leave my systems vulnerable without my knowing about it just to appease that handful of dolts who're too stupid or too cheap to hire competent help for the job. In this day and age there's no excuse for not knowing you need competent admins running your systems.
As a user, I don't care about the vendor's ability to fix it quickly. Really I don't. That's their problem. My problem is that my systems are vulnerable to compromise and I have to do something about it. I need to know what the vulnerability is, in enough detail to understand it myself, and I need to know the possible workarounds (not just the vendor's recommended one(s), which is another reason I need to know what the vulnerability actually is so I can understand all the other possible ways of dealing with it). I need to evaluate my options and take whatever steps I need to to protect my systems. If the vendor needs a month to get the fix through their change-control process, I still need to protect my systems today.
The vendor's advice will be based on their most-likely scenario. Problem is that my situation may be radically different from the vendor's most-likely one. There's definitely going to be local considerations even if my situation's one the vendor's workaround covers. I need to understand the vulnerability to be able to evaluate it intelligently. It may not even be relevant to my setup. If it is, I may have less-intrusive workarounds (eg. for the SSH OTP authentication bug, if we've got a purely internal network that isn't accessible to the outside world or the Windows desktop portion of the network it may be less intrusive to just monitor for attempted exploits and defer doing anything until I see someone having gotten past the air gap rather than changing an authentication method that a lot of people depend on and that can't be exploited easily without being physically in the building). And if I need to take drastic steps like disabling the vulnerable SSH authentication method, I may have clients who insist they must be able to use it (maybe because their systems are based on it and they need my systems to integrate with their authentication because I'm providing services to them) and I need to be able to intelligently discuss exactly what's wrong and why it's simply not possible to use that method without being vulnerable and we've got to change to a different method despite the disruption. I can't do that unless I understand the vulnerability.
Notice that in all the above I haven't mentioned the vendor at all. Like I said, the vendor isn't relevant at all. It's my systems that're vulnerable and me that has to do something about it. If the vendor already has a fix then well and good, but if they don't it doesn't change my situation. When vendors say they need more time, they're asking me to leave my systems vulnerable without telling me they're vulnerable. Sorry, but no. Not, that is, unless they're willing to shoulder 100% of all the costs resulting from that vulnerability being exploited. Not just direct costs, things like the costs of lost business and clean-up if the vulnerability is exploited and liabilities I may incur because of the compromise. If a vendor isn't willing to take on that liability, then they don't get to tell me I shouldn't have the information I need to protect myself from that liability. If they don't like it... this is the sound of the world's smallest violin, playing the world's saddest song just for them.
One of the most important things when it comes to avoiding a group creating a mess is to have collective agreement on the architecture and design and the divisions and interfaces between components. Everybody doesn't have to agree that this way's the best way, but they have to agree that it's acceptable and they'll write to it. This goes both ways: you have to acknowledge that you'll follow the design even when you don't agree with it, and you also have to acknowledge that the other guy (who isn't getting his way) has valid points even though you're doing it your way instead of his.
NB: the above is why my mantra is "I am not a rock star. I am a professional.". I'll argue vehemently for what I think is the best way to do things, but in the end I need to write code that fits well with the rest of the system even if that code isn't technically "the best way".
The response isn't necessarily to fix the bug. The response is to mitigate the risk due to the vulnerability. One way is to fix the bug that's behind it. Another is to change configurations or add additional layers to remove exposure due to the bug. For instance there was once a vulnerability in SSH caused by one particular authentication method. Since that method was rarely used and there were alternative ways of doing the same kind of authentication, the most popular immediate solution was to just disable that authentication method. 5 minutes to change a config file and restart sshd and you're done. I'm not sure they ever did fix the bug, and if they did it took at least weeks, but that didn't stop people from protecting themselves within a matter of hours after the problem was made public.
They're already at significant risk due to the vulnerability. The only difference is that now they have to acknowledge and mitigate that risk instead of pretending it isn't there.
Discovery: there's legal issues there, yes, but there's also the fact that it's not your property that the data's on anymore. With physical documents a discovery order for the company doesn't give the company the right to come in and search my home for documents that might relate. Why should it be any different for electronic documents? The pattern should be that of any other case: the company responds that some of those documents are not under their control and supplies the contact information of the people who do control the documents.
Break/fix plan: not the company's problem. It's my device, fixing it is my job. And frankly I build stuff so my break/fix plan is "Buy a replacement.". I try to design things so I can hit Fry's and get replacement parts if it's really an emergency, mostly that means I'm down for an hour or three depending on which one I have to go to.
Exising desks etc.: again not the company's problem. I shouldn't need a docking station just to plug in a power cord and Ethernet cable, and the monitors should be using standard VGA/DVI/HDMI connectors.
Corporate software: this should've been dealt with before you started a BYOD program. If you require software that's got complex licensing requirements, figure out how you're going to let users use it first.
Failed app installs: this mostly shouldn't be a problem unless your apps have some really hairy dependencies. Despite this being a common scare tactic, I've rarely run into situations where an app wouldn't install because of some complex interaction with a personal setup. Most often it's because of stupidity like "We designed it to only work with one specific patch level of Java 1.5, and the user's got current Java 7 installed.". Often it ends up being the corporate developers who created that problem. For example that Java app before would run just fine in current Java 7, the only problem was that the corporate developers deliberately set the configuration to refuse to run except with that one specific patchlevel of one specific version of Java. Take that restriction out and presto, app works perfectly.
Smart Card mandate: again this is something the company ought to be working out beforehand. Remember that when you want to use someone else's equipment you can't always mandate what it has to be capable of or how it must operate. You either deal with this up front, or you acknowledge that the company needs to own the equipment which means it's not going to be BYOD.
The big problem seems to be that companies want to have employees paying for and owning the equipment, but want to treat that equipment as if the company owned it. The company needs to change it's attitude if it wants to use BYOD, design things to not require the company to own and control the equipment. It's not like it's a big deal, it's not like Oracle or Adobe or Intuit or Blizzard or any other software publisher hasn't had to figure out how to make their software live and work on machines they have no control over. If they can do it, I'm positive the problem isn't insoluble.
How does commercial software give you anyone to pin liability on? All of it that I've seen either disclaims liability entirely or limits liability to refunding your money (even from major vendors like Oracle it reads like "if it breaks, you get to keep both pieces"). You definitely won't be able to hold the vendor liable for the cost of lost business due to the failure of their software. Sure it gives you someone to blame, but you're still left holding the bag when it comes to the actual money the failure cost you. At least with open-source software, if the failure's bad enough the business can put it's own resources to work fixing it. Contrast that with commercial software where the business has no choice but to sit and wait for the vendor to decide the problem's important enough for the vendor to fix it.
When I grew up we had a saying. "Sticks and Stones may break my bones, but names can never hurt me."
If you believe that, try having a child falsely accuse you of molesting them. It may be only words and completely untrue, but I assure you the consequences will not be anything you can just ignore and they will harm you in very direct and unignorable ways.
If the statements were defamatory, then the organization has suffered harm. That's what defamation means, someone's said something false about you that's harmed your reputation. That also covers #1, true statements aren't normally defamatory. Hence why the posters should be allowed to participate in the first step with their anonymity protected, because one defense they could raise is that the statements were true and if so then PETA wouldn't be able to prevail on the "the statements were defamatory" part.
As for #2, that's another matter. If the statements were true but confidential then it wouldn't be defamation, it'd be breach of a non-disclosure agreement. For that, PETA should again have to show why they believe such an agreement was violated first. And again, the posters should be allowed to participate without their identity being revealed since "We weren't subject to any such non-disclosure agreement and we weren't obliged to respect the confidentiality of the information." would be a valid defense and if carried would mean PETA's claims would fail before they got to the point where they could ask for identities to be revealed. NB: yes, sometimes third parties are required to respect and help protect confidentiality even though they haven't explicitly agreed to do so. It's based on the principle that while you aren't bound by agreements you didn't yourself agree to, you aren't legally supposed to knowingly assist someone else in breaching contracts they've agreed to. The "knowingly" part is the dividing line.
PETA should be allowed to discover the identities of the posters for the purposes of suing them, if the statements are in fact defamatory. But the first bar PETA should have to clear is to demonstrate to the court that the statements are in fact defamatory. And they should be required to identify the allegedly-defamatory posts publicly, so the posters can retain counsel and contest the allegations without having their identity revealed. Only after they've prevailed on the "the statements are defamatory" part should they be allowed discovery as to the identities of the posters. And if they fail to follow through and file suit, sanctions should be imposed for abuse of process.
Being anonymous should not mean you can't be held accountable for what you say, but the first step should be showing that someone could be held legally accountable for saying what was said. If what was said isn't actionable, then it shouldn't matter who said it.
This is easy to implement in software, but you will not in general find software in the forwarding path at an ISP; you will find hardware.
Two words: Cisco iOS. Not Linux, but far more capable and can make use of the massive built-in hardware assist. I don't think there's a modern router that's pure hardware-based, all of them are software-based with some degree or another of hardware assist (except maybe home routers which're mostly just generic ARM boxes running Linux with no hardware assist beyond what's in the NICs themselves).
True, but as was pointed out in the ronpaul.com dispute, having a trademark doesn't mean nobody else has any right to use that name. And as pointed out in the Brazil iPhone dispute, just because you have a trademark doesn't mean nobody else has that same trademark.
One rule I learned was never go into any legal proceeding (and UDRP's close enough for jazz) with anything unless you've got evidence in hand to conclusively prove it. Overreaching and getting called on it's one of the fastest ways to blow your credibility, as Ron Paul found out.
Even if you run your own DNS servers, it's easy for an ISP to force you to go through theirs. On Linux it only takes a couple of iptables rules to redirect all traffic to destination port 53, TCP as well as UDP, to a specific IP address. It's the same trick used to force all HTTP traffic through a proxy, or block outbound SMTP except through the ISP's servers.
Be careful, though. Part of what you see for a given domain name depends on your ISP. For instance, if you're on Cox's cable Internet service and try going to "nonexistent.silverglass.org" (a name which definitively does not exist in the zonefile), you'll get a Web site filled with ads. A Web site I never created and have no part of. If you look at the URL bar, you'll see that Cox has resolved that name (that should've gotten an NXDOMAIN result) to the IP address of one of their servers and redirected you to one of their Web sites. Cox at least does a redirect, some ISPs simply serve up the page as if it came from the server name you used leaving you no clue that the domain owner isn't the one running that site.
It looks from my side like the site's just parked at GoDaddy, and what you're getting is the generic site GoDaddy serves up to every parked domain. The only ad is the button GoDaddy puts there to see about buying the domain, which is there whether the domain owner is interested in selling or not.
Seconded. For nearly a decade I had a domain that had no Web sites in it and in fact no e-mail service (no MX records). But it was very definitely in use. I used it to hold A records for hosts I needed convenient names for that didn't have names of their own (or not names I could resolve from my home network anyway). It was especially convenient for dynamic names, where the IP address changed regularly but I still needed a way to access the machine remotely. And most of those machines would look dead to anyone probing them, because the firewalls were designed to prevent probing and to restrict remote access to (more or less) SSH from specific networks so attackers would have a harder time gaining access. You wouldn't even get an error, my firewall policy on unauthorized packets was "Drop 'em down a black hole, let gravity (or client-side timeouts) sort 'em out. If they aren't authorized then they're Not My Problem.".
The domain owner here may well be a squatter, but just because the domain doesn't appear to be active to an outsider doesn't mean it's not active. It just means that J. Random Internet Passerby isn't being allowed to see any activity.
Or someone spilled to his wife what he was getting her for her birthday. The classic example of something that you don't want (certain) people to know but that you very much should be doing (unless you like spending time in the doghouse) and that can be quickly spoiled to your detriment by having it revealed.
The problem is that in practice you usually can't get a full definition of what a major project is supposed to do until after you've implemented it. It's simply too large, and there's too many things nobody thought of until they tripped over them during implementation. And worse, the longer you spend analyzing the problem to figure all those things out before-hand the more changes have to be made to the requirements because the problem you need to solve is evolving and changing over time. Your process is nice in theory, it merely fails to acknowledge reality.
Agile often goes too far the other way, though. Sometimes things are changing too fast to keep up at all, which is usually a sign that you need to be in R&D phase rather than trying to design and implement a production system. And there's usually a minimum amount of the system that has to be present for the system to function sensibly at all, trying to release anything before you've got to that point is an exercise in futility.
Actually that was before that time. The days of company scrip were the first days when companies considered workers an interchangeable commodity to be used up and replaced. Then government regulation came in and forced companies to treat workers decently and provide certain benefits. That forced companies to change, because the best way to recover the cost of investing in an employee became to keep that employee for a long time. Give them time to learn, become more productive, contribute value that came only with accumulated experience. Like the shift foreman who knows all the tricks because he's worked all the jobs, who can bring new workers up to speed in half the time and whose shift is half again as productive because he knows what to do to stop problems from happening in the first place. Or the general manager who's been with the company for 30 years, knows every department inside and out, can spot problems starting and head them off while they're still minor.
But then along came the MBAs, whose religion is that companies exist only to make money, not to operate a business. And now we're heading back to the bad old days. The only problem for the MBAs is that the first time around the jobs were manufacturing and the cost of going off on your own was high. Now the jobs are information and services, you don't need a large physical plant, you don't need a large number of employees, and you mostly don't even need to be physically present. Or they're jobs where the MBAs can't get a foothold. Think your local mechanic or plumber.
If my employer considers it important enough to have production problems addressed on the weekend, then they'll prepare for it. They'll hire enough people to have staff to cover things on weekends. They'll assign an on-call rotation. They'll provide the beeper or cel phone to contact the on-call people (since the device goes with the role it can be passed from one person to the next). And they'll provide compensation for working that time (either as part of salary negotiated at hire or as additional compensation for additional work beyond what was agreed upon at hire). If they don't consider it important enough... well, it's their business, it's not my place as their employee to dictate to them how they should run it.
I think it wasn't so much that he didn't show he had a right to the domains, as he didn't show that the current owners didn't. How it's supposed to work is that someone who has rights to the name wins over someone who doesn't, but if both parties have a right to use the name then whoever registered it first wins. "Rights" here gets a bit fuzzy, too. Ron Paul himself obviously has a right to use his name, but eg. a blogger doing commentary on Ron Paul's political activities also has a right to use the name (he's got every right to name who he's commenting on).
One thing about this is that this isn't the only license, nor is it even the license of most interest to open-source projects wanting to use the WebM codebase. The license here is for a bare patent license independent of any software or code. If you're wanting to use the WebM code, you're more interested in the Additional IP Rights Grant that'd apply in that case. You'd only be interested in the cross-license agreement if you wanted the patents alone and weren't using WebM in an open-source project.
Slashdot Mirror
So, let me get this straight. He didn't surreptitiously gain access to any area any random member of the public wouldn't have access to. He didn't plant any recording device to record in his absence. He stood outside a door and with a cel phone recorded what any passerby would have heard had they stopped to listen. Is that correct?
That doesn't even sound particularly unethical to me. A bit sleazy, but then if McConnell's careless enough to have that kind of discussion where anyone in the hallway can overhear the problem doesn't lie with the people in the hallway listening.
I'd agree with this on three conditions:
First problem is that sure, not every black hat will have the details, but any black hat may. In this age of automated toolsets for attackers, once one black hat figures it out and includes it in a toolset it's only one update away from being in the arsenal of any attacker using that toolset. In that environment you can't wait for them to prove they have the information, by the time that happens you're compromised and cleaning up and suffering all the financial, legal and PR liabilities that come with being breached. You have to assume that if a vulnerability exists then the guy attacking you has the tools to exploit it, and if it turns out after the fact that he didn't then you're still secure.
As far as not everyone being a competent admin and organizations having policies that prevent doing the right thing, tough. This was all well-understood 30 years ago when I was starting out, and I find as I grow older that I've less and less patience for people who expect me to leave myself vulnerable just because some people lack common sense.
As far as disclosing only to vendor's customers, down that path leads "We'll inform you of vulnerabilities, but only if you subscribe to our Ultra Platinum Plus support package for only $YOURFIRSTBORN per year. Oh, and the terms are that you can't say anything that might show us or our products in a bad light.". As far as I'm concerned, once the vulnerability's in the wild and actively being exploited the vendor's a side-show. Whatever they do is nice and all, but priority #1 is making sure that the people who'll be targets of the black hats know what they need to know to protect themselves. If the vendor wants to exercise any control, they need to start being proactive and finding the vulnerabilities before they get into the wild. 'cause frankly most of the vulnerabilities I'm seeing these days are from basic stuff that should have been dealt with before the code ever went to QA. Things like "All externally-supplied data is presumed hostile until proven otherwise." or "If a service is physically accessible, someone will attempt to access it. See preceding about externally-supplied data.".
Except that the black hats already know about it, and are actively using it to compromise systems. Telling me about it doesn't give the black hats any information they didn't already have. The only way keeping the information confidential helps me is if it's something the black hats can't possibly figure out without being told, and the track record says there's no such thing. I have yet to see a vulnerability that wasn't known and at least a proof-of-concept exploit in circulation for before the vendor disclosed it, I've seen plenty where the vendor only disclosed after major compromises attributable to that vulnerability became public knowledge.
As far as not everyone being able to protect a system goes, if you're unable to do basic system administration then you shouldn't be administering a system. You hire people who are qualified to do it for you. Don't expect me to agree to leave my systems vulnerable without my knowing about it just to appease that handful of dolts who're too stupid or too cheap to hire competent help for the job. In this day and age there's no excuse for not knowing you need competent admins running your systems.
As a user, I don't care about the vendor's ability to fix it quickly. Really I don't. That's their problem. My problem is that my systems are vulnerable to compromise and I have to do something about it. I need to know what the vulnerability is, in enough detail to understand it myself, and I need to know the possible workarounds (not just the vendor's recommended one(s), which is another reason I need to know what the vulnerability actually is so I can understand all the other possible ways of dealing with it). I need to evaluate my options and take whatever steps I need to to protect my systems. If the vendor needs a month to get the fix through their change-control process, I still need to protect my systems today.
The vendor's advice will be based on their most-likely scenario. Problem is that my situation may be radically different from the vendor's most-likely one. There's definitely going to be local considerations even if my situation's one the vendor's workaround covers. I need to understand the vulnerability to be able to evaluate it intelligently. It may not even be relevant to my setup. If it is, I may have less-intrusive workarounds (eg. for the SSH OTP authentication bug, if we've got a purely internal network that isn't accessible to the outside world or the Windows desktop portion of the network it may be less intrusive to just monitor for attempted exploits and defer doing anything until I see someone having gotten past the air gap rather than changing an authentication method that a lot of people depend on and that can't be exploited easily without being physically in the building). And if I need to take drastic steps like disabling the vulnerable SSH authentication method, I may have clients who insist they must be able to use it (maybe because their systems are based on it and they need my systems to integrate with their authentication because I'm providing services to them) and I need to be able to intelligently discuss exactly what's wrong and why it's simply not possible to use that method without being vulnerable and we've got to change to a different method despite the disruption. I can't do that unless I understand the vulnerability.
Notice that in all the above I haven't mentioned the vendor at all. Like I said, the vendor isn't relevant at all. It's my systems that're vulnerable and me that has to do something about it. If the vendor already has a fix then well and good, but if they don't it doesn't change my situation. When vendors say they need more time, they're asking me to leave my systems vulnerable without telling me they're vulnerable. Sorry, but no. Not, that is, unless they're willing to shoulder 100% of all the costs resulting from that vulnerability being exploited. Not just direct costs, things like the costs of lost business and clean-up if the vulnerability is exploited and liabilities I may incur because of the compromise. If a vendor isn't willing to take on that liability, then they don't get to tell me I shouldn't have the information I need to protect myself from that liability. If they don't like it... this is the sound of the world's smallest violin, playing the world's saddest song just for them.
One of the most important things when it comes to avoiding a group creating a mess is to have collective agreement on the architecture and design and the divisions and interfaces between components. Everybody doesn't have to agree that this way's the best way, but they have to agree that it's acceptable and they'll write to it. This goes both ways: you have to acknowledge that you'll follow the design even when you don't agree with it, and you also have to acknowledge that the other guy (who isn't getting his way) has valid points even though you're doing it your way instead of his.
NB: the above is why my mantra is "I am not a rock star. I am a professional.". I'll argue vehemently for what I think is the best way to do things, but in the end I need to write code that fits well with the rest of the system even if that code isn't technically "the best way".
The response isn't necessarily to fix the bug. The response is to mitigate the risk due to the vulnerability. One way is to fix the bug that's behind it. Another is to change configurations or add additional layers to remove exposure due to the bug. For instance there was once a vulnerability in SSH caused by one particular authentication method. Since that method was rarely used and there were alternative ways of doing the same kind of authentication, the most popular immediate solution was to just disable that authentication method. 5 minutes to change a config file and restart sshd and you're done. I'm not sure they ever did fix the bug, and if they did it took at least weeks, but that didn't stop people from protecting themselves within a matter of hours after the problem was made public.
They're already at significant risk due to the vulnerability. The only difference is that now they have to acknowledge and mitigate that risk instead of pretending it isn't there.
Well,
Discovery: there's legal issues there, yes, but there's also the fact that it's not your property that the data's on anymore. With physical documents a discovery order for the company doesn't give the company the right to come in and search my home for documents that might relate. Why should it be any different for electronic documents? The pattern should be that of any other case: the company responds that some of those documents are not under their control and supplies the contact information of the people who do control the documents.
Break/fix plan: not the company's problem. It's my device, fixing it is my job. And frankly I build stuff so my break/fix plan is "Buy a replacement.". I try to design things so I can hit Fry's and get replacement parts if it's really an emergency, mostly that means I'm down for an hour or three depending on which one I have to go to.
Exising desks etc.: again not the company's problem. I shouldn't need a docking station just to plug in a power cord and Ethernet cable, and the monitors should be using standard VGA/DVI/HDMI connectors.
Corporate software: this should've been dealt with before you started a BYOD program. If you require software that's got complex licensing requirements, figure out how you're going to let users use it first.
Failed app installs: this mostly shouldn't be a problem unless your apps have some really hairy dependencies. Despite this being a common scare tactic, I've rarely run into situations where an app wouldn't install because of some complex interaction with a personal setup. Most often it's because of stupidity like "We designed it to only work with one specific patch level of Java 1.5, and the user's got current Java 7 installed.". Often it ends up being the corporate developers who created that problem. For example that Java app before would run just fine in current Java 7, the only problem was that the corporate developers deliberately set the configuration to refuse to run except with that one specific patchlevel of one specific version of Java. Take that restriction out and presto, app works perfectly.
Smart Card mandate: again this is something the company ought to be working out beforehand. Remember that when you want to use someone else's equipment you can't always mandate what it has to be capable of or how it must operate. You either deal with this up front, or you acknowledge that the company needs to own the equipment which means it's not going to be BYOD.
The big problem seems to be that companies want to have employees paying for and owning the equipment, but want to treat that equipment as if the company owned it. The company needs to change it's attitude if it wants to use BYOD, design things to not require the company to own and control the equipment. It's not like it's a big deal, it's not like Oracle or Adobe or Intuit or Blizzard or any other software publisher hasn't had to figure out how to make their software live and work on machines they have no control over. If they can do it, I'm positive the problem isn't insoluble.
How does commercial software give you anyone to pin liability on? All of it that I've seen either disclaims liability entirely or limits liability to refunding your money (even from major vendors like Oracle it reads like "if it breaks, you get to keep both pieces"). You definitely won't be able to hold the vendor liable for the cost of lost business due to the failure of their software. Sure it gives you someone to blame, but you're still left holding the bag when it comes to the actual money the failure cost you. At least with open-source software, if the failure's bad enough the business can put it's own resources to work fixing it. Contrast that with commercial software where the business has no choice but to sit and wait for the vendor to decide the problem's important enough for the vendor to fix it.
If you believe that, try having a child falsely accuse you of molesting them. It may be only words and completely untrue, but I assure you the consequences will not be anything you can just ignore and they will harm you in very direct and unignorable ways.
If the statements were defamatory, then the organization has suffered harm. That's what defamation means, someone's said something false about you that's harmed your reputation. That also covers #1, true statements aren't normally defamatory. Hence why the posters should be allowed to participate in the first step with their anonymity protected, because one defense they could raise is that the statements were true and if so then PETA wouldn't be able to prevail on the "the statements were defamatory" part.
As for #2, that's another matter. If the statements were true but confidential then it wouldn't be defamation, it'd be breach of a non-disclosure agreement. For that, PETA should again have to show why they believe such an agreement was violated first. And again, the posters should be allowed to participate without their identity being revealed since "We weren't subject to any such non-disclosure agreement and we weren't obliged to respect the confidentiality of the information." would be a valid defense and if carried would mean PETA's claims would fail before they got to the point where they could ask for identities to be revealed. NB: yes, sometimes third parties are required to respect and help protect confidentiality even though they haven't explicitly agreed to do so. It's based on the principle that while you aren't bound by agreements you didn't yourself agree to, you aren't legally supposed to knowingly assist someone else in breaching contracts they've agreed to. The "knowingly" part is the dividing line.
PETA should be allowed to discover the identities of the posters for the purposes of suing them, if the statements are in fact defamatory. But the first bar PETA should have to clear is to demonstrate to the court that the statements are in fact defamatory. And they should be required to identify the allegedly-defamatory posts publicly, so the posters can retain counsel and contest the allegations without having their identity revealed. Only after they've prevailed on the "the statements are defamatory" part should they be allowed discovery as to the identities of the posters. And if they fail to follow through and file suit, sanctions should be imposed for abuse of process.
Being anonymous should not mean you can't be held accountable for what you say, but the first step should be showing that someone could be held legally accountable for saying what was said. If what was said isn't actionable, then it shouldn't matter who said it.
This is easy to implement in software, but you will not in general find software in the forwarding path at an ISP; you will find hardware.
Two words: Cisco iOS. Not Linux, but far more capable and can make use of the massive built-in hardware assist. I don't think there's a modern router that's pure hardware-based, all of them are software-based with some degree or another of hardware assist (except maybe home routers which're mostly just generic ARM boxes running Linux with no hardware assist beyond what's in the NICs themselves).
True, but as was pointed out in the ronpaul.com dispute, having a trademark doesn't mean nobody else has any right to use that name. And as pointed out in the Brazil iPhone dispute, just because you have a trademark doesn't mean nobody else has that same trademark.
One rule I learned was never go into any legal proceeding (and UDRP's close enough for jazz) with anything unless you've got evidence in hand to conclusively prove it. Overreaching and getting called on it's one of the fastest ways to blow your credibility, as Ron Paul found out.
Even if you run your own DNS servers, it's easy for an ISP to force you to go through theirs. On Linux it only takes a couple of iptables rules to redirect all traffic to destination port 53, TCP as well as UDP, to a specific IP address. It's the same trick used to force all HTTP traffic through a proxy, or block outbound SMTP except through the ISP's servers.
Be careful, though. Part of what you see for a given domain name depends on your ISP. For instance, if you're on Cox's cable Internet service and try going to "nonexistent.silverglass.org" (a name which definitively does not exist in the zonefile), you'll get a Web site filled with ads. A Web site I never created and have no part of. If you look at the URL bar, you'll see that Cox has resolved that name (that should've gotten an NXDOMAIN result) to the IP address of one of their servers and redirected you to one of their Web sites. Cox at least does a redirect, some ISPs simply serve up the page as if it came from the server name you used leaving you no clue that the domain owner isn't the one running that site.
It looks from my side like the site's just parked at GoDaddy, and what you're getting is the generic site GoDaddy serves up to every parked domain. The only ad is the button GoDaddy puts there to see about buying the domain, which is there whether the domain owner is interested in selling or not.
Seconded. For nearly a decade I had a domain that had no Web sites in it and in fact no e-mail service (no MX records). But it was very definitely in use. I used it to hold A records for hosts I needed convenient names for that didn't have names of their own (or not names I could resolve from my home network anyway). It was especially convenient for dynamic names, where the IP address changed regularly but I still needed a way to access the machine remotely. And most of those machines would look dead to anyone probing them, because the firewalls were designed to prevent probing and to restrict remote access to (more or less) SSH from specific networks so attackers would have a harder time gaining access. You wouldn't even get an error, my firewall policy on unauthorized packets was "Drop 'em down a black hole, let gravity (or client-side timeouts) sort 'em out. If they aren't authorized then they're Not My Problem.".
The domain owner here may well be a squatter, but just because the domain doesn't appear to be active to an outsider doesn't mean it's not active. It just means that J. Random Internet Passerby isn't being allowed to see any activity.
Or someone spilled to his wife what he was getting her for her birthday. The classic example of something that you don't want (certain) people to know but that you very much should be doing (unless you like spending time in the doghouse) and that can be quickly spoiled to your detriment by having it revealed.
The problem is that in practice you usually can't get a full definition of what a major project is supposed to do until after you've implemented it. It's simply too large, and there's too many things nobody thought of until they tripped over them during implementation. And worse, the longer you spend analyzing the problem to figure all those things out before-hand the more changes have to be made to the requirements because the problem you need to solve is evolving and changing over time. Your process is nice in theory, it merely fails to acknowledge reality.
Agile often goes too far the other way, though. Sometimes things are changing too fast to keep up at all, which is usually a sign that you need to be in R&D phase rather than trying to design and implement a production system. And there's usually a minimum amount of the system that has to be present for the system to function sensibly at all, trying to release anything before you've got to that point is an exercise in futility.
Actually that was before that time. The days of company scrip were the first days when companies considered workers an interchangeable commodity to be used up and replaced. Then government regulation came in and forced companies to treat workers decently and provide certain benefits. That forced companies to change, because the best way to recover the cost of investing in an employee became to keep that employee for a long time. Give them time to learn, become more productive, contribute value that came only with accumulated experience. Like the shift foreman who knows all the tricks because he's worked all the jobs, who can bring new workers up to speed in half the time and whose shift is half again as productive because he knows what to do to stop problems from happening in the first place. Or the general manager who's been with the company for 30 years, knows every department inside and out, can spot problems starting and head them off while they're still minor.
But then along came the MBAs, whose religion is that companies exist only to make money, not to operate a business. And now we're heading back to the bad old days. The only problem for the MBAs is that the first time around the jobs were manufacturing and the cost of going off on your own was high. Now the jobs are information and services, you don't need a large physical plant, you don't need a large number of employees, and you mostly don't even need to be physically present. Or they're jobs where the MBAs can't get a foothold. Think your local mechanic or plumber.
If my employer considers it important enough to have production problems addressed on the weekend, then they'll prepare for it. They'll hire enough people to have staff to cover things on weekends. They'll assign an on-call rotation. They'll provide the beeper or cel phone to contact the on-call people (since the device goes with the role it can be passed from one person to the next). And they'll provide compensation for working that time (either as part of salary negotiated at hire or as additional compensation for additional work beyond what was agreed upon at hire). If they don't consider it important enough... well, it's their business, it's not my place as their employee to dictate to them how they should run it.
I think it wasn't so much that he didn't show he had a right to the domains, as he didn't show that the current owners didn't. How it's supposed to work is that someone who has rights to the name wins over someone who doesn't, but if both parties have a right to use the name then whoever registered it first wins. "Rights" here gets a bit fuzzy, too. Ron Paul himself obviously has a right to use his name, but eg. a blogger doing commentary on Ron Paul's political activities also has a right to use the name (he's got every right to name who he's commenting on).
Because the average user doesn't want the source code, they want to download a prepared binary in an installer or zipfile?
One thing about this is that this isn't the only license, nor is it even the license of most interest to open-source projects wanting to use the WebM codebase. The license here is for a bare patent license independent of any software or code. If you're wanting to use the WebM code, you're more interested in the Additional IP Rights Grant that'd apply in that case. You'd only be interested in the cross-license agreement if you wanted the patents alone and weren't using WebM in an open-source project.