Whitelist Chat as a Strategy to Protect Children Online

The ability to interact with other players is one of the most compelling aspects of online multiplayer games. However, in games for young children, there are obvious privacy and safety concerns in allowing unrestricted chatting. The state of the art solution, implemented in practically every online community for kids is “whitelist” chat (on some websites, combined with live monitoring). Whitelist chat means that only real dictionary words are allowed (bonus: helps spelling!) and certain real words (e.g., names of place and numbers) are excluded from this list. As an enthusiast of children’s online communities, I’ve been fascinated by the many ways that children have found to get around these restriction. In this blog post, I will use the children’s online game Petpet Park as an example, though honestly it could be one of any number of communities (Roblox, Club Penguin, etc.).

In Petpet Park, children play a creature who does quests around town, plays mini games, buys clothes and toys, and decorates their own little corner of the world. The website combines a strict set of whitelist restrictions and live monitoring to ensure safe chat. However, kids always find a way!

Petpet Park

A screenshot from Petpet Park. Children create creatures that can do quests, play games, and chat with each other.

petpet park taboo

Creative combination of real words and referring to cultural landmarks as a way of conveying real locations — a taboo topic on children’s websites.

Consider the public chat to the right (username removed for privacy). This person has found a creative way of combining real words (“train i dad” = Trinidad) and references to cultural landmarks (“cowboys” = USA, “place with that arch” = St. Louis) to discuss places of residence (a taboo topic on a children’s website). I want to be clear that I am not criticizing Petpet Park. In fact, I was impressed that this discussion was almost immediately shut down by a live monitor (booting the over-sharing child off the server), but this behavior is quite common and the damage could be done before a monitor steps in. Here are some common ways that I’ve seen children getting around the rules:

  • Typing a single letter on each chat line to spell out a forbidden word. (Not possible on all websites — Petpet Park does not allow this, for example)
  • Using the letter “i” to convey numbers. (e.g., “I am i i i i i i i years old”)
  • Spelling out a non-whitelisted word using first letters of allowed words. (e.g., “Read only first letters. My name is Like Amazing Nutty Almonds.”)
  • Using the meanings of allowed words to convey forbidden information. (e.g., “I go to the school that’s named after the guy that flew the kite.”)

The point that I want to make is that no online community is going to be 100% safe. In particular, the state of the art whitelist strategy is only effective when augmented with live monitoring (and even then, it may be too little too late). Safe chat is not a replacement for parental engagement and keeping open lines of communication about online rules. The other thing to remember is that no online filter will ever be able to enforce empathy and kind interaction online or be able to protect the child from being excluded or hurt by others. Both conversations should be an important part of raising digital citizens.

Designing Technology for Major Life Events Workshop

High emotional impact and the value of the journey are two big aspects of designing tech for major life events.

High emotional impact and the value of the journey are two big aspects of designing tech for major life events.

While at CHI, I got the wonderful opportunity to help organize the workshop on Designing Technology for Major Life Events along with Mike Massimi, Madeline Smith, and Jofish Kaye. We had a great group of HCI researchers with a diverse range of topics: gender transition, becoming a parent, dealing with a major diagnosis, bereavement, and more. My own interest in the topic grew from my experience designing technology for divorce and technology for recovery from addiction. In one of the breakout groups, we discussed the challenges of designing technology in this space and some of the ways we’ve dealt with these challenges in our work. In this post, I want to highlight a few of these:

Building Tech is Risky. Building a system requires the designer to commit to specific choices and it’s easy to find something that wasn’t adequately considered after the fact. In tech for major life events, this challenge can be exacerbated because the consequences of a failed design might have big emotional repercussions (e.g., tech messing up some aspect of a wedding). Sometimes, it is a big question of whether we even should try to bring tech into a given context.

Ethics of Limited Access. Building technology to support a major life event may mean excluding those without the financial means, skills, motivation, language, etc. to use the provided intervention. Additionally, we frequently stop supporting a prototype technology at the end of the study which can be really problematic if it was providing ongoing benefits to the participants. Again, because of the high stakes involved, issues of ethics of access to technology may be exacerbated when designing for major life events.

Tension Between Building Your Own and Leveraging Existing. Many systems we build require some critical mass of adoption before they are really useful. This is particularly important with tech for major life events because there may be relatively few people facing a particular relevant context at any point in time. One of the ways to deal with this is to piggyback on existing systems (e.g., building a Facebook app instead of a new SNS), but this may cause problems when the underlying technology makes changes outside of the researcher’s control (e.g., privacy policies change, APIs stop being supported, etc.).

