I probably would too. Which is why one of the questions I ask before deciding to deal with a hosting or colo provider is "What kinds of customers will I be sharing a network with?". I look at what this provider's reputation is, what sort of history they have when it comes to spam, malware and similar things. Do they have a lot of complaints about spam and malware originating from their network? Are they known for investigating and taking action when problems are reported, or do they have a reputation for ignoring the problem for as long as possible? Do I find them showing up as a place to go for "bulletproof" hosting? Do I see their netblocks showing up in spam e-mail, attacks on my firewall or lists of netblocks known to originate malware? I make sure I've got answers to those questions that I like before I decide to do business with them.
Part of your responsibility when you start a business relationship is to know who you're getting yourself involved with. If you choose not to, don't be suprised when it comes back to bite you later.
My immediate reply to that suggestion is "Company marketing plans. Legal strategy documents. The CEO's e-mail. The company's detailed internal financial records. Do we regularly hand those over to someone outside the company? No, didn't think so. Anyone doing my job is going to have access to those things, they can't do the job without it. What kind of risk will you be taking giving someone who isn't within the company access to those things?". Just the legal aspects alone make the company lawyers curl up in a corner whimpering considering recent e-discovery rulings. And if you have to have someone in-house to do that kind of work for all the stuff you can't let an outsider see without undue risk, it's cheaper to have them doing all the work rather than pay for them and the outsourced people too.
If it's a manufacturing company, point to the machines on the production line and the routine maintenance (oiling, cleaning, checking) that gets done on them. How much does that maintenance improve productivity? How much time does the maintenance guy's work save other workers? And what happens to the company's output when that maintenance doesn't happen?
Or, for a more graphic example, point to the restroom. How much time does having the janitor clean it save other employees? How much does that cleaning contribute to the company's bottom line? And what are the consequences if the restroom isn't cleaned every day? Or the trash cans emptied, or the floor cleaned?
Usually it's additional requirements for a non-normalized data model. You design a nice clean data model, and then business throws in a requirement that forces you to read part of the object, look at what's in it and make a decision on how/where to get the rest of the object before being able to read it. So now you've got business logic, and information only available to the business layer, buried down inside your persistence layer controlling how objects are represented in your database. Of course the right way to deal with this is to change your data model to match the requirements, but you can't do that since there's now other applications that depend on the database schema and you're not allowed to break them or force them to change. So now you've got an operation that needs to be atomic but that involves a set of steps that, in Hibernate's universe, aren't atomic. There's several ways around the problem but none of them are pretty and they're all time-consuming, more so than management will allow for.
And when the form exists, what you end up getting back when you say "OK, that change is going to add 3 weeks to the schedule." is "That's not acceptable.". And no process in the world will help with that.
The problem is that the standard response from the business people, when I try to anticipate future requirements, is "But we're not asking for that. Can't you just do what we asked instead of adding all this extra stuff that's taking too much time to do?". Part of it seems to be that business wants and is given the authority to add to and change the requirements, but never been required to take responsibility for the consequences of those additions and changes.
His "blue" comment makes sense. It's how I run my wireless network: unencrypted at the 802.11a level, but the physical connection terminates at the gateway machine and the only traffic allowed in through that interface is that needed to negotiate and maintain an IPSec VPN connection. The IPSec server, meanwhile, will only negotiate a connection with someone presenting a certificate signed by my CA cert. If I don't know your machine, you don't get access. If you need access, you talk to me and I'll get you a certificate you can use.
Yes, I could enable security at the physical level. I prefer to drive home the point that the wireless portion is untrusted, potentially compromised at any and all times, and you configure your machine to live in that environment safely right from the start.
Your IT people need to remember that whole-disk encryption only protects against some threats, not all. It's mainly going to protect against physical theft of the drives themselves, or the computer they're in. That means it's going to mainly benefit laptops that're out in the world where they can be easily stolen. Office desktops, if they're stolen that means someone had physical access to the building to take them. If the IT department can't name the last time a desktop was stolen from the building, theft is probably not an issue. Servers aren't likely to be stolen at all, they're locked up in a presumably secured data center and I just don't see an outsider being able to get in there let alone unrack a server and walk out with it under their arm. Again, if IT can't name the last time a server was stolen it's probably a non-issue.
And even in the case of a laptop, the encryption only protects the disk while the computer's powered off or in a state where the encryption software's discarded the key and won't decrypt the disk again without you re-entering the password. We found where I work that the standard suspend mode of the laptops does not trigger PGP to prompt for the password on resume, for instance. Since most of our people leave their laptop suspended while carrying it around rather than turning it completely off (to speed up start-up), the PGP encryption essentially isn't protecting the disk at all since the thief won't need the password to get the data decrypted. I don't count the normal screen lock, since if that were sufficient you'd just force password lock on the screen saver and not need encryption at all.
And of course whole-disk encryption won't protect you at all from viruses, trojans and other malware that gets onto the system and starts sending data back home. That stuff's running after you've helpfully given PGP the password and it's cheerfully decrypting data for you, and it's running as you so PGP thinks it's you accessing the data. Again, for office desktops and servers remote access by malware's probably a bigger concern than physical access to the machines and you need something other than whole-disk encryption to protect against those threats.
To be honest, I'm much more of a fan of removeable media. Put the patient data on a USB stick, then plug the stick in to access the data and remove it when you're done. If the sensitive data isn't on the computer then nobody can get it by stealing the computer. Just don't fall victim to those "encrypted" USB sticks, many of them either use algorithms that're trivial to break or they fail miserably at some point (eg. leaving the encryption key in unencrypted unprotected space where it can be extracted and used by a thief). It's much easier to lock some USB sticks or CD/DVDs up in a secure drawer than it is to protect a computer.
Seriously, this has been how it is since the early 80s. 25 years ago it was the teenagers who were war-dialing and breaking into time-sharing systems. They're the ones who've got free time for it. As you get older you get into college or into a job and you've got a lot less free time for messing around like that. It only makes sense, then, that school kids would be one of the two major groups doing this (the other being those adults for whom this kind of crime is their job).
If it's really the alteration they're worried about, dig around on Google and create a short list of all the commercial shrink-wrap programs and consumer hardware that's shipped with viruses and malware embedded in it over the last 5 years or so. even the iPod was hit with this just 2 years ago. Highlight the vendor's reactions, including the denials that there was a problem until confronted with incontrovertible proof. Then pull up the few stories of this happening to open-source vendors like Debian, pointing out how quickly it was detected and fixed (Debian's was found less than 24 hours after the compromise), how quickly customers were informed so they could fix the problem, and how few of these have occurred compared to closed-source software. I'd also play up the direct-from-author factor. All the compromises of OSS have been by placing compromised binaries on servers. OSS allows you to ignore binaries and get source packages instead, compiling them yourself. If you don't ever download binaries, you can never get hit with a compromised binary. Closed source doesn't allow you to bypass the whole problem like that. Finish by noting the only attempted source compromise I can think of, the attempt to introduce malware into the Linux kernel a while back and point out that the attempt was detected almost at the point it was attempted, long before it got to the point where it would've been even considered for inclusion in the publicly-distributed source code.
Also note that with OSS most of the major vendors provide MD5 checksums of their packages that you can check yourself to insure your binaries are identical to what the vendor produced, and many of them use cryptographic signatures on the packages that you can verify against their published keys to insure the package actually came from them. No commercial vendor provides this, so there's really no way to insure the discs you get really have the vendor's versions on them and haven't been altered. Even physical media isn't insurance here, not with how easy it is for even the average person to burn a disc. And note that this ability to verify packages also allowed customers, in the cases of the security breaches noted above, to determine whether they'd actually been affected by the breach and whether they really needed to clean up bad software or were in fact safe. Victims of the closed-source compromises had to just assume they'd been affected whether they had or not.
Not, mind you, that the above will do much good. The people objecting to open-source don't care about any of this. They just don't want to deal with anything new, anything that might disturb their precious status-quo and familiar environment.
The big difference is the affected company can do something about the problem. The CEO can come down and tell the admin he's not going home until this is fixed. They can call in any extra people they need. They can, if it's really that critical, have someone physically go and buy a new server and get enough software installed on it to get mail back up and running until the main system can be fixed. Expensive proposition there, but the company gets the option of deciding whether it's worth it or not.
Compare this to the situation Bill W.'s company is in. Their e-mail is down. All they can do is wait until it comes back up. No matter how crucial service is, no matter how much money they're losing because it's down, they've got absolutely no control over how fast the problem gets fixed. That'll be determined by how important to Google restoring service is. And the cost equation to Google is the cost of having staff working overtime all night to fix the problem vs. the cost of giving Bill W.'s company 15 days more service (about $2.06 at the $50/year rate for Google Apps).
Actually they did have an SLA. The users complaining were using Google Apps, for which they pay and which includes a Service Level Agreement. However, the users are learning 2 important life lessons:
Down is down, SLA nonwithstanding. All the SLA means is that you may get limited compensation when the service is down. It doesn't get your service up and running one second sooner.
In this case, the compensation is pretty poor. Google won't compensate for damage to their businesses due to e-mail being down. All Google has to do is provide 15 more days service at the end of the contract period. But then, what did you expect for $50/year?
For me, the version of the software makes a difference. The very first released version I'm going to be wary of, it's likely to need some shaking-out given the industry's track record. Similarly when a package undergoes a major internal re-write I'm wary of the first release of the new codebase for the same reason. But the version number doesn't play into that at all. Call it 1.0 or 6.73, it's still the first released version and I'll still be wary until I see some real-world evidence of whether it's good or flaky.
Of course, version numbering does affect my decision in another way. If a company's straight-forward in their versioning, keeping minor revisions containing only bug-fixes and minor enhancements, incrementing the major version number when they make major internal changes that might affect stability, major API changes and the like, then I tend to trust their releases because they're giving me a clear indication what I can expect. OTOH, if they obfuscate the version numbering to try and deceive me into thinking the release is something it isn't, I immediately start to distrust everything about their software. If they're deceptive in one place, they'll be deceptive in others and I've got enough headaches to deal with already thankyouverymuch.
Bingo. 99.8% of game buyers don't care about DRM, but that 0.2% that do care tend to be the hard-core gamers. And 75% of the 99.8% ask their hard-core gamer friends for recommendations on new consoles and new games to buy. When what they hear is "Skip the EA games, they're just a nightmare to work with. Go get this other game instead, you'll like it just as much and it'll give you fewer headaches.", well, sales for EA will tend to sort of suck.
What I've found is there's two sets of best practices, depending on the type of driving.
1. Highway driving, dominated by long periods of cruising. With modern aerodynamics, air resistance isn't usually a problem for passenger cars at posted speed limits (up to 75mph). SUVs and trucks have issues, but if you're interested in fuel economy changing to something else is the single biggest fuel savings you can get. Fuel consumption then's determined by two things: how efficiently your engine's turning fuel into power, and how many RPMs it's making. The first you can find by looking at a graph of your engine's power band (power produced vs. RPM). It's a plateau with a drop-off at either end. You want to stay in the plateau region, if you let the RPMs drop too far or climb too high your engine's burning more fuel than it needs to to generate power to keep you moving. The second's mostly determined by what gear you're in. So you want to maintain the speed that keeps you at the low end of the power band in the highest gear you have available. Any slower than that and you need more throttle (and more fuel burned) to maintain speed, or you have to drop into a lower gear and increase your RPMs (which means burning more fuel).
2. City driving, dominated by acceleration from stops. Speed has a small effect, but the biggest fuel burn you have is accelerating away from a stop light. So adjust your speed to match the interval between lights as closely as possible. If you find lights going green just after you've stopped, slow down a bit. And if you find them going red before you get there, speed up. Going faster may burn more fuel, but starting from a dead stop burns much more so you save by avoiding the stop. And don't lolly-gag on the acceleration. You don't want to peel out, but you want to get up to speed fairly quickly so you spend the least time in lower gears. Remember, the lower the gear the higher the RPMs at a given speed and the more fuel you're burning. Plus, getting up to speed smartly makes it easier to judge the speed you need to maintain to hit the next light while it's green. Spend too much time accelerating and you'll either have to hit a much higher speed or you'll miss the next green, have to stop, and burn all that fuel accelerating again.
Except that DNSSEC is DNS. Period. It isn't compatible with DNS, it is DNS. It simply adds some additional records that aren't normally present that a DNS server or resolver can, if configured to, use to verify that the responses come from a valid server. It's not difficult to deploy, all current DNS servers already implement it so it's already deployed. What's difficult is the process of generating the signature chains, since the validity of the signatures at any level depends on the signature chain back to the root be intact and valid. So, if I have silverglass.org signed, the com and root domains also needs to use DNSSEC and sign their records before the DNSSEC records on silverglass.org can be verified.
Note that the signature chain's the critical part. The first question that needs answered, before you can validate any response, is "What's the correct, valid key I should verify this domain's records with?". Fail to solve the problem of answering that question securely, and the system's not secure regardless of anything else it may try to do.
Decide what you consider "private". I'm not worried about things like my name, address and phone number appearing on FaceBook. I'm in the phone book, anybody who can read and has any interest can find them trivially. Given that, merely having a FaceBook account isn't a privacy problem. What's problematic is the tracking the various FaceBook gadgets can do even when you're not on FaceBook. Some configuration of my browser eliminates that problem (as long as I remember to keep FaceBook in it's own browser session so it can't see anything from my non-FaceBook browsing). Detailed information on my social life? I simply don't post that on FaceBook. I've other places to put that kind of stuff, places that give me more control over who sees it. Photos? That's a decades-old problem, and I deal with it on FaceBook with the same rule I've used since college: if it's something I wouldn't want widely published, I make sure either I get control of all prints and the negatives or I don't allow the photo to include me.
And finally, I keep track of what my friends are doing. If they're in the habit of making things about me public that I've asked them not to, I reconsider just how good of a friend they are. I'm a grown adult, I'm fully capable of making friends with people with a modicum of discretion.
Firstly, I'd have heartburn with the whole non-compete portion. You got this offer due to your work on this project. Likely you'll get future offers based on your familiarity with this project and ability to do things with it. They're asking you to foreclose on all those opportunities, throw them away before you even get them. I wouldn't do that unless I was truly desperate for money to pay the bills, or unless they were willing to compensate me for the expected value of all those no-longer-possible opportunities. In short, I'd be wanting compensation not just for the work they want me to do but for the impact of their demands on my entire career for the rest of my life. I think that's only fair.
Secondly, they sound like they don't quite grasp the licenses, and that would worry me. Once code's been released under a license, it can't be taken back. They can take ownership of what you wrote if you give it to them and then going forward refuse to release it under the BSD license anymore, but they can't unlicense those copies already out there nor prevent people from doing what the license permits with what they've already got. If they think they can, they're either in for a nasty shock when their lawyers enlighten them or they intend to play dirty and try and knock down the whole project so they can have sole possession of it. Either way, I wouldn't want to be connected to the mess that's going to result. Again, the backlash is going to have negative impacts on your future career, and I'd be wanting compensation from them for that. And we're not talking just about the time you're working for them, we're talking about the whole rest of your career here.
Personally I'd be willing to do proprietary work for them, but I wouldn't grant them ownership of anything except what I'd written specifically for them, I wouldn't agree to an open-ended ban on future work and I wouldn't agree to an extended non-disclosure period without them compensating me for the entirety of that period.
The CAPTCHA-crackers aren't using software. The most common methods are to either hire a large number of humans in low-wage countries to solve the CAPTCHAs, or to present CAPTCHAs from sites needing them cracked on the registration pages of created-for-the-purpose porn sites and let unwitting visitors solve them. Which means that CAPTCHAs are fundamentally broken. We no longer need something that can distinguish a computer from a human, we need something that can distinguish a legitimate human from a spammer-aiding human. That's a much harder problem.
Personally I favor requiring registration combined with an easy, anonymous registration process with out-of-band verification. We don't need any absolute identity of the registrant, what we need is to make it non-trivial to obtain a different identity for the same person. So, take the case where the registrant/poster has a cel phone. The person when registering gives a cel-phone number that the site will send a text message to containing a verification code. Registration is complete only when the person enters the verification code. If the cel-phone number has been used to register previously (I wouldn't have the system store the phone numbers, a cryptographic hash of the number will suffice), the site will force the registration to go through a more elaborate process. You can quickly get registered on the site under any identity you want, but you can't readily get multiple identities on the same site without talking to a human (which spammers will be reluctant to do, and which won't happen fast enough for their purposes anyway).
My basic formula for swap space is: worst-case memory usage that I don't want the system to fail under, minus the amount of system RAM I have, rounded up to the nearest even amount (I usually make it an even multiple of 16M or an even number of gigabytes). My minimum for swap space is the amount of system RAM, to allow for things like hibernation, but that's a personal preference. I don't like running without swap simply because there's no overflow, no buffer for the occasional nasty memory hog. And a lot of the time it's useful to have somewhere to put idle program address space, freeing up system RAM for I/O buffer cache. I've a number of programs that really only become active in the wee hours of the morning, and I'm willing to let them take a moment to swap in when I'm not around to get the better performance during working hours that comes from having the memory they'd otherwise be occupying available for buffers and cache.
And, on today's systems with 250+G hard drives, 2-4G for swap is almost negligible.
My solution's what it's been for the last 15 years. I own a domain, and have it hosted with a reputable provider (my old ISP, in fact, as part of my basic web-hosting package). I run a local-only SMTP server (incoming from the LAN and localhost only, outgoing via SMTP/AUTH/SSL to my provider's relay server) and an IMAP server on my own machines, along with an SSH server. I'm dependent on my provider for the physical servers, but I can move those servers to any other provider as quickly as I can get service arranged if I need to. My mail transfer system's configured to keep copies on both my provider (who also provides IMAP/SSL access to my server-side mailboxes) and on my home machines. I can access either set, provider or home, via either IMAP/SSL or by SSHing in and running local mail clients (including graphical ones) remotely. Any machine may fail, but as long as both sides don't fail simultaneously I can recover without loss. My provider takes care of the bulk of the spam-filtering (one reason I've stayed with them even though they cost more than some alternatives), and my own filtering (mainly bogofilter) takes care of the little that gets through. It took a couple days' work to set all this up, but I figure 2 days' investment for 15 years of trouble-free running is a pretty good ROI.
Buy a domain. Set up e-mail hosting with a reputable provider (usually a good web-hosting place will provide e-mail as part of the web-site deal). Set up your local mail system to route outgoing mail through your provider's mail servers. This is how I do it with mine (my e-mail and web-hosting are provided by my old ISP). I can change ISPs without affecting my e-mail at all. I can, if I want, move my e-mail service anywhere I want without affecting my e-mail addresses (they continue to go to my domain, regardless of where the servers are physically hosted). With my provider offering SMTP relay service via authenticated/encrypted connections, I can send e-mail from anywhere I can configure the e-mail client with my provider's information regardless of the state of the local mail system. And it's time-proven, setups like this have been used for the last, oh, 25 years or so in one form or another.
GMail supports POP3. But by the time you've set things up to be able to use it to usefully back up your mail, you've gotten a complete remotely-accessible mail solution in place that doesn't need GMail at all.
It's not having your data stored on the Internet, it's the cloud-computing idea of only having your data stored on the Internet. GMail's a good example. Where other than out at Google are your e-mail messages stored? How do you propose to get at your e-mail if GMail isn't available? Note that it doesn't matter why GMail's unavailable, it could be because you're at a place that doesn't have Internet, because the network links are down because of a disaster, or because Google's gone out of business without warning, unavailable is unavailable. Having your mail on GMail in addition to being stored locally is fine, but GMail doesn't support acting as a backup to a standard mail client and their normal Web interface doesn't provide an easy way to make a local backup of your mailboxes or save new messages locally as you send them.
And if the idea of GMail going away sounds improbable, remember how improbable it was just a month ago that all the major Wall Street investment banks, the backbone of the US financial system for better than half a century, would all be either in bankruptcy or out of the investment-banking business in literally a matter of a week or so.
Slashdot Mirror
I probably would too. Which is why one of the questions I ask before deciding to deal with a hosting or colo provider is "What kinds of customers will I be sharing a network with?". I look at what this provider's reputation is, what sort of history they have when it comes to spam, malware and similar things. Do they have a lot of complaints about spam and malware originating from their network? Are they known for investigating and taking action when problems are reported, or do they have a reputation for ignoring the problem for as long as possible? Do I find them showing up as a place to go for "bulletproof" hosting? Do I see their netblocks showing up in spam e-mail, attacks on my firewall or lists of netblocks known to originate malware? I make sure I've got answers to those questions that I like before I decide to do business with them.
Part of your responsibility when you start a business relationship is to know who you're getting yourself involved with. If you choose not to, don't be suprised when it comes back to bite you later.
My immediate reply to that suggestion is "Company marketing plans. Legal strategy documents. The CEO's e-mail. The company's detailed internal financial records. Do we regularly hand those over to someone outside the company? No, didn't think so. Anyone doing my job is going to have access to those things, they can't do the job without it. What kind of risk will you be taking giving someone who isn't within the company access to those things?". Just the legal aspects alone make the company lawyers curl up in a corner whimpering considering recent e-discovery rulings. And if you have to have someone in-house to do that kind of work for all the stuff you can't let an outsider see without undue risk, it's cheaper to have them doing all the work rather than pay for them and the outsourced people too.
If it's a manufacturing company, point to the machines on the production line and the routine maintenance (oiling, cleaning, checking) that gets done on them. How much does that maintenance improve productivity? How much time does the maintenance guy's work save other workers? And what happens to the company's output when that maintenance doesn't happen?
Or, for a more graphic example, point to the restroom. How much time does having the janitor clean it save other employees? How much does that cleaning contribute to the company's bottom line? And what are the consequences if the restroom isn't cleaned every day? Or the trash cans emptied, or the floor cleaned?
Usually it's additional requirements for a non-normalized data model. You design a nice clean data model, and then business throws in a requirement that forces you to read part of the object, look at what's in it and make a decision on how/where to get the rest of the object before being able to read it. So now you've got business logic, and information only available to the business layer, buried down inside your persistence layer controlling how objects are represented in your database. Of course the right way to deal with this is to change your data model to match the requirements, but you can't do that since there's now other applications that depend on the database schema and you're not allowed to break them or force them to change. So now you've got an operation that needs to be atomic but that involves a set of steps that, in Hibernate's universe, aren't atomic. There's several ways around the problem but none of them are pretty and they're all time-consuming, more so than management will allow for.
And when the form exists, what you end up getting back when you say "OK, that change is going to add 3 weeks to the schedule." is "That's not acceptable.". And no process in the world will help with that.
The problem is that the standard response from the business people, when I try to anticipate future requirements, is "But we're not asking for that. Can't you just do what we asked instead of adding all this extra stuff that's taking too much time to do?". Part of it seems to be that business wants and is given the authority to add to and change the requirements, but never been required to take responsibility for the consequences of those additions and changes.
His "blue" comment makes sense. It's how I run my wireless network: unencrypted at the 802.11a level, but the physical connection terminates at the gateway machine and the only traffic allowed in through that interface is that needed to negotiate and maintain an IPSec VPN connection. The IPSec server, meanwhile, will only negotiate a connection with someone presenting a certificate signed by my CA cert. If I don't know your machine, you don't get access. If you need access, you talk to me and I'll get you a certificate you can use.
Yes, I could enable security at the physical level. I prefer to drive home the point that the wireless portion is untrusted, potentially compromised at any and all times, and you configure your machine to live in that environment safely right from the start.
Your IT people need to remember that whole-disk encryption only protects against some threats, not all. It's mainly going to protect against physical theft of the drives themselves, or the computer they're in. That means it's going to mainly benefit laptops that're out in the world where they can be easily stolen. Office desktops, if they're stolen that means someone had physical access to the building to take them. If the IT department can't name the last time a desktop was stolen from the building, theft is probably not an issue. Servers aren't likely to be stolen at all, they're locked up in a presumably secured data center and I just don't see an outsider being able to get in there let alone unrack a server and walk out with it under their arm. Again, if IT can't name the last time a server was stolen it's probably a non-issue.
And even in the case of a laptop, the encryption only protects the disk while the computer's powered off or in a state where the encryption software's discarded the key and won't decrypt the disk again without you re-entering the password. We found where I work that the standard suspend mode of the laptops does not trigger PGP to prompt for the password on resume, for instance. Since most of our people leave their laptop suspended while carrying it around rather than turning it completely off (to speed up start-up), the PGP encryption essentially isn't protecting the disk at all since the thief won't need the password to get the data decrypted. I don't count the normal screen lock, since if that were sufficient you'd just force password lock on the screen saver and not need encryption at all.
And of course whole-disk encryption won't protect you at all from viruses, trojans and other malware that gets onto the system and starts sending data back home. That stuff's running after you've helpfully given PGP the password and it's cheerfully decrypting data for you, and it's running as you so PGP thinks it's you accessing the data. Again, for office desktops and servers remote access by malware's probably a bigger concern than physical access to the machines and you need something other than whole-disk encryption to protect against those threats.
To be honest, I'm much more of a fan of removeable media. Put the patient data on a USB stick, then plug the stick in to access the data and remove it when you're done. If the sensitive data isn't on the computer then nobody can get it by stealing the computer. Just don't fall victim to those "encrypted" USB sticks, many of them either use algorithms that're trivial to break or they fail miserably at some point (eg. leaving the encryption key in unencrypted unprotected space where it can be extracted and used by a thief). It's much easier to lock some USB sticks or CD/DVDs up in a secure drawer than it is to protect a computer.
Two words: Mike Nifong.
Seriously, this has been how it is since the early 80s. 25 years ago it was the teenagers who were war-dialing and breaking into time-sharing systems. They're the ones who've got free time for it. As you get older you get into college or into a job and you've got a lot less free time for messing around like that. It only makes sense, then, that school kids would be one of the two major groups doing this (the other being those adults for whom this kind of crime is their job).
If it's really the alteration they're worried about, dig around on Google and create a short list of all the commercial shrink-wrap programs and consumer hardware that's shipped with viruses and malware embedded in it over the last 5 years or so. even the iPod was hit with this just 2 years ago. Highlight the vendor's reactions, including the denials that there was a problem until confronted with incontrovertible proof. Then pull up the few stories of this happening to open-source vendors like Debian, pointing out how quickly it was detected and fixed (Debian's was found less than 24 hours after the compromise), how quickly customers were informed so they could fix the problem, and how few of these have occurred compared to closed-source software. I'd also play up the direct-from-author factor. All the compromises of OSS have been by placing compromised binaries on servers. OSS allows you to ignore binaries and get source packages instead, compiling them yourself. If you don't ever download binaries, you can never get hit with a compromised binary. Closed source doesn't allow you to bypass the whole problem like that. Finish by noting the only attempted source compromise I can think of, the attempt to introduce malware into the Linux kernel a while back and point out that the attempt was detected almost at the point it was attempted, long before it got to the point where it would've been even considered for inclusion in the publicly-distributed source code.
Also note that with OSS most of the major vendors provide MD5 checksums of their packages that you can check yourself to insure your binaries are identical to what the vendor produced, and many of them use cryptographic signatures on the packages that you can verify against their published keys to insure the package actually came from them. No commercial vendor provides this, so there's really no way to insure the discs you get really have the vendor's versions on them and haven't been altered. Even physical media isn't insurance here, not with how easy it is for even the average person to burn a disc. And note that this ability to verify packages also allowed customers, in the cases of the security breaches noted above, to determine whether they'd actually been affected by the breach and whether they really needed to clean up bad software or were in fact safe. Victims of the closed-source compromises had to just assume they'd been affected whether they had or not.
Not, mind you, that the above will do much good. The people objecting to open-source don't care about any of this. They just don't want to deal with anything new, anything that might disturb their precious status-quo and familiar environment.
The big difference is the affected company can do something about the problem. The CEO can come down and tell the admin he's not going home until this is fixed. They can call in any extra people they need. They can, if it's really that critical, have someone physically go and buy a new server and get enough software installed on it to get mail back up and running until the main system can be fixed. Expensive proposition there, but the company gets the option of deciding whether it's worth it or not.
Compare this to the situation Bill W.'s company is in. Their e-mail is down. All they can do is wait until it comes back up. No matter how crucial service is, no matter how much money they're losing because it's down, they've got absolutely no control over how fast the problem gets fixed. That'll be determined by how important to Google restoring service is. And the cost equation to Google is the cost of having staff working overtime all night to fix the problem vs. the cost of giving Bill W.'s company 15 days more service (about $2.06 at the $50/year rate for Google Apps).
Actually they did have an SLA. The users complaining were using Google Apps, for which they pay and which includes a Service Level Agreement. However, the users are learning 2 important life lessons:
For me, the version of the software makes a difference. The very first released version I'm going to be wary of, it's likely to need some shaking-out given the industry's track record. Similarly when a package undergoes a major internal re-write I'm wary of the first release of the new codebase for the same reason. But the version number doesn't play into that at all. Call it 1.0 or 6.73, it's still the first released version and I'll still be wary until I see some real-world evidence of whether it's good or flaky.
Of course, version numbering does affect my decision in another way. If a company's straight-forward in their versioning, keeping minor revisions containing only bug-fixes and minor enhancements, incrementing the major version number when they make major internal changes that might affect stability, major API changes and the like, then I tend to trust their releases because they're giving me a clear indication what I can expect. OTOH, if they obfuscate the version numbering to try and deceive me into thinking the release is something it isn't, I immediately start to distrust everything about their software. If they're deceptive in one place, they'll be deceptive in others and I've got enough headaches to deal with already thankyouverymuch.
Bingo. 99.8% of game buyers don't care about DRM, but that 0.2% that do care tend to be the hard-core gamers. And 75% of the 99.8% ask their hard-core gamer friends for recommendations on new consoles and new games to buy. When what they hear is "Skip the EA games, they're just a nightmare to work with. Go get this other game instead, you'll like it just as much and it'll give you fewer headaches.", well, sales for EA will tend to sort of suck.
What I've found is there's two sets of best practices, depending on the type of driving.
1. Highway driving, dominated by long periods of cruising. With modern aerodynamics, air resistance isn't usually a problem for passenger cars at posted speed limits (up to 75mph). SUVs and trucks have issues, but if you're interested in fuel economy changing to something else is the single biggest fuel savings you can get. Fuel consumption then's determined by two things: how efficiently your engine's turning fuel into power, and how many RPMs it's making. The first you can find by looking at a graph of your engine's power band (power produced vs. RPM). It's a plateau with a drop-off at either end. You want to stay in the plateau region, if you let the RPMs drop too far or climb too high your engine's burning more fuel than it needs to to generate power to keep you moving. The second's mostly determined by what gear you're in. So you want to maintain the speed that keeps you at the low end of the power band in the highest gear you have available. Any slower than that and you need more throttle (and more fuel burned) to maintain speed, or you have to drop into a lower gear and increase your RPMs (which means burning more fuel).
2. City driving, dominated by acceleration from stops. Speed has a small effect, but the biggest fuel burn you have is accelerating away from a stop light. So adjust your speed to match the interval between lights as closely as possible. If you find lights going green just after you've stopped, slow down a bit. And if you find them going red before you get there, speed up. Going faster may burn more fuel, but starting from a dead stop burns much more so you save by avoiding the stop. And don't lolly-gag on the acceleration. You don't want to peel out, but you want to get up to speed fairly quickly so you spend the least time in lower gears. Remember, the lower the gear the higher the RPMs at a given speed and the more fuel you're burning. Plus, getting up to speed smartly makes it easier to judge the speed you need to maintain to hit the next light while it's green. Spend too much time accelerating and you'll either have to hit a much higher speed or you'll miss the next green, have to stop, and burn all that fuel accelerating again.
Except that DNSSEC is DNS. Period. It isn't compatible with DNS, it is DNS. It simply adds some additional records that aren't normally present that a DNS server or resolver can, if configured to, use to verify that the responses come from a valid server. It's not difficult to deploy, all current DNS servers already implement it so it's already deployed. What's difficult is the process of generating the signature chains, since the validity of the signatures at any level depends on the signature chain back to the root be intact and valid. So, if I have silverglass.org signed, the com and root domains also needs to use DNSSEC and sign their records before the DNSSEC records on silverglass.org can be verified.
Note that the signature chain's the critical part. The first question that needs answered, before you can validate any response, is "What's the correct, valid key I should verify this domain's records with?". Fail to solve the problem of answering that question securely, and the system's not secure regardless of anything else it may try to do.
Decide what you consider "private". I'm not worried about things like my name, address and phone number appearing on FaceBook. I'm in the phone book, anybody who can read and has any interest can find them trivially. Given that, merely having a FaceBook account isn't a privacy problem. What's problematic is the tracking the various FaceBook gadgets can do even when you're not on FaceBook. Some configuration of my browser eliminates that problem (as long as I remember to keep FaceBook in it's own browser session so it can't see anything from my non-FaceBook browsing). Detailed information on my social life? I simply don't post that on FaceBook. I've other places to put that kind of stuff, places that give me more control over who sees it. Photos? That's a decades-old problem, and I deal with it on FaceBook with the same rule I've used since college: if it's something I wouldn't want widely published, I make sure either I get control of all prints and the negatives or I don't allow the photo to include me.
And finally, I keep track of what my friends are doing. If they're in the habit of making things about me public that I've asked them not to, I reconsider just how good of a friend they are. I'm a grown adult, I'm fully capable of making friends with people with a modicum of discretion.
Firstly, I'd have heartburn with the whole non-compete portion. You got this offer due to your work on this project. Likely you'll get future offers based on your familiarity with this project and ability to do things with it. They're asking you to foreclose on all those opportunities, throw them away before you even get them. I wouldn't do that unless I was truly desperate for money to pay the bills, or unless they were willing to compensate me for the expected value of all those no-longer-possible opportunities. In short, I'd be wanting compensation not just for the work they want me to do but for the impact of their demands on my entire career for the rest of my life. I think that's only fair.
Secondly, they sound like they don't quite grasp the licenses, and that would worry me. Once code's been released under a license, it can't be taken back. They can take ownership of what you wrote if you give it to them and then going forward refuse to release it under the BSD license anymore, but they can't unlicense those copies already out there nor prevent people from doing what the license permits with what they've already got. If they think they can, they're either in for a nasty shock when their lawyers enlighten them or they intend to play dirty and try and knock down the whole project so they can have sole possession of it. Either way, I wouldn't want to be connected to the mess that's going to result. Again, the backlash is going to have negative impacts on your future career, and I'd be wanting compensation from them for that. And we're not talking just about the time you're working for them, we're talking about the whole rest of your career here.
Personally I'd be willing to do proprietary work for them, but I wouldn't grant them ownership of anything except what I'd written specifically for them, I wouldn't agree to an open-ended ban on future work and I wouldn't agree to an extended non-disclosure period without them compensating me for the entirety of that period.
The CAPTCHA-crackers aren't using software. The most common methods are to either hire a large number of humans in low-wage countries to solve the CAPTCHAs, or to present CAPTCHAs from sites needing them cracked on the registration pages of created-for-the-purpose porn sites and let unwitting visitors solve them. Which means that CAPTCHAs are fundamentally broken. We no longer need something that can distinguish a computer from a human, we need something that can distinguish a legitimate human from a spammer-aiding human. That's a much harder problem.
Personally I favor requiring registration combined with an easy, anonymous registration process with out-of-band verification. We don't need any absolute identity of the registrant, what we need is to make it non-trivial to obtain a different identity for the same person. So, take the case where the registrant/poster has a cel phone. The person when registering gives a cel-phone number that the site will send a text message to containing a verification code. Registration is complete only when the person enters the verification code. If the cel-phone number has been used to register previously (I wouldn't have the system store the phone numbers, a cryptographic hash of the number will suffice), the site will force the registration to go through a more elaborate process. You can quickly get registered on the site under any identity you want, but you can't readily get multiple identities on the same site without talking to a human (which spammers will be reluctant to do, and which won't happen fast enough for their purposes anyway).
My basic formula for swap space is: worst-case memory usage that I don't want the system to fail under, minus the amount of system RAM I have, rounded up to the nearest even amount (I usually make it an even multiple of 16M or an even number of gigabytes). My minimum for swap space is the amount of system RAM, to allow for things like hibernation, but that's a personal preference. I don't like running without swap simply because there's no overflow, no buffer for the occasional nasty memory hog. And a lot of the time it's useful to have somewhere to put idle program address space, freeing up system RAM for I/O buffer cache. I've a number of programs that really only become active in the wee hours of the morning, and I'm willing to let them take a moment to swap in when I'm not around to get the better performance during working hours that comes from having the memory they'd otherwise be occupying available for buffers and cache.
And, on today's systems with 250+G hard drives, 2-4G for swap is almost negligible.
My solution's what it's been for the last 15 years. I own a domain, and have it hosted with a reputable provider (my old ISP, in fact, as part of my basic web-hosting package). I run a local-only SMTP server (incoming from the LAN and localhost only, outgoing via SMTP/AUTH/SSL to my provider's relay server) and an IMAP server on my own machines, along with an SSH server. I'm dependent on my provider for the physical servers, but I can move those servers to any other provider as quickly as I can get service arranged if I need to. My mail transfer system's configured to keep copies on both my provider (who also provides IMAP/SSL access to my server-side mailboxes) and on my home machines. I can access either set, provider or home, via either IMAP/SSL or by SSHing in and running local mail clients (including graphical ones) remotely. Any machine may fail, but as long as both sides don't fail simultaneously I can recover without loss. My provider takes care of the bulk of the spam-filtering (one reason I've stayed with them even though they cost more than some alternatives), and my own filtering (mainly bogofilter) takes care of the little that gets through. It took a couple days' work to set all this up, but I figure 2 days' investment for 15 years of trouble-free running is a pretty good ROI.
Buy a domain. Set up e-mail hosting with a reputable provider (usually a good web-hosting place will provide e-mail as part of the web-site deal). Set up your local mail system to route outgoing mail through your provider's mail servers. This is how I do it with mine (my e-mail and web-hosting are provided by my old ISP). I can change ISPs without affecting my e-mail at all. I can, if I want, move my e-mail service anywhere I want without affecting my e-mail addresses (they continue to go to my domain, regardless of where the servers are physically hosted). With my provider offering SMTP relay service via authenticated/encrypted connections, I can send e-mail from anywhere I can configure the e-mail client with my provider's information regardless of the state of the local mail system. And it's time-proven, setups like this have been used for the last, oh, 25 years or so in one form or another.
GMail supports POP3. But by the time you've set things up to be able to use it to usefully back up your mail, you've gotten a complete remotely-accessible mail solution in place that doesn't need GMail at all.
It's not having your data stored on the Internet, it's the cloud-computing idea of only having your data stored on the Internet. GMail's a good example. Where other than out at Google are your e-mail messages stored? How do you propose to get at your e-mail if GMail isn't available? Note that it doesn't matter why GMail's unavailable, it could be because you're at a place that doesn't have Internet, because the network links are down because of a disaster, or because Google's gone out of business without warning, unavailable is unavailable. Having your mail on GMail in addition to being stored locally is fine, but GMail doesn't support acting as a backup to a standard mail client and their normal Web interface doesn't provide an easy way to make a local backup of your mailboxes or save new messages locally as you send them.
And if the idea of GMail going away sounds improbable, remember how improbable it was just a month ago that all the major Wall Street investment banks, the backbone of the US financial system for better than half a century, would all be either in bankruptcy or out of the investment-banking business in literally a matter of a week or so.