I had the same idea the last days, but did not find the time to create it. AWESOME u did it. Thanks and i wish u success with it. i am definatly going to use it.
Obvious mistake made in the calculation. From "We also know that they had 3.4 million unique payers in the September quarter, which is up from 3 million at the end of December 2010." lead them to "In other words, they added 400,000 additional payers and they spent $120 million to acquire them.”
This is an obvius mistake, as not all of the 3 Million from Dec 2010 continued to be a customer in Sept 2011. I roughly assume they lost 800.000 customers in that span (i think its more), then the newly aquired customers triple to 1.2 Million. Thus Zynga makes 50$ profit per customer.
I'd go farther, if players stick around 12-15 months historically, and they had 3M users, then in 9 months they could lose 60%-75% so 1.8M to 2.25M players! This of course depends on distribution of lifespans, and assumes that the 12-15 month figure remains accurate.
If that's true, they're getting users for as cheap as $50 each, and making $100 on each.
Oh, come on, guys...
You all are over simplifying a complicated calculation.
Have you considered that you don't know the distribution of the 3M players? How many of them had just joined compared to how many had been around already for a while? (this could push both ways)
Also, have you considered how many new users they were expect to get just by word of mouth and no investment?
What is the percentage of regeneration of users that quit in 12-15 months but maybe also brought in other users to play with them?
Without knowing the details you can't say anything.
I'm not saying that I agree or not with the article, but I assume that every person working as an analyst learns on their first day what you were suggesting above. So, it could be that the analysis is wrong (and it does look wrong), but the calculation that an analyst should do is much more complicated that you guys seemed to think from what you wrote (and two wrong analysis won't make a correct one).
I would have spent at least part of those $120M in funding startups to develop new games (and later bring them in, in case...). I'm pretty positive the return might have been better...
Yeah, the math is a bit wonky and requires speculation about many numbers we don't know, but the fact is that Zynga spent $120MM to grow...slightly. It's not the straw to break the bulldog's back, but a straw nonetheless.
But that skews in the opposite direction: If they lost more users, that means they lose customers more quickly, so the value of a customer decreases the higher you raise your estimate here.
Losing more users is good in that it means they gained more in the same timespan - for fixed changes in the number of users (which is the datapoint we have). But it also means they are having a hard time keeping them.
Parse is very unsecure because you essentially give the user full read/write/delete access to all of its data as no logic is run server side but clientside. That means any scriptkiddy can change all data as it likes.
That has nothing to do with MongoDB, but with the cirtical design flaw of Parse to trust the client not to send fake data.
My initial intuition is that such an egregious oversight can't possibly be real for a YC11 company, can anyone validate this? Does Parse really provide no way to set document fields writable, readable and so on?
Just by having a forged SSL Certificate for ssl.google-analytics.com how can they supply their javscript ? The request still goes to the google servers and not to any evil-democracy-suppressors.gov.ir
So sure if they could reroute the request to their servers evil things could be done. But they can NOT. Or am i missing something ?
Of course they can reroute traffic.
All they have to do is
* Force every ISP/Telco within their borders to add fake google.com entries to their DNS servers.
and/or
* Force every ISP/Telco to transparently proxy all DNS traffic and provide fake replies for google.com queries
You can even make it easier:
Just hijack IP routing at the borders, such that IP traffic to 209.85.149.99 (and all other google networks) are not routed to the real google servers on the internet, but their own malicious filtering proxies.
Even without involving the ISPs/Telcos, they could transparently hijack and proxy you, for a whole country it might be a rather big task though, but here's what you do:
* Find all the cables carrying internet traffic in/out of your country.
* Bring a shovel, dig up the cables.
* break the cables.
* hook up the cables to your transparent proxy/filtering machinery.
Done properly, all everyone would know know was some lights flickering in the few seconds the cables were broken.
I imagine that more sophisticated networking equipment uses something like TDR (https://secure.wikimedia.org/wikipedia/en/wiki/Time-domain_r...) to detect when the cables have changed in length. Some PC BIOSes include a tool that will report the length of attached network cables, whether or not there is a system at the other end.
It'd be a far greater task intercepting all downloads for every browser out there and replace it with a malicious one. Besides, you'd not get to hijack people browsing with the IE that came installed on their PC, which likely outnumbers firefox users.
So then they can only fake the traffic in their country what they can do anyway with non SSL traffic. I sounds more like this could be a global attack.
It's 'local', since you somehow need a way to intercept the traffic and there's a limit to the feasibility. Let's say this is 'local' for everyone in Iran.
But going for the certificate Colin suggests broadens the attack quite a lot: Instead of being able to server your own version of GMail/intercepting mail traffic you're now able to inject Javascript into what? 60% of the websites of the net? Basically everyone using Google Analytics now silently serves your code and the browser runs it without warnings.
So local/global is orthogonal to this impersonation 'improvement'. Even if you do this (somehow tricking a CA) yourself in the internet cafe of your choice, you would make the attack so much worse if you don't target a single service anymore and inject your code into as much content as possible.
The aim is for monitoring traffic from within Iran.
The government almost certainly controls all internet traffic entering or leaving the country at the ISPs, and could intercept and/or redirect it as necessary.
