somewhere to talk about random ideas and projects like everyone else


#chrome os

Google Won't Kill Chrome URL Bar 21 February 2011

I saw this article on hacker news and slashdot recently about how Google might remove the URL bar from future versions of Chrome. It’s almost definitely not true.

First off, the images are about Chrome OS. Not Chrome. The page doesn’t signal any intent to change the behavior of “Chromium-based browsers”. Side tabs and the contact nav bar make sense on Chrome OS because netbooks such as those Chrome OS is targeting tend to be really wide with very little vertical space. There’s also generally not much RAM so having lots of tabs isn’t practical.

The compact nav bar as it was known existed in builds of Chrome OS from late 2009 (when it was open sourced) and 2010. But it’s been discontinued and the page hasn’t been updated for almost a year.

A quick search on the chromium bug tracker for the compact nav bar shows that nearly all the bugs related to it have been marked WontFix. It’s been discontinued for over 7 months.

And please follow me on twitter.

HTML5 Offline Wikipedia Reader and Help me win a Cr-48 04 February 2011

690 (1)

So, lets begin with a plead for you to rate my submission (ideally favorably) for the LucidChart chrome notebook contest, partly because it would be awesome, and I need to test the aforementioned HTML5 offline Wikipedia dump reader.

Wikipedia is awesome, and on my service-less iPhone 2G, one of the most useful apps is one with an outdated (by something like three years) Wikipedia dump reader. There’s something very much like the Hitchhiker’s Guide in carrying the “sum of all human knowledge” in one’s pocket. Wikipedia grows really quickly and the English language dump (as of last month at time of writing) is over six gigs of bzipped XML.

Another reason for building an offline Wikipedia dump reader is simply that I can. There’s a lot of cool and cutting edge stuff in this. It uses the file input JS API, FileReader, Blobs, WebWorkers, fast Javascript to handle a pure-JS implementation of the LZMA compression algorithm, and the FileSystem API.

All this stuff has only been possible for a very short amount of time. In fact, the FileSystem API only arrived with the release of Chrome 9 today. It’s pretty awesome to imagine that a web page, HTML and Javascript is processing multiple gigabytes of data at real time. At the current unoptimized state, the search results and the article shows up instantly within 100ms of a key press event (However, I admit it has yet to be tested on the actual English Wikipedia).

This app is almost ideally suited for Chrome OS. A hundred megabytes worth of data in a month (with the Verizon deal, not to mention that it’s limited to two years) isn’t very much and it would be a pity for the sixteen gigabytes of SSD space on a Cr-48 to be wasted. One of the dumps that I’ve compiled is a subset of the English Wiktionary which makes a great lightweight (8MB) dictionary with over sixty five thousand words. Wiktionary is fairly large at 217MB, and the Simple English Wikipedia is 51MB.

Assuming you can somehow access the dumps, I probably won’t post them on this server because of the massive bandwidth usage, someone else could, the process for using it is very simple. Download the file to your computer through HTTP, a torrent, or create it yourself. You might have noticed that the favicon is a picture of a carrot because that’s the current codename. Well, not really a codename, but I was scrolling through some icon lists and saw one for a carrot on the first page. I don’t even like carrots, but I digress. The dump uploading screen has a picture of a bunny biting a file upload carrot that you click on to select the file. Select the file, and it automagically copies it over to a persistent folder. Then you’re off to searching and reading articles and definitions :)

I’m not done yet, or at least, I don’t feel like packaging it up and submitting it to the chrome webstore yet because I need to figure out a good way to host database dumps.

my ideas for a browser os are coming true. 08 October 2009

Yes, I know that the title is lowercase with a period in the end. It’s totally strange and inconsistent but it feels right.

Google’s working on a notification API for Chrome. Chrome has a Pin Tab feature. Firefox has Faviconize Tab. Gears has a basic privledge escalation (not very fine grained yet). Firefox shows UAC-type privledge escalation for storing data and Geolocation.

To review the old post, this is how I think Chrome OS might work. All user facing applications (all apps other than the window manager, kernel, browser, should be user facing) should operate in Tabs. There are two types of tabs, “pinned” tabs and normal browsing tabs. Pinned tabs are automatically loaded when the user is logged in, are only a tiny icon, but are still always visible.

There will be a unified and consistent way for the user to voluntarily grant privledges to a web site that requests it. It won’t be a catch-all i-totally-trust-this-app-to-every-bit-of-data-on-my-HDD sort of system that most operating systems use. It will be very fine grained, you can grant access to XHRs to a certain domain and huge warnings if the site requires access to the wildcard . The privledges can extend from just accessing the notification API, cross domain XHR, geolocation, and communicating with other tabs. Communication with other tabs should be dome something like cross domain XHR, by allowing the user to grant a tab access to a certain domain/url. I would prefer the permissions dialog to be something less of a modal window that is employed by Gears or the little thing that pops up on the top for Firefox, and more of a icon that subtly appears somewhere that the user can click voluntarily. I think a UAC type stop-what-youre-doing-to-show-a-scary-message dialog is horrible and makes the user incapable of deciding intelligently. If there were a button which would make a box filled with checkboxes and a green/red gradient safety bar with messages, and educating the user that he or she really *does not have to give the site permissions).

A typical application such as a mail notifier would be as follows

