Key information on revenue is on page 50. 85% of revenue comes from ads, which grew 69% Y/Y mostly driven by user growth (39% Y/Y) and showing a bunch more ads starting Q4 2010:
2011 Compared to 2010.
Revenue in 2011 increased $1,737 million, or 88% compared to 2010. The increase was due primarily to a 69% increase in advertising revenue to $3,154 million. Advertising revenue grew due to a 42% increase in thenumber of ads delivered and an 18% increase in the average price per ad delivered. The increase in ads delivered was driven primarily by user growth. The number of ads delivered was also affected by many other factors including product changes that significantly increased the number of ads on many Facebook pages beginning in the fourth quarter of 2010, partially offset byan increase in usage of our mobile products, where we do not show ads, and by various product changes implemented in 2011that in aggregate modestly reduced the number of ads on certain pages. The increase in average price per ad delivered was affected by factors including improvements in our ability to deliver more relevant ads to users and product changes that contributed to higher user interaction with the ads by increasing their relative prominence.
The key information is on page 54-55: Why the massive jump in Q4 2011 revenue over Q3? It looks like there is a seasonality factor, but their explanation only covers Q4 2010, to Q4 2011.
This is going to be a super volatile stock. If there Q1 2012 revenue is flat QoQ, this is probably a $50B company, if it is up 15%, then this is probably a $100B company.
The key information is on page 54-55: Why the massive jump in Q4 2011 revenue over Q3? It looks like there is a seasonality factor, but their explanation only covers Q4 2010, to Q4 2011.
This is going to be a super volatile stock. If the Q1 2012 revenue is flat QoQ, this is probably a $50B company, if it is up 15%, then this is probably a $100B company.
I was actually most curious to see if they had developed a source of revenue other than ads. It seems like the answer to that is mostly no, although they are working on payments.
I agree that ads revenue growth will be key for them in the short term. The Q4 2011 vs 2010 growth was 44% and it seems like perhaps the growth rate is slowing down.
Given that Google has made a ton of huge bets but doesn't make a dime outside of advertising, it is hard to think Facebook will move the needle with an alternative revenue stream. Even if they hit a Groupon sized home run with an alternative revenue stream, it only moves the valuation by 10-20%.
I think on balance mobile is not really an opportunity. They are losing the game revenue to the mobile/tablet platforms and in-app mobile monetization is a minimal opportunity for a task based application.
I don't use facebook, but can you explain what it means to be working on payments? I thought that was just their taking a 30% cut on game payments on their platform. That kind of margin doesn't exist for more general "payments".
Even with all my negativity, I am still cautiously bullish on Facebook. They are only making 50 cents/month per active user. I see no reason they can't double that.
Secure password hashes don't protect users, and particularly not users who use one-time effectively-random passwords.
Secure password hashes protect application developers from the disclosure of hundreds or thousands of user passwords from their database. It allows them to attest to their userbase "your password is cryptographically stored in a manner that makes them hard to break even by dedicated hardware; you should consider changing your password if it's weak and shared", instead of, "expect to see your password on Pastebin any day now".
To clarify, I assume you mean that using secure password hashes instead of insecure ones does not help users who use one-time effectively-random passwords, because those users are already safe?
That is true.
However, it seems to me that the combination of an effectively-random password and password hashing does protect users, because their password is not effectively crackable in a situation like this. Additionally, there's a tradeoff between how secure your password hashing is and how much randomness users need to put into their password: every additional factor of 1000 in the iterations of the hash saves you a random character or two.
I wish everyone could use complex, unique, strong passwords all the time, but some use cases just don't support it. For example, I have to type my Apple ID into my iPhone/iPad what seems like every 5 minutes in iOS. Without access to 1password or a similar tool, I just can't use a strong password. Even if I did, I couldn't change it as often as I'd like to. FWIW, I wish I could.
My point was that the choice is sometimes not left in the user's direct control. If I thought I could choose an absurdly strong password (e.g., to overcome the shortcomings of the developer's choice of SHA1), I would always do that – except if I'm going to need to enter that password from memory a bunch of times per day.
You're looking at more like 5+ billion/sec today. There was a listing of modern consumer video cards + their hashing capabilities posted on another HN story recently, but I can't find it.
"Hashes" aren't interchangeable, they're an abstract concept. In this case, the thread is talking about the SHA-1 hash algorithm. AFAIK Bitcoin uses SHA-2 w/256-bit digests.
So, actually, in this case the two happen to be related but different - SHA-1 being considered potentially flawed but not (yet) the stronger SHA-2.
Also, the Bitcoin block headers that are hashed are (I think) 80 bytes (640 bits) long, salted passwords probably a bit shorter.
Wikipedia says SHA-256 runs about 2/3 the raw throughput of SHA-1. You can the comparative rate yourself on any nix computer:
$ openssl speed sha1 sha256
-snip-
Doing sha1 for 3s on 16 size blocks: 7760096 sha1's in 2.99s
Doing sha1 for 3s on 64 size blocks: 5502820 sha1's in 3.00s
-snip=
Doing sha256 for 3s on 16 size blocks: 5460366 sha256's in 3.00
Doing sha256 for 3s on 64 size blocks: 3169031 sha256's in 3.00s
-snip-
*
So... about 2/3 faster. I don't know enough about crypto implementation, but I'd guess this ratio would scale roughly to the much faster GPU implementations as well.
Yes, I have 2 6950s, which together average to about 660MH/s on hashkill mining bitcoin, but when I tried MD5, IIRC they averaged to about 3200MH/s. I'd assume SHA1 to be slightly slower, but not much.
If my understanding is correct that's not the issue here. Hashes are meant to be one-way functions, the developer can easily check if a user's password matches the hash, but it should be practically impossible to deduce the password from the hash.
What the user chose as their password should be irrelevant if using a good hash.
[Edit: I stand corrected on the effect of password length.]
SHA-1 is a reasonably good hashing algorithm, but for the sake of argument, I'll talk about an imaginary SHA-4 which is perfect in every respect. It will be a 4096 bit hash function which has no faster-than-bruteforce collisions or preimage attacks or second preimage attacks.
Let's also assume that this perfect SHA-4 function is freakishly fast, say, a million times faster than SHA-1.
Now, even though my imaginary SHA-4 function is perfect in every way, it would be strictly worse to use this for password hashing than SHA-1. Why? Because cryptographic attacks aren't the problem here. The problem is that the entropy of a user's password is very VERY small. So small, in fact, that attacks on passwords aren't done through cryptographic weaknesses, they are done by simply hashing everything someone might pick as a password and asking "did I get it right?". An attacker will repeat this process for a little while, and eventually they'll get the answer "YES, this user chose to make abc123 as their password!".
(Edit: see child comment -- I was responding to something other than what was intended. I'm leaving this here for clarity, but you can ignore it.)
No, not really. Hashing functions aren't designed for passwords, they're mainly used for integrity checks and other uses which need to be fast: why do you think one of the axes the SHA-3 hashes are competing on is speed?
You have your 10gb file and want to send it to your coworker and let him know it's really yours and no one has messed with it. So you run an HMAC over it and then sign it with your private key.
You want it to be as fast as possible. It would be optimal if there was a single x86 instruction called sha4 which did this in the time it takes to do an add.
Hashing is really, really not meant for passwords.
Woah, slow down, I think you whipped up a 4 paragraph reply before you ever got to my last sentence.
Or, go on and tell me more about all the things hashes are used for as if I just fell off the turnip truck.
This discussion is not about checksums on files. It's abotu passwords. And your "perfect hash" in your example about passwords is "freakishly fast." In fact, like the other guy that replied to me mentioned, this is the entire point of the workfactor in bcrypt, right?
Of course, bycrypt is really, really not meant for checksums. Good thing nobody was talking about checksums then.
When you wrote "this fictional hash" I read that as talking about the SHA-4 I made up, not the one you did.
I then didn't respond to the rest of the post because when you said "for password hashing, it's a good start" I again assumed you were talking about my hash function, which is not good for hashing. Yours would be perfectly fine.
Apology accepted, and thank you for adding a lot to the discussion further down the page (the interesting maths related to the probability of collisions on a hashed-hash)
Sure, but if you can run through billions of possible hashes per second then it's possible to brute force the "one way" hash by exploring hashes for short passwords.
1 billion passwords per second is 86 trillion passwords per day. If a hacker wanted to gain access to a particular password then it can become trivial to crack with fairly modest resources. The only thing that protects you is a sufficiently complex and long password.
But there are rainbow tables, or tables of all of the MD5s/SHA1s/<insert favorite hash algorithm> for arbitrary strings. So the time's already sunk in.
8 days for one password is a very short amount of time comparatively (tiny for a botnet). If you use bcrypt, which you can force a certain complexity on, you can get that amount of time up much higher.
You shouldn't be so quick to knock the idea. People probably said the same thing about a stupid website that was pretty much a yearbook online. It has 3milliom monthly users, he can definitely turn it into a revenue generator and is in a great position to be strategically acquired by Washington Post (which owns Kaplan), or Princeton Review. Dropping out of MIT is a risk- but, he can always return.
I speak for myself here, but I don't think something needs to be the "Future of the World" for it to be an immensely fulfilling way to lead one's life, degree or not.
Having a website that 20% of teachers nationwide use is a pretty powerful place to build a business from. Quia started from the same place, and now does something like $40M/year in revenue with their IXL product.
This looks like a pure fluff announcement to me -- it's not enabling any new functionality. Mark Zuckerberg even said that this is built on top of the Graph API so anyone could have built this app but no one cares.
It looks to me like facebook slipped on the deadline to launch whatever they've been in "lockdown" for and they had to scramble to put this and the other minor things together for the press.
