Kyle Graehl

Testing does this work

2019-08-03T00:00:00+00:00

Testing if this works. 1 2 3.

My Devtools wishlist

2016-04-13T00:00:00+00:00

This mostly regards Chrome apps and extensions. When a window is created that previously had the devtools open, it remembers that the devtools were open, and reopens devtools. Unfortunately there is some delay and the devtools have not yet attached, so they will miss catching any exceptions for the first few hundred ms or so.
Turn off editing in source window. 99% of the time I don’t want to edit in the source window, I want to type something in the console. I would like to turn off editing and have keyboard focus be on the console window. Currently I press escape twice about every time I focus in the devtools to force focus on the console window.
An option to make a sound when we enter the debugger. Ding!

MP4Cast for Google Cast

2016-04-06T00:00:00+00:00

I’ve just released a new Chrome App, MP4Cast. I started working on it when I noticed there was no way for me to stream a locally stored mp4 video from my ARM Chromebook directly to my Google Chromecast™.

Actually, it sort of was possible. I had to spin up Web Server for Chrome, select the directory containing the file, then make sure the options were set to allow connections from other computers, then find the exact media URL, and then find a way to tell Chromecast to play that URL. Not a very friendly experience!

So to simplify that, I built MP4Cast.

You can read more about it on the MP4Cast help page. You can use it today, all you need to do is visit www.mp4cast.com

Web Server for Chrome

2015-10-01T00:00:00+00:00

I just put a new user interface on my Web Server for Chrome. I used the post 1.0 Polymer release and a few paper components. The documentation for Polymer is a little obtuse for somebody like me who just wants to code a UI without learning the detailed inner workings of Polymer. But altogether it was OK.

If you’re ever in need of a basic static web server, definitely give it a try! It’s open source with a MIT license and available on github

Ever since Chrome 44 went stable about a month ago, ChromeOS has had the ability to open up the firewall. So now the web server app can also serve files over the local network on a Chromebook. Pretty useful!

Sorry facebook, I can't keep your mobile app installed

2014-09-21T00:00:00+00:00

I have a few friends who don’t use facebook, at all. Well perhaps one day I will manage this myself, but for a number of reasons I haven’t yet managed this. I do look forward to the day that facebook is no longer relevant to my life.

But I have done one thing that nobody else I know does. I have uninstalled the facebook app from my android phone and haven’t missed it in the slightest. I now use the mobile facebook website instead. There are three main reasons for this

I don’t like all the permissions the app requests.

I’m generally paranoid about permission prompts and like to reduce the number of apps which have access to essentially all data on my phone and all sensors on my phone.

Facebook messenger. I was so annoyed when I could no longer read or send facebook messages within the app.

I don’t want to have two facebook apps installed, both with more permissions than any other app except possibly google services. Also I have a low end phone and this is slow.

Links opening in a webview.

This is the straw that broke the camel’s back. After clicking on open in the actual web browser several times, I decided it was over.

So what are the drawbacks of using the facebook mobile website instead of the native app? For me, there are none. Horay!

ISO Extractor Chrome app

2014-09-11T00:00:00+00:00

I have been using a Chromebook for my main computer for a long time now. Every once and a while I have a strange itch I need to scratch. Most recently, I had an ISO file that I needed to extract some files from.

Now of course the ISO 9660 file format is not exactly one that many using ChromeOS need to know about, let alone want extract files from. But for some reason I wanted to write an app that would let me extract the files.

ISO Extractor - Available on the Chrome Web Store

ISO Extractor Source code on Github

My first step was to find a nice library that had minimal dependencies and would be easily translated into javascript. I found a small Python library on github iso9660.py which looked perfect. Only it uses generators (yield) semantics for iterating over files, which would not easily translate into javascript. What to do?

I pull out the trusty google-traceur-compiler which lets you compile ECMAScript6 which has generators into standard javascript.

First, I needed to have something that behaves like cStringIO on a file. I need to .seek() and .read() synchronously. Javascript gives us FileReaderSync which must be run in a web worker.

Then, I needed an equivalent to python’s “struct” module. I found a node.js module by tjfontaine and proceeded to make minor modifications to translate from node’s Buffer objects into standard javascript DataView and the .getUint8(position, isLittleEndian) family. You can use my modified jsstruct.js if you ever need to do something similar. I didn’t translate the .pack() stuff, only the .unpack() things.

When debugging breakpoints traceur-compiled javascript code that uses generators, it looks like a horrible mess (unreadable state machine case statements). However, if you go to chrome://flags and enable experimental ES6 javascript, you can simply run the generators without the aid of traceur, and you can step through your code normally. Almost. As it turned out, hitting a breakpoint inside a generator function inside a web worker was causing chrome to crash. Maybe this will be fixed in the future.

