It's true that historically "he" has often been used a generic pronoun, but singular "they" also has a long history. I'd start with this Wikipedia article:
> Proponents of gender-neutral language argue that the use of gender-specific language often implies male superiority or reflects an unequal state of society. According to The Handbook of English Linguistics, generic masculine pronouns and gender-specific job titles are instances "where English linguistic convention has historically treated men as prototypical of the human species." Words that refer to women often devolve in meaning, frequently taking on sexual overtones.
> These differences in usage are criticized on two grounds: one, that they reflect a biased state of society, and two, that they help to uphold that state. Studies of children, for instance, indicate that the words children hear affect their perceptions of the gender-appropriateness of certain careers. Other research has demonstrated that men and women apply for jobs in more equal proportions when gender-neutral language is used in the advertisement, as opposed to the generic he or man.
Many years ago, I would have agreed with you that using "he" as neuter was correct and therefore preferable to singular "they". I no longer feel that way. I'd attribute that change in opinion to two causes:
One, I'm less concerned with by-the-book "correctness" and pedantry, and more concerned with the real-world effect my words have on people.
Two, I now realize that English is a living, evolving language, and there is no one authority on what is or is not correct usage. What is widely held to be proper English at a given time is a product of who happened to have influence in society at that time, no more, no less.
Also, although this is not what changed my opinion, I find it interesting to note that many of the same people who call the matter trivial will also expend considerable time and effort defending generic "he". If you find it so trivial, why not humor the people who think gender-neutral language is important?
Thanks for your comment and for the information. I definitely agree with your point that the singular "they" is, at this point in time, as correct or more correct than the neuter "he".
I also totally agree with your point about humoring people who actually care passionately about this — that's precisely my issue with this whole debacle. I wasn't taking the position that "he" is the only correct option, and other phrasings must be attacked. Rather, that the entire matter is a bikeshed, and that people should not assume that just because someone used "he" as neuter that he (see what I did there?) is sexist.
> we are creating a client-side, in-browser encryption system where a user can upload their already encrypted content to our storage system and be 100% confident that their data can never be decrypted by anyone but them.
This concept may sound clever at first but gives you as the user no additional confidence compared to encrypting data on the server side upon arrival. Either way, you're trusting the host.
The threat model for server-side encryption is essentially:
1) the host has an unethical employee who wants to read your content.
2) the host's servers are insecure and get compromised.
3) someone successfully MITMs your connection to the host (possibly due to the SSL problems being discussed here).
4) the government compels the host to provide your data (i.e. what happened with Lavabit).
The threat model for browser-based client-side encryption is the same! In any of these cases, the attacker (or the host, in case of #1 or #4) simply sends JavaScript encryption code to your browser with a backdoor in it.
Cryptocat originally worked the same way: all chats were encrypted on the client side, but with JS code sent from the server, in which a backdoor could be inserted at any time. After much criticism, this is why Cryptocat is now a browser add-on, with discrete releases made available from a central source (Chrome Store/Mozilla addons site), which can be audited.
We'll be releasing tools, like a browser-extension, that will help confirm that the code you've received on the site is the same as that in the repository.
And since the whole frontend is open-source and is only html/js/css, you can host it on your own box if necessary.
To address your points 1 and 4: Since all data is encrypted BEFORE leaving your browser (this was NOT the case with lavabit) even if our servers were compromised your data would still be secure.
That doesn't solve the problem. No one is going to manually view source and compare it every time they use the damn thing.
> To address your points 1 and 4: Since all data is encrypted BEFORE leaving your browser (this was NOT the case with lavabit) even if our servers were compromised your data would still be secure.
At rest. Yes, at rest it's fine, like I said, but if someone logs in while the server is compromised, it would be trivial to decrypt anything they post or access during that session. Same as Lavabit.
> We'll be releasing [..] a browser-extension, that will help confirm that the code you've received on the site is the same as that in the repository.
So it'll download two copies of the code, one from your servers and one from GitHub, and check that they match? Doesn't seem to me that that buys you much. And unless it's mandatory, you'll be leaving the users that don't install the extension unprotected.
When you create an account with cryptic.io, a private key is generated in browser and encrypted with the hash of your password. This encrypted private key is what we keep server-side. All files you upload, and all of your user-data, is encrypted using that private key. In short, all encrypting/decrypting of ANY sort happens inside your browser. So someone logging onto the server and viewing data as it is uploaded is still seeing encrypted data. Short of compromising a user's computer there is no way for them to see it. Our encryption scheme is nothing like the scheme that lavabit used.
The extension won't be able to mitigate an attack, but it will be able to alert you to one, which for someone who had the initiative to install it (which we will be heavily encouraging users to do) would be enough to inform them that something is amiss. And if something is amiss they can host the front-end themselves and use a local copy of the html/js/css so they can be sure they're getting a good copy of the site (something we will also be making easy to do).
I have thought about a similar service but was dissuaded by various sources warning against the idea of using javascript with cryptography, e.g. http://www.matasano.com/articles/javascript-cryptography/. That's not to say a reasonable solution cannot be found, but there are a good number of issues that need to be addressed. The one that seems crippling to me is that the strength of javascript crypto libraries is questionable at best - nevermind the various other javscript attack vectors. A browser plugin could address some issues, but then that limits users to browsers with the plugin installed. Might as well have a native application where the quality of the cryptographic algorithms are more thoroughly tested at that point. Still, I like the idea and wish you the best of luck.
You seem to suggest storing their hashed password in the browser, but if they change machines they won't have that hashed password around. How will you go from plaintext password to hashed password without having the salt used with PBKDF2?
You say user passwords are never sent over the wire (not even the hash)[1], but then say users have an object containing their hashed password (is the documentation here out of date?)
The browser extension is the missing link. That's what makes it impossible for malicious code in a frontend's source code to go unnoticed.
I wish you had an example of a custom application that uses your storage, so people can see how easy/hard it is to use and customize the frontend for their own applications. How would the browser plugin properly attest the frontend code hasn't been modified if an application dynamically generates custom frontend code per user?
Having done a few Clojure projects lately, I got most of these right immediately, but there were a few I messed up. It would be cool if you could go through these flashcard-style: one try for each koan in a category, then re-show the ones you got wrong, and repeat until you get them all right.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is a reply to a comment posted by graue on 2013/11/21 at 06:00h GMT.
> Hmm... did this site get served a secret warrant last week? Or did they just forget to update their warrant canary?
> https://mediacru.sh/transparency/warrant-canary.txt
> (Note: the date 08/11 is written European style meaning November 8th, as you can see if you go up a directory.)
Hi, just wanted to let you know that we haven't, in fact, been served a warrant.
The failure to update the canary was due to my own mistake, and I'm terribly sorry about that.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAEBAgAGBQJSjdtLAAoJELJF4ERQRPL8VuMP/j8bqNm/uAMzq1n+ebf90RRq
cDQUsjCbENoR3/1VF4GR0iQhzxDQ28C2Wcc/rjgPjNkL5fLL9QQNb5hUZ38a+ray
r3fBE4ZQZ5XSriq9iOGy2RoXKhwM/1QuJ9qaOOYmJwkc+/Re+1WbAtAbKnBoPkOy
z5xMkSnr7b1jI/sUHHmlU6s5wvchXKKLmniCKjtaLp2WLVv95FoxrzRoNu/gHVv2
LXnjKTllzfcPm9thvCRoikv/N3PKuDBvCIbGm6yhYsNo8a1croAlnChEf0rDWk1B
8IFM5SXcsuVOSymHJ18VVp2s7xGi1RRcTpUyDt/s74kUuLx7Wpd27YWf5Yko8O+m
BWfLXbAUamxwRyCmNN219xnhdAb0paaiddbvQX+PHUMMM2+UwdWSSgWnyloFVhGs
bqZ/vQO6FSP4CVCZvvxyFm493MWSBTvZ2bpWWgdVdIBAg/qSv+D0I6XGyAhUdCqh
5j38U7nMaHFROr+lCISXdtMxUvPBzNFxKV+3ZTxm/L3hWU75pT9XWsJOxejiIdFe
7IMgKpbwsWDUg5Mat5muhn13vBH9B5qfa1smhO1eiP/29XLogLj3B2gZ0nnEIO0q
1o+j/G5crxxhqW01nGBzJq3IaP3+dsCP9Eiwom3cO0EsulZUL9TRsAPjT5IhXJNz
uPzRgvYpICnrL2qqyGfP
=uKWu
-----END PGP SIGNATURE-----
Ack! My other half is responsible for the warrant canary. He keeps forgetting it. We may as well not even have it. It doesn't mean much without a signature, but I assure you that we have never been served a warrant.
As of November 11th, 2013, neither MediaCrush nor its admins have ever received any sort of warrant, or any other kind of notice or request, from the government of any country.
Additionally, we do not store anything about a user who visits our site. Here's an example from the HTTP log:
When you upload a file, your IP address is run though bcrypt (12 rounds) and saved with the file information in redis. Reversing bcrypt is infeasible with modern technology (and probably for many years to come). We store nothing else about you.
I'm going to respond to all of you at once by saying this: bcrypt is the best possible solution that we are aware of. It's infeasible for anyone but the most resourceful adversaries to brute force your hashed IP, and even then it's still expensive.
However, that's part of why we're open source. You can't trust us when we say that we aren't storing your IP. We could be doing it and you'd have no way of being able to tell. If you're concerned about this, run a private instance of MediaCrush. There are instructions in the README, it's pretty easy to set up.
I don't know exactly what situation you are trying to avoid, but with the standard bcrypt, if somebody has the IP hash and a candidate's specific IP, they can positively match the two (something you specifically mention on your privacy page).
One possible tweak is to continue using bcrypt and a salt, but instead shorten the hash output to something like 24 bits. This way it still cannot be so easily reversed or rainbow-tabled, and collisions still shouldn't be an active problem. However, it wont be possible to positively match a given IP to a hash, since multiple IPs will likely hash to a given output. Granted, if you have a candidate IP and it matches the output hash, there is a very high probability that it was the source IP, but it wouldn't be 100%.
At 1/3 of a second to compute a single hash, brute forcing the entire space of possible addresses takes around 45 CPU-years. But computing the hash of every single IP address is ridiculously parallel, so it's trivial to spin up 2k machines on EC2 and brute force the entire thing in a week. Total cost, somewhere under $8k if you don't want to bother owning real machines, less for any organization that happens to need to do similar things on a regular or semi-regular basis.
It's not a trivial investment since that effort only gets you a single IP address, but it's easily within the reach of a vast number of organizations if they have real motivation (read: not a fishing expedition) to reverse it.
And of course, they wouldn't have to test every IP address in the world, they'd only have to test the IP addresses that appeared in the webserver logs at some point, substantially reducing the time requirement.
Good answer... It looks like it would take on the order of 7 CPU years to create a table of every used address, much less time to target an area or individual.
I don't think this is an issue at all though, I was just curious.
Actually, the salting is an important detail. Those 7 CPU years would only create a table for one hash. That's how long it takes to brute force a single hash, not the entire space.
I think the whole point of a warrant canary is that you have to do something, every week/month, to confirm that you never had to obey a warrant. And (presumably, I don't think it has been tried in courts yet) a gag order can prevent you to speak about a warrant, but it can't force you to do anything, including actively saying that you didn't receive anything.
If it's automated.. the gag order prevents you to stop it, so it might as well not be there.
mike@glue:~$ wget -qO - https://mediacru.sh/transparency/warrant-canary.txt|gpg --verify
gpg: Signature made Fri 08 Nov 2013 11:48:13 GMT using RSA key ID 5044F2FC
gpg: BAD signature from "MediaCrush Administrators <admin@mediacru.sh>"
mike@glue:~$
josemanueldiez@InfiniteImprobabilityDrive:~$ wget -qO - https://mediacru.sh/transparency/warrant-canary.signed.txt|gpg --verify
gpg: Signature made Fri Nov 8 12:48:13 2013 CET using RSA key ID 5044F2FC
gpg: Good signature from "MediaCrush Administrators <admin@mediacru.sh>"
"every undoable action first needs to be represented by an object in your code. This is called the Command Pattern"
This is too OO for my taste. Having just seen a talk about MiniKanren, I wonder if you can implement undo effectively with a relational (logic) programming system. Is anyone aware of research (or practice) to that effect? My googling isn't turning up anything relevant.
Shoot, no patch for the 1.2.x series? That's disappointing. It's not that old, is it? I feel like I upgraded to 1.2.x, which was then the newest stable branch, just over a year ago.
Debian does commit to security support for packages in main, i expect they will backport the patch to their current version and send notification from security-announce when an update is released. Also keep an eye on https://security-tracker.debian.org/tracker/CVE-2013-4547
1. Old version compiles new version
2. New version, compiled by old version, compiles new version
3. New compiled by new-compiled-by-old compiles new version
I hadn't heard of this before and initially didn't see why #3 is special. But I guess the idea is, the output object code is a function of both the input source code and the compiler version. And those two are the same for #2 and #3. So you expect the output of both #2 and #3 to be identical, and if it's not, that's a bug in the compiler. Is that how it works?
If you're going to comment mentioning it, you should probably tell people what it is :)
For those who haven't seen it, Nightcode is a new, open-source Clojure and Java IDE written by the person I'm replying to. Has project templates, paredit mode, REPL and CLJS build integration. I only played around with it for 5 minutes and went back to Vim, so I can't really endorse it but it looks cool.
https://en.wikipedia.org/wiki/Singular_they
Some object to the usage because:
> Proponents of gender-neutral language argue that the use of gender-specific language often implies male superiority or reflects an unequal state of society. According to The Handbook of English Linguistics, generic masculine pronouns and gender-specific job titles are instances "where English linguistic convention has historically treated men as prototypical of the human species." Words that refer to women often devolve in meaning, frequently taking on sexual overtones.
> These differences in usage are criticized on two grounds: one, that they reflect a biased state of society, and two, that they help to uphold that state. Studies of children, for instance, indicate that the words children hear affect their perceptions of the gender-appropriateness of certain careers. Other research has demonstrated that men and women apply for jobs in more equal proportions when gender-neutral language is used in the advertisement, as opposed to the generic he or man.
https://en.wikipedia.org/wiki/Gender-neutral_language_in_Eng...
Many years ago, I would have agreed with you that using "he" as neuter was correct and therefore preferable to singular "they". I no longer feel that way. I'd attribute that change in opinion to two causes:
One, I'm less concerned with by-the-book "correctness" and pedantry, and more concerned with the real-world effect my words have on people.
Two, I now realize that English is a living, evolving language, and there is no one authority on what is or is not correct usage. What is widely held to be proper English at a given time is a product of who happened to have influence in society at that time, no more, no less.
Also, although this is not what changed my opinion, I find it interesting to note that many of the same people who call the matter trivial will also expend considerable time and effort defending generic "he". If you find it so trivial, why not humor the people who think gender-neutral language is important?