About a year ago I asked where the async Google AdSense was. It finally arrived, and you need to do nothing to gain the performance. Awesome!
Categories
Tag: Google
The Chrome team announced they are dropping support for H.264.
WebM Support
WebM support will be growing quickly as Firefox 4 rolls out (Firefox upgrade adoption is legendary). Chrome commands sizable market share and is pushing the Chrome OS platform. Opera is also supporting WebM.
Apple and Microsoft could join the party and bundle WebM support along with the other codecs they support at any time, though they are licensors for H.264 and wouldn’t benefit from WebM market penetration. Microsoft’s implementation does allow for VP8 support if a codec is installed. I’m not aware of anything for Safari and am rather certain nothing can be done for the iPhone without Apple intervening.
On the hardware side AMD, ARM, Nvidia are backing WebM. Broadcom announced support, as did Qualicomm and TI. These are major vendors for mobile chips. Intel is working on stuff too.
H.264 Trouble
H.264 is problematic and bad for the web for many reasons I’ve mentioned here before as well as great posts by roc and shaver. I’ll leave it at that rather than rehash.
There was buzz a while back about H.264 being “free” (quotes intentional), but it’s not really “free” if you read the fine print. As Peter Csathy of Sorenson Media notes:
But, you say, MPEG LA recently announced that it will no longer charge royalties for the use of H.264. Yes, it’s true – MPEG LA recently bowed to mounting pressure from, and press surrounding, WebM and announced something that kind of sounds that way. But, I caution you to read the not-too-fine print. H.264 is royalty-free only in one limited case – for Internet video that is delivered free to end users. Read again: for (1) Internet delivery that is (2) delivered free to end users. In the words of MPEG LA’s own press release, “Products and services other than [those] continue to be royalty-bearing.”
That’s hardly “free”. That’s just one potential use case that’s now royalty exempt. The reason they are doing that is presumably if they can get H.264 adoption high enough, all the other cases will be paying and therefore subsidizing this one case.
WebM is licensed a little different: Patent wise, it’s irrevocably royalty free. License is about as liberal as you can get.
There’s no proprietary html, css, or images (GIF was, now it’s dead) used across the web. Why should video be any different? The key to success and growth has always been an open platform that’s low cost and encourages innovation.
Implementing Today
For anyone who suggests that this further fragments the market, that’s not really true. Adobe Flash actually creates an excellent shim to help migrate away from Flash to <video/>. Allow me to explain:
Adobe will soon be supporting WebM through Flash. Adobe already support H.264 in Flash. For legacy browsers and those who won’t support WebM, you have the option of delivering a Flash experience just like most websites do today. There are websites doing this today via Flash and H.264. For modern browsers you can just use <video/>. Once your non-WebM market share drops low enough, you can get rid of the Flash experience. Soon enough you’ll be able to push WebM to your Flash users. The benefit of switching your Flash experience to WebM as a middle step would be one encoding for both delivery mechanisms vs. using H.264 and WebM in parallel. Of course if you’re supporting mobile you likely need H.264 for a bit longer but likely use a smaller resolution and different profile for mobile consumption.
No matter what there will be two delivery mechanisms for those looking to push video using HTML5 to users today. The only thing that changes is the lean towards standardizing on the actively developed WebM codec vs. H.264.
All new technology has speed bumps, that’s the cost of being on the bleeding edge. However this is a positive turn as things are now starting to line up. The most awesome thing is that the codec, HTML5 specs, and some of the most popular browsers in the world are open and inviting feedback and contributions to improve things.
There’s been a storm of discussion over the past 72 hours about Eric Butler’s Firefox extension Firesheep. To summarize, it’s a Firefox extension that facilitates session hijacking by packet sniffing for data from certain websites. As far as software goes, it’s more evolutionary than revolutionary, at its core it’s a packet sniffer. The evolution is the pretty UI which makes it trivial to hijack someone’s session (he really did do a good job on the UI, it’s so easy a child could use it).
It’s actually surprising to me that so many people are shocked by what this demonstrates. Even those who claim to be technically literate seem taken back. Insecure sites by definition are insecure. Anyone can read what’s going across the wire (that includes WiFi) when it is sent unencrypted. If your browser can interpret and use the information to let you browse Facebook, Twitter, etc. so can any browser, on any computer. It’s that simple. Firesheep only supports a handful of sites, but adding support for more sites isn’t difficult. If your favorite website hasn’t been done yet, I expect it will be soon enough.
How Do You Protect Yourself?
The best way to protect yourself is to demand that websites that hold private information use HTTPS from the moment you log in until you log out. Short of that, the best you can do is use a Firefox extension like EFF’s HTTPS Everywhere to force your browser to use HTTPS. This won’t work everywhere as not every web server even has HTTPS working, but many secretly do. They sometimes use HTTPS for certain things like login, then use insecure HTTP for the rest of your visit. That’s so your password isn’t transmitted in plain text. Protecting a password is important, but if the session is insecure anyone can intercept what you do. HTTPS Everywhere works by rewriting all requests to many popular sites to use HTTPS ensuring your privacy and security through the length of your visit. Some websites will have minor issues. For example Facebook Chat is impossible to support right now due to it not working via HTTPS. The rest of Facebook however works.
For more advanced users, HTTPS Everywhere lets you write your own rulesets for sites it doesn’t support.
How Do Websites Protect Their Users?
It’s very simple. Use HTTPS for the period a user is logged in, not just when authenticating and submitting sensitive data. Sure it’s a little slower and requires more hardware, but scaling HTTPS these days isn’t nearly as difficult as it was just 5 years ago. In 2 years it will be even easier. Google went as far as forcing HTTPS upon all of Gmail users. Binding a session to an IP address is fussy and largely ineffective due to NAT, WiFi hotspots and mobile services that can cause an IP to just change with little/no notice. It’s not effective security. It’s better than nothing, but it’s not a fix.
Google could make a huge difference by supporting SSL in Google AdSense, something I’ve called for since 2008. Google has supported SSL with Google Analytics for some time, but they have lagged with rolling out support in other services. Lots of websites monetize with AdSense and this is just another reason websites put off supporting SSL. Other ad networks should do the same. Google AdSense has the least barrier to entry since they serve their text ads off of their own infrastructure, vs. creatives hosted by other parties like some smaller ad networks. One could argue having third-party code inserted on a page mitigates security but it would still be a major improvement over the current state of affairs and would prevent simple session jacking.
“What’s old is new again” the saying goes. Google Instant is a pretty interesting UI change. One of the big things mentioned is that all you need to do is type “w” and you’ll see the local weather. A way to get information by just typing… some of us know that as command line interface.
Essentially we’re seeing Google move from a point & click UI to almost a command line UI. For ages the focus was automatically set on the search box, no need to click on it. Just type, press enter or as I’m sure many (if not the majority did) mouse over the “search” button and click on it and you got search results. It’s just another step forward in simplifying the process. This is one less interaction (pressing search).
It’s interesting to see a less mouse centric UI develop after decades of anti-keyboard UI. For those of us comfortable typing quickly and using keyboard shortcuts constantly it’s a constant nuisance when applications don’t handle shortcuts nicely. We’re now seeing an effort to reduce use of the mouse, even if it’s just to press the “Search” button. One less reason to take your hands off the keyboard.
One interesting quirk I’ve noticed is Google’s calculator (the ability to type a math problem into Google and get an answer) just feels awkward and unpolished. I suspect they will improve upon that shortly. This can vastly improve the utility of these little applications. Google has several little apps built into its search (try typing “movies” for example). It’s just that much easier to use.
Categories
Google Pac-Man Hacking
Quick Hack
Here’s a literally 2 minute hack for the Google Pac-Man tribute on the homepage right now to put your own face on Pac-Man (pardon my poor photoshopping):
To try it add the following bookmarklet to your browser by dragging the link below to your bookmark bar:
raccettura-ize pacman
{document.getElementById('actor0').style['backgroundImage']="url('http://robert.accettura.com/wp-content/uploads/2010/05/raccettura_pacman.png')";})()){kind=link}
Now go to Google and press “Insert Coin” to play the game. Once the game loads, run the bookmarklet by clicking on it.
Hack yourself into Pac-Man
Want to make your own? You likely have better photoshop skills than me. Download this image and replace the Pac-Man (and optionally Ms. Pac-Man) images with ones of your own keeping the position and sizes the same. Save as a PNG with transparency. Then upload somewhere. Now make a bookmarklet that looks like this (replacing URL_TO_YOUR_IMAGE with the url of your image):
javascript:(function(){document.getElementById('actor0').style['backgroundImage']="url('URL_TO_YOUR_IMAGE')";})()
Now share with your friends.
Permanent Home
Google has now removed Pac-Man from the homepage but it can still be found here.
Edit [5/24/2010 @ 8:45 PM EST]: Added “Permanent Home”.
In August 2009 after the On2 announcement, I suggested that Google might open source a codec in hopes of derailing OGG which it feels is inferior as well as h.264 which is patent-encumbered. Google took VP8, the successor to the popular VP7 codec and started The WebM Project. To quote the project page:
WebM is an open, royalty-free, media file format designed for the web.
WebM defines the file container structure, video and audio formats. WebM files consist of video streams compressed with the VP8 video codec and audio streams compressed with the Vorbis audio codec. The WebM file structure is based on the Matroska container.
Google describes the license as “BSD-style”. A very good move since it’s liberal enough to encourage widespread open and proprietary inclusion. GPL is to viral for some potential adopters.
Software Support
For the browser side, Chromium and Firefox Nightly builds support WebM starting today. Opera and Google Chrome to come shortly.
Google also created patches against FFmpeg for encode as well as decode and created DirectShow filters which are available for download. I suspect by way of libavcodec we’ll see support in lots of other products in the near future.
Microsoft will support VP8 in Internet Explorer 9 if you have the VP8 codec installed. Not quite “support”, but better than nothing.
Adobe is also supporting VP8 in Flash, which means content producers can eventually kill VP7 and VP6 encoding and use VP8 to reach most of their audience. This is very important as encoding videos into several formats is costly and time consuming (I know this very well).
Hardware Support
Google has already said they are working with video and silicon vendors to add VP8 hardware acceleration to their chipsets. I suspect newer phones in the near future will be supporting it. Especially if they run Android.
Content
Google is supporting WebM in the HTML5 test for YouTube which I mentioned a few months ago. I suspect we’ll see lots more support in the very near future.
Supporters
Even more telling of the potential than the above is the list of supporters which contains some big names who can put a lot of weight behind hardware/software/content support. AMD (who owns ATI), NVIDIA, Marvell (lots of mobile chipsets), Qualcomm (think mobile chipsets), TI, Broadcom, ARM on the hardware side alone is impressive. If the majority of them add hardware support to their upcoming offerings, that will be game changing. On the software side leaves 1.5 holdouts in the web video world: Apple (1) and Microsoft (0.5).
This is a game changer.
Google should use Google Wave against Facebook.
It’s not as crazy as it sounds. I will be the first to say I was unimpressed by Google Wave from a user point of view. I should note Google Wave was pitched as an email alternative, and it’s not great at that job. The technical perspective was pretty impressive. It is however a potentially killer distributed social media network. It will take slight retooling to adjust it for the task, but it is already better suited to compete against Facebook than against email.
It’s actually a pretty good alternative if the UI were better tuned to the task. Allow me to explain:
It’s close feature wise
I won’t go into point after point, but Google Wave can carry out many of the same things that Facebook can. It’s a good way to communicate in an open or closed fashion and each wave can already be granular in terms of privacy. It can be used to share much more than text. It can be used for the purposes of photos or video. It can be extended by third parties utilizing its API. It already has chat support. It’s built on XMPP. It can easily parody Facebook in almost every way already. It can be extended to do what it can’t today. Profiles are the biggest thing it lacks. I suspect that wouldn’t take much to add in. I’m thinking an extendable XMPP vCard from the technical side.
It’s distributed
Google Wave is hosted by Google, but it’s also an open protocol and Google’s releasing chunks of their implementation. That means they can partner with other large companies (AOL, Yahoo, Microsoft, Apple etc.) who can federate and let their users all instantly be part of one huge social network. Users already have “friends” via their address books for email. Importing from other sources is easy, just look how Facebook did it. If Google got AOL, Yahoo, or Microsoft to partner join them they would overnight reach a huge chunk of the Internet population via their e-mail users.
For those who are going to try and argue that Facebook users don’t have email addresses, yes they do. It’s a primary method of notifying users of things other than SMS and is required to signup for an account.
This also means you can host yourself, or use the provider of your choice. Your not subject to Facebook deciding your fate, or any one company.
It would be more private
One of the primary gripes against Facebook is its privacy measures are inadequate. Facebook has motives to force people to be more public. There’s little incentive to help you stay private, since the alternatives are slim. With Google Wave being hosted by several providers they will need to give you more control, or you will just move to a provider that will give you the controls you want. Just like with email. By using your own domain to point to a provider you would have portability of your identity. Once again Google Wave by design is more granular than Facebook. It’s based already around the concept of sharing data. What Google Wave really needs is a robust profile implementation with granular permissions and the ability to bucket contacts to make permissions more manageable.
Despite its UI and marketing pitch, it’s a surprisingly close Facebook competitor.
It would be a healthier ecosystem
Like I mentioned before, Google Wave has a fairly decent API already. What is great about it is that providers would be pressured to provide a robust enough API so that the killer apps exist on their platform. Again, no more reliance on a single source. By standardizing at least a subset of the API developers can target multiple providers and implementors. It also means providers will need to allow for more granular controls over privacy settings for third-party apps or once again, people will be switching.
Google wins too – keeps them in the center of the universe
Google likes to be the center of things, especially information. By doing this Google would still be able to organize a users information in meaningful ways for them, which is really what Google Wave’s main goal for Google is. Google has a major win. Anyone a user trusts to index their information can do so. If the user is paranoid, they can keep totally private. If you really want to be private you could run it on your own private server. If you don’t trust Google, you can avoid them but still join the party.
It would be more permanent
Facebook is still not guaranteed to be around in 10 years. Email however is overwhelmingly likely to still be around. Just like newsgroups and IRC still have their place, even if they aren’t as mainstream anymore. Why? Because they are all open standards and not tied to one companies profitability. I can still find and read old newsgroup posts from over 20 years ago. Feel that confident about Twitter? Facebook? foursquare? How much time do you invest in them?
What about dispora or _______?
diaspora is a clever effort and a noble one getting a lot of press today. It really is. But I think it’s to complex for real widespread adoption, especially in the era of easy to use web apps. It’s true that users flocked to P2P apps despite complexity but that’s because of no alternatives with less overhead. I’d give most of these efforts a 5% chance of any real success.
StarWars is copyright Lucasfilm
Anyone who cares about website performance comes to the quick realization that ads are a huge slow down. They are also the source of income for many websites. I somewhat casually mentioned back in December that Google was beta testing an async Google Analytics call. I found a bug in the early version but since updated it works extremely well and is non-blocking. It’s rather awesome.
Google AdSense like most ad networks is still a major slowdown. Often ads are implemented via a script which itself can include several other resources (including other JavaScript). Because it’s just a <script/> it’s blocking. It would be nice if AdSense would have an asynchronous version that lets you specify an element where it could insert the ad when loaded by passing an element object or id. It could then be non-blocking and speed up a large number of websites thanks to its popularity.
I can’t find any reason this wouldn’t technically be possible. It would make setup slightly more complicated, but the payoff for those who choose this implementation would be a faster website. Perhaps Steve Souders could poke the AdSense folks for a faster solution.
I’m also still hoping for SSL support. Another place where Google Analytics is ahead.
Categories
Google Conversion Madness
Google’s calculator is starting to bug me because it has some rather odd gaps. I finally decided to dig a little deeper. Take these conversions for example:
2 hogsheads in tierces – Works
1 chain in inches – Works
1 league in furlong – Works
1 MiB in MB – Fail
MiB is likely the most common unit of measure in this list. It’s also IEEE and CIPM endorsed I’m perplexed why this doesn’t actually work. Besides for Google engineers likely using that more themselves.
I know some Googlers read this blog. Please forward this appropriately.
Google has been a long time supporter of HTML5. They recently launched a HTML5 beta of YouTube however it will only work in Safari and Chrome. The reason for this is not due to the actual markup but the video codec chosen. YouTube is using h.264, the same codec used for YouTube HD via Flash. This works in Safari and Chrome because Safari uses QuickTime to render <video/> and Google licensed h.264 for Chrome. Firefox however doesn’t include the proprietary codec for licensing reasons. It’s not a matter of cost but principle.
IE is supported through “Chrome Frame” which is essentially the Chrome browser in IE’s chrome. Your really just browsing the YouTube site with Chrome. Google could use this as a way to get people away from Flash and IE and onto Chrome one way or another.
I discussed the h.264 debate in more depth a few months ago.
You have to wonder why we don’t want anything proprietary slipping into HTML5, or want proprietary image formats (GIF turned us off to that) but exceptions are made for video.
Edit 1/23/2010: More on the topic:
- Robert O’Callahan’s Video, Freedom And Mozilla
- Mike Shaver’s HTML5 video and codecs
Edit 5/21/2010: Thoughts on WebM.