Archive
Improved adblocking expected to a browser near you in Fall/Winter 2015
Web publishers primarily those with a large mobile web audience may see a big delta in pages served and ads served starting from Fall 2015 when iOS 9 and El Capitan launches. This will be coupled with improvements under the hood in Firefox 41 which should make Ad Block Plus much more efficient
Here’s a few links on the new content blocker extensions coming in iOS9 and Mac OSX El Capitan
- Introduction to WebKit content blocking
- How to write a content blocker extension in 10 minutes
- An hour with Safari Content Blocker in iOS 9
Also note that UC Browser which has a sizable userbase in fast growing smartphone markets such as India and China also comes with built in ad-blocking.
There is no such thing as too much meme-ification
Recently, we’ve been testing some new WiFi access points at work and one of the vendors we’ve wanted to test out their equipment is Ubiquiti Networks.
Hope the following images can give you an idea of what its been like. Well, actually I’ve always wanted to incorporate a Der Untergang parody but till now never found the appropriate occasion.
Mockup to demonstrate optimisation of Market app on Android devices
My last post described a simple personalization feature which could optimise app discovery on both the iOS and Android platforms.
Animoca has elaborated this point more lucidly and provided a mockup of how this would look on an iOS device.
I would like to share a mockup of the Android Market app which shows how apps would bubble up and become more naturally discoverable
Improving App Discovery in the iTunes Store as well as Android Market
Edit: This suggestion is expanded and elucidated more comprehensively in the official Animoca blog post
Mobile App Developers both on the Android as well as iOS ecosystem are consistently looking for more ways to have their apps discovered since they don’t buy in to “If you build it, he will come” philosophy.
Apps are discovered by users in many ways including pervasive marketing via mobile banner ads, video clips, cross promotion ads and very often discovered by users via “ranked lists” whether they be called “Top Charts” on iOS or the various Top Lists on Android Market which are quite well described via in this presentation by Eric Chu at Google I/O 2011.
Developers try very hard to get high up in the overall ranking since that improves organic discovery. This in general involves spending fair bit of money on advertising their app so that maximum users can be made aware of it or if the developer has an existing app or set of apps cross promoting amongst them.
However, lets take the viewpoint of a user who wants to discover more apps. Wouldn’t the user find the Top Lists more useful if they eliminated apps which were already installed on the users account or a device combination. This would allow apps which were ranked lower in the charts to bubble upward and thus users who had already consumed apps in the Top 10 or Top 25 content (the specific list within Android Market doesn’t really) would see other content which may have been below the fold for them and if the voracious consumers found that content to be useful, maybe that would be a signal for the app to bubble faster up the list.
Both Google and Apple have the ability to know what apps have been downloaded by a user specific to a device and/or an account and thus personalise the Top lists by eliminating apps which have already been installed by the user from the Top various lists. They would in effect become “Top lists of apps which have not been installed by the user”
This relatively simple change in my opinion would improve discovery and make the ecosystem more useful to both mobile users and app developers.
Facebook OAuth 2.0, HTTPS, Credits : Implications for developers
Facebook is migrating to OAuth 2.0 (an open standard for authorization) and HTTPS to provide better security on the world’s largest social network. This has some implications for Facebook developers and users, and there are also some items of concern and others that require clarification.
As announced in May on the Facebook Developer Blog, by October 1, 2011, all Canvas apps on Facebook must have completed transition from the old Facebook authentication system and HTTP to the newer and more secure OAuth 2.0 and obtain an SSL Certificate.
Facebook released updated PHP and Javascript SDK’s to provide OAuth 2.0 support. There is a small snafu that after releasing the Javascript SDK, the PHP SDK which supposedly had OAuth 2.0 support didn’t work with the new cookie format so an updated one is to be released next week.
One of the ambigious requirements for developers is that they “obtain” an SSL certificate for Facebook Canvas and Page Tab apps. It’s not clear what “obtain” mean.
Are developers just to buy an SSL certificate and prove to Facebook that they bought one or are they required to host the Canvas or Page Tab app under HTTPS
Assuming developers have to host their apps under HTTPS, other questions which arise are
- Will Facebook default to as well enforce HTTPS access for all users on Oct 1 ?
- Will developers have to cater to both HTTP and HTTPS access to their apps ?
- Will Facebook ‘map/redirect’ HTTP traffic to HTTPS ?
Whatever it means, Facebook app developers already have a lot on their plate: viral channels on Facebook are diminishing fast and users are getting more expensive to acquire every day. Additionally, the trend to spend more time on mobile channels results in a reduction of time spent on Facebook Canvas games (many of which are built using Flash/Unity and are thus not available on a large number of mobile devices).
Will these changes hurt small to medium developers in particular? SSL has a reputation of being expensive to deploy and, although a lot of work has been done recently to lower this cost, the software tuning and the know-how for high performance SSL stacks typically exist primarily in large corporations.
Advertising snags
Canvas apps can incorporate advertising from Facebook-approved providers, but unfortunately Google AdSense – which offers some of the best eCPM rates – is not one of them. A number of developers have been clamoring for Google AdSense to be included in Facebook’s list of approved ad providers, however nobody seems to be holding their breath waiting for Google and Facebook to come to an agreement.
To ensure a good user experience, all elements in a Canvas page will have to be served over HTTPS; to do otherwise will result in browsers popping up mixed-content warning dialogs that interrupt and bewilder many users.
Additionally, Google’s browser Chrome is moving toward blocking mixed scripting, which is likely to affect non-SSL advertisements on Facebook Canvas pages that are served over SSL.
Are advertising networks ready to serve ads over SSL ? Or will app developers be forced to find some other way to monetize their products if Facebook-approved ad providers are not able to serve ads over SSL?
What will be the impact on their costs if Facebook app developers are forced to use content delivery networks (CDNs) to serve assets over SSL ? Developers also need to be aware that name based virtual hosting is not possible over SSL unless browsers, SSL libraries and server stacks support Server Name Indication.
If Facebook requires developers to provide both HTTP as well as HTTPS access to Canvas apps then that will increase complexity and cost of deployment.
Facebook Credits and impact
Any company or person deploying a game on Facebook must already cope with the mandatory requirement of using Facebook Credits instead of a proprietary currency. Before the requirement to use Facebook Credits, companies offering games and apps via Facebook’s Canvas system would determine their own currency and product pricing, selecting third party payment providers of their choice. For example, a vendor like PayPal used to provide a payment gateway for your Facebook app for a few percent commission on every transaction. The commission on the (mandatory) Facebook Credits system is a whopping 30% on every transaction. So much for the cost advantages of a unified currency!
Facebook Credits provide a fairly liquid unified currency – and that’s good. What’s not so good is that this currency still has a substantial number of zero-value credits in circulation, and users who pay with these “free” credits provide no revenue whatsoever to developers.
Options ?
One option Facebook app developers can consider is to host the application outside of Canvas and use Facebook’s Graph API to access Facebook platform features. Given that Facebook’s own FBML is deprecated and that almost all Canvas apps today are in iframe, the Graph API workaround is relatively easy and does not constrain developers with various rules (including the need to have the app hosted under SSL).
The ability to use Facebook Credits is obviously not useful or available outside of Facebook Canvas but there are alternatives, including the upcoming Google In-App Payments for the Web (5% fee on every transaction). Perhaps the rise of Android will increase the proliferation of Google Checkout accounts and if Google could address the issue of increased mechanisms of adding funds to Google Checkout accounts this can be a good beginning for the much rumored Google+ Games
Google Checkout limited mechanisms of adding funds and its impact on monetizing freemium Android games
Mobile analytics firm Flurry has an interesting chart showing the rise of freemium games and its impact on the list of Top Grossing Games.
According to them, at the end of June 2011 65% of the revenue generated by the Top 100 Grossing games in the US App Store were freemium games. This is in large part due to Apple having access to over 200 million credit card on file. Apple also makes it convoluted to activate an iOS device without providing a credit card. There is also the ability to buy iTunes gift cards as well as link the iTunes account with Paypal
Compare this to the Android Market where Google provides in-app billing service via Google Checkout. Android usage is booming and activation requires a Google account. However there is no need to create or associate a Google Checkout account during activation.
Also, prior to it use for Android Market the only reason one would have funds in a Google Checkout account would be to pay for extra storage for Gmail or Picasa or buy a premium plan for Google Apps. That’s a fraction of the Android userbase.
If freemium gaming is going to be one of the big drivers for increased Android apps and particularly ports from iOS thereby increasing usage of Google Checkout then it becomes very important to have lots of mechanisms to add funds to Google Checkout in a relatively frictionless manner.
Facebook has spent a lot of effort partnering with alternative top-up mechanisms and now Facebook Credit pre-paid cards are available in a ton of places particularly in South East Asia where credit card penetration is very low and there are established infrastructure for topping up funds to use for micro-transaction payment. Carrier billing is very expensive and this can easily be seen when buying Facebook Credits which cost 3x as much via mobile payments compared to walking to the neighbourhood shop and buying a scratch card.
PowerDNS does not as yet support GPD as an upstream forwarder
My last post explained how Dan Bernstein’s dnscache could be used alongwith Google Public DNS (GPD) as an upstream forwarder.
For those who spend time with DNS, they are likely to be aware of Bert Hubert’s PowerDNS which comes in two flavours, an authorative nameserver and a recursive nameserver
PowerDNS currently hard-codes the RD (recursion desired) bit to 0 when it sends DNS packets to nameservers configured in its forward-zones/forward-zones-file configuration parameter. This makes it impossible for one to configure an open recursive nameserver such as GPD as a forwarder. There is a ticket open in PowerDNS about it and Bert has mentioned on the mailing list that he is close to making the changes to provide the required functionality. Maybe this feature might come in a future PoweDNS recursor release
Combining DJB’s dnscache and Google’s Public DNS
Most of the comments which I’m reading about Google Public DNS (GPD) performance centers around round trip latency from an end-users location to GPD’s resolvers vis-a-vis their network location and comparing the round trip time to their local ISP DNS cache. Ping time is only one part of the time taken for DNS resolution, one needs to factor in DNS resolution time also which can be affected by cache locality and sizing as well as how connected the requested authorative nameserver for the query is relative to the DNS resolver. IMHO, an effective way for setting up an office DNS cache is to setup a local caching nameserver such as Dan Bernstein’s dnscache and use GPD as an upstream forwarder.
Thus domains which are repeatedly asked are answered from your local dnscache and the long tail of domains can be answered by GPD which may have its in its cache because what may be infrequent for your organisation is frequent for someone else who is using GPD thus giving you the best of both worlds. Fast local caching, and a fast recursive resolver when you have no locally cached results.
I’m assuming that in the coming weeks, Google will reach out to a number of organisations who use anycast DNS such as Content Delivery Network operators (Akamai, Limelight, CDNetworks etc) and authorative DNS servers operators (Dynect,UltraDNS,DNSMadeEasy etc) and work out better network routing amongst them.
These instructions assume that you have setup dnscache as an external forwarding cache for your organisation.
Then run the following commands (asssumes that you have installed dnscache as per DJB’s setup. Ubuntu/Debian users may have to adjust paths if they use packages from these distributions
echo 1 > /service/dnscache/env/FORWARDONLY echo '8.8.8.8 8.8.4.4' > /service/dnscache/root/servers/@ svc -t /service/dnscache
Using Google Public DNS in conjunction with DD-WRT/DNSMasq
There has been a lot of buzz regarding Google Public DNS herafter called GPD. Google’s instructions are designed for end users modifying their own computers. I think GPD can be very useful if used in conjunction with a forwarding cache on a router. This is the mechanism I used on my Linksys WRT54GL running DD-WRT
v24 to combine using DNSMasq and use GPD’s provided IP addresses 8.8.8.8 and 8.8.4.4 as the upstream DNS.
I assume that you have enabled SSH access to the router so you can login via SSH and take backups of the old values of the upstream DNS
- SSH into your router and run
cat /tmp/resolv.dnsmasq. Save the IP addresses listed somewhere in case you want to revert back - Go to the Commands tab under Administration.
- In the Commands box paste the following:
- Click Save Firewall (note: your WAN interface will be restarted)
echo "nameserver 8.8.8.8 nameserver 8.8.4.4" > /tmp/resolv.dnsmasq sleep 1 killall -HUP dnsmasq
Now, you can take advantage of the DNS caching on your router and misses on the routers DNS cache are sent to GPD for resolution. Note that websites which use CDN will now determine the closest node based on where the anycasted GPD addresses 8.8.8.8 and 8.8.4.4 resolve to relative to your network.
In a future post, I’ll write about how GPD can be integrated as an upstream forwarder using dnscache and why PowerDNS recursor doesn’t support using an open resolver as an upstream forwarder at present
Why I think Chrome is coming out of beta now
There have been a lot of discussions, blog posts describing how Chrome is one of the shortest if not the shortest beta cycle from Google. Most of the discussion has centered around the business requirements from OEM of having a non-beta software for pre-installation. Whilst this is valid, in my opinion this pre-deployment would still take a while to go through since I expect the earliest manufacturers will start a new build will be after Chinese New Year (end of Jan) and subsequently with another QA cycle could be March-April before boxes with Chrome pre-installed show up in stores
In my opinion, Google wants to take advantage of the holiday season where everyone is visiting family and doing the usual “tech support”. A lot of early adopters would like to get their parents computer cleaned up and install alternative browsers. Google’s Chrome is clean and with the search box integrated nicely with the address bar would be very useful to many who don’t care about the lack of extensions.
I for one would really like for sites to actively discourage use of Internet Explorer 6 and push their users to alternatives such as Firefox, IE7, Chrome, Opera.
It will however be interesting to see how Chrome’s mechanism of being chatty with Google for its auto-suggestion may impact usage in markets where people have bandwidth limits.
Yusuf Goolamabbas 