Panflute

Panflute is the new black Music Applet.

Let me explain.

Panflute is slated to be the successor to Music Applet. Its fundamental architectural change is the complete separation of the part that draws the panel applet from the part that figures out how to talk to the backend music player. By “complete”, I mean that Panflute makes them entirely separate programs. This opens the possibility of other software also using the Panflute backend instead of figuring out its own way to talk to a dozen different music players. A panel applet is just one possibility — you might want a desklet, or whatever GNOME 3.0 will replace panel applets with, or an alarm clock, or something else I can’t even think of.

The goal of the Panflute backend is to make everything look like it has a nice, clean MPRIS interface. MPRIS is great because it specifies a common interface for programs to talk to music players. MPRIS isn’t so great because many popular players (such as Rhythmbox and Banshee) don’t use it, and many players that do implement it either deviate from the spec in some areas (such as Audacious) or have some odd quirks about their interpretation of the spec (such as Amarok). The Panflute backend papers over all these issues, presenting a single, common, consistent interface, regardless of what player is actually running. It also adds some (clearly marked) extensions to MPRIS to provide features not available in MPRIS 1.0, such as setting metadata (particularly ratings) for the current song, or having a convenient way to get updated position information without having to resort to polling.

Panflute also provides a panel applet to replace the old Music Applet. At this time not much has changed feature-wise, but by doing a ground-up reimplementation, I’ve been able to throw out a bunch of legacy code to work with now-fairly-old libraries and to redesign things to support more flexible layout of the applet’s content, such as the oft-requested support for fat panels.

Perhaps most importantly, however, is the fact that I’m using Launchpad to host development of Panflute instead of doing things directly off of kuliniewicz.org. This means I’ve now done something I should’ve done a long time ago and started using a proper bug tracker instead of relying on e-mail. Finally.

The plan for now is to get Panflute up to feature-parity with the most recent release of Music Applet and make that a 0.something release. The 1.0 release will try to include as many feature requests from Music Applet as I can manage, as well as a testing tool to help verify that the code that handles talking to each music player works as expected, and to map out what functionality isn’t available. (Hey, that’s another thing that can exploit the applet/backend separation!) The 1.0 release should also make sure those player support modules implement as much of the MPRIS spec as possible; so far I’ve been focusing on the /Player object (which the applet makes heavy use of) and largely ignoring the /TrackList object (which it ignores completely). Obviously, for the Panflute backend to be generally useful for other developers, it needs to be full-featured.

I really ought to formalize the above paragraph a bit and get a proper blueprint for future development up in Launchpad….

Anyway, the Panflute code hosted on Launchpad is functional, with all applet features except pop-up notifications implemented and backend support for Rhythmbox, Banshee, Amarok, Audacious, Muine, and VLC implemented. There’s still some rough edges, particularly how the applet doesn’t yet bother to start the backend process, but those issues will be easy enough to fix. (And now that there’s an actual bug tracker, you can file a bug if something is amiss and/or missing.)

How to protect yourself from Comcast’s latest idiocy

You know how there are shady people on the Internet who will register domains that are one letter off from popular domains, in hopes that someone will mis-type the website’s address in their browser? And how this is invariably used for one of three things: filling your screen with ads, filling your screen with porn, or filling your screen with ads for porn?

Comcast thinks this is a fantastic idea, and will now be typo-squatting over all unregistered domains.

Technically, this is DNS hijacking and not typo-squatting, but the end result essentially the same: mistype an address, get ads in your face instead of an error message.

Comcast pitches “Domain Helper” [sic] as something to help their customers; they say this because they’re greedy liars who think users are stupid. (Take a look at the comments on that post, and you’ll see that users aren’t as stupid as Comcast seems to think — they’re almost universally opposed to the idea.) By having the DNS server resolve addresses for domains that don’t actually exist, not only do you break applications that depend on being able to detect an error condition (such as e-mail spam filters that check for invalid domains), but you also risk helping attackers hijack user’s computers.

Apparently Comcast learned nothing from the Site Finder fiasco from several years ago, where VeriSign — the ultimate authority for registering .com and .net domains — rolled out a similar service attack across the entire Internet. That didn’t go well. They ultimately got smacked down by ICANN — the organization responsible for overseeing the domain name system and with whom VeriSign has a contract with to manage the aforementioned .com and .net TLDs. Meanwhile, the developers of BIND — the software that probably runs the DNS server you’re using right now — rushed out an updated version to counter Site Finder. Basically, everyone responsible for keeping the Internet running united against Site Finder, and if you know how hard it is to get people on the Internet to agree on anything, well, that should tell you something.

Of course, since Comcast thankfully doesn’t have any authority over the global domain name system, their current idiocy is limited to the networks they operate. Comcast offers a way to opt-out of their DNS hijacking “service”, but not surprisingly the steps are intended to make it difficult for users to actually opt-out. After all, that’s partly why companies use opt-out instead of opt-in in the first place. (The other reason? They know nobody would actually opt-in to the “service”, so dumping it on users and forcing them to explicitly refuse it is the only way to get them in.)

Anyway, here are the hoops Comcast makes you jump through to opt-out:

  1. Look up the MAC address printed on the bottom of your cable modem.
  2. Enter the MAC address and your e-mail address in the form.
  3. Wait for a confirmation e-mail.
  4. Click the link in the confirmation e-mail from the location where you have Comcast’s Internet service.
  5. Wait two days or so for the change to actually go into effect.

Making customers look up the MAC address of their cable modem is completely unnecessary, and is clearly only required in order to make it more difficult to opt-out. The average user isn’t going to know what a MAC address is (nor should they have to), and in a typical home network the cable modem is going to be wedged in some difficult-to-access corner of the building. In my case, it’s in the back of an alcove behind my TV and holly’s dessicated powered-off husk, requiring some effort to balance on one foot atop a pile of cables while reaching down through a narrow gap towards the blinkenlights.

Ostensibly, Comcast needs you to tell them your cable modem’s MAC address so they know who is opting-out of their attack service. This is a lie. Comcast’s opt-out page could instead look for what IP address your request is coming from, which requires no action whatsoever on the user’s part. Comcast already keeps track of which of their IP addresses they’ve assigned to each cable modem — if they didn’t, their Internet service simply wouldn’t work — so they could figure out the MAC address that way. And their procedures already require you to visit the confirmation page using your Comcast Internet connection anyway. Likewise, the e-mail confirmation shouldn’t be necessary — connecting via your Comcast-provided Internet connection should be enough to prove that you’re who you say you are, and to prevent someone from using a script to automatically opt-out all possible 248 MAC addresses.

We’ll see whether the opt-out really works. When I tried looking up a bogus domain name earlier this evening, I got a DNS error as expected, which means Comcast might not yet have rolled Domain Helper [sic] to this particular network.

tl;dr version:

  • Comcast’s Domain Helper [sic] breaks things you use the Internet for
  • If you use Comcast, opt-out now
  • Comcast makes opting out needlessly difficult; don’t let them win

I guess if you were wondering what it was going to take to break my month-long silence here, well, apparently this was it.

Comments Off

4,096 ought to be enough for anybody

Other than pointing out that the fault lies primarily with how Adobe’s programmers don’t know how to do anything efficiently on non-Windows platforms except crash the browser, I can personally verify that today’s xkcd is 100% accurate. Including the mouse-over text, and the fact that the kernel patch mentioned in the comic indeed exists.