Wandering Thoughts archives

Designing services for disengagement

A while back I wrote about how I had realized that a lot of my syndication feeds were only for casual reading and how I thus wanted to reduce their impact on my time. I suspect that I'm not alone in this pattern of having periods of initial enchantment with services and then winding up less interested in them, which leads me to a corollary for designers of services.

There are a lot of services where it's easy to move from just starting out to really immersing yourself in the service; sometimes this just happens, and sometimes this is deliberately designed into the service. However, some amount of your users (perhaps many of them) will wind up getting in too deep and want to scale back their involvement in your service.

If you want these people to stick around at all, what I think you need is something that automatically ramps down their involvement for them. When your system notices that someone's interacting with you less, you should intelligently trim down the number of things that they have to deal with. You don't want to leave this to the person to do for themselves by hand, because that takes work which means that the easiest thing for the person to do is to abandon your service entirely.

Or in short, you want to design for disengagement as well as engagement.

Note that this is not the same thing as designing for beginning users or casual users. Disengaging users will wind up as more and more casual users, but they get there by a different path. To try to summarize it, casual users have simply stopped moving forward; disengaging users need to move backwards. Disengaging users may not even be able to use the same interface as casual users, because they're working in different environments.

(To give an actual example, consider syndication feed reading. A casual feed reader has probably never added very many feeds, and so has a low article volume. A disengaging user (such as me) has added a bunch of feeds but can no longer keep up with the resulting high article volume. You can't reduce the disengaging user to a casual user except by removing most of their feeds, and that may not at all be what they want and what serves them. A similar thing holds on a social website like Facebook; a casual user generally has few 'friends', while a disengaging user has lots of 'friends' that they can no longer keep up with.)

An incomplete list of the ways around MAC address blocking

In an earlier entry I wrote that there were plenty of ways for someone with a banned MAC address to get back on your network. Since some people may doubt that, today I feel like running down some of those ways to emphasize how weak MAC-based blocking is.

The straightforward workaround is to change your MAC address to some new random one you made up (often you can just vary the last octet of the MAC address slightly), then register your 'new' machine for network access. This works best in environments with an automated registration portal.

The next option is to skip the whole registration process by borrowing someone else's MAC address, ideally the MAC address of a machine that itself is not currently on the network. This usually requires some advance planning to acquire the MAC addresses of other machines, but has the obvious advantage of working even if you can't register new machines.

The more extreme option is to skip straight to what you actually care about, which is getting the DHCP server to give you an IP address. Well, who needs a DHCP server? After all, if you know the IP address range and other routing information, you can just give yourself an IP address without bothering the DHCP server. (You probably want to give yourself a different IP address than you used to be using.)

It's quite difficult to stop the first two attacks without side effects. In fact I think it's close to impossible to reliably block MAC address impersonation if you allow machines to roam from port to port. It's possible to block the third attack but it requires that your DHCP server and your network firewall talk to each other, so that the firewall only passes specific IP addresses that the DHCP server has given out.

All of this leads to the larger point, which is that both MAC addresses and IP addresses are only a very weak form of access control. They will keep ordinary people out, but they're not going to stop someone who knows what they're doing. If you need strong network access restrictions, you need strong authentication either of machines, via mechanisms such as IPSec, or of users, via mechanisms such as VPNs.

(This is nothing new to networking people, of course.)