Asking the Right Questions about the System You Built. The final challenge is understanding what kinds of questions to ask during the system evaluation. On one hand, it is important to go into the evaluation with some understanding of what it would mean for the system to be successful and the claims you hope to make about its use. On the other hand, it is valuable to be open to seeing and measuring unintended side effects and appropriations of the technology.

I think my two major take-aways from this discussion were a greater appreciation of how difficult it is to actually build something helpful in this space and the insight that many of these problems can be partially addressed by getting away for the type of study that focuses on evaluating a single system design using a small number of metrics. The risks of committing to a specific design solution can be mitigated by providing multiple versions of the intervention, either to be tested side-by-side or to let participants play around until they decide which solution is a better option for them. The ethics of access can be ameliorated by providing low-tech and no-tech means of achieving the same goals that your high-tech approach may support (e.g., Robin Brewer built a system to let the elderly check email using their landline phones). Planning for multiple solutions when building using others’ APIs can lead to a much more stable final system (e.g., the ShareTable we could easily switch from the Skype API to the TokBox API for the face-to-face video). And lastly, the problem of figuring out what to ask during and after a system deployment can be addressed by combining quantitative methods that measure specific predicted changes with qualitative methods of interviewing and observation that are more open to on-the-fly redirection during the course of the study. Overall, diversity of offered solutions, flexibility under the hood of your systems, and diversity of methods used in the evaluation lead to a stronger study and understanding of the target space.

Reflecting on the Academic Job Hunt

I wore a suit, like a real grown-up!

I wore a suit, like a real grown-up!

My last post (seven months ago!) proclaimed that I was thinking about going back to academia and contemplating going on the job market. Seven months later and mission accomplished — I have accepted an offer and I will start in August as an Assistant Professor in Computer Science at the University of Minnesota! I am back to blogging (aiming for every other week). This week, I will be reflecting on the job process for all those who are thinking about going on the market soon. So, here are four insights:

  1. The job hunt takes a lot of time. This may be obvious, but it’s not to be underestimated. I tracked my time: 40 hours spent writing my general materials and preparing the job talk, 2 hours spent preparing each application (21 places, so more than 40 hours total), additional 30 hours on preparing and doing phone interviews and general follow-ups to application, and each on-site took an average of 40 hours when accounting for preparation, travel, actual meetings, and general logistics (so, my 8 on-sites took me a total of 320 hours!). Most of the prep happened in October and November, most of the followups in December, and the on-sites were in February and March. In those 5 months, the job hunt was basically an additional half-time job, on top of my actual full-time job (thank the powers that be for AT&T’s generous vacation package!).
  2. I’d rather be myself and not get the job than get it while pretending to be someone else. You may know me: I’m loud, I’m in-your-face, I have a weird sense of humor, and no fashion sense at all. If those things are not a good fit for a place, then I’d rather find that out by not getting an offer than come tenure time. So, I made the explicit decision to act as I would and hoped for the best.
  3. It’s better to identify than compare. One of my friends who did this whole thing two years ago (the wonderful Sarita) advised me early in the process to not look at where other people were getting interviews. I also figured out that when I began comparing myself to others, I only made myself envious, insecure, and miserable. Lots of my friends were also on the market and I made the explicit decision to be happy for them and look for ways to share happiness and provide support, instead of stalking their Google scholar pages. By making this decision, other people who are on the market became a wonderful source of insight and support instead of a source of stress.
  4. Have fun! Yes, it’s ultra stressful. And all the travel gets exhausting. But, it’s also incredibly fun to be traveling to new places, getting wined and dined, sharing my research, and hearing about all the awesome research at the places I visit! There’s something magical about getting the opportunity to imagine my life at each school! Holding on to that feeling made the whole process a lot less stressful and a lot more beautiful.

One of the things that my Ph.D. lab does really well is sharing resources like everybody’s application packages, job talks, etc. I think others may be able to benefit from this sort of an archive, so for what it’s worth, here are all of my materials: research statement, teaching statement, cover letter template, job talk slides, and video of job talk. Though do take these with some caution, I don’t actually know how good they are: I didn’t get all the interviews/offers and the ones I did get may have had more to do with my letters of recommendation than anything I wrote (I am forever indebted to Gregory, Amy, and Tara!!!). But, I did get 6 offers from the 8 places I interviewed (and more importantly, I got the offer that was perfect for me!), so at the very least, these were not terrible deal breakers. I hope that some of this can be helpful to others who are about to undergo this process!