There has to be proof that such devices CAN'T harm a plane's avionics. Once that is done, we'll be able to play with our toys.
You are allowed to bring them on board. That's all the proof you need.
Anybody who put those on their application forms these days is just asking to be sued.
It's stupid also: age can be deduced from the resume. Someone who finished high school in 1995 like me is not going to be 18 nor 60.
The real question is: if Mars once had Earth-like conditions, is there a risk Earth will end up with Mars-like conditions in the foreseeable future?
If you aren't currently in college, you have to buy a mobile phone that can receive texts in order to verify your account.
If you have a computer or regular access to one and an interest in Facebook, chances are you also already have a cell phone or could easily get a lousy prepaid for a tenner. There are plenty of concerns one can have with Facebook, but this really is not one of them.
It's been over twenty years since the inception of Linux. With 20/20 hindsight, what you have done differently if you had had today's knowledge and experience back in the early days?
Around 12 years of Slackware. Then moved to Ubuntu LTS for VPSes and Mint for the laptop about 3 years ago.
First, you don't know how much google's passwords accept. You know that they don't tell you it's only 16, and it may be 17, but it probably isn't 10'000. So where's your line? Is 17 enough? What about 32? How about six megs?
Six megs should be enough to break to most web server configurations for the maximum HTTP POST size.
Whenever I see any website that rejects passwords longer than X characters, I turn away and go somewhere else.
Allow me to nitpick: all websites do for sufficient values of X. Most browsers have a built-in maximum for the length of input fields (32-bit unsigned int for Webkit, 65535 characters) and most webservers have a maximum size configured for HTTP POST requests.
The question that should be asked is, "What's a 'Special Character' and why shouldn't it be allowed in a password?"
I had this argument with a developer the other day.
Any character that cannot be hashes or escaped before sending it to the storage backend. (Which, agreed, on a modern platform are none.)
When I started web programming in 1995 some sites had little more than CSV files for storing data. Input filtering then suddenly makes a lot of sense, especially because handy utility methods for hashing and escaping weren't as widely available in all languages as they are now. Any developer still opting for such requirements is obviously an old-timer who hasn't updated his or her skills, or was trained by one.
Does this mean they were storing the passwords in cleartext? In a real system they would simply be storing the hashes, shortening the password would cause it to create a different hash and not match.
Not necessarily. The UNIX crypt(3) algorithm uses only the first 8 characters of any password. Given Hotmail's age I'm sure something similar is going on here. Not every website was developed in an era of HMAC-SHA-512 with proper salt and pepper flavouring.
It would however be possible for them to upgrade passwords upon login (in which case the unhashed match would be available from input), but for a system the size of Hotmail it would take forever before the legacy support could be deprecated.
You didn't get yours in 1997. That is 15 years ago.
Apple is definitely not the cheapest option, but neither are the high-end and competing Android devices. The point is not that the top of the line items don't sell, it is that the budget options have become insanely cheap in the Big Mac index.
HTC lets you do this already by flipping your phone. Both are just a motion sensor output value linked to operating state.
When I asked about the differences a few months ago, the Vodafone customer service told me: "The information on your Vodafone account online is the real usage. Numbers from data usage apps are not reliable." But I highly doubt that I used 36 MB over the last day of the month, so it seems that within Vodafone they have different systems.
Most likely the numbers in their on-line usage monitor are not truly up-to-date. The Vodafone website here in the Netherlands is not always the best example of engineering.
I have been toying with a site idea. Your account name is your public key fingerprint. You public nicname is whatever you use in the message. Your login is validated because everything you send is signed wiht the key that matches the fingerprint (and encrypted with my public key for transmision). Input to user form is constrained and validated within those constraints (to prevent padding attacks).
I would then have a database "key x","paid through date y".
Sure, I couldn't sell any farmed data a-la facebook, but suppoena requests woudl be a breze... "here's your hex dump..."
If you accept payments, wouldn't those keys still be linked to contact information and/or payment transactions?
Lots of folks confuse bad management with destiny. -- Frank Hubbard
