Archive for the ‘Nonsense’ Category

This is the story of the Fullscreen API, one of prefixes, capitalization, and event targets…

March–October 2007: “Shouldn’t the video API include a way to toggle full screen on/off?” asks Mihai Sucan, a mere month after Opera’s debut of the video element. Much is said about the security implications of such an API, nothing happens, and years pass…

November 2009–March 2010: Eric Carlson (Apple) adds an API for fullscreen video to WebKit:

partial interface HTMLVideoElement {
  readonly attribute boolean webkitSupportsFullscreen;
  readonly attribute boolean webkitDisplayingFullscreen;
  void webkitEnterFullScreen();
  void webkitExitFullScreen();

The webkitbeginfullscreen and webkitendfullscreen event are fired on the video element.

The inconsistent capitalization is noticed and fixed by adding webkitEnterFullscreen() and webkitExitFullscreen() aliases. The original names are kept for backwards compatibility.

Revisions: 50893, 54143, 55946

June 2010: Robert O’Callahan (Mozilla) begins working on a proposal to allow any element, not just video, to go fullscreen.

August 2010–January 2011: Jer Noble (Apple) implements something similar to the then-current Mozilla proposal in WebKit:

partial interface Element {
  const unsigned short ALLOW_KEYBOARD_INPUT = 1;
  void webkitRequestFullScreen(unsigned short flags);
partial interface Document {
  readonly attribute boolean webkitIsFullScreen;
  readonly attribute boolean webkitFullScreenKeyboardInputAllowed;
  readonly attribute Element? webkitCurrentFullScreenElement;
  void webkitCancelFullScreen();

The webkitfullscreenchange event is fired on the current fullscreen element and bubbles.

Revisions: 66251, 75277

September–December 2011: Chris Pearce (Mozilla) begins implementing the proposal in Gecko. Meanwhile, Anne van Kesteren (then Opera, now Mozilla) starts working on a spec at the W3C. The fullscreen element stack is introduced, which makes nested fullscreen (e.g. video in a presentation) possible. When exiting from nested fullscreen, it now becomes un-obvious which element(s) to notify, so the event target is changed to the document.
Revisions: 1c36dc1c92c5, 332cd2925b28

These spec changes are implemented in Gecko, but the old names, and mozFullScreen, are kept:

partial interface Element {
  void mozRequestFullScreen();
partial interface Document {
  readonly attribute boolean mozFullScreen;
  readonly attribute boolean mozFullScreenEnabled;
  readonly attribute Element? mozFullScreenElement;
  void mozCancelFullScreen();

The mozfullscreenchange event is fired on the document and bubbles.
Bug: 545812

March 2012: Jer Noble implements the W3C spec in WebKit:

partial interface Element {
  void webkitRequestFullscreen();
partial interface Document {
  readonly attribute boolean webkitFullscreenEnabled;
  readonly attribute Element? webkitFullscreenElement;
  void webkitExitFullscreen();

Notably, the webkitfullscreenchange event target is the fullscreen element, not the document. Because the event bubbles, listening on the document does work, though.
Revision: 111028

September 2012: The Fullscreen API moves to the WHATWG. The W3C version has been unmaintained ever since.

November 2012: Opera 12.10 is released with support for the spec as it was in February, without prefixes. Opera 12 is the last major version based on Presto, so this unprefixed implementation does not last long.

May 2013: Vincent Scheib (Google) questions why the events bubble. Since it is just an accident of history, they are made to not bubble in the spec.
Commit: 5eb5af63369385c888a5146dda57d462cb9a41da

October 2013: Internet Explorer 11 is released with an ms-prefixed fullscreen API:

partial interface Element {
  void msRequestFullscreen();
partial interface Document {
  readonly attribute boolean msFullscreenEnabled;
  readonly attribute Element? msFullscreenElement;
  void msExitFullscreen();

The MSFullscreenChange event is fired on the document… and bubbles! Most likely the implementation predates the spec change.

Now: This is a bit of a mess! The long history of changes in capitalization and event targets has given JavaScript library authors ample opportunity to write code that will fail once the unprefixed API is made available. I’m trying to implement and ship the unprefixed Fullscreen API in Blink, and some bumps in the road are likely.

Read Full Post »

Media playback restrictions in Blink

Blink and WebKit have a setting for requiring a “user gesture” to play or pause an audio or video element, which is enabled in Opera for Android, Chrome for Android, the default Android browser, Safari for iOS and probably other browsers. This makes some sense, since mobile devices are used in public and in bed, where unsolicited sound from random Web sites could be a nuisance. Also, autoplaying video ads would waste bandwidth.

The trouble is that this gets in the way of reasonable use cases like games or playlists, and developers are not impressed. We’ve discussed this a lot internally at Opera, and as an experiment we’ve removed the restrictions in Opera beta for Android.

However, I’ve also found a workaround for current browsers. As of WebKit r108831, all restrictions are removed in the first successful load() or play() call. Any user gesture is accepted, so one can listen to all input events and remove the restrictions as soon as the user clicks, touches or uses the keyboard. One does not need to start playback at that point, but can wait until a later time. For example, one could “liberate” a number of audio elements for later use in a game.

I’ve prepared a demo of the workaround. It works in current versions of Opera, Chrome and Safari. While it does not work in the default Android browser prior to KitKat, even there it could be adapted to e.g. autoplay background music by calling play() instead of load() in the input event handler.

Given this, I think that either a user gesture should be required for every play() or the restrictions should be removed completely. My tentative suggestion is the latter.

Read Full Post »

One month in Blink

On October 1, I began working in Opera’s new Web Technology team, tasked with improving the Web platform by contributing to the Chromium and Blink projects. Most of my effort has been on the Blink side, and it has been a very pleasant experience so far. Since I’ve worked so much with <video> before, I jumped right into that area and looked for things to work on. Chromium/Blink is a big code base which will take time to get intimately familiar with, but I was still able to make small improvements in a few areas.

Event handler attributes

My colleague Henrik reported that onplay and friends were missing on HTMLMediaElement, and I thought it surely would be easy to fix. However, I am easily distracted, so instead of just adding them I decided to implement GlobalEventHandlers and WindowEventHandlers, which ended up taking me 11 commits and even requiring IDL code generator (Perl!) changes. Now onplay is supported, but you probably don’t want to use it – use addEventListener(‘play’, func) if uncertain!

While in the neighborhood, I also made the onerror attribute on <body> and <frameset> work per spec. I was a bit surprised to find this broken, presumably it isn’t that important for site compat…

Removing features

Although I’m quite happy with Blink code, I was surprised to find how much non-standard stuff there is, including prefixed APIs, undocumented quirks and things that have been removed from the spec. Fortunately, the Blink project is supportive of removing these things, with care, and I’ve now picked most of the low-hanging fruit on HTMLMediaElement, getting rid of a weird npr.org quirk, webkitPreservesPitch, webkitHasClosedCaptions, webkitClosedCaptionsVisible, startTime and initialTime.

Counting features

When there’s a risk that removing a feature is going to break the Web, the first step is to figure out by how much. UseCounter counts (opt-in) which features are used on each page view, so I went ahead and added/improved counters for various things that would be nice to eventually remove: a bunch of prefixed HTMLMediaElement APIs, the TextTrackCue constructor, the beforeload event and the two (!) prefixed fullscreen APIs. There’s also the media attribute on <source>, which is still in the spec, but getting usage data will help us decide whether to remove it.

Fixing bugs

It’s a beautiful thing when you can fix a bug just by removing code, and I did so this month by removing the width and height properties from the <video> intrinsic size logic. After my fix intrinsic size is still not per spec, but at least it’s less wrong.

In my only non-trivial Chromium contribution, I made CookieMonster wait for disk flush when deleting cookies, so that cookies are really gone when the UI says they are. This involved fixing a flaky test, which was fun.

Loading text tracks

I began looking into <track> and WebVTT and soon stumbled upon a FIXME in TextTrackLoader, which is what feeds data to the WebVTT parser. Unable to resist the bait, I refactored TextTrackLoader to use RawResource and removed TextTrackResource. Finally, I fixed some other minor issues and fiddled a bit with the TextTrack IDL.

One year ago

Also this month, one year has passed since my final commit in Core (Presto), which was on October 12, 2012. I was a little bit sad when I noticed this anniversary, but at the same I’m really happy about working on Chromium and Blink. Hopefully the next month will be even better!

Web Technology

The Web Technology team (source)

Read Full Post »

Weird commit log

I stumbled upon something strange on page 895 of Swedish TV4′s teletext:


This is clearly counting the number of commits in source code repositories, but why is this information in the teletext system?

Read Full Post »

Favorite podcasts

About a year ago I discovered the delights of listening to podcasts, and I have done so practically daily during my commute. Unfortunately, the screen on my phone recently went black and for a while I thought my feeds were lost. I did eventually managed to extract them, so now I’m making a public backup, in the form of podcast recommendations:

60-Second Space (RSS) is one of several bite-sized podcasts from Scientific American. Since it’s so short I seldom remember anything, but when queued up it can serve as an overview of recent space news.

Discovery (RSS) is a science podcast from the BBC.

Freethought Radio (RSS) is a podcast with news, music and interviews from the Freedom from Religion Foundation. The news is rather US-specific, so I just pick the episodes with interesting interviews.

Humanistpodden (RSS) is the official podcast of Humanisterna, a Swedish secular humanist organization. Some episodes are in English, e.g. the excellent interviews with Ophelia Benson and Peter Singer.

Little Atoms (RSS) is a “talk show about ideas and culture.” The host sounds like a really nice guy, maybe it’s the British accent?

Planetary Radio (RSS) is the Planetary Society’s show with news and interviews. It sounds very scripted and a bit dry, but the actual content is interesting.

Red Planet Radio (RSS) is a newly launched podcast from the Mars Society.

Science Talk (RSS) is a science podcast from Scientific American.

Science Weekly (RSS) is a science podcast from The Guardian.

Skeptoid (RSS) is my probably my favorite podcast, see my previous post for episode recommendations.

Språket (RSS) is a Swedish radio show about the Swedish language, and is what got me started listening to podcasts.

StarStuff (RSS) is by far the best space podcast that I have found. The host, Stuart Gary, has a nice Australian accent and appears to be incredibly knowledgeable when interviewing the authors of recent papers, etc.

The Atheist Experience (RSS) is actually a call-in TV show from Austin, Texas, but I listen to it as a podcast. I recommended episode #795 on Twitter, with my favorite hosts Tracie Harris and Matt Dillahunty.

I’ve prepared an OPML file with all 13 feeds for importing. I can recommend DoggCatcher for Android if you don’t already have a podcast player.

Read Full Post »

Favorite Skeptoid episodes

Skeptoid is an excellent podcast for a skeptical treatment of paranormal claims, conspiracy theories, alternative medicine, etc. Over the past 8 months or so I’ve listened to every episode up to and including #376, and I thought I would share my favorites. The most reward episodes have often been those challenging my own beliefs, since those open the door to learning something new.

Happy listening!

Read Full Post »

Fail2ban is useful for slowing down brute force attacks against SSH, and in the few days since I enabled it it’s become very clear that these attempts are happening all the time. I don’t want to disable password authentication for all users in case I find myself without my SSH keys, and even if I did it’s not impossible for SSH keys to be compromised. For the day when the walls are breached, I’ve put this in my /etc/ssh/sshrc:

IP="$(echo $SSH_CONNECTION | awk '{print $1}')"
if ! grep -Fqsx $IP $KNOWN_IPS; then
  echo $IP >> $KNOWN_IPS
  echo "$IP added to $KNOWN_IPS" | \
    mail -s "ssh $USER@$(hostname) from $IP" spam@foolip.org

It sends me an email the first time a particular IP successfully logs in over SSH. (If you use this, make sure that mail is configured correctly first: dpkg-reconfigure exim4-config in Debian.)

Read Full Post »

Web hosting

About a month ago, I began looking for a new hosting solution for foolip.org, having started with a wardrobe computer in 2006 and never really having found a stable home. My needs are modest, so I went shopping for the cheapest possible shared hosting. I settled for JustHost, which popped up on many comparison sites and seemed to be good value for money, at $2.81/month including VAT.

JustHost isn’t terrible, but there were a few problems. The server (just44.justhost.com) seemed starved for memory and I was unable to work with my www.git because of it at one point. Another time I couldn’t log in over SSH for the better part of a day. Finally, on August 2, there were some major problems, with my site going up and down like a yo-yo. One of the first things I did was to point Pingdom at foolip.org to get some good uptime data. I have a public status page, where you can judge for yourself.

Wanting more control, I started to look for a VPS instead, and eventually settled on DigitalOcean, based on the location (Netherlands), technology (KVM) and price ($5/month, but counted hourly). As of August 6, foolip.org is hosted on a virtual machine running Debian and nginx. Having root access and doing things the hard way is great, it feels like having a wardrobe computer all over again. Time (and Pingdom) will tell if it’s robust or not, but so far I’m very happy. Also, JustHost will refund me for the remaining time, which is very good of them.

In closing, if I were to pick a Web hosting solution all over again and was not in a hurry, I would try to ignore individual reviews and claimed uptimes, and instead use Pingdom to monitor sites hosted using my candidate solutions before making a decision.

Read Full Post »

New GPG key

I’ve uploaded a new GPG key to various keyservers, fetch it manually or on the command line:

$ gpg --recv-keys 0xF75964F29DC6C210

Before creating the key, I took inspiration from Ubuntu and Christopher Wellons, arriving at this for my gpg.conf:

cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed
personal-cipher-preferences AES256 AES192 AES
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
s2k-cipher-algo AES256
s2k-digest-algo SHA512
s2k-mode 3
s2k-count 65011712

The first half is in order to use the SHA-2 and AES instead of SHA-1 and CAST5, while the s2k settings are there to make brute force as expensive as possible in the event that my private key should be compromised.

I’m starting from scratch with my web of trust, so if you want to play key signing, let me know.

Read Full Post »

Chinese Diceware

I’ve been trying to come up with strong passwords since forever, and have failed to find a magic alternative to entropy. Recently, I took Diceware for a roll, but wasn’t entirely happy with passwords like “wn rare swung strop situs slept”—wn isn’t even a word, is it? I also tried the Swedish dictionary but wasn’t much happier.

How about Mandarin Chinese, written using pinyin? There are only around 400 pinyin syllables, but thousands of characters with different meanings, so I guessed that for a random sequence of syllables it should often be possible to come up with a somewhat meaningful phrase.

The kHanyuPinlu property from the Unihan database turned out to be an excellent source for character to syllable mapping, so I wrote syllables.py to reverse that mapping. The output is a list of 392 pinyin syllables with example characters in traditional and simplified Chinese.

Unfortunately, 392 is not a power of 6, so using real dice to generate the numbers is a bit complicated, albeit possible. Instead I wrote roll.py, which uses as few bytes as possible from /dev/random to roll a die with an arbitrary number of sides.

Using my list and my virtual D-392, here are the first 6-syllable pinyin phrases I generated, each with a memorable (?) Chinese phrase and a rough English translation.

