Shaanan Cohney

Public Policy and Computer Science

This typically does not mean addressing a policy need by building a straightforward technical system—that is too close to engineering rather than research for my group.

Rather, the problems I’m interested in tend to fall into one of a few categories:

• Policymakers are unaware that advances in computer science might change the problem space itself, if only someone would figure out how.
• Policymakers use a specific type of evidence to do their jobs, but measuring what they need is fundamentally difficult in a way that would require a methodological advance or a novel type of research project.
• Computer scientists are approaching a challenge in a way that misses a significant aspect of law/policy.
• A new law or policy is being considered that will have significant technical implications, but neither the technical nor the broader community has fully understood what those implications are.

I also have some theme areas that I am particularly interested in:

• Safety of vulnerable populations online (particularly students and children)
• Handling surveillance technologies that are dual-use (i.e., they can be used for both good and bad purposes)
• Consumer protection and security/privacy technologies

Impact-Driven Research

A core feature of my research philosophy is that I want my research to have real-world impact. This means that I want my students to think about how their research can be used in practice, and to take steps to ensure that it does. This might include:

• Engaging with policymakers or other stakeholders to understand their needs and how to shape our research to meet them
• Publishing in venues that are read by policymakers, the public, or other stakeholders
• Speaking with the media about our research

Automated Software Testing (Fuzzing) and Vulnerability Discovery

This is my secondary area of interest, and I am open to taking on students here.

Van Thuan Pham and Toby Murray at the University of Melbourne and I jointly run a research group addressing this topic.

Our theme has been “testing what is hard to test” — we have built a number of tools (EDEFuzz, TrailBlazer, and others) that are designed to test software systems that are difficult to test with traditional fuzzing techniques.

In the past, we have targeted IoT devices and web applications, but we are open to exploring other areas as well.

If you are interested in working with me on this topic, you should have a strong background in systems and programming, as well as some experience with web technologies (JavaScript, HTML, etc.). Advising on this topic is co-supervised with Thuan or Toby, and we advise as a group (e.g., meetings are scheduled with all of us, though more often than not one of us will not be present for a given meeting).

The co-advising arrangement allows us to take on more students, to benefit from our different perspectives, and also allows us to handle workloads and time zones. Each of us frequently travels or has outside commitments, so this arrangement allows us to be more flexible.

Other Research Areas

I occasionally take on students working in other areas of security/privacy research, particularly if they are tangentially related to my core interests. I have worked with students on topics including:

• Internet Security
• Applied Cryptography and Cryptographic Protocols (I no longer consider myself primarily a cryptographer, but I will work with students in this area if we can find a way to work together)

Methodologies

I am open to a broad variety of research methodologies, but my most significant personal expertise has been in reverse engineering, measurement, and human-subjects research. While I am not a lawyer, I also bring a legal perspective to my research, and have co-authored work with lawyers and law professors.

If you are my student, you should expect to bring to the table a mix of technical and non-technical skills, though depending on what stage you’re at, you will likely learn how to think about the “other side” of problems as you go (e.g., technical for my less technical students or non-technical for my more technically oriented students). You should also not expect that I will be able to help you with all aspects of your research—I hire students hoping that they will teach me something new as well!

Expectations and Advising Style

I expect my students to operate with high levels of autonomy. I enjoy working closely with students on developing professional skills around writing, communication, and the research process itself. Frequently, I will work with my students to help them develop the soft skills that are important for successful research careers: writing, presenting, and communicating clearly.

Much to my chagrin, I find I function better with fewer pre-scheduled meetings but frequent ad-hoc check-ins. Where I work with Toby and Thuan, this is facilitated by the fact that though we have a regular meeting, it is supplemented by ad-hoc meetings as needed, with scheduling flexibility for all of us.

I am also a more “managerial” advisor, meaning that I expect my students to be responsible for acquiring the skills they need to do their own research, even where those have not been explicitly taught. That said, I also enjoy getting down in the weeds sometimes, both with writing and technical details. I quite enjoy systems administration and debugging, so you might find me helping you with that sort of thing.

I believe in work-life balance, but also generally expect my students to be contactable as a general matter given the nature of research—some aspects of research are inherently unpredictable, and may require bursts of work at less convenient times. I do not expect my students to be working 24/7, but I do expect them to be responsive and engaged.

My Communication Style

Weekly meetings are typical, but are not the only point of contact. Depending on the project, there may be lab meetings, or more informal check-ins. My students should expect to send regular updates and to come to meetings with a clear agenda.

I am “very online” and typically respond to emails and messages within a few hours or a day or two at most. I am also happy to meet outside of scheduled meetings, and encourage my students to reach out as needed.

Your (Ideal) Communication Style

I expect students to respond promptly to communication. If my students are going to be unavailable or less responsive (e.g. attending a conference, traveling, handling personal matters), I expect to be notified in advance when feasible.

I take student wellbeing seriously, and I want to make sure that my students are supported. Let me know if you need support, are facing challenges, or need help with anything outside of research as well—I value open lines of communication.

Group Structure and Community

I run a collaborative group. Students often work together on some projects to share knowledge and skillsets, while still owning independent research threads. We frequently meet as a group to share progress and challenges.

I expect my students to share the mission and values of my lab. I value kindness and empathy, expect collegial behaviour towards labmates and collaborators, and I expect students to lend a hand when labmates need it.

I also expect my students to maintain regular contact with other members of the group. Many projects will involve students with different backgrounds; I expect students to be proactive in sharing knowledge and to be good citizens of the lab.

What traits do you look for in a student?

I look for students with:

• Technical acumen. I have a preference for students who have both a strong understanding of computer science fundamentals and ideally some background in security/privacy. That said, I have worked with students from a variety of backgrounds, and I am open to students who are willing to learn and grow.
• Experience in systems thinking. I expect my students to be able to think about systems as a whole, and to understand how different components interact with each other. This is particularly important for the types of research I do, which often involve complex systems. Particularly successful students often have some disciplinary knowledge in a field outside of computer science (e.g. law, economics, psychology, etc).
• A critical or adversarial mindset. I typically value students who are good at finding flaws in systems, arguments, and assumptions, and are not afraid to challenge received wisdom. This is both helpful for problems with existing research (and thus research opportunities), writing strong papers, and also for analyzing systems themselves.
• Strong communication skills, both written and verbal. While these are both skills that I would expect a student to develop over time, I expect a baseline level of proficiency and a willingness to do the work to improve.

How do I join your lab?

First read all of the above and make sure that our interests align. If you email me because you wish to join my institution, we are not aligned, and you have not read the above, I will likely not respond to your inquiry.

Otherwise, email me with a brief description of your background, your research interests, and why you think you would be a good fit for my lab. Include the word banana. This should include an explicit reference to my past work, with arguments outlining how your interests match. Noting that you enjoyed prior work and referencing it by title would not be sufficient to demonstrate that you have read my work or understand it.

If you have a CV or resume, include that as well.

Using AI to help draft your email

I am generally a proponent of using AI tools to help with writing and learning. However, in this case, I expect you to draft your own email. This is partially a warning, as I receive a number of emails that are clearly AI-generated, and I do not respond to those—this includes those that have been translated from another language. Writing your own email helps me understand your communication skills, and typically comes across better.