Posted on

URL Shorteners

So I’ve been annoyed by the increasing use of URL shorteners. What is a URL shortener you ask? Well, it’s a service, provided by an owner of a short domain name, that provides URL redirection—providing a short URL you can use with services like Twitter or Facebook, but originally conceived for handling URLs in emails to avoid problems with copying and pasting when the URL wraps onto the next line. When you follow a short URL, your browser contacts the owner’s web server, and is given a 301 or 302 error code in an HTTP response that tells the browser where to locate the correct content, which it then does in succession. Popular services include tinyurl, bit.ly, goog.le, and t.co.

So why am I annoyed by it? Mainly because I cannot see where the link is going to end up. I don’t like clicking on links I get from friends unless I know what website I’m going to end up on. This is primarily due to concerns over the potential that the link might take me to a malicious site, or a site I might find offensive. But a number of friends post links that I think I might find interesting–yet I never follow them because they are shortened URLs.

A secondary concern is the tracking done by the URL shortening company. It allows a third party company to track all references to a destination site through the posted URL, which to me seems like a loss of privacy.

Granted – for services like Twitter, which have a small upper-bound on the message size, something like this is needed—albeit only because of the somewhat arbitrary limits placed on message sizes. So what solution might I offer? For my primary concern (knowing where you’re headed before you visit the website), it might be good if browsers recognized the URLs for short URL providers, and used a HEAD request to determine the actual destination to present to users. Alternately, a browser might include a new feature for requesting a HEAD request for a link instead of a standard GET request. The HEAD request, rather than opening the URL, just asks the server for the headers the website would contain, and could be presented to the user so they know what is healthy and normal.

Posted on

NSDI 2012 Paper Accepted: Distalyzer

So I learned last night that our submission to NSDI was accepted. It described the methodology for a tool we built which we can Distalyzer. Distalyzer works to help developers diagnose performance problems in their systems. It works by utilizing a minimal amount of structure from the logs, and then doing two kinds of analysis (t-tests and dependency networks) to discover the most relevant and most divergent aspects of groups of log instances. We have used it to find bugs in Transmission and H-Base, and applied it to other another system’s problem (TritonSort) to show reductions in effort needed to diagnose the problem.

Soon there will be a blog post at our research group website which describes it in more detail, but I wanted to go ahead and post about the good news.

Posted on

Recent Security Papers

So in research progress, we’ve recently published or had accepted two conference papers in the area of distributed system security. The first is a paper called “Removing the Blinders”, with co-authors David Zage and Cristina Nita-Rotaru. The basic insight of the paper is that in many protocols, nodes make decisions about other nodes based on just the last message they got from them. This is a kind of “blinders”, hiding other information the node has about the other nodes, which prevents them from making smart decisions about the peers based on the holistic information available.

However, the effort required in the first paper is totally manual. Discovering the set of attacks, and then finding the defenses for those attacks is takes a smart person thinking about it for a long time. We next set out to solve part of the problem – discovering the attacks. We focused on a restricted set of systems—those implemented in a structured language such as Mace. By applying a greedy state space exploration search strategy, we can discover a class of attacks that cause poor performance in systems. This work was accepted to NDSS 2012, about a tool we call Gatling.

Meanwhile, part of our current research involves further generalizing this work.

Posted on

Public WiFi: should you use a VPN if you only use HTTPS sites?

I got this question from a friend, so thought I would post these thoughts in case they help others too.

Okay – so to VPN or not to VPN on a public wi-fi network….

I guess, in the end, it all comes down to the security concerns you have.

Before discussing details, I’ll start by saying that I do not often personally connect to a VPN when using a public WiFi network, despite having one Purdue hosts that I could use.

The technical difference between VPN and HTTPS comes down to the layer of the network stack where the encryption takes place. A VPN would encrypt all traffic leaving your machine, but moreover, would direct it all to your VPN provider (your desktop, as the article suggests). Once it reaches your desktop, it will travel over the desktop’s normal network path to the rest of the internet. HTTPS, on the other hand, is
applied to a specific and single network connection between your mobile device and a given server.

