Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×

Comment Re:" why T-Mobile finds it profitable" (Score 3, Informative) 482

It's not just the dumb 2-year contract scam. We're also being fleeced for voice contracts, on both our land-line and mobile, because the phone companies prefer to continue charging a 1970's service charge for something that modern networks deliver practically for free. T-Mobile doesn't need 850MHz spectrum. They need free VoIP over WiFi whenever you're indoors at work, home, or a friend's house.

Fortunately, there's a new kid on the block, Republic Wireless, who is doing contract-free ultra-cheap service. By offloading traffic to your own home wifi, RW can in theory make money $25/mo for Sprint 3G "unlimited" service. That's the plan I have, and I have the $10 plan for my kids. Verizon 4G LTE was great (my previous phone was a Verizon/Google Galaxy Nexus), but for the $60/month savings on just one phone, I'll live with Sprint. Also, they've got the Moto-X for $300, contract free, and it's hands down the best phone I've had. Time will tell if sane service providers have a chance in this country.

Comment Re:Many methods to speed reading (Score 1) 92

Very cool! Thanks for the abstract and the tip for how to track down research. The abstract sounds about right to me. It's kids with reading difficulty that may benefit the most from combining listening and reading, with adjustable speed. I find that kids seem to have a different difficulties in early reading, and if it is too difficult, they wont start reading chapter books, and it is difficult for them to naturally ramp up their reading speed. Some audio help at that stage might help a lot.

Comment Re:Many methods to speed reading (Score 1) 92

I'm honestly not actually sure why your idea *would* increase reading speed.

It's very simple. As you suggest, the bottleneck is in the brain's ability to process the information rapidly, not in eye movement, for most readers. Therefore, whether you learn to speed "read" with audio or text, doesn't really matter. It's the back-end processing that needs improvement in both cases, and it's the same back-end. Improving one will improve the other.

Comment Re:Many methods to speed reading (Score 2) 92

I had a very similar idea, and it will work. Really. By the way, the poster above, Bysmuth, is dead wrong, labs and all. Feel free to contact me (Bill Cox - waywardgeek@gmail.com) if you need me as a reference to support this idea.

One of my contributions to open source and the blind community has been improving speech speedup algorithms. I listen at > 600 wpm, and have a blind friend who listens at double that. As part of this, I've done numerous A/B tests on many subjects (friends, family and acquaintances), trying to figure out what works for them. Here's what I found. First, anyone who is already a high speed reader also very rapidly becomes able to listen at high speed. This is 100% correlated, after maybe 100-ish tests. I found no counter examples, and the strength of listening speed ability increases with the subject's reading speed. While some speed readers do not hear a voice while reading, it must still using the speech centers in their brain, because high speed readers are already prepared for speed listening, whether they claim to vocalise or not. There are other contributing factors, most notably age. I am the only non-blind person I know who learned to be comfortable speed-listening after the age of 40, though I do have a strong central vision loss issue. Every test I did on with anyone over 40 backed up the fact that speed readers are also naturally speed listeners, but the > 40 crowd is almost violently opposed to speed listening, while the under 40 crowd thinks it's cool. I know... that's such an objective scientific observation :-)

Also, I found that non-blind listeners who force themselves to learn to speed listen (including me), discover that their regular reading speed increases naturally. People can argue all day long about vocalisation being good/bad while reading, but the fact is that the same centers in the brain are used regardless. If you train to listen fast, your reading speed will increase, and vise-versa. This is the single most obvious conclusion I have been able to draw. It's a very real effect.

Another interesting point is that young people will, given a chance, naturally turn up the audio speed over time while listening to good books, very much like we see kids reading faster as they read a good series.

Reading a story both visually and audibly in parallel should enable a reader (whether mostly using their eyes or ears) to focus on the story the way that is more natural for him, and as he goes faster over time, his regular reading speed will increase, regardless of his preference for audio or printed text.

Comment Re:Commodore Amiga 3000T (Score 1) 702