In the end, I was able to get a directory listing of the files within an ISO, which seemed good enough for a days work, so I released the app and see that it’s getting about 10 installs per day. Which means maybe I’ll add some more functionality, like the ability to extract and save files from the ISO image.

Chrome fileSystem notes

2014-02-26T10:00:00+00:00

(Update – I found out what the problem was. The app was being “suspended” and I was not listening for the event. When an app is suspended, nothing is guaranteed to work anymore). So make sure and listen for the chrome.runtime.onSuspend event!

I’ve been trying to fix a bug in JSTorrent for the past few days. The problem I’m seeing is that an HTML5 DirectoryEntry reference becomes “stuck” – doing any sort of request against it like .getFile() or .getMetadata() simply does not fire any callbacks. I’ve rewritten the whole Disk I/O subsystem of JSTorrent, hoping to get better insight into which conditions trigger this “broken” state.

One thing I’ve started doing is keeping a cache of FileEntry objects and re-using those. That seems to work pretty well. I haven’t run into any issues re-using a FileEntry reference, even when the underlying file changes due to other processes writing to or truncating the file.

However, if you do the same thing to the result of a FileEntry.file() (the actual File object on which you can do .slice() and use a FileReader to do reads), the reference becomes invalid once the underlying file is modified in any way (even “touch”ing the file will make the file reference invalid)