<!doctype html>
        <script src="jquery.js"></script>
                if(navigator.hasPermission && navigator.hasPermission("xhr","" && navigator.hasPermission("notify")){
                    $("#status").html("YAYNESS! You granted Awesomeness!").css("background-color","green")
                    $.ajax("", {user: $("#userid").val(), pass: $("#pass").val()}, function(data){
                    $("#status").html("no permissions!")
        <div id="status" style="background-color: red">No Permissions, please give me some super-powers?</div>
        <input id="userid" type="text" value="USERNAME" />
        <input id="pass" type="password" value="PASSWORD" />

        # Super Insanely Awesome Notifier!

        This is a super awesome notifier, if this doesnt work then you are an idiot or
        the internet isnt in the future yet. Here is where the about stuff and other stuff
        and stuffs that are stuffs can be put in! And if its not in the future, we all know
        the easiest way out is to blame microsoft for all our problems and say that at
        least google tried fixing our problems but it was all microsoft's fault.


The great thing about the thing above is that it gracefully degrades into a functionless web page if its not running in my imaginary super browser OS of the future. It’s quite easy to make and requrires no API documentation (or at least for me since there’s only 2 API calls and I just totally made them up). It’s similar to the Jetpack and Chrome extensions idea in which the developer has little to learn for making an extension, but lowers the barrier even more: There’s nothing to learn. Whats above is just a standard html5 web page with jQuery. The only thing different is the hasPermission and requestPermission functions which don’t exist so I made them up. It’s not that it has anythign different, its just that the developer is thinking of the web page as a background process instead of thinking of it as static content.

It’s the same idea is Google Wave, it could be a Wiki, IM, or Email, all depending on how you think about it.

For the permissions system, it really doesn’t matter how it’s implemented but it really has to eventually be done. The web is getting new abilities, and things like Geolocation, Local Storage, Offline SQL DB, Saving to disk, Reading files, and such all require special permissions (You wouldn’t want any random site uploading your SAM file from your hard disk). Each of them have their own modal type dialog which queries the user if they want to grant the permission. Eventually, things like Audio from microphone, Video from webcam, cross-domain XHR, and other peripherals like toasters get their own implementation, requiring special user granted permissions, an application may want 3 or more permissions simultaneously, it becomes very obvious a more consistent UI is needed for delegating these abilities.

For the interface, its easier for both users and developers. Developers dont need to do something like write complex xml manifests showing which location the file which shows the about text is and which one is the help. Here, you just have a web page that you put stuff in. Since the interface is the page. The tab/web page is a unified Install Page, Help Page, About Dialog, Credits, Donation Box, everything, but unified (sure you could split it into multiple pages if you wanted like with any other web page). Installing is just right-clicking on the tab and selecting the menu button that says “Pin Tab”. If the application requires special privledges, the user can click the icon which show you what the site wants, and you just check off whatever you feel the site deserves.

How I Would Design The Browser 2 Addons 21 August 2009

So I was watching Aza Raskin’s TechTalk on Jetpack, and I was thinking on how I would design an extension system. I would have to say to not have one, it’s just too complex, and why restrict the sound recording functionality to a taskbar. Even worse, why fragment the API and require someone to use Flash or <audio> in the page space and have a nice jetpack.future.import(“audio”) for a taskbar?

I think a good idea would to expose the power to web pages. The page could request special capabilities through a magical button dropdown or bouncy annoying notifier on a corner of the page saying permissions, populated by checkboxes of whatever features that the page wants to be able to use.

I think bookmarklets are almost perfect. Adding some more greasemonkey-like features would make it just about perfect. Scripts can run with the same permissions as the page, and the page’s permissions can be granted easily by the user (and the permissions persist through refreshes and browser restarts). Again, if functionality is not supported, things can gracefully degrade with partial functionality.

After that, is the idea of background tabs or alternatively, merging the statusbar type widgets into the tab bar. This is logical with everything merged into the page, and allows things to gracefully degrade if they don’t support the feature. You also get the benefits of being able to reorder remove, get info (which would be the contents of an extension page), etc. I think the interface for a plugin that operates in the background (like a gmail notifier) would be just a small tab that only has an icon, with special flag that makes it run on browser start (I think this could be one of the things for the permissions panel).

So one problem I see in the way Jetpack works, is that it doesn’t easily allow you to make a jetpack that hacks another running jetpack. Sure you can “fork” it, but that defeats the purpose of extensions, rather than having extensions only 1-level deep, make it work all the way down. The easy way I see is just to use the bookmarklet philosophy, and everything can mess around with anything within the page. So if you have a GMail notifier, that came out before the tab persist feature existed, you could just add a simple bookmarklet-type-greasemonkey thing that adds something to the permissions box that says “Persist Page” and then the user could check that in order to make a background GMail Notifier that runs on browser startup.

Malware is easy to fight now. Imagine if every application was forced to have a icon in the taskbar of windows at all times. Finding malware is as easy as looking for things you dont want running and closing it. And if some tab-bar autohide is to be implemented on the system, only people who are quite experienced would use 10+ extension/notifier pages and it would still be easier to recognize than finding some other strange wcultns.exe or whatever when half of the system things look like that.

With these features, Browser as an OS would really make sense. I wouldn’t be suprised if Google Chrome OS implements some stuff that are similar to what I’ve listed here.