No Such Weblog

dopplr v tripit: Use both!

2009-04-18T18:38:46Z

I've been on dopplr for quite a while and found it fun and useful. After some raving notes on Twitter, I decided to give TripIt a spin. Where dopplr's claim to fame is the social networking aspect, TripIt's is that it's a really nice tool to manage information: Take an itinerary (or a hotel booking confirmation), send it to TripIt, and all that important information will be extracted. You can then subscribe your calendar to it, or access your account through a relatively nifty iPhone application. No more searching for that hotel address when you arrive at an airport -- quite useful indeed, information at one's fingertips. It appears like you can also manage your entire meeting schedule during a trip through the application, though I haven't tried that. Interestingly, TripIt's strengths don't really seem to be on the social networking side. Case in point, dopplr (like facebook) actively encourages finding friends and colleagues to share one's data with. TripIt lets its users walk their social network, and it lets them invite others by e-mail address -- but nothing in between (like a search by name). Want to manage your flight data and hotel stays, and have a backup of all that travel information in the cloud? Go for TripIt. Want restaurant recommendations or city guide pages that are built by the users? Better stay with Dopplr. Fortunately, though, it's possible to combine TripIt's information management with Dopplr's social networking strengths: You can subscribe your dopplr account to the calendar feed made available by TripIt. The result: Dopplr gets the page views, TripIt does some of the grunt work till Dopplr catches up on that. I'm having a hunch whose business model is going to survive better. PS: I won't spend time expanding my network on tripit -- the one on dopplr is larger, I don't want to rebuild it, and it isn't too useful for the things I'll use TripIt for.

Persistence is hard.

2009-03-27T15:21:07Z

Keeping historical documents around is hard, as my native city of Cologne painfully experienced a few weeks ago, when the city archive collapsed. But it's also hard on the web. Case in point, a number of important early specifications for the Web (like pre-standard SSL, or the original Cookie spec) have traditionally been sitting at netscape.com URIs. Unfortunately, AOL seems to have pulled these pages around the time they disbanded the remains of Netscape. While the wayback machine helps us out this time, one would wish that organizations that acquire historically important technology spent more effort preserving the documents they have. With the consolidation that the economic crisis will bring, I fear that this hasn't been the last time that these kinds of historical documents disappear from their canonical location.

Facebook me!

2009-02-22T17:45:16Z

While I'm usually comfortable using social networks of all kinds, I hadn't ever joined Facebook. Well, the recent ruckus about their terms of service tickled my interest sufficiently that I finally gave in. There really is no such thing as bad publicity for facebook. Now, what's interesting about it for this latecomer? Beside not finding much actually useful or new on facebook (well, perhaps except for new lows in advertising), two points really struck me: An incredibly simple user interface, literally going out of the way when it should, making it as easy as at all possible to let me do what I'd most likely want to do -- and all that, of course, within the walled garden's fences. As an exhibit, consider the exchange between Ann Bassetti and myself up there: With Twitter, I'd have linked to it. In Facebook, it seems like I can't do that, so your only chance is going into the walled garden and trying to search for it. Second, a subtle persuasion that I'm safe and secure there. For the first couple of "friends", I'm bothered with a CAPTCHA (which goes away eventually), to "make sure I'm legit"; when I "friend" somebody who isn't in the "same network" as I am, I'm politely told that (and why!) I can't see their profile. Nothing like letting your users softly run into limits if you want to convince them that they're protected by these limits, and that you're their friend, by enforcing these limits. Remember: Facebook is your friend, it is not scary, and it helps you keep your privacy. There is nothing that Facebook would ever do wrong with your data. It helps you keep your privacy. It's almost fortunate, then, that Facebook also inflicted one of its little indiscretions on me... I hadn't quite told the world that I had given in to that particular temptation, yet, despite some misgivings on principles. Well, this takes care of that. So, what's the conclusion? So far, Facebook indeed very much looks like Hotel California, with nice rooms, and a somewhat chatty concierge. Nothing to see here as far as I'm concerned, except for network effects in action, and some really neat persuasion packed into UI. (Good that I can use Twitter to update my status.)

Election transparency good. Vote transparency bad.

2008-10-29T23:20:54Z

