nstr10

I would be curious to see this compared with SHA-384, and across multiple languages.

I feel like that's because XSLT introduced so much complexity that mere humans found it impossible to work with. I've searched in vain for a decent XSLT editor to help me; the ones I've tried have themselves been incredibly complex. The idea was good, but the implementation is the stuff of nightmares.

I was all excited to make my first multi-billion dollar acquisition when suddenly a project showed profits of $NaN, an error that cascaded through the interface, eventually turning nearly all values to NaN. The board became very upset about our profits of $NaN.

Apparently our friends at Mozcolonslashslasha don't realize how many more important things they could be working on than this.

+1 for security theater. If 1Pass app is compromised, you're compromised - period. Even with app permissions, does it not still have file system access? I don't see how this change would prevent it from accessing all your Dropbox files anyway. Also, since Dropbox uses an exploit to gain permissions, I'd say we're placing blame in entirely the wrong place here. On the other hand, the 1Pass folks in that thread are giving all the wrong reasons. "We won't do this because it's hard," is very different from, "we won't do this because it offers no benefit in any scenario." Users who are security conscious aren't using Dropbox to sync their password vaults.

Rewards should always be in accordance with made-up words IMHO.