I think the whole method that these sites use to deliver content is completely backwards, at least from the user perspective.
The goal of going to a web site is ultimately to get the content you are looking for. If you're going to Twitter, it's to read someone's twitter stream, etc.
The way these hashbang sites function is to display the least-relevant (to the user) information first, all the chrome and ads of the page. Then, when all the stuff you don't actually care about is done rendering, only then does it go and get the content you came to see.
This drives me nuts as a user. It is particularly annoying on slower devices, such as Edge or 3G smartphones, where you see the lag even more strikingly.
From a user-experience, content-oriented framework, this entire architecture should be reversed. The URI should point to the content, not the presentation as it does with Hashbang. The content should be served first, in a readable format, and then the javascript magic should kick in, download all the chrome in the background and then update the page once with all the other elements.
If you're going to have your page do a secondary load anyway (as hashbang does now) you might as well make the content the front-and-center part.
They can sell other places, but not promote those other places within the app.
They could offer their subscription on their web site and collect 100%. Their app would then be required to offer the same subscription deal as an in-app purchase for the same-or-lower price, and then they would collect 70%. The app could not refer users to their web site for purchases.
I've been trying to figure out a reason other than greed for this move, and I think you nailed it: It's a barrier to entry for competing media distribution platforms. Apple makes most of it's non-app-store money off media sales and this would be a less obvious way than "we won't let any other media company on our device" to accomplish that. Great insight!
It's more for content you don't control that you want to include in a site. For example, if you want to show the CNN feed within a secure portal page, it will give you the mixed-content warning because of the images in the feed.
Running the RSS feed through FixSSL does some basic remapping of the links so that it routes the images through FixSSL, which prevents the mixed-content warnings from appearing.
Of course, if CNN (and other sites) offered HTTPS versions of their feeds, there would be no need for this, but until they do it serves a purpose.
Correct, it's for showing off-site content on your own secure pages, such as a portal site showing a photo-of-the-day from another site or an RSS feed containing images.
Yes, you could roll your own solution, but this is, well, easier and lots of non-programmer admins might have trouble with it. This is just a simple way to access that site without having to write or load scripts onto your server.
Right now, it's just a straight passthrough (GET/ECHO) of the requested URL, nothing fancy. If you request an HTML or RSS page it will try some basic munging of the content to change the non-SSL links to reroute them through the fixssl system. I could expand on those if there's any interest in the service.
I set it up as an RSS feed and read it on my iPhone in idle times in Google Reader.
I've also found that I seem to need at least one distraction, so if I play some good music (I seem to work best to Queensryche or Eminem) that keeps the "I want a distraction" part of my brain happy and the rest of it can focus on getting things done.