I solved my cellphone battery life problem with a Moto-X from Republic Wireless. Republic still has a few growing pains to get past, but for big geeks who don't mind putting their phone in airplane mode and enabling wifi once or twice a day, it's amazing. In that mode, I go for days without having to charge it, though my phone is only a few feet from the wireless router most of the time. For $25/month for "unlimited" Sprint 3G everything but tethering, it's hard to beat.

Comment Re:To Crypt or Not To Crypt (Score 1) 171

I'm always amazed at how hard something as simple as password hashing can be. Yes, it's the user's fault for reusing passwords, but we should try and protect him anyway, because it's very common. Part of the job of the computer security industry is protecting stupid people. Improving this is situation one reason for the Password Hashing Competition.

You are right that password strengthening before encryption is a different problem from user authentication, but the solutions tend to be the same. You can use Bcrypt or Scrypt for strengthening a password hash on an authentication server just like you can while deriving a volume decryption key. The main difference seems to be that a common server may not have a significant fraction of a second to spend on authenticating a user/password combo. TC has some additional constraints, like the volume needs to appear as random data, making it harder to embed various encryption parameters, such as which key stretching algorithm is in use. To an attacker, he doesn't care whether the password/salt is protecting a login account or an encrypted volume. To him, it's just so many rounds of PBKDF2 (or whatever), and then a quick check to see if he got the right answer, and do as many in parallel as possible. Salt is used either way to defeat rainbow tables, so instead attackers use GPU farms to do massively parallel brute force guessing, where each guess is user/salt specific.

However, the two cases I've mentioned are both encryption: TC encrypted volumes, and OpenSSh id_rsa private keys. We could argue about how much effort a server should put into protecting it's user's passwords, but both TC and OpenSSh do *nothing* more than a typical server, devoting only a millisecond to key stretching. That's just lame.

Comment Re:To Crypt or Not To Crypt (Score 1) 171

I just added a keyfile as you suggested. I put it on a couple of USB keys, so I have a backup, and now in theory my encrypted volume can't be mounted without having the physical key. That should greatly increase my passphrase protection, as well as the volume contents (basically a list of all my various user/password credentials at various sites). I'm still running TC in Windows, and several times I've answered "yes" to let various programs make changes to my hard disk, and my machine probably comes with back-doors from both Lenovo and Microsoft and maybe even Intel. I don't trust our company's closed-source VPN provider, either. So, I still don't feel secure, but at least it's an improvement. Thanks for the tip.

Comment Re:To Crypt or Not To Crypt (Score 2) 171

I don't do this for a living, but I'm not totally ignorant about this topic. TrueCrypt does a poor job strengthening passwords. TC's users would be far better protected if TC ran something even as lame as PBKDF2 for a full second, with rounds somewhere in the 100's of thousands or millions. Not only does TC do a poor job protecting my data, but when an attacker does manage to guess a user's low-entropy password, he can then try that password all over the place to see where else the user has used it. This is why I say that the user's password is at risk due to TC, not just the data TC encrypts.

To give TC some credit, OpenSSL has the same lame password strengthening as TC, putting id_rsa passphrases at risk, in addition to the user's private key. So, there seems to be plenty of lameness to go around. I hear that a Bcrypt option is in the bleeding edge version of OpenSSL. I which they'd push out that patch along with the Heartbleed fix.

Comment Re:To Crypt or Not To Crypt (Score 2) 171

I use TrueCrypt. Not that it likely matters given all the other back-doors on my Lenovo Wintel laptop, but I use a passphrase from Hell, and I suspect even the NSA's biggest cracker would have trouble with it.

Other than the backdoors in various places on this toxic waste dump of security, the biggest security threat to my passphrase from Hell is TrueCrypt itself. TrueCrypt by default does 100% useless password strengthening (key stretching or whatever it's called). It's strongest mode, which you have to select manually, is 2000 rounds of SHA-256. I can buy SHA256 boxes that do 1 Giga-hash/second per $10. Figure a government has a few million at least for such boxes, and go compute how strong your password needs to be, and it isn't pretty.

I use my password and TrueCrypt to protect my data. Why didn't it occur to the TrueCrypt authors to protect my password? I mean, Bcrypt at least, come on...

Slashdot Top Deals

To the systems programmer, users and applications serve only to provide a test load.

Working...