Because they want to stick it to Apple. Whereas Netflix opted to eat the 30%, Google would rather recoup it. Additionally, whoever wrote the article is being a little disingenuous, since Google takes the same 30% on app and IAP sales. They can just ignore that for Red as it's their store, their service.
Alas, Google takes the exact same 30% on apps and IAPs. They're just willing to eat it on their own platform for their own service.
https://support.google.com/goo...
"For applications and in-app products that you sell on Google Play, the transaction fee is equivalent to 30% of the price."
Everything loves jumping on Apple for the 30%, but misses that it's the norm.
Uhm, the OS doesn't crash when the rendering engine sees that. The app, if it's using the system libraries to render it, may. App-level crash, no obvious vector to leverage the issue to do anything further. It's really more in the realm of annoyance, since apps crash for plenty of other reasons too.
Here's everything fixed up in the 10.8.5 update release last week: http://support.apple.com/kb/HT5880
RIR allocations to ISPs are premised on users getting entire networks versus a single address. That by itself should ensure end-users get larger than a single IPv6 address. Whether it's static or not is irrelevant for cases like this, just that it's a public IP and therefore directly accessible (barring the non-packet mangling stateful firewall).
Now, if the ISP will charge for a static IPv6 prefix, versus whatever their provisioning system hands out, who knows? For many services, they won't care, since with all the NAT we've had to deal with over the years, those services have central registries they update when they come online, or can be handled via some DDNS updates.
Same reason they don't offer unlocked phones.
Hmm, I guess that "Buying from Apple" "Unlocked iPhones" section on their store support (http://store.apple.com/us/questions/iphone) was put there by hackers.
It's the carriers that want the lock. Apple couldn't care less, long as they see the revenue for the device from someone.
In any case, the problem here is in regards to the handshake, to handle NAT or other end-to-end traversal issues. Pretty much every protocol that wants to be peer-to-peer in a world with NAT has that issue, especially SIP (ergo, STUN. Nevermind how many SIP devices have no clue about IPv6, which is going to be another problem here soon). The VirnetX patent apparently covers some of how to handle that, and since their implementation apparently tripped over something in the claims, now FaceTime has to skip the direct attempts, and go via a relay.
Uhm... http://www.spamhaus.org/lookup/ If you're in the XBL, it'll tell you which list comprising the XBL you're in. Usually that means the CBL, which has a fairly instant delist process for listings, unless the problem keeps coming back.
"Mr. Watson, come here, I want you." -- Alexander Graham Bell