Originally I wanted to use the synchronous versions of all these APIs because that would have been much simpler. But unfortunately there is no way to pass a FileEntry to a web worker, (https://code.google.com/p/chromium/issues/detail?id=242373), and you need a FileEntry to be able to do file operations (currently you call FileEntry.createWriter and get a FileWriter object).

Experiment: what happens when you have a cached DirectoryEntry and somebody moves the file? It fires the error callback to whatever you try to do on it.

Privacy Guardr chrome extension

2014-01-22T16:01:00+00:00

Update Dec 1 2014 - Changed name of app from Privacy Guard to Privacy Guardr due to trademark conflict with privacyguard.com

Today I am releasing a very simple Chrome extension, Privacy Guardr.

Recently there have been a few articles about malware extensions in the Chrome Web Store. Of course, malware and spyware has been rampant in the Chrome Web Store for quite a while already.

Lifehacker recently featured an article about an extension “ExtShield” that notifies you if you have one of a set of known malicious extensions installed.

The funny thing about ExtShield is that this extension could very well be malware itself. For it requests the most dangerous permission an extension can ask for (Access to all data on all websites), and it has no reason to ask for this permission. It simply does not need it in order to function.

I have had the idea to do a simple Chrome Extension that simply identifies which installed extensions have “high risk” permissions.

So I am announcing Privacy Guardr, a free extension in the Chrome Web Store. I am releasing it now with a minimal set of functionality because it is, I believe, more useful than something like ExtShield. For one, the source code is freely available, and it also does not make use of hard-coded lists of known “bad” extensions. It simply helps you by giving you all the information in a glance and lets you filter extensions and apps by their “risk level”

For example, the Pinterest Pin it Button Chrome extension is a high-risk app, because it requests the “Access your data on all websites” permission. This app is the perfect example of an app that is flagrantly requesting more permissions than it needs. The proliferation of apps that request these permissions where they are clearly not needed (they can use a browser action instead) contributes to numbing users to the gravity of the permission grant.

The “Access your data on all websites” permission means that the extension can steal any authentication tokens, capture every keystroke on every website, and do so rather undetected.

So, make your reasonable voice heard, and re-evaluate whether you need to have high risk extensions installed. At the very least, take a look at who is publishing the extension and make a judgement as to whether you can trust the publisher.

I have a few ideas for more features to add to the Privacy Guardr extension. I want to store the publisher data and be able to notify the user when an extension’s publisher is changed. I also would like to be able to mark certain publishers as exempt (for example, if you want to trust all Google apps and extensions). And of course, I want to add actions inside the app to disable and remove extensions. I may also incorporate lists of extensions known to have bad behaviors (injecting ads without notice, stealing affiliate links)

tldr; Give Privacy Guardr a try.

Using Chrome Platform app chrome.fileSystem.retainEntry

2013-12-04T14:01:00+00:00

I’ve been tweaking JSTorrent to add support for writing directly to user selected directories.

In the manifest file, you need to add the “write”, “directory”, and “retainEntries” permissions. The documentation is here

The tricky part is handling external media. There’s a way to get events when external media is attached and detached. You need to request “system.storage” permission. Docs here

Unfortunately the directory “Entry” given by chrome.fileSystem.chooseEntry with the {type:”directory”} option does not give any information as to whether the directory selected by the user resides on an external storage or the internal storage of the device.

This could be a very poor user experience. A torrent job would simply show some kind of “storage error” and not be able to tell the user that they need to re-attach a specific external storage device.

The documentation for chrome.* APIs is spartan as usual, so it leaves developers to explore all the edge cases and make guesses as to whether these are accidental or intended and with unit tests backing these behaviors.

When the storage is detached, a call to chrome.fileSystem.restoreEntry will NOT fail! However, when trying to do some kind of access on the machine that would require actually accessing the device, such as trying to read the entry’s metadata, you will get the error callback.

So it’s at least possible to infer that a given retained Entry may be from a detachable storage, if doing a getMetadata call returns a NotFoundError. However this error also occurs when the selected directory is renamed or removed (incidentally, if a new directory is created and has the same absolute path on the same disk, it can be accessed and written to via retainEntry, even though the actual inode is different)

So the moral of the story is – to the retainEntry mechanism, there is really no difference between external storage not being available, and a directory simply being removed from the SSD/internal disk. I guess that’s pretty elegant, after all. So simply messaging “directory or external disk missing” is the simplest solution. Maybe only displaying “or external disk” if chrome.system.storage.getInfo shows there was in fact an external disk present when the user called chooseEntry.

Use yielding (await) in javascript today, with traceur!

2013-08-27T12:01:00+00:00

Javascript is pretty annoying sometimes, especially when writing a lot of callbacks. If you’re feeling adventurous, try out the ultra awesome traceur compiler which lets you use ECMAScript Harmony features today.

Boilerplate code (traceur.js and bootstrap.js from traceur)

<html>
<head>
    <script src="https://traceur-compiler.googlecode.com/git/bin/traceur.js"
        type="text/javascript"></script>
    <script src="https://traceur-compiler.googlecode.com/git/src/bootstrap.js"
        type="text/javascript"></script> 
    <script>
      traceur.options.experimental = true;
    </script>
</head>
<body>
<script type="text/traceur">

The “traceur.options.experimental” is to enable the “await” keyword, which is what we’re going to show off.

And now some boilerplate code to wrap the async XMLHttpRequest into a “Deferred” (a Promise).

var simpleGet = function(url) { 
  var deferred = new Deferred(); // traceur defines this
  var xhr = new XMLHttpRequest(); 
  xhr.onreadystatechange = function() { 
    if (xhr.readyState == 4) { 
      deferred.callback(xhr);
    } 
  }; 
  xhr.open('GET', url, true); 
  xhr.send(); 
  return deferred; 
};

Now here’s the cool part that we’ve been waiting for. You can now write code that looks synchronous, but doesn’t block the event loop. This is a definite readability win, as opposed to minor gains you get with things like CoffeeScript.

The Grand Finale

var url = 'http://example.com/api';
function run() { 
  var result;
  await result = simpleGet(url);
  console.log('GOT IT...', url, result);
}

run()

If you’re already compiling your application into javascript, you might as well do it with traceur and get some actual cool features (unlike CoffeeScript, which only gives you ambiguous looking syntax that omits parenthesis with function calls, ick)

Have fun, and be safe!

Here is what the compiled code for run() ends up looking like:

function run() {
  var $that = this;
  var $state = 4;
  var $storedException;
  var $finallyFallThrough;
  var result;
  var $value;
  var $err;
  var $result = new Deferred();
  var $waitTask;
  var $G = {
    GState: 0,
    current: undefined,
    yieldReturn: undefined,
    innerFunction: function($yieldSent, $yieldAction) {
      while (true) switch ($state) {
        case 4:
          ;
          $state = 5;
          break;
        case 5:
          console.log('REQUESTIN...');
          $state = 7;
          break;
        case 7:
          $waitTask = simpleGet(url);
          $waitTask.then($createCallback(1), $createErrback(2));
          return;
          $state = 1;
          break;
        case 1:
          result = $value;
          $state = 3;
          break;
        case 2:
          throw $err;
          $state = 3;
          break;
        case 3:
          $state = 9;
          break;
        case 9:
          console.log('GOT IT...', url, result);
          $state = 11;
          break;
        case 11:
          $result.callback(undefined);
          $state = -2;
          break;
        case -2:
          return;
        case -3:
          $result.errback($storedException);
          $state = -2;
          break;
        default:
          throw "traceur compiler bug: invalid state in state machine" + $state;
      }
    },
    moveNext: function($yieldSent, $yieldAction) {
      while (true) try {
        return this.innerFunction($yieldSent, $yieldAction);
      } catch ($caughtException) {
        $storedException = $caughtException;
        switch ($state) {
          default:
            $state = -3;
            break;
        }
      }
    }
  };
  var $continuation = $G.moveNext.bind($G);
  var $createCallback = function($newState) {
    return function($0) {
      $state = $newState;
      $value = $0;
      $continuation();
    };
  };
  var $createErrback = function($newState) {
    return function($0) {
      $state = $newState;
      $err = $0;
      $continuation();
    };
  };
  $continuation();
  return $result.createPromise();
}

Good thing we did not have to write that code!

Make sure to go check out the traceur project on github and show your support for their badassery.

Chrome extension rants, optional permissions, and chrome.tabs

2013-08-18T10:53:00+00:00

If you are the type that writes extensions that request access to “access my browsing tabs and history” or “all data on all websites” or “all data on my computer and all websites I visit” then please stop reading now. Go ahead and request your permissions and I will happily refuse to accept them.

For people like myself, slightly more mindful of exposing myself to unnecessary security risks, please read on. The main reason why chrome extensions are so tricky is because optional permissions are a relatively new feature, and many of the APIs are simply easier to use when you have full access to everything.

I have been hacking on a chrome extension for the past few days for a hack project. I have not written an extension before (having only done chrome platform apps , i.e. jstorrent). Compared to packaged apps, chrome extensions are hard. Content scripts are a pretty weird thing, and I am spending as much time on stack overflow and chromium issues as I am in my editor.

Some things I’ve learned:

chrome.tabs is a complex beast

chrome.tabs is available even without any special permissions. But you won’t know the URLS for updated tabs. If your extension wants access to only a single domain (i.e. www.myapp.com) and you want to inject content scripts there, I found it wasn’t reliable doing it in the manifest with the “matches”. Perhaps I could write a test app and file a bug report. But this method is not flexible enough anyway.

Rather than using the manifest origin matching to inject content scripts, doing it manually allows for added flexibility. With chrome.tabs.executeScript, you can have your extension request additional access (say <all_urls>”) and now inject on those pages. This is not possible with manifest based pattern matching.

Each time you see a chrome.tabs.onUpdated, attempt to execute code from your (background) event page

// keep a "PID" for the background page, so that the content script
// can know if the background page was updated. Maybe also include the
// version number, so a content script can know if the extension was
// updated.
var backgroundPID = Math.floor(Math.random() * Math.pow(2,31))

chrome.tabs.onUpdated.addListener( function(tabId, changeInfo, tab) {
  var updateInfo = {pid:backgroundPID,
                    event:'onUpdated',
                    changeInfo:changeInfo,
                    tabInfo:tab.status}
  chrome.tabs.executeScript(tabId, 
                            {code: "var updateInfo="+
                                    JSON.stringify(updateInfo)+
                                    ";[updateInfo,window.location.origin]" }, 
                            function(results) {
    if (results === undefined) {
       // we didn't have access to this tab's origin
    } else {
       var injectedContentScriptInfo = results[0]
       // then we have window.location.origin information 
       // for all content scripts which we were allowed to access

       // now inject the actual content script, which will have access to relevant updateInfo 
       // (so it will know not to run twice, etc)
       chrome.tabs.executeScript(tabId, {file: "your_content_script.js"}, function(content_result) {
          // do other things if you want
       })

    }
  }
}

Of course this method has a distinct disadvantage. If you look in your background page’s console logs, you’ll see a lot of errors “Cannot access contents of url…”

There is a chrome.tabs.query which will return a list of tabs matching your host query, but it has no edge triggered option. Perhaps if you star this issue we will see some improvement on this front.

Event pages are cool

From that page: “the performance advantages are significant, especially on low-power devices.” I wonder if this means extensions on ARM devices, like androids is to come in the near future.

Spotify skip track chrome extension

2013-08-15T14:07:00+00:00

Update - the more advanced extension (Spotify Web Extension has remote-control abilities. It uses Google Cloud Messaging to setup a push channel. When you want to remote control another computer, my server wakes up your extension using the channel, and then sets up a relay between the two (a WebSocket connection on both ends).

I just published a very simple extension to skip to the next track in the spotify web player. Here is the chrome web store link. The source code is also on github.

Make sure to set a keyboard shortcut for easiest use (go to the chrome extensions page (type chrome://extensions in the URL Bar) and on the bottom click “Keyboard shortcuts”. Enjoy!

I’m working on a more featurefull extension that will allow you to do more than just skip tracks :-)

finally using my pixel!

2013-08-14T10:11:00+00:00

The other day I stayed home nursing my tennis back and had left my work computer (a macbook pro) at work, so I had to make do with my secondary computer, a chromebook pixel I picked up at Google I/O.

I really liked the hardware of the machine and when I first got it I tried crouton but was annoyed that the touchscreen didn’t work very well in X11. You have to run ChromeOS’s fancy window manager system (called Aura) and a special Chrome browser build to enjoy all the benefits of the multitouch screen.

I did manage to settle on a development environment that suits me alright.

Little known tip. Shift-Control-plus and Shift-Control-minus do a GLOBAL zoom in/out. If you want more screen real estate quickly then you can use your tiny display as if it were a full 2560 monitor. Super useful!

First of all, enable developer mode. Then follow crouton instructions to setup your linux “VM” (a chroot actually) at crouton.

I recommend setting a chromeos root password as well as using encryption for your chroot for added security. (otherwise any other local user would be able to inspect the data in your chroot, which means anyone with physical access would be able to look at your shit pretty easily)

Now you’ll want a terminal: hterm/crosh window

Open your terminal (ctrl-alt-T in Chrome) and open the developer tools, and go to the javascript REPL. Disable the audible bell

term_.prefs_.set('audible-bell-sound', '')

If you’re an emacs user, you’ll want to set some other options ( found from hterm FAQ )

term_.prefs_.set('alt-backspace-is-meta-backspace',true)

That makes emacs alt-backspace actually delete a word.

term_.prefs_.set('font-size', 13)

I found the default font size of 15 to be too large.

Now you’ll probably want to use tmux because it’s such a pain to bring up more terminal windows inside your chroot.

# inside your ~/.tmux.conf
# allow scrolling through history buffers
set-window-option -g mode-mouse on
# I use C-b a lot inside emacs, so 
# rebind tmux to use C-t, which I never use
unbind C-b
set -g prefix C-t

If you want to use an X11 program from aptitude ( say you download an MKV using jstorrent and want to use VLC to watch it), you can do so using the useful “host-x11” command that prints out some environment variables that you can set and then run the program in the current X server. Best to put it in your ~/.bashrc

eval $(host-x11)

I’m not used to using terminal emacs (have used emacs with the gtk interface for a long time) and I end up opening a lot of separate emacs processes. Copy/paste between them is a pain, so I ended up using some clipboard functions to allow copy/paste (remember to “apt-get install xsel”)

I am sometimes wondering if the fan is turning itself on too aggressively and harming my battery life. /sys/devices/virtual/thermal has a bunch of devices. I would like to try manually disabling the fans on occasion. But I’ll hold off on that

If you use an SSH passphrase, Another nice thing to put in your ~/.profile would be a keychain. apt-get install keychain and then you won’t have to type in your ssh key (your SSH key does have a passphrase, right?)

keychain --attempts 3 -q ~/.ssh/id_rsa
. ~/.keychain/$HOSTNAME-sh

Saving a torrent to your cloud

2013-02-08T00:00:00+00:00

I finally have a working prototype of saving a torrent to your cloud disk. The motivation for this was to be able to consume torrent content while on an iOS device, such as an iPad. Check out JSTorrent.com. (Note: the iOS App store does not approve of “torrent” apps, so we need to put the app in the browser instead) this is not working anymore, as BitTorrent, Inc. disabled websocket connection access to their clients Please go complain on their forums and complain :-)

On your first visit, you’ll be prompted to sign into your google account. Don’t worry, it will only ask for access to write and read from files in its own sandbox. It doesn’t even ask for your identity or other information.

It’s a major pet peeve of mine when applications ask for permission to do a lot more than I care to let them have access to, so rest assured I am not interested in spying around your files, and I don’t even ask that you trust me that I won’t.

Anyway, the drill is as per usual. Find a torrent URL somewhere on the web, paste it into the text input box at the top, and you’ll now be saving the files not to your local disk, but be streaming them directly to your google drive. Currently any gmail user will have a google drive automatically, I think it gives you something like 2GB for free (Then $2.50/month for 100GB)

You can inspect the upload progress by clicking on the files tab. There’s a column that represents the fraction of data for that file that’s been uploaded to the cloud drive.

Once it’s saved, you’ll see icons for opening and saving the files from the cloud drive.

I’ve started to add support to saving to your DropBox, which has a similar client side javascript library.

All hail the static web app that uses javascript APIs.

Next time – will be adding WebRTC DataChannel functionality so you can share files directly with other browsers.

Torrent in a google chrome packaged app.

2013-01-14T00:00:00+00:00

I finally released something based on the jstorrent code.

You can download the packaged app from google play. If you’re not aware, packaged apps are like browser extensions, only they get their own top level window. As of the date of this writing, they are not searchable within the google app store that you find in your chrome browser, but should be at some point. There is an ongoing discussion thread on google groups for commonly encountered issues.

It’s pretty neat, having access to raw sockets. The goal of jstorrent is to work with any type of connection, be it websockets, webrtc, or raw sockets. I like the abstraction of an “IOStream” that I picked up while working with tornado.

    function IOStream(host, port) {
        this.host = host;
        this.port = port;
        this.sockno = null;
        this._closed = null;
        this._connected = false;
        this._created = false;
        chrome.socket.create('tcp', {}, _.bind(this.oncreate, this));
    }

    IOStream.prototype = {
        oncreate: function(data) {
            this.sockno = data.socketId;
            _.bindAll(this, 'onconnect','do_read','send','onsend','got_read');
            chrome.socket.connect( this.sockno, this.host, this.port, this.onconnect );
        },
        onconnect: function(data) {
            if (this._closed) {
                return;
                // BUG in implementation
            } else {
                this.onopen(data);
                this.do_read();
            }
        },
        do_read: function() {
            assert(! this._closed)
            assert(! this._connecting);
            chrome.socket.read( this.sockno, 4096, this.got_read );
        },
        got_read: function(data) {
            if (this._closed) {
                return;
                // BUG in implementation
            } else if (data.resultCode < 0) {
                this.doclose();
            } else {
                this.onmessage({data:data.data});
                // somehow onmessage can close the connection... (bad data?)
                if (! this._closed) {
                    this.do_read();
                }
            }
        },
        send: function(data) {
            chrome.socket.write( this.sockno, data, this.onsend );
        },
        onsend: function(result) {
            if (result.bytesWritten > 0) {
            } else {
                this.doclose('did not write all data');
            }
        },
        doclose: function(reason) {
            this.onclose({});
            if (this._connected) {
                chrome.socket.disconnect(this.sockno);
            }
            chrome.socket.destroy(this.sockno);
        },
        close: function(reason) {
            this._closed = true;
            // cancel pending read?
            this.doclose('called close');
        },
    }

Neat. The chrome.socket implementation seems to be pretty undocumented at this point so I had to make a few guesses with the edge cases but this class lets me use it in about the same way I would use a websocket stream.

Currently I’m working on adding functionality to download to a cloud storage provider (Google drive first, Dropbox and others later) so that browsers without filesystems can still consume torrents. It’s kind of a pain, because pieces can span multiple files and I want to make sure I don’t have any memory leaks. Working with streams is rather tricky. And handling error states with resumable uploads will add even more complexity.

After that, implementing a WebRTC stream class will be a game-changer! Well, maybe. At least it’ll be a good example use case for WebRTC. Really though, I think the best use cases for WebRTC are real time games. It would be neat for example to see Warcraft II ported to the browser and maybe have the connection to your friend be initiated like it was back in the good old days, by dialing a phone number. The browser based version should make the modem baudrate handshaking song, too, for added effect.

Predicting the future?

2013-01-14T00:00:00+00:00

My brother pointed out this article at http://squid314.livejournal.com/352406.html. The author makes the point that prediction markets could be the most efficient and accurate way to reliably predict the future. A prediction market is some kind of system where you can bet on future outcomes based on hypotheses.

It’s an interesting thought experiement to think that I could, instead of investing my money in markets or specific companies or stocks, that I could invest in very specific things that match my idealogical interests. I have some vision for how things should or could be in the world and I put money behind my hypothesis, that if say a certain legistlation or law or initiative is adopted, then a favorable measurable outcome can result. Or, alternatively, if not adopted, a measurable and less favorable outcome will result. I view it as a kind of altruistic gambling.

You can play with such prediction markets at http://www.intrade.com. There are currently many asinine questions on there like “Will Lincoln win best picture.” As such, it has apparently been classified as off market trading or gambling by the US govt and I think it’s not currently advisable or possible to trade inside the US.

Personally, I hardly see how buying shares in AAPL vs betting that Les Miserables wins best picture are much different. I suppose it has something to do with there being no oversight into the obvious type of corruption that could result from this type of trading.

What the article seems to be arguing, though, is that with enough liquidity, that these problems are self-correcting?

BitTorrent video streaming in your browser

2012-12-07T00:00:00+00:00

This post contains outdated information! Proceed reading with a grain of salt. I’ve abandoned trying to get torrents working on the open web platform :-)

I started working on an HTML5 torrent client a few months ago when I had the realization that if enough BitTorrent clients would accept WebSocket connections, it would be possible to download pieces directly from a desktop torrent client to your web browser. There would be several advantages to being able to participate it BitTorrent swarms in the “naked” web. By naked, I mean without any special plugins or software. A whole new set of users could participate in the BitTorrent ecosystem. From those who are unable and who are unwilling to install custom desktop software, to those who are stuck in walled gardens, but especially for those who don’t know or don’t care what a torrent is.

There were a number of challenges I encountered when developing the prototype. The most difficult problem is the lack of wide browser support for the FileSystem API. Google Chrome provides this very convenient and stable and usable interface. The only complaint I have is that it does not support sparse files (i.e. seeking far into a file and writing without having to manually fill in a lot of null bytes). I was very disappointed when I read Mozilla’s arguments against the implementation. There are polyfills that make use of IndexedDB, but they have severe limitations for my use case, which needs to support files up to multiple gigabytes in size.

I went ahead anyway implementing the protocol and saving files to the browser sandbox filesystem, intent on supporting only the Chrome browser for the time being. The code to the first prototype of the browser torrent client is available. You can see the app hosted at jstorrent.com. It also can be loaded as a Chrome packaged app and will make use of the chrome experimental socket API.

I currently work at BitTorrent, which maintains the popular µTorrent client. Updates to these clients are slow and methodical, so most clients as of this date are still unable to accept Websocket connections (this will be rolling out in version 3.3). If you have been following the latest developments with WebRTC, you’d know that Firefox and Chrome are rolling out the DataChannel API, which will also allow for browsers to connect directly to each other. You can bet µTorrent will learn to speak WebRTC, too.

For purposes of demonstration, I decided to write a small embeddable html page that attempts to stream a video from a BitTorrent swarm directly in your browser. Since it is still not possible to connect directly to most swarms until µTorrent 3.3 usage is widespread, these make use of a custom proxy server that behaves much like websockify.

<iframe width="500" height="300" 
src="http://jstorrent.com/examples/embed_window.html#hash=f8049a655273f6a000be2bb2119716bcd4c741bc" 
frameborder="0" allowfullscreen="1"></iframe>

Embed window:

Click to load embed window (Chrome only)

Basically, we are downloading data from the swarm and saving it to the HTML5 FileSystem storage, then creating a video element and sourcing it to that file.

Since the file is not completely downloaded, the video element will not be immediately playable. Some javascript code running in a web worker attempts to parse the MP4 box format (borrowed code from broadway, see this fascinating article). We download, somewhat unintelligently, from the beginning and end of the file in order to get the important video metadata information that the webkit video player needs to be able to start playing.

When seeking to somewhere in the middle of the file, we need to manually calculate using the mp4 keyframe and time to sample tables which byte offsets the video player will actually use, and prioritize downloading that data from the swarm.

The implementation is very much at an early prototype stage, but it would be interesting to see how good the performance could be if each stage in this process were optimized. For example, it would be better to make use of the new MediaSource API being developed by Microsoft, Google, and Netflix. And it would be much better if every torrent video was encoded in multiple bitrates so that it could be compatible with MPEG-DASH.

I am currently working on a prototype to add support to other browsers (such as iOS Safari) that lack the FileSystem API. Instead of saving back to a local disk (which happen to be relatively small on mobile devices anyway), it would save to Google Drive or Dropbox’s multipart upload APIs.

If this sounds interesting to you, I would tell you that BitTorrent is a great place to work. BitTorrent provides options, not rules.

Non-blocking UDP in Tornado web's IOLoop

2012-12-07T00:00:00+00:00

I’ve always enjoyed working with Tornado Web, the python web framework that is centered around the idea of using non-blocking sockets. It is a very versatile framework for working with asynchronous streams and I’ve used it to write a number of applications, including proxy servers, media streamers, and even BitTorrent clients. But tornado is noticably lacking in UDP support. This is fine, of course. After all, it is an HTTP library.

When you would like to do some non-blocking UDP stuff using tornado, all you need to do is use this custom “UDPStream” class that I wrote. It acts a lot like tornado’s IOStream class.

class UDPStream(object):
    def __init__(self, socket, in_ioloop=None):
        self.socket = socket
        self._state = None
        self._read_callback = None
        self.ioloop = in_ioloop or IOLoop.instance()

    def _add_io_state(self, state):
        if self._state is None:
            self._state = tornado.ioloop.IOLoop.ERROR | state
            self.ioloop.add_handler(
                self.socket.fileno(), self._handle_events, self._state)
        elif not self._state & state:
            self._state = self._state | state
            self.ioloop.update_handler(self.socket.fileno(), self._state)

    def send(self,msg):
        return self.socket.send(msg)

    def recv(self,sz):
        return self.socket.recv(sz)
    
    def close(self):
        self.ioloop.remove_handler(self.socket.fileno())
        self.socket.close()
        self.socket = None

    def read_chunk(self, callback=None, timeout=4):
        self._read_callback = callback
        self._read_timeout = self.ioloop.add_timeout( time.time() + timeout, 
            self.check_read_callback )
        self._add_io_state(self.ioloop.READ)

    def check_read_callback(self):
        if self._read_callback:
            # XXX close socket?
            self._read_callback(None, error='timeout');

    def _handle_read(self):
        if self._read_timeout:
            self.ioloop.remove_timeout(self._read_timeout)
        if self._read_callback:
            try:
                data = self.socket.recv(4096)
            except:
                # conn refused??
                data = None
            self._read_callback(data);
            self._read_callback = None

    def _handle_events(self, fd, events):
        if events & self.ioloop.READ:
            self._handle_read()
        if events & self.ioloop.ERROR:
            logging.error('%s event error' % self)

The basic use of this class is illustrated in the following code snippet.

import socket
udpsock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
udpsock.setblocking(False)
udpsock.connect( ('tracker.openbittorrent.com', 80) )
s = UDPStream(udpsock)
s.send( 'some data' )
data = yield gen.Task( s.read_chunk )

complaining about osx window manager again

2012-08-30T09:22:00+00:00

The past few days I’ve had an external monitor plugged into my macbook. It’s been nice having more real estate.

But now I’m sitting in a comfortable chair away from my monitor trying to do some work. But there’s too many windows! And I can’t move them around!

I want my dream setup – virtual desktops that I can page around by just moving the mouse to the edge of the screen. Why does osx only let me page desktops horizontally? And why isn’t there an option to page between the screens by moving the mouse over there?

I want more options, not fewer!

reinventing the flat tire

2012-08-27T14:34:00+00:00

http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/240003442

I love reading that leads to intense cognitive dissonance. Alan Kay says the web was created by “amateurs” and is headed in the wrong direction.

It’s too bad his vision of computing wasn’t better understood.

I would love to read more about Kay’s views on the web!

mozilla falling behind?

2012-08-27T14:18:00+00:00

I thought I would see how Mozilla’s browser would work with my new app using the HTML5 FileSystem API.

I install Firefox. Eww, no retina support still. Okay… let’s see how the app works. Oops… Mozilla hasn’t implemented the FileSystem API yet. I was led to a discussion on https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/.

It seems Mozilla is a bit behind! The arguments against the FileSystem API are weak. No file locking? Not interested! All the operations are asynchronous anyway. Oh, you have a competing effort underway, the “Web API”? First off, that is a terrible name for an API. So generic. Second, why are you guys documenting some C++ classes for some dreamed-up API instead of participating in WHATWG discussions?

Still, I’m interested in seeing what they come up with. But I suspect they won’t have enough manpower to come up with anything more compelling than what’s already been implemented under Chromium

waiting for WebRTC DataChannel

2012-08-27T11:17:00+00:00

I have been spending some time recently with Websockets, and while they’re quite powerful (the latest spec supports sending javascript byte arrays), they still have one rather limiting problem: two browsers still cannot communicate directly to each other.

I work with peer-to-peer software as a part of my job. Having WebRTC’s DataChannel API available would make my life such a pleasure.

http://stackoverflow.com/questions/10218250/transfering-json-between-browsers-with-webrtc

According to some comments on that page, I may have something to work with by the end of the year. Here’s hoping!

It seems like there may be some very unexpected and important privacy implications. Browsers have never had true peer-to-peer capabilities before.

I hope nobody worries too hard about this and the first implementations are simply pulled into the Chromium source.

coping with osx

2012-08-27T10:56:00+00:00

I have been very happy with me new Macbook Pro with fancy retina display. The screen is beautiful and the pleasure it affords me is not unlike having some cold sweet cream melting on my tongue. Only on my eyes.

Allow me to complain about how the OS, OSX, is failing me…

moving windows around is too hard (have to navigate my cursor to the top of the window title)
resizing windows is too hard (have to move to the very corner of the window)
moving windows between desktops is too hard (have to wait around on the edge for about 1/3 a second)
etc etc

I lose so much time just because the window manager is so rigid.