yeah I've thought about that, both ssh tunnelling to/from home from some hosted machine (e.g. AWS, or Linode, etc). The problem (from my point of view) is that the hosted machine is in someone else's "house". Even if it is a co-lo.... it is still sitting in someone else's house.
Thanks for the suggestion though. It gets part-way there
The input space is too small for SHA1 to effectively anonymize. The NANP, for example, has less than 10^9 possible numbers; it would be a very simple task to create a rainbow table mapping every possible phone number to its corresponding SHA1 hash.
For the same reason, you can't just use a simple cryptographic hash to "anonymize" data such as birthdates, zip codes, SSNs, or PINs.
Using a key derivation function with a very high cost factor can mitigate this to some extent (e.g. making it take 5 seconds on an average CPU to generate the hash from a phone number), but it by no means makes for secure anonymization; eventually computing power will catch up.
Encrypting the number with a secret key (or using an HMAC), and destroying the key after the anonymization takes place might be a reasonably secure way of doing this, however.
Yes. Definitely pre-sell. Not only does this fund your development efforts, it is the ultimate validation that you have actually come up with a product that people want to buy. There's a big difference between people saying they would buy something--and actually pulling out a credit card.
Offer your "charter members" 10% or 20% off for life in exchange for a 3 or 6 month prepay. Reverse the risk by guaranteeing their money back if they don't love it.
If you can't get clients to pre-pay, then your offer is not compelling enough.
Customers paying late is a fact of life, and from time to time you'll need to be persistent and/or agressive about collections.
Get in touch with your contact at the client company and let them know you haven't been paid for your work yet. Ask for a contact in their Accounts Payable department. Follow up with that person and make sure that your invoice got entered into their system. Make it clear to them that they're past due, and unless you receive payment on the next banking day that you will begin assessing the late fee you stipulated in your contract (you did stipulate a late fee, right?)
If you're dealing with quality clients, they'll almost never just try to stiff you on the payment; instead, it's because their accounting processes are completely disorganized (sometimes intentionally!). If your client isn't a large, trustworthy, stable company, always get your payment up-front. Even if they are a big company you trust, get an advance; it'll help tide you over while you're waiting for them to pay your net-15 invoice... net-90.
After consulting for more than four years, my past-due receivables balance (which at one point exceeded $200,000!) finally went to down to $0 only last week. And that's because I stopped taking on new work.
I've had customers who were nearly 90 days behind on payment (I used to be really bad / lazy about collections) and required almost a dozen followup emails and calls to get things straightened out. As far as I can tell, it was never out of outright malice, just the general disorganization and reluctance to part with cash that you find at big companies.
Don't take any aggressive / adversarial actions until you've exhausted all the polite request options. Give them the benefit of a doubt (unless your contact is already the person who writes the checks, and has no excuse). Be polite, firm, and extremely persistent. Get a commitment that you will be paid before date X, and if you haven't been paid in full by then, assess your late fee and start calling / emailing on alternate days until you do get paid, or until your patience is exhausted. Get lawyers involved only as a last resort. And next time, get paid in advance. :)
The file traversal vulnerability allows an attacker to access unauthorized files outside of the document root, assuming that there exists a symlink from inside the document root to a path that is outside of it.
An attacker could request /foo/../really_secret, which the OS would interpret as /secret/path/really_secret and happily serve up.
The attacker is limited in the number of ".." components they can add to the path by the number of real path components that precede it, i.e. they still cannot do /foo/../../../etc/passwd
The fixed version of rack correctly removes ".." path components before passing the resulting path to the OS, i.e. "/foo/../really_secret" is translated to "/really_secret", and results in a 404 error instead of a security breach.
This vulnerability is particularly concerning for Rails apps deployed using Capistrano (unless config.serve_static_assets = false). This is because there are typically symlinks from public/assets and public/system to the corresponding directories under the Capistrano deploy's "shared" directory, and also under "shared" are typically things like logs, configuration, and a copy of the application code!
Fortunately, Rails ships by default with a production configuration that sets serve_static_assets to false, relying on the frontend web server to serve up all static content (so the attacker will just get a 404). This directory traversal bug is not present in current versions of Apache or nginx.