Tom Mollerus' Weblog

In today's day-two keynote speech at Google I/O, Sundar Pichai announced that "Chromebooks" were coming to market from Samsung and Acer. Chromebooks, aren't laptops or even netbooks; instead, they're better defined as web clients running in a laptop-like form factor. Given that a majority of my time is spent on the web and that a significant portion of my applications are web-based, I can believe that an OS that consists of only a browser can be a success. After all, with an 8-second boot time, an 8-hour battery, and less installed software to grow corrupt as it ages, Chromebooks are going to be very appealing to users who currently use slow, old laptops which take a while to boot.

But here's one extremely interesting aspect of the Chromebook specs as listed on the feature pages for the Samsung and Acer models: there's no specification of hard drive size. It's internal storage isn't even mentioned.

What an incredible development in computing. If you're going to access all of your applications from the web, you may as well keep all of your files there, too. You'd only have to upload them anyway. Plus, it makes the whole "portable computing" concept a lot more practical. On the Chromebook platform, any user can conceivably use any Chromebook to do their work. Just log in (with your Google account, of course), and no matter whose Chromebook you're on, you have access to your accounts, apps, settings, and files. You couldn't do that if the Chromebook had local versions of your files.

So do Chromebooks need a hard drive? I'm sure they need some manner of long-term storage, but they're right that it's becoming pointless to list it as a spec.

While Eric Meyer was talking humorously about the "dark side" of CSS, he mentioned a really interesting fact: most modern browsers will "lie" to you when reporting properties of visited links via JavaScript. For instance, if your current stylesheet specifies that unvisited links are blue and visited links are purple, and your code try to access the color property of a link that's been visited, it won't return the value for purple; instead, it will report that the link's color is... blue. The same will happen for any property that you can access for a visited link: background image, background color, font face, size, etc. So why did browser makers do this?

Eric's example of why browser makers would do this was that in authoritarian countries which restrict and monitor Internet access, a government might be interested in trying to monitor which URLs people visit. If that government can inject a script into each page requested from their country, or if they can control the browser or operating system (let's think China), then they have one more method of tracking which URLs a particular user has visited. It doesn't sound efficient, but it's possible.

I think I have a more accurate guess as to why this has been done: XSRF, or cross-site request forgery. This was an exploit that was discovered a couple of years ago, and it works by a script causing your browser to request a URL, perhaps to a site that you're already logged in to, for someone else's benefit. For instance, if a malicious script created a link on a page you were browsing, and could detect that you had visited it, it could then initiate a JavaScript event that caused your browser to make a friend request on Facebook, or purchase something on eBay, or share your email address book on GMail, or reset your password on NYTimes.com to something the script owner knows about.

If you're concerned about online privacy, and don't like the thought of your ISP capturing the content of your browser traffic, then you should access your favorite websites via https whenever possible. Enter the EFF's HTTPS Everywhere Firefox Extension, which ensures that you are accessing sites like Google search, Wikipedia, and Facebook securely whenever possible.

Get it at https://www.eff.org/deeplinks/2010/06/encrypt-web-https-everywhere-firefox-extension