  • yan kai bo ren se dai—眼開撥任色帶—eyes open, poke any ribbon
  • zui ku ba ge mei xu—最酷八個沒序—the coolest eight have no order
  • ban zhai dian die keng bao—搬宅殿爹吭抱—moving villa/palace, dad says hold (this)
  • you mu sa kang xu su—有母萨扛需速—(things) carried by mother Bodhisattva need speed

A native speaker would probably be able to come up with better phrases, but I think that I could remember any of these, with 最酷八個沒序 being the easiest. If this is a representative sample, I think the scheme works.

How about the entropy? With 392 syllables, each syllable contributes log2(392) = 8.6 bits, so these 6-syllable phrases have 51.6 bits of entropy, slightly better than a completely random 8-character alphanumeric password. English Diceware has 12.9 bits of entropy per word, so to get as much entropy as with a 6-word English phrase, a 9-syllable Chinese phrase is needed. The average word and syllable length are 4.2 and 3.2 respectively, so the average phrase lengths (including spaces) would be 30.2 for English and 36.8 for Chinese. (Removing spaces blindly will lose some entropy if the pinyin becomes ambiguous.)

Feel free to use/improve my lists and scripts, and never forget: the coolest eight have no order!

Read Full Post »

Older Posts »


Get every new post delivered to your Inbox.