So, considering only traffic to HTTPS sites, let’s look at what information is leaked.

  • With the VPN, all traffic is destined for your desktop. On the one hand, this is good, because no one can tell what sites/services you
    are using. None of your network traffic, except that which was to setup the VPN, is readable on the public network. There are, however,
    two kinds of things which are leaked. (1) the volume and pattern of traffic you use. [There is no solution for this. But you should be
    aware that it is viewable to all, and there may be profiling techniques which can be applied to learn things based on this.] (2) the fact that you have a connection with your VPN provider. From a privacy standpoint, this in fact may be a very serious concern, because if you are using your desktop as your VPN, then it may very precisely identify who you are, where you live (see an article today in Ars Technica on mapping based on an IP, etc.
  • With HTTPS, only the web traffic to the given server(s) is encrypted. In particular, other information is leaked. (1) The IP addresses of all the sites you connect to, which may identify who you bank with, who you work for, who your email provider is, etc. (2) The DNS queries you issue, which would make it even easier to identify what sites you are visiting, without having to reverse-map an IP-to-hostname, when the IP may have multiple hostnames. (3) More precise information about your traffic patterns, since it is subdivided by destination rather than being aggregated in the VPN case. (4) Some HTTPS sites will include static content or images from a non-encrypted source (some browsers warn about such things). This information of course would also be unencrypted.

Next, consider the other traffic your mobile device may be sending. For example, if it participates in any convenience networks (i.e. Bonjour
for peer host discovery), this traffic will all be present too, and may or may not be encrypted, based on the service.

Another consideration is the exposure to attack your device has. In both cases, your device is connected to the wireless network. However,
in the VPN case, the default settings of the device may be generally more secure, since the wireless network wouldn’t need to support some of
the extra traffic. It becomes harder to launch an attack, since the machine is mostly looking for traffic from the VPN, and will ignore most
local traffic. HTTPS leaves any such services (e.g. iTunes listening for connections from the Remote.app on the iPhone) listening.

Finally, there is the cost. VPN adds an extra layer of overhead, and an extra layer of places where things can go wrong. Also, all traffic is
going through your desktop, which may significantly reduce the bandwidth you can achieve, and add latency. (And of course, an HTTPS site when using a VPN is being encrypted twice – once at the HTTPS layer, and once at the VPN layer). Further, the choice of a VPN vs HTTPS may have other unpredictable effects – a wireless network provider may block VPN traffic, or possibly deprioritize it. Or they might do the same for HTTPS traffic (though deprioritizing is more likely than blocking in this case).

Okay, one more consideration – which is the quality of the encryption. Both technologies can provide a range of encryption quality, so
vigilance must be used in ensuring effective encryption is used. Some browsers will warn about weak SSL configurations on servers, but VPN
encryption quality is generally less well verified.

Hope this helps,
Chip

Posted on

GPS iPhone Apps

I have received a number of requests from people interested in lists of worthwhile Apps for iDevices (iPhone, iPad, etc.). Underlying this is of course a question about whether I like my iPad. I do. I rate it as a “fun toy”. It is good enough that many evenings I do not need to use my computer – because if I am just consuming content (reading news, shopping, etc.), then there is no need for my laptop. It’s only (like tonight), when I’m doing a lot of typing that I need my laptop. As an added bonus, the iPad is easier to use in bed, and never gets hot.

In any case, today I want to focus on one particular kind of App – the GPS app. Around Thanksgiving last year, we (Kristina and I) tested out several GPS Apps on the iPhone. These included Navigon, CoPilot Live, and MotionX GPS Drive (in opposite order).

In rating GPS Apps, we identified a few key factors:

  • Maps: downloaded on-the-fly, or as part of the app itself. This impacts map freshness, app size, and mobile data usage. Including the maps in the app means the maps will be more stale, and makes the app around 2GB. Downloading the maps as you go makes the maps more fresh and keeps the app small, but uses more mobile data, and doesn’t work well in areas of poor coverage.
  • Live Traffic: Useful for routing around accidents and such.
  • Routing: TTS (Test-to-speech), for reading street names aloud. We found this feature very important to avoid looking at the screen too often. Some apps read only street numbers or numbered streets: you actually want one which can synthesize street names.
  • Polish. How elegant is the App.
  • Price
  • Map Data: there are two main map providers NavTeq and TeleAtlas. They have different qualities, strengths, and weaknesses. This turned out not to be a major issue for us (I forget which one we’re using anyway).

The apps rate as follows:

  • MotionX GPS: This is the cheapest of the options, but comes with a subscription model instead of a pay-for-the-app model. Maps are downloaded on the fly. The app was reasonably impressive, but in the end we decided we needed the maps included in the app. At the time, it also did not support TTS, though I think that may have changed.
  • CoPilot. CoPilot worked just fine – with the features we wanted, but was rather unpolished. However, in exchange it was cheaper.
  • Navigon. This was the most expensive app we tried, and in our opinion, you get what you pay for here. It has TTS, live traffic (add on charge), and also includes the maps in the app. All this, and a very polished interface as well.

While I have not tried the newer Garmin App, it downloads the maps as you go, so it doesn’t really fit the criteria we needed. In our opinion, Navigon was the best choice. I do, however, recommend looking for times when the app is on sale. You can use something like AppShopper to see the history of pricing on an app. Note also, with Navigon, you can pay different amounts depending on how much maps you want. If you don’t need Canada – get the US only version, etc.

Posted on

Keeping it Simple (or: Grilling on Charcoal)

So a couple weeks ago our gas grill stopped working. Right in the middle of cooking. Originally, I thought we were just out of gas, so I had swapped it out with our spare tank we keep on hand for just such an occasion. But I could not get the grill to re-light. I couldn’t hear the gas either, which I usually can do. I re-tried many times, before finally giving up. Later on, after doing some debugging, I had decided to try replacing the regulator. Unfortunately, despite using a wrench, etc., I could not disconnect the old regulator/hose assembly. At this point I was fed up. The grill was I think about 6 years old, so it lived an okay life.

In deciding what to do about it, I did not envy the thought of replacing it with another gas grill. Gas grills just seemed to me to be overly complex, with a large number of parts which can break and stop working. Couple this with the fact that I’ve never been as happy with the gas grill as I wanted to be — the burners worked pretty well on low and high, but anywhere in between, and they would flicker out and back on, which was always puzzling. Plus, I have to say I never felt like the gas grill made foods taste all that “grilled”. I’m not sure how much benefit it had over the gas range which I had indoors. That flame was consistent, reliable, didn’t run out, was self-lighting, instantly ready, and did not require me to cook in the outdoor elements. So, my go-to grill was the cast-iron grill tray on the gas range, or sometimes, the George Foreman.

So, in looking at new charcoal grills, they were cheaper, promised more-grill-tasting food, fewer parts to break. After all, in the end, it’s basically a fire-safe kettle you put charcoal in. The Weber grill I got had the added feature of a one-touch ash-sweeping system to make it easy to keep clean. It took all of 30 minutes to assemble, and the only tool it required was something to tap the caps on to keep the wheels from sliding off.

Pros and Cons are pretty well established across the internet, but here are a few considerations I went through:

  • Cost: Gas grills are more expensive, but the fuel is supposedly much cheaper. If I the grill is $200 cheaper, and you grill 20 times a year, and your grill lasts 6 years (like my last one), you would have to save $1.66 per meal to make the difference up. I’m not saying it’s impossible, just that I’m not convinced the cost is all that significant either way.
  • Convenience: Gas grills are instant-on, while charcoal grills take more effort and time to get started. Technically, this one is true. However, the starter on my gas grill didn’t last long, and then I needed to use a lighter to start it. Next, I never knew how much gas was left to know when it might run out. Also – as for the instant-on: I always needed to clean the grates before use, so it wasn’t like I could start cooking immediately (not to mention pre-heating the grill). Now, perhaps the charcoal takes longer, but since I generally use that time to prep the food, it seems to be about the same amount of pre-prep in both cases.
  • Taste: The charcoal grill definitely is more grill-like in it’s taste. Plus, I can add fresh herb sprigs to add some smoke to the cooking. Very cool.
  • Cooking simplicity: I have to say, the actual cooking seems pretty nice. Putting the lid down, and just waiting an amount of time for things to be done is great.

I’ve used the grill 4 times now. The first time was an utter failure (I didn’t figure out how to start it properly). Then we had friends come over to show us how it works. Since then I’ve grilled twice, and both times came out great. So, I’m now a happy charcoal grill operator now.

Does anyone want two propane tanks for the exchange system? One is full. The other has an unknown amount of propane (could be empty). I won’t be using them anymore.

Generalizing this out, it is basically illustrates the principle of keeping it simple. The gas grills are more complex, more features, more money, and should be easier and better to use. But for my use, the charcoal grills are more durable, reliable, predictable, and therefore useful. Software often follows the same principle. When we add a lot of complexity to it, we generally add bugs, issues, and make it much harder to know what the software will do. So in summary: keep it simple. Even if you lose some features or flexibility, you may make up for it in the bigger picture.

Posted on

Live from my iPad

Well, this morning I went and bought an iPad. So far? Very pleased. This post is written using an app for wordpress, which is quite nifty! I especially like the NPR app so far.

Posted on

Update on the iMac/TV

So one feature of the iMac which I hadn’t really considered was that it comes with SnowLeopard. On the one hand, this seems like a good idea, since it’s the latest Mac OS. However, in my experience, I actually prefer these days to be slightly behind the curve on OSes, since it usually takes a while to get all of the kinks out of the systems.

One such kink was the support for the Apple Remote. We did eventually get one from our local Best Buy (amusing side story: I had checked availability at the store online, gone in to buy it, and been told by the clerks that they didn’t have any. I went home, observed the availability still online, and so I bought one for in-store pickup. A few hours after that, I got the email telling me to go pick it up, which I did.) Unfortunately, the Apple Remote did not “just work”, like things are supposed to on the Mac. Looking further at it, I saw that in fine print on Hulu Desktop, it very clearly states the same problem.

Oh well. After scouring the forums, I discovered people linking to candelair, a free software driver from the makers of RemoteBuddy for OSX to resolve the issues with the remote on OSX. So I’ve installed it, and now our Media PC works nicely by remote (no configuration necessary for FrontRow, HuluDesktop, Boxee (+Netflix), and MythFrontend). Now, if only the Apple Remote had more than 6 buttons, which would be really nice for MythTV!

Posted on

Pros on the Macbook Pro

So I’ve spent enough time giving you my downs on the MBP, that I kinda feel in fairness I should talk about things that I like about it. So here’s a partial list:

  • UNIX Programming Environment. Since it runs on top of FreeBSD, a lot of the software I am used to working with in Linux either “just works” or is easy to port to the Mac. This includes my own research project Mace, and MythTV. This software has been easy to port to OSX, but either doesn’t work on Windows, or works after a fairly complicated set of steps.
  • Better support for X11. Okay, technically this is related to the first item, but is work mentioning separately. To get X11 support on Windows, you either have to install an expensive third-party tool, or CygWin. CygWin is great (and I don’t think I could manage to use Windows without it), but its quite sluggish and X apps don’t quite integrate into the environment as well as you might like. The integration is still less than perfect, but much better on OSX, and I don’t feel the severe performance penalty.
  • Marking up PDFs. I always used to complain about this — my adviser would send me marked-up PDF files, which I find annoying to work with. Plus, using Acrobat Reader, you can’t make any markings yourself, so its hard to make it a two-way street. Further, there isn’t (that I know of) any free software which does markups of PDF files on Windows. However, I discovered that the built-in “Preview” app on OSX supports marking up the PDF files. So when someone sends you a PDF and you need to mark it up, it is convenient.
  • Time Machine. I suspect something similar exists on Windows, but I haven’t poked around enough to find the one which suits my needs. But Time Machine on the Mac is very convenient, and I feel confident that not only are my files backed up, but various versions of them, in case I discover I overwrote something important. Further, Time Machine was convenient and easy to find, setup, and use.

So it’s not all bad. It’s just not as good as it had been advertised to be.

Posted on

Another Macbook Pro Update

Just as a quick update, this afternoon I had another problem which isn’t “supposed to happen” in MacOS. When I arrived home from school, my laptop was burning hot in my bag. When I opened the screen, there was an error message telling me I needed to hard-power cycle my macbook by holding in the power button, because of an error. It was a kernel panic, but the laptop was left in some continuous processing loop, with the fan spinning, but doing no good in my bag, while an unhelpful message was telling me to power cycle it. So much for Mac’s “Just working”. At least with other OSes, I expect such errors, and am very careful about making sure they aren’t happening.