We're all used to hyperlinks to web sites (http://) and email addresses (mailto:), but as mobile devices become more popular, you might find yourself needing to use some other types of links. If so, check out Apple's short, succinct reference for creating links for some of the less common resources such as calling telephone numbers (tel:), sending SMS messages (sms:), or even linking to iTunes (http//: again, but calling Apple's phobos.apple.com server should open up iTunes on the user's device).

http://developer.apple.com/safari/library/featuredarticles/iPhoneURLScheme_Reference/Introduction/Introduction.html#//apple_ref/doc/uid/TP40007899

You've probably heard of Apple's HTML5 showcase by now, but not for the reason that Apple hoped. Instead of showing off the latest capabilities of Apple hardware and software, the site has garnered criticism for promoting HTML5 and web standards while requiring the use of Safari to view the demos.

Even though this issue hit the blogosphere last week, I just came across these entries in Apple's own Safari Web Content Guide which show just how hypocritical this move really is:

Follow Good Web Design Practices

You should follow well-established rules of good web design...

• Be browser independent.
  Avoid using the user agent string to check which browser is currently running. Instead, read Object De- tection to learn how to determine if a browser supports a particular object, property, or method, and read Detecting WebKit with JavaScript to learn how to detect specific WebKit versions. Also use the W3C standard way of accessing page objects--that is, use getElementByID("elementName"). Only as a last resort, use the user agent string...

There are better ways to promote Safari than to make users believe that Safari is the only browser that supports HTML5. I wouldn't blame them if they told users "For the best experience, use Safari", or if they directed users to download Safari without intimating that it was required.

One of the nice features in Android and the iPhone is that you can save website bookmarks to the home screen with an icon that looks like any other app, giving web apps the same look as installed apps. But just how do you indicate which of your icons the mobile device should use?

When specifying an icon to display in a browser's tabs or address bar, we've long had a short and simple set of choices either a rel
<link rel="icon" href="/path/to/some.png" />
<link rel="shortcut icon" href="/path/to/some.ico" />

But for mobile devices, there are a few more tags that you will come across. Besides the shortcut icon tags mentioned above you have these choices:
<link rel="apple-touch-icon" href="/path/to/some.png"/>
<link rel="apple-touch-icon-precomposed" href="/custom_icon.png"/>

Android versions 1.5 and 1.6 will read the second tag (with "-precomposed"), and versions 2.1 and newer will read the first tag. Apple's and Google's specifications say that you should use 48x48 pixel PNGs, but you can use a large image, like Google does for its own apps, for a crisper result.

Unfortunately, even if you use these tags, your icon won't always show up correctly on Android. If your web site uses SSL but the certificate is expired or doesn't match your domain, then a standard bookmark icon will appear instead of your icon. And on HTC-manufactured phones with the Sense UI, you'll only see your icon as a small overlay on the bottom left of the regular bookmark icon. I hope that HTC and other manufacturers change this behavior in the future.

Lastly, there are a few configuration tags which Apple supports that Android has yet to implement (though I'm not sure whether they're each applicable).

Indicate whether to hide the browser's status bar on startup:
<meta name="apple-mobile-web-app-capable" content="yes" />

Indicate the color of the browser's status bar:
<meta name="apple-mobile-web-app-status-bar-style" content="black" />

Indicate an image to display while the mobile web app is loading:
<link rel="apple-touch-startup-image" href="/path/to/some.png" />

Christine Tsai of the Google I/O team has posted a note about next year's I/O conference: May 10-11, 2011 at Moscone West. As an attendee of the most recent conference, I can definitely say this conference is well worth going to. It's a great place to learn about the latest technologies such as web fonts, web video, mobile platforms, and HTML5.

Brad Neuberg gives an excellent summary of just which specifications and technologies are part of the concept that's been given the nebulous label of "HTML5". If you ever wanted to see a definitive list of what's new on the web without trying to slog through the specification, read his post.

According to analytics provider StatCounter, FireFox 3.5 has surpassed the market share of IE7 and IE8 for the first time. That's good news if you like the idea of diversity in the browser "ecosystem", and great news for Firefox fans and web standards devotees. But looking at the trends indicated in StatCounter's graph, I'm not sure whether Firefox's top position will continue.

David Pogue just posted a great list of tech tips for the basic computer user. The only one I would have added would be the key-commands for a screen grab. Here are a few highlights:

Why did Google go to the effort to create their own browser, named Chrome? If you read Google's own explanation of why they built a browser, here's the essential part of what you'll read:

"At Google, we spend much of our time working inside a browser. We search, chat, email and collaborate in a browser. And like all of you, in our spare time, we shop, bank, read news and keep in touch with friends - all using a browser. People are spending an increasing amount of time online, and they're doing things never imagined when the web first appeared about 15 years ago.

Since we spend so much time online, we began seriously thinking about what kind of browser could exist if you started from scratch and built on the best elements out there. We realized that the web had evolved from mainly simple text pages to rich, interactive applications and that we needed to completely rethink the browser. What we really needed was not just a browser, but also a modern platform for web pages and applications, and that's what we set out to build."

Certainly that's an admirable goal of helping end users. That's what puts Google in such an enviable position in the Internet space-- any time that the size or the use of the Internet increases, they stand to gain from the inevitable need we all have to get help in navigating the web. Google is the helpful, ubiquitous traffic sign on the information superhighway.

But is their intention with Chrome completely selfless? I don't think so. One part of Chrome's default homepage is labelled "Search your history".

This made me wonder: would Google capture a user's browsing history on their own servers to use for their own purposes? Reading Chrome's privacy policy, a few of the bullets are revealing:

"...Google Chrome features send limited additional information to Google:

• When you type URLs or queries in the address bar, the letters you type are sent to Google so the Suggest feature can automatically recommend terms or URLs you may be looking for. If you choose to share usage statistics with Google and you accept a suggested query or URL, Google Chrome will send that information to Google as well. You can disable this feature as explained here.
• If you navigate to a URL that does not exist, Google Chrome may send the URL to Google so we can help you find the URL you were looking for. You can disable this feature as explained here."

It seems clear to me that Google is collecting the browsing history of anyone who is using Chrome. Whether that's a good thing or a bad thing, I'll leave up to you. Personal browsing histories which used to be isolated to your own computer would now be stored on Google's own servers as well. What happens to that remote data when you want to delete your own history-- does it stay in Google's datacenters? What might someone malicious do with that information if they ever had access to it?

I know that Google has disclosed this information in their privacy statement, but to me it seems to come close to running afoul of their corporate motto, "Don't be evil".

Internet Explorer 8 Beta introduces a new live bookmark feature they call "WebSlices". WebSlices actually subscribe you to portions of a Web page. It's a pretty cool idea-- with some easy mark-up in your page, you can allow users to subscribe to subscribe to your site's information without creating an extra RSS feed. And, users can view the feed not as a text list in a grey menu, but as a slightly larger window with its original HTML/CSS formatting. It's kind of like a graphical RSS feed, but without the work of maintaining the feed.

So you've heard about IE8 and how it implements standards mode, right? Unless you add a specific meta tag to your page that indicates to IE8 that it should render pages to its full capability (<meta http-equiv="X-UA-Compatible" content="IE=8" />), it will render them as if it were IE7 instead. And it's set the web industry abuzz with wonder and discussion. Why would you upgrade a browser with new capabilities but have them turned off by default?

Jeffrey Zeldman says that Microsoft is just guaranteeing that future versions of IE (8 and onward) will work with the existing sites of "millions of small business owners, school teachers, pastors, coaches, and so on who create websites every day, armed with crappy software and little else." That could be true, but does Microsoft really care about those millions of small-time content creators? After all, they've never seemed to care too much about all of us professionals.

But I think that Joel Spoelsky put it best in today's article, Martian Headsets (a.k.a., pragmatists versus idealists). Joel points out that it's not the web designers, professional or not, that Microsoft is worried about: it's the end user. He argues that if end users were come down to their desktop computer in the morning after it's been automagically Microsoft Updated to IE8 in the middle of the night, and if IE8 were set to standards mode by default, then most of the sites people viewed would break. And who or what would these end users blame? The creators of the web site which looked so good and worked so well just the previous day? Nope.

They'd blame IE8. And perhaps, just perhaps, IE would lose some market share.

Now I think that makes sense as a reason for Microsoft to be cautious in how IE8 renders sites. They probably don't care too much about making life easy for professional developers-- after all, we all know how to add a meta tag to a site pretty easily, and who knows, some of use will make some money off of it. Microsoft probably doesn't even care about the small business owners and coaches who-- let's face it-- wield little money and even little influense in the technology industry. But I can't blame them for not wanting to "break the web" for users.

Look at Joel's article, it's well worth a read.

It still happens these days that every so often you have to write different code for different browsers-- you might output different form controls for Firefox versus IE, or might write in different stylesheets for older browsers, or you might write out different JavaScripts for IE5 on the Mac. So what's the easiest way to tell which browser and OS is calling your page?

Obviously, you can look through the server's CGI variables too see this information. But you don't want to parse through it every time you have an if-else condition, so I suggest identifying this information once per request or even just once per session with the following code:

<!--- Get the user's platform and browser --->
<cfif CGI.HTTP_USER_AGENT contains "MSIE">
	<cfset REQUEST.userAgent = "IE">
<cfelseif CGI.HTTP_USER_AGENT contains "Opera">
	<cfset REQUEST.userAgent = "OP">
<cfelseif CGI.HTTP_USER_AGENT contains "Safari">
	<cfset REQUEST.userAgent = "SF">
<cfelseif CGI.HTTP_USER_AGENT contains "Netscape">
	<cfset REQUEST.userAgent = "NS">
<cfelseif CGI.HTTP_USER_AGENT contains "Gecko">
	<cfset REQUEST.userAgent = "MZ">
<cfelse>
	<cfset REQUEST.userAgent = "NS">
</cfif>

<cfif CGI.HTTP_USER_AGENT contains "Mac">
	<cfset REQUEST.platform = "Mac">
<cfelseif CGI.HTTP_USER_AGENT contains "Linux">
	<cfset REQUEST.platform = "Linux">
<cfelse>
	<cfset REQUEST.platform = "PC">
</cfif>

Afterwards, you can just refer to REQUEST.userAgent and REQUEST.platform to get the user's environment.

But while it all sounds convenient, syncing my history, tabs, and windows is about all I would allow it to do. I mean, there's a reason that saved passwords and cookies were written with local filesystem security-- they're not meant to be shared across different computers through a network. Sure, the Browser Sync extension encrypts your data, but I just don't want my history, cookies, and passwords stored on anyone else's systems. After all, encryption once thought to be "unbreakable" has been broken plenty of times before.

So I may use Google Browser Sync, but if I do I'm going to use it in a very limited fashion. The convenience of having my passwords and cookies synced is not worth the security risk of having them stored elsewhere on the 'Net.