Relevant Degree Programs
Complete these steps before you reach out to a faculty member!
- Familiarize yourself with program requirements. You want to learn as much as possible from the information available to you before you reach out to a faculty member. Be sure to visit the graduate degree program listing and program-specific websites.
- Check whether the program requires you to seek commitment from a supervisor prior to submitting an application. For some programs this is an essential step while others match successful applicants with faculty members within the first year of study. This is either indicated in the program profile under "Requirements" or on the program website.
- Identify specific faculty members who are conducting research in your specific area of interest.
- Establish that your research interests align with the faculty member’s research interests.
- Read up on the faculty members in the program and the research being conducted in the department.
- Familiarize yourself with their work, read their recent publications and past theses/dissertations that they supervised. Be certain that their research is indeed what you are hoping to study.
- Compose an error-free and grammatically correct email addressed to your specifically targeted faculty member, and remember to use their correct titles.
- Do not send non-specific, mass emails to everyone in the department hoping for a match.
- Address the faculty members by name. Your contact should be genuine rather than generic.
- Include a brief outline of your academic background, why you are interested in working with the faculty member, and what experience you could bring to the department. The supervision enquiry form guides you with targeted questions. Ensure to craft compelling answers to these questions.
- Highlight your achievements and why you are a top student. Faculty members receive dozens of requests from prospective students and you may have less than 30 seconds to peek someone’s interest.
- Demonstrate that you are familiar with their research:
- Convey the specific ways you are a good fit for the program.
- Convey the specific ways the program/lab/faculty member is a good fit for the research you are interested in/already conducting.
- Be enthusiastic, but don’t overdo it.
G+PS regularly provides virtual sessions that focus on admission requirements and procedures and tips how to improve your application.
Graduate Student Supervision
Master's Student Supervision (2010-2017)
Security of data is tightly coupled to its access policy. However, in practice, a data owner has control of his data’s access policies only as far as the boundaries of his own systems. We introduce graduated access control, which provides mobile, programmable, and dynamically-resolving policies for access control that extends a data owner’s policies across system boundaries. We realize this through a novel data-centric abstraction called trusted capsules and its associated system, the trusted data monitor. A trusted capsule couples data and policy into a single mobile unit. A capsule is backwards-compatible and is indistinguishable from any regular file to applications. In coordination with the trusted data monitor, a capsule provides data integrity and confidentiality on remote devices, strong authentication to a trusted capsule service, and supports nuanced and dynamic access control decisions on remote systems. We implemented our data monitor using ARM TrustZone. We show that graduated access control can express novel and useful real world policies, such as revocation, remote monitoring, and risk-adaptable disclosure. We illustrate trusted capsules for different file formats, including JPEG, FODT, MP4 and PDF. Wealso show compatibility with unmodified applications such as LibreOffice Writer, Evince, GpicView and VLC. In general, we found that applications operating on trusted capsules have varying performance, which depends on file size, application access patterns, and policy complexity.
Facebook accounts are secured against unauthorized access through passwords, and through device-level security. Those defenses, however, may not be sufficient to prevent social insider attacks, where attackers know their victims, and gain access to their accounts using the victim's device. To characterize these attacks, we ran two Amazon Mechanical Turk studies geographically restricting participant pool to US only. Our major goal was to establish social insider attack prevalence and characteristics to justify a call to action for better protective and preventative countermeasures against it. In the first study involving 1308 participants, we used the list experiment, a quantitative method to estimate that 24% of participants had perpetrated social insider attacks, and that 21% had been victims to it (and knew about it). In the second, qualitative study with 45 participants, we collected stories detailing personal experiences with such attacks. Using thematic analysis, we typified attacks around 5 motivations (fun, curiosity, jealousy, animosity and utility), and explored dimensions associated with each type. Our combined findings indicate a number of trends in social insider attacks. We found that they are common, they can be perpetrated by almost all social relations and often have serious emotional consequences. Effective mitigation would require a variety of approaches as well as better user awareness. Based on the results of our experiments, we propose methodological steps to study the perception of severity of social insider attacks. In this procedure, we include an experimental design of the study and its possible limitations. The study consists of presenting stories collected in the previously mentioned second study to a new cohort of participants. It the asks them to provide a Likert Scale rating and justification for how severe they perceive the attack in the story to be if they were the victim as well as how likely they feel they might be a victim to such an attack. Lastly, we discuss possible future work in creating countermeasures to social insider attacks, their viability and limitations. We conclude that no single technique is complete solution. Instead mitigation will require a number of techniques in combination to be effective.
The availability of open source software projects has created an enormous opportunity for empirical evaluations in software engineering research. However, this availability requires that researchers judiciously select an appropriate set of evaluation targets and properly document this rationale. This selection process is often critical as it can be used to argue for the generalizability of the evaluated tool or method.To understand the selection criteria that researchers use in their work we systematically read 55 research papers appearing in six major software engineering conferences. Using a grounded theory approach we iteratively developed a codebook and coded these papers along five different dimensions, all of which relate to how the authors select evaluation targets in their work. Our results indicate that most authors relied on qualitative and subjective features to select their evaluation targets. Building on these results we developed a tool called RepoGrams, which supports researchers in comparing and contrasting source code repositories of multiple software projects and helps them in selecting appropriate evaluation targets for their studies. We describe RepoGrams's design and implementation, and evaluate it in two user studies with 74 undergraduate students and 14 software engineering researchers who used RepoGrams to understand, compare, and contrast various metrics on source code repositories. For example, a researcher interested in evaluating a tool might want to show that it is useful for both software projects that are written using a single programming language, as well as ones that are written using dozens of programming languages. RepoGrams allows the researcher to find a set of software projects that are diverse with respect to this metric. We also evaluate the amount of effort required by researchers to extend RepoGrams for their own research projects in a case study with 2 researchers. We find that RepoGrams helps software engineering researchers understand and compare characteristics of a project's source repository and that RepoGrams can be used by non-expert users to investigate project histories. The tool is designed primarily for software engineering researchers who are interested in analyzing and comparing source code repositories across multiple dimensions.