Google is encouraging people to video their vote. That sounds like a good idea, in particular where difficulties with voting machines are to be expected. Just one caveat: I'd rather that voters don't video who they vote for. Classical paper ballots are a fairly sophisticated security system with many important properties, and one of them turns out to be the inability of the voter to prove their choice to a third party: If a voter can prove to a third party how they voted, then selling one's vote turns into a viable business model. That's one of the reasons why absentee voting is problematic from a big picture perspective, and why it's sometimes only permissible under exceptional circumstances. It's also why people shouldn't even be allowed to video their vote. If you think that videoing one's vote is necessary to expose trouble with voting machines, think again, and look at the Chaos Computer Club's excellent work in Germany: They're sending volunteer observers to any computerized election that's going on, they document problems as they occur (and failures to follow business processes critical to the voting system's security), and they take their work to court where they need to.

"Attached, please find ICANN's proposal to sign the root zone file with DNSSEC technology."

2008-09-23T23:07:51Z

ICANN has just published an exchange of letters with the US Department of Commerce, around a proposal to deploy DNSSEC in the DNS's root.

iPhone 3G: I'm not buying it.

2008-09-21T12:46:52Z

Every once in a while, I'm at risk of falling for the iPhone -- it's a really nice device after all, and from day one, the user interface had something going for it. The first generation of the device was just too expensive for my taste, and it didn't have either 3G or GPS. It was also a closed platform, but presumably, that was going away at some point, so I guess I was willing to compromise on that point. The 3G variant pretty much looks like the phone I'd take; the price range (including the one of the subscription that I'd need to change into) works for me, and the feature set (except for the camera's resolution, but hey, it's rare that any cell phone camera leads to great photos, so that's not a big deal at all) is what I'm looking for; the UI looks like they have taken care of many of the subtleties that I heard others complain about (e.g., you can now navigate the address book by initials). But what really keeps me away from that phone is Apple's attitude of keeping applications off the device for competing with Apple, or for having an interpreter built in, or for whatever other reason they come up with, depending on the phase of the moon. What we're seeing in action here is an environment that's tightly controlled, and in which innovators indeed need to ask for permission from some company that thinks it's competing with them. So I'll stick to Nokia for now, where I can run applications like Joikuspot to my heart's content. (Now, if Nokia would just finally get its act together and release decent desktop software for any platform other than Windows...)

Building an IPv6 bridgehead

2008-09-01T08:19:03Z

For no good reason in particular, I started looking into IPv6 this week-end. The quick summary first: It works. It's not really difficult to set up. But it's not easy enough, either. The first realization was that the Macintoshs on the network here had been hapiily chatting IPv6 among themselves while I wasn't looking; link-local addresses had configured themselves, and multicast DNS had glued things together seamlessly. Kudos to Apple for that. Now, the first thing to try was of course telling the MacBook to open a 6to4 tunnel. That's supposedly all that's needed to connect a host to the ipv6 Internet, and it's really easy. Except, well, you need a publicly routed IPv4 address, static if you want to get routed ipv6 addresses from one of the tunnel brokers out there. Bummer. Next thing to look at, the NAT box. It's actually in a reasonably good position to set up these things, but, alas! -- there's a plethora of firmware options out there, some without IPv6 support, some with broken IPv6 support, some with outdated documentation. The firmware that's installed doesn't support IPv6, and I wasn't in a device-bricking mood. The solution that I went for was two-tiered: First, IPv6-enabling the server that runs this Web site. Second, setting up Debian on a spare machine here and connecting it to that server through OpenVPN. Hurricane Electric's tunnel broker turns out to be a really easy way to get IPv6 address space, and to get it all up, I just needed to add the following to this Debian box's /etc/network/interfaces file:

iface sit0 inet6 static
      address 2001:0470:1f0a:974::2
      netmask 64
      gateway ::216.66.80.30

Then, ifup sit0 and the machine had IPv6, as verified by showing ipv6.google.com in a command line browser. Next, the home network: Hurricane Electric offers /48 prefixes (yes, we are talking of 2^80 IP addresses here). I got one of these delegations; the network is simply routed through the existing v6-over-v4 tunnel. The missing piece was a tunneling solution that only needs one fixed endpoint. My tool of choice, OpenVPN, running (on the local end) on an old Laptop with Debian. It's reasonably easy to run. Parameters on the server side:

