How the audio is played is interesting:

<div id="embed-container">
  <audio autoplay="autoplay" id="html5Player"></audio>
  <div class="goog-ui-media-flash">
    <embed wmode="window" pluginspage="http://www.macromedia.com/go/getflashplayer" type="application/x-shockwave-flash" seamlesstabbing="false" allowfullscreen="true" allowscriptaccess="sameDomain" bgcolor="#000000" flashvars="" src="r/musicplayer.swf" class="goog-ui-media-flash-object" name=":0" id=":0" quality="high" style="width: 1px; height: 1px;"></embed>
  </div>
</div>

You’re reading that right. That’s a HTML5 <audio/> tag. First time I’ve seen it appear in a major product. However as of this writing in Firefox, Safari, and Chrome on Mac OS X the Flash player seems to be used. I suspect, but can’t confirm that this may indicate a future intent of using HTML5 <audio/> in place of Flash. Flash is likely the default for now. But it’s still very interesting to see.

The audio itself seems to be 44,100 Hz 320 kb/s MPEG Layer 3 (MP3) audio. The samples I’ve looked at were encoded with LAME 3.98.2. Obviously if they intend to use HTML5 audio they will need to offer something other than MP3 at least for Firefox users. It’s not currently possible to serve everyone without multiple encodings. I don’t see that changing anytime soon.

The servers serving the media seem very similar to YouTube’s delivery servers for H.264 video. It’s progressive download, again just like YouTube. No DRM. I suspect there’s a shared history between this delivery system and YouTube or a very strong influence. But knowing how Google works, there’s likely a shared backend.

It’s pretty good stuff. I highly recommend checking it out. Google built a decent mp3 player in the cloud.

I’m still looking at it myself, but my first impression is that the point of another language is buried in the details of the announcement. This particular sentence I think is the focal point (emphasis mine):

• Ensure that Dart delivers high performance on all modern web browsers and environments ranging from small handheld devices to server-side execution.

I suspect the real goal behind Dart is to unify the stack as much as possible. Web Development today is one of the most convoluted things you can do in Computer Science. Think about just the technologies/languages you are going to deal with to create a “typical” application:

• SQL
• Server Side Language
• HTML
• CSS
• JavaScript

That’s actually a very simple stack and almost academic in nature. “In real life” Most stacks are even more complicated, especially when dealing with big data. Most professions deal with a handful of technologies. Web Development deals with whatever is at hand. I’m not even getting into supporting multiple versions of multiple browsers on multiple OS’s.

Google even said in a leaked internal memo:

- Front-end Server — Dash will be designed as a language that can be used server-side for things up to the size of Google-scale Front Ends. This will allow large scale applications to unify on a single language for client and front end code.

Additionally:

What happened to Joy?
The Joy templating and MVC systems are higher-level frameworks that will be built on top of Dash.

By using one language you’d reduce what a developer needs to know and specialize in to build an application. This means higher productivity and more innovation and less knowledge overhead.

This wouldn’t be the first attempt at this either for Google. GWT is another Google effort to let developers write Java that’s transformed into JavaScript. This however doesn’t always work well and has limitations.

The web community has actually been working on this in the other direction via node.js which instead takes JS and puts it on the server side, rather than inventing a language that seems almost server side and wanting to put it in the browser.

Google still seems to have plans for Go:

What about Go?
Go is a very promising systems-programming language in the vein of C++. We fully hope and expect that Go becomes the standard back-end language at Google over the next few years. Dash is focused on client (and eventually Front-end server development). The needs there are different (flexibility vs. stability) and therefore a different programming language is warranted.

It seems like Go would be used where C++ or other high performance compiled languages are used today and Dart would be used for higher level front-end application servers as well as the client side, either directly or through a compiler which would turn it into JavaScript.

Would other browsers (Safari, Firefox, IE) consider adopting it? I’m unsure. Safari would likely have a lead as the memo states “Harmony will be implemented in V8 and JSC (Safari) simultaneously to avoid a WebKit compatibility gap”. Presumably IE and Firefox would be on their own to implement or adapt that work.

New languages rarely succeed in adoption. On the internet the barrier is even higher.

For my younger readers, Chrome 10 is an “ancient” version from March 2011. This is back when Obama was still in office, the United States was in a recession, there was a debt problem in Europe, hipsters carried their iPads in man purses… These were crazy times.

For whatever reason this Chrome install, like a number out there didn’t update. It could be security permissions, it could have been disabled for some reason. I really don’t know, or care terribly much. The reality is not everyone can update on release day regardless of opinions on the matter.

Go try and find Chrome 10 Mac OS X on the internet. Try using a search engine like Google. Now try and find it for any platform. Good luck. It’s a pain. I can get a Phoenix 0.1 binary from Sept 2002 (this was my primary browser for part of fall 2002, I used it before Firefox was cool), but I couldn’t find Chrome 10 from way back in 2011. I was eventually able to trace down a Chrome 10 binary, work around the problem and move forward however it took way more time than it should have.

