bmastenbrook

My experience being on the reviewer side of the process is very limited. As a frequent reader of papers in CS I'm of the opinion that peer review is accomplishing very little outside of checking theoretical results with proofs that can be vetted. I can count on one hand the number of papers I've read in the past month or two describing an implementation of a technique where the implementation described was available publicly. In all other cases, I had to take the authors' words for it. Given the poor handling of data for publication I've seen in the past, I'm not especially inclined to do that.

I also don't believe that the current conference / journal system for publication of results works especially well. There's a well-documented bias against the publication of negative results. It encourages authors to "save up" interesting work for publication when pieces of it could have been independently examined much sooner. In combination with "publish or perish" metrics, it discourages valuable or interesting work that might not ever rise to the level of a full journal publication. The format is incredibly stifling; important information is left out to satisfy page limits, code mangled to fit within columns, and interesting data visualizations not even considered because of the constraints of the media.

I think it's inevitable that the current common publication system will be recognized as a relic of the paper era, but I fear that any fix will only make superficial changes to the system. I think it'd be much more useful to have a publication system that allows work to be published with full data in a format that allows evolution in response to open reviews. This obviously wouldn't work well in areas where protection of patient privacy requires data obfuscation; I don't have a good answer for that. In all other areas, especially where the research is funded by public money, full data and code transparency ought to be key, especially where raw data must be adjusted or normalized in order to be useful and in situations where bugs in modeling programs could subtly affect results.

Edit: see also this excellent article from last month's Atlantic: http://www.theatlantic.com/magazine/print/2010/11/lies-damne...

Using a password manager is a great idea in theory. In practice, I have the same problems with the concept as many other people do. It's great if you have, say, a MacBook, a Windows system, and an iPad that you want to keep synced. When you have one of everything, your options are narrowed drastically. Many of these solutions also either punt on synchronization and rely on me to find an option I like to handle that problem, or they use some kind of cloud service not under my control. I don't need or want that cloud service. I don't care how well the file itself is protected; you can't attack what you don't have.

What I do have access to from most of those systems is SSH to a machine I control. I'd be willing to run a password manager on that system, but I haven't yet found one I'm willing to install. I'm not going to put Qt and X11 on the system just to run KeePassX. I'm tempted to write my own at this point. It'd at least solve the password management problem in way that I'm comfortable with (i.e. any problems in the solution are my own fault and if I get owned, I'm the only one to blame) and without having to send a copy of the encrypted database out to the cloud (except in tarsnap backups, but I'm already trusting cperciva with the keys to the kingdom there!).

I don't think it's just about hashing. When I see restrictions on passwords or other fields, I always assume the worst. If < is not allowed, that's because your password will show up unencoded in HTML somewhere. If $ is not allowed, that's because somebody is afraid that it will actually be treated as a variable reference somewhere. Likewise & or % in URL-encoded data, ' or " in JavaScript, etc.

The most universal and silent restriction seems to be on NUL bytes.

In order to solve this problem for myself I looked into SuperGenPass as well, and reimplemented it in Racket so I could understand what it's doing. Here are a few notes on that:

• It's based on MD5.

• It repeats the hash 10 times. Typical key strengthening functions will do at least 1000 iterations, and at least 10000 seems to be becoming more common.

• Each time it repeats the hash, the output is encoded with a variant of Base64.

• The implementation of Base64 is deliberately nonstandard. + and / are replaced with 9 and 8 in the output (respectively). It pads with A, not =. The point is presumably to avoid generating special characters that could be disallowed by some password systems. This actually seems like an unintentional benefit to me: while it theoretically increases the probability of a collision, it does make it slightly more difficult to recover the original passphrase from the hash, or so it seems to me. (Any cryptographers want to comment on this one?)

• Hashing is repeated until it generates a password that starts with a lowercase letter and contains at least one uppercase letter and at least one number. The first restriction must come from some actual site, but it hardly seems common enough to enforce.

The biggest risk is in a site fishing your master password, though their "mobile" version allows you to run it in a different window. All in all, I think the concept has promise, but the implementation could be significantly improved.

You left out the bit where it was his company that he claimed added the alleged backdoors. If he's as untrustworthy as you've hinted at, I expect that those with authoritative knowledge will speak to that soon enough, but it seems like it will take more than just evidence of past lying to put this one to rest. Even liars tell truths.

I'm disinclined to trust Gnosis' word for it, but they say they don't have access anymore: http://www.mediaite.com/online/exclusive-gawker-hacker-gnosi...

If the servers are still compromised, I don't think they'd have stopped with a dump full of hashes and a few posts on Gawker. My guess is that the intrusion was discovered while they were doing the dump, which is why it's incomplete.

I can't see how it's unethical, unless even looking at the data is unethical, and you'll have to convince me of that. I'd be more concerned about the ramifications than the ethics. The least bad thing that could happen here is winding up on some big ISP's blacklist because enough of their users marked this unsolicited mail as spam. Once that happens, good luck communicating with your customers.

I'm sure you can imagine the worst that could happen. Courtrooms are not happy fun places.

There's no need to assume when authoritative information is but a few keystrokes away. And yes, it is under the GPL v2 + Classpath exception, except for Java ME which is under straight GPL v2.

You can't write a good JIT overnight. You can't adapt an existing JIT for a JVM-like VM to Dalvik either. I don't think working around patents had much to do with it, especially since they got sued anyway.

Nope, it's definitely the EDGE icon: http://picasaweb.google.com/sergenthalo/Gentouch78#549871101...

They're shipping the Market on the device, but it doesn't meet the conditions for access to the Market. While the Android device compatibility requirements for 2.1 allow devices without cellular connectivity, they still require a 2.0MP camera, Bluetooth, 3-axis accelerometer, and compass. This device doesn't seem to have any of those. As such Google won't license the use of the Android name for this device. Even once you meet the requirements you aren't automatically allowed to ship the Market; you have to sign a separate business agreement with Google. See http://source.android.com/compatibility/overview.html for the complete requirements to be able to use the Android trademark.

The device identifies itself as being an evaluation board for the Telechips TCC8900 SoC. They stubbed out the cell radio code with the same stub that's used by the platform simulator. As a result, the device shows that it has an active EDGE connection all the time.

http://picasaweb.google.com/sergenthalo/Gentouch78#549871111... http://picasaweb.google.com/sergenthalo/Gentouch78#549871101...

The hardware is a rebranded version of the Dawa D7 tablet:

http://www.androidpads.com/2010/06/01/dawa-d7-android-a-7-in...

Note that it actually has a 600MHz processor, though Augen claims 800MHz. That's probably because they added the on-chip 200MHz DSP to the 600MHz ARM11. Processors work like that, right? http://www.droid-life.com/2010/07/27/augen-gentouch-android-... (Scroll down to the comments.)

The videos I've seen show a Documents To Go Full Version key preloaded on the device. I'd be shocked if that was actually being paid for.

The principals of Augen Electronics (incorporated in 2005) started another business in 2006. The name of that business? Amway World Distributors Corp.

http://www.corporationwiki.com/Florida/Hollywood/augen-elect... http://www.corporationwiki.com/Florida/Dania/amway-world-dis...

You can draw your own conclusions from this.

The hardware itself seems to be cheap but serviceable from early reports. If I was an enterprising Android hacker, I'd be tempted to pick one up and put together a better designed Android-derived image that used only the open platform bits. Then I'd contact the company that actually made the tablet about getting some made with that ROM preloaded.

I think my point was a lot more nuanced than you give it credit for.