Even if Gmail loads tells the marketer that you have opened the message (as people are pointing out, it's a bit unclear), there are still some advantages.
It protects you from the guys at marketer tracking your user-agent, your ip address (which gives a rough geo-ip), the number of times you opened the email, etc. It's unclear to me whether the images could set cookies before (they probably did), but even without that, they could just use etag-tricks, or stuff like that, to track you cross-sites.
Marketers might now know when you open the message, but proxying the image prevents them from getting more precise information.
(No idea exactly how much of this and more Google does, obviously, but they put themselves in position to do it)
Mass-email senders probably would put a unique identifier in the image url (different for all users), so Google will open each image, because it can't know before loading them that it's the same image.
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.
No. Any thick client architecture has to deal with this problem. The current resource-oriented models (by which I mean they're focused on serving http resources) are severely limiting those of us who want to develop a web application.
Some people are side-stepping the issue by saying that the whole presentation layer must be moved to the front-end, but that approach is really incompatible with the web.
If anything, the current state of the front-end is thanks to server-side developers who want to bring their world view to the browser. (Think: MVC -> Backbone / Ruby -> Coffeescript -- apologies to the authors of those tools)
I've encountered hurdles like that, but most of the time, they aren't strictly due to billing issues, and more likely due to intentional restrictions coming from the seller. As soon as you have a credit card, pretty much all payment processors will happily accept to process your payment, wherever you are in the world.
I've had quite a few bad experiences trying to purchase internationally (if your billing address and your shipping address are in different countries, you're in for trouble), but I don't think BTC solves any of those. BTC doesn't solve the shipping part, and BTC doesn't solve the fact that some stuff isn't internationally available (for example, music/movies/TV shows).
The overlap between people who enjoy the same videos as me and people I trust enough to them tell my real name is almost non-existent.
And I'm not sure I'm the only one thinking that way. If I want to talk about a video, I can, you know, share it (I can even share it on Google+, that way Google loses nothing). If it turns out to be a really cool video, I'll even maybe get to impress my friends that way.
In the initial stages of a product lifetime, you shouldn't focus on code quality. Releasing a crappy product beats waiting until it is well polished before releasing it, every single time.
But you should absolutely work on replacing, refining or polishing the crappy parts that turn out to be actually successful, or you'll end up in a dead end where you can't make your product evolve anymore without breaking everything. Or you'll get hit by the 'unlikely to be exploitable and difficult to fix' security flaws.
Crappy alpha code is good. Crappy legacy code, not so much.