This to me illustrates a few key points:

• Version numbers still matter – They matter. Simple enough. Even in a rather sterile environment that this was, I had to deal with an older browser. They exist in larger quantities out in the wild web. Saying they don’t matter anymore is naive. Idealistic, but naive.
• Make old platforms available – Just because you ship a new version doesn’t mean the old one has no relevance or need anymore. Google lost some serious credit in my mind for making it nearly impossible to get an “older” version of Chrome to test with. This shouldn’t be difficult. Google is said to have approximately 900,000 servers. Surely they can setup an archive with an explicit notice it’s an archive and user should download the latest. Mozilla’s got less than that.

The web is a fluid platform. Browsers are evolving platforms. Versions still matter as long as two things, the web at large, and the platform that is the browser need to interact. When version numbers no longer exist, it will likely be because monoculture is so strong it doesn’t matter. Until then, knowing what browser and what version will matter. Browsers will likely never agree 100% on what to implement and a timetable for implementation.

That image is a joke if you can’t tell. Google Chrome Developers are good people, they just need to put together an archive page for web developers.

My observations/conclusions/insights (if you can call it that) can be found after the raw data.

Backend

Frontend

Frontend (cont)

Observations

I retooled this for 2012 based on how web development and the internet has changed as well as the data that’s available. The most noteworthy thing is that EVERY campaign uses open source. Perhaps it’s saving money in this economy? Windows Server isn’t free after all. Most use it extensively. Regardless who wins, that candidate would be very hypocritical to support the (unlikely regardless) “open source is communism” mantra. If this isn’t proof that open source is as mainstream as ever in America, I don’t know what is. Apache is a huge winner. So is jQuery, WordPress, Drupal, even Nginx and Varnish made a showing (they weren’t even on the radar in 2008).

Lots of websites are using the HTML5 doctype now. That doesn’t mean they are using HTML5, but many are moving in that direction. Web Fonts were spotted. Tables were very rare.

Shockingly, CDN usage and HTTP compression were pretty rare. Given Google will host popular javascript frameworks (jQuery for example), if you can’t afford the CPU to gzip data you could let Google host it for free. Lots of cloud hosting though.

Between popular CMS’s, and popular plugins/modules for those CMS’s, there’s little diversity in these sites this time around. It was obvious last time, it’s much more obvious this time. Mono-culture has set in regarding the technicals of these sites.

One thing that really stood out is the amount of analytics on each site. This election is really a data war. Knowing as much as possible about voters and the candidates base. Clearly this is an escalation from 2008. There is also a proliferation of real-time analytics usage this time around. Data is everything in the business world, it’s becoming that way in campaign websites as well.

Misc Notes

Data collection method: The data for this blog post was mostly done on the evening of August 30, 2011 and August 31, 2011 by myself. The character set was however Firefox 6.0 interprets the page. HTML validation was checked by submitting to the W3C validator. All other analysis was done by eye and using tools like cURL. Some things were a little bit of a judgment call, such as CSS layout. I didn’t generally penalize if a table was used, it depends how it was used, and the context. I viewed source on all of them, and spent some time looking around while collecting data. I didn’t view every page on every site, since that would drive me insane. The data is based on the homepage of the site however I did make a brief attempt to hunt for feeds since some only include a link on a “news” page. If I couldn’t find it quick enough, it doesn’t exist.

Secrets In Websites III?: Yes there will likely be a third installment. I don’t know when, I don’t know what will be included. I do have some ideas and notes. It takes time to put these together, and I’m not exactly drowning in free time these days.

* Roy Moore’s website is Flash in an iframe. For purposes of this analysis I’m using the page containing the flash object.

Couldn’t do this better if I tried.

The first thing I found was the hostname where the request originated was out-sw251.tfbnw.net which is obviously owned by Facebook. That’s not terribly interesting and supports my theory up above.

Then I found these two curious bits in the request:

X-FB-USER-REMOTE-ADDR: 66.249.67.211
USER-AGENT: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

That IP address is crawl-66-249-67-211.googlebot.com. That UserAgent is very telling and needs no introduction.

The request is otherwise pretty unremarkable other than no query string which a normal person would generate when hitting that canvas URL. However fb_sig_request_method is set to GET which suggests to me it’s actually using POST despite that what it claims. There’s no fb_sig_user or anything else that would suggest an actual user, which makes sense because fb_sig_logged_out_facebook is set to 1.

It appears as of March 20, 2011 Google has started crawling Facebook Apps. I’ve got no idea what it’s intent, abilities or relationship is. I can tell you that I’ve monitored since at least April 2010 and this only started a few days ago.

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.

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.

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.