proto udp
dev tun0
tun-ipv6
ifconfig 10.1.1.1 10.1.1.2 
ping 10
up /root/ipv6-simpler
ping-restart 60 
persist-tun
secret /root/openvpn.key

In other words, I'm using an encrypted tunnel, it can speak IPv6, and we use 10.1.1.1 and 10.1.1.2 as the addresses on the tunnel. For authentication purposes, a pre-shared key (created with openvpn --genkey is used. The client-side configuration:

secret /root/openvpn.key
proto udp
dev tun0
tun-ipv6
ifconfig 10.1.1.2 10.1.1.1 
remote newtoy.does-not-exist.org
ping 10
up /root/ipv6-simple
persist-tun
ping-restart 60

That's pretty much the same as the server-side configuration, except that the "ifconfig" parameters are swapped, and the remote end is specified. The important piece that remains here are the up scripts referenced in the two configurations, as these are where we actually set up the IPv6 part of the tunnel. Server-side first:

ip addr add 2001:470:9aae:1::1/128 dev tun0
ip route add 2001:470:9aae:1::2/128 dev tun0
ip route add 2001:470:9aae:f100::/64 via 2001:470:9aae:1::2
sysctl -w net.ipv6.conf.all.forwarding=1

In other words, we add an IPv6 address (::1) within the /48 netblock to the tunnel interface, we add a host route to another address in that network (::2), and we route a /64 prefix (:f100::) through the other end of the tunnel. Now, client-side:

ip addr add 2001:470:9aae:1::2/128 dev tun0
ip route add 2001:470:9aae:1::1/128 dev tun0
ip route add default via 2001:470:9aae:1::1
ip addr add 2001:470:9aae:f100::1/64 dev eth0
sysctl -w net.ipv6.conf.all.forwarding=1

This is (mostly) the same as the server, with roles reversed as far as the tunnel is concerned, and a default route pointing at the server's end of the tunnel. At this point, the bridgehead machine is connected to the IPv6 internet as both ...:1::2 and ...:f100::1. The final missing piece: Telling other machines on the local network that there is an IPv6 router. I'm using radvd, with a pretty simple configuration file:

interface eth0
{
   AdvSendAdvert on;
   prefix 2001:470:9aae:f100::/64
   {
        AdvAutonomous on;
        AdvOnLink on;
        AdvRouterAddr on;
   };
};

radvd tells other hosts on the local networks that the bridgehead machine is an IPv6 router, and what the prefix is on that network. Thanks to IPv6 stateless autoconfiguration, IPv6 clients on that network will acquire addresses within the prefix that's assigned there, and will route through that machine. That's really all: Devices on the local network with a functioning IPv6 stack will now acquire globally routable IPv6 addresses, and will be reachable from other IPv6 hosts without a NAT or anything of that order. ]]>

RSS feeds: ICANN correspondence and minutes

2008-08-27T21:36:13Z

It seems like ICANN doesn't have RSS feeds for its correspondence and minutes pages. Well, two quick screen-scrapers later:

(These are updated hourly. If anybody on the ICANN webmaster staff reads this, I'm happy to send you the XSLT sheets that generate these feeds.)

Si tacuisses, Enrique, ...

2008-07-20T14:46:24Z

Among the great privileges of working at W3C is the occasional geeking with people like Michael Sperberg-McQueen's evil twin Enrique. Enrique's latest is on what RDF gets us. In that blog item, RDF is characterized as an extremely thin semantic layer -- interestingly, ignoring the RDF Semantics recommendation. The point of that recommendation is that RDF is -- even when you ignore RDF schema, OWL and friends -- more than just nodes, arrows, and URIs. ]]>

You can always add more stuff, and that won't invalidate anything you've learned so far.

You can always remove stuff, but you won't learn anything new if you do.

If you think of RDF as a framework to do web-scale data aggregation, then these are very useful principles: They guarantee that you won't run into a world of inconsistency when you discover additional information, and they also guarantee that you can learn things about the world piece by piece. These principles permit relatively stupid and generic software to draw useful conclusions without knowing anything about the "real" meaning of data. They are also why comparing XML and RDF is comparing apples and oranges: There's nothing in XML that permits software to make similar assumptions; XML's semantic layer is indeed thinner than RDF's. All the interesting logic needs to be dealt with on the application layer. Now, one important piece of Enrique's thinking is that precisely the thinness of RDF's semantic layer (similar to the thinness of XML's) is what makes it appealing. So, what does the semantic layer that the RDF Semantics add mean for that argument? The gain is clear, in that tools can make stronger assumptions about the data they deal with, and some aspects of application logic are pushed deeper in the stack. The price, though, is that those who model data on top of RDF need to understand what constraints are imposed on them by the format's properties -- in an RDF world, there isn't much of a "no"; "si tacuisset, philosophus mansisset" is a conclusion that won't work, since once you're a philosopher, you remain so till the end of your days. RDF semantics, therefore, is exposed to criticism from two angles: On the small scale, it imposes restrictions on those who model data -- restrictions that are harder to understand than those imposed by just using XML trees, and that can indeed bite badly. On the large scale, real life isn't monotonic (we invalidate prior knowledge all the time), and RDF's modeling can't deal with that. The first of these criticisms is ultimately about the ability of people to use the model. The second is about the problem space to which the model can be applied. XML is "dumb" enough to not be subject to either of these criticisms. It is, however, not even trying to address the issues that large-scale data integration and aggregation will bring.

Youtube data disclosures: The limits of data governance.

2008-07-03T12:01:53Z

Wired.com reports that a US judge compelled YouTube ~~Google~~ to turn over its complete user logs - including time stamps and IP addresses, which might be used to discover the real life identity behind a request. Denied motions in the same decision include the disclosure of Google's and Youtube's search engine source code, private videos, and various database schemata. Leaving aside that Viacom's demand for assorted crown jewels smells of an attempt to force YouTube into a settlement, the judge's decision really is a staggering example of the limits of data governance: Building data avoidance into protocols and services makes privacy-threatening disclosures hard or impossible; it also limits the usefulness of some services. But approaches that accept (almost unlimited) storage and processing of data (and then rely on technology and procedures to enforce certain rules) are ultimately limited by the ability of the surrounding legal and social system to stick to these rules. That really means two things: On the one hand, the social context needs to hold data processors accountable for the privacy promises that they make. On the other hand, it must not turn into a threat to these promises itself. This case is a particularly spectacular example of the latter aspect, made worse by an environment in which little is ever forgotten. Food for thought when you next dump personal data into some Web 2.0 information silo.

Some recent talks: Usability, Policy languages, Widgets, and HTML5

2008-05-27T11:47:10Z

Blogging has been light here for a while, though Twittering hasn't. The past few months have seen a busy travel schedule and a number of talks; maybe time to quickly dump links to the various slide sets here:

At RSA Conference in San Francisco, I spoke on a panel about security usability with fellow Web Security Context Working Group members Mary Ellen Zurko, Rachna Dhamija, and Phillip Hallam-Baker. No slides, but a reasonably nice discussion.
At the Web Conference in Beijing, just two weeks later, I ended up on a panel on policy languages, with Renato Iannella, Piero Bonatti, and Lalana Kagal.
Also at the Web Conference, I spoke about Widgets - Web Vulnerabilities for All, taking a look under the hood of some commonly found widgets, and explaining how they can be used to break into your computer. As much as I like that Widgets are making it easier to write portable network client applications, as much do I think that the current platforms' security models make it far too risky to actually run these beasts. We've got some catch-up work to do there.
In Web Application Security Issues at the same conference, I also talked about widgets, but then asked the question what the programming practices there tell us about the future of Web Applications, when ever more security critical code actually runs on the client. That outlook is rather dark right now, in terms of security. (Although it won't get much worse than the current situation.)
Finally, I went to nearby Ghent, to talk about HTML5 and what's security relevant in there. Slides here: Would you like fries with that? In short, there's a bunch of good work being done in that spec, but other parts need some serious attention from the security community.

Enough with the Mac Blogging already...

2008-02-23T10:24:26Z

... but before we return topics here to more productive things, let's note that Apple's support has so far been rather more impressive than IBM's: After exchanging some e-mails with their service provider here in Luxembourg and a phone call on Wednesday, spare parts (a new top case assembly, for the case crack, and a new airport card) were waiting there when I brought the laptop on Friday. They were exchanged on the spot, and I took a repaired machine home an hour later. Also, quite mundanely, the service provider is, for once, a 10 minute bus ride from Luxembourg's central station -- instead of hiding in the countryside near Belgium, and even then only acting as a glorified post office. I'm not quite ready to declare victory, but so far, things look well.

Time Machine desiderata

2008-02-17T21:26:01Z

Apart of the wireless and case problems, I'm actually a reasonably happy Mac user -- which is, indeed, somewhat surprising after 10 years of Linux on the desktop. Among the things I like a lot with MacOS 10.5 (Leopard) is the TimeMachine backup program. It follows Kristian's law: Nobody wants backup, everybody wants restore. And the user interface for restoring data is cheesy enough to actually work. Kudos for that. Well, almost: To be compliant with Norm's law, there need to be at least two backups, on two different hard drives. And while Time Machine is indeed totally capable of doing that, it involves manually switching backup disks, and a lengthy first pass while the "new" disk is first used. Both of these seem unnecessary -- Time Machine should be able to recognize a backup drive, and it should be able to keep track locally of where it's putting backups, and what has happened since the last one to any given medium. The other surprising gap is a lack of encrypted backups: On the one hand there's FileVault for encrypted home directories, and ample support for mounting encrypted volumes. There's even dynamically growing encrypted volumes, and support for easily creating them hidden in the hdiutil command line tool. I'm seriously puzzled why TimeMachine doesn't make that kind of support available automatically. Let's hope that things will improve soon, both from the wireless perspective, and in TimeMachine. Later: It appears as though multiple disk mode works reasonably well; in particular, the additional pass through the entire disk stopped occurring after a while. However, there's still the dance through the preferences whenever the backup disk is changed.

MacBook Distractions

2008-02-15T20:50:37Z

I had ranted before about the occasional trouble that I'm experiencing with the MacBook's wireless card. The symptoms continue to occur: Typically at home (when the machine is in the same place and sits on my desk for extended amounts of time, sometimes days), typically during work hours, often when somebody else toys around with a network nearby, and only reproducible when I really can't use them. In other words: At least here, the MacBook isn't reliable accessing the wireless network during work hours, and I can't figure out anything in particular that I can do to trigger or avoid the problem. (It's also clear that the problem isn't with the access point, as other machines here have no problem. Including a wifi enabled mobile phone and the Thinkpad. This is a genuine client issue, genuinely on the Mac.) Searching around online has been a fool's errand and a time sink as well: While there are quite a few examples of similar problem (and while discussion threads often have a "yeah, I have the same problem"), none of them yield useful information about either causes or cures for the problem. The only consolation is, maybe, that the trouble seems to be common across the BSDs and Linux, and is certainly not just a Mac problem. (That consolation is rather immaterial, though -- we are, after all, talking about a problem with the (Atheros) wireless card that ships in these machines. By default.) From what I've seen so far, this could be a Heisenbug anywhere between overheating (a bad fan?), a loose contact, a bit of conducting dust on the motherboard, a buggy driver, neighbors' secretly building and testing EMP weapons while cooking pancakes, or sun spot activcity -- even though some general instability (two panics and a freeze within two hours or so, anyone?) this morning points at hardware troubles close to the motherboard. (Oh, of course all is stable now that I'm sitting in elsewhere and have the laptop balanced on my leg -- overheating, after all?) The next step is presumably AppleCare -- and I'll probably have to see how well my environment is back-ported to Linux on the Thinkpad, since travel and work won't wait for Apple to get it's act together. PS: A crack that occurs on the right-hand palm rest, toward the front, on about every MacBook I've seen, doesn't count as quality hardware either. PS2: I do like MacOS's, and the overall machine's usability. Really. But, please, not in a less stable environment than what Linux on the Thinkpad gave me. Till that machine's motherboard broke, that is. 2 weeks repair time there.

Geocaching waypoints for N95 and friends

2008-02-03T09:18:15Z

I've gotten a bit curious about geocaching. However, being the lazy type, there is no way that I'll enter all these waypoints manually on a mobile phone keyboard. Therefore, here's an XSLT sheet to convert geocaching LOC files to Nokia LMX files. Just store the result in a file with the extension .lmx and drop it on your N95.