Reproducing results is an important part of research, and an awesome way to really learn how something works! Pick any of the systems we learn about in the course and implement your own version of it. Then try to reproduce their results! You may wish to simplify some aspects of the system to make the reproduction practical within the time available.

The best way to evaluate whether a system or technique is effective is to apply it to real-world application! A thorough case study entails comparing the performance of the modified application relative to the original, reasoning about the application-level guarantees provided by the system, and discussing the overall experience of applying the system. Here are some example ideas:

• Apply K9db or RuleKeeper to existing web applications.
• Apply the methodology of the GDPR comparative evaluation to Sesame or Riverbed.
• Build a censorship-resiliant application on top of Nostr, e.g., GitHub or Piazza.
• Implement a differentially-private version of RateMyProfessor (or similar review aggregating applications).
• Build a reusable MPC survey application (e.g. an MPC version of Google Forms or SurveyMonkey).

Several of the systems we read have complementary guarantees or cover different parts of the web ecosystem. Perhaps they can be combined to offer stronger protections! Some examples include: (1) combining K9db and Sesame to create a complete GDPR compliance package, (2) applying IFC techniques to MPC frameworks to ensure computations are allowed and secure, and (3) tracking differential privacy budgets via Sesame policies.

In Resin and Sesame, each sensitive datum is stored within a privacy container with an associated policy. The datum is outside application reach, and can only be manipulated via the systems, which ensures they keep track of the policies.

These systems require developers to specify their desired policies in Python or Rust, and manually review filter objects or review and sign critical regions. Some ideas to reduce this effort include:

1. Create a small domain-specific language (DSL) for formally expressing privacy policies, including generating APIs for combining these policies and reasoning about their exact meaning.
2. Create a mechansim for verifying that a filter object or privacy region satisfies the requirements of the associated policy and context, e.g. by automatically analyzing the code via a theorem prover (e.g. Z3) or Rust verification tools (e.g. Verus).

Systems like Resin and Sesame track policies and data within the application process and ensure data leaves the application only when the policy allows it. This is not ideal in the case of large scale applications where data leaves the boundary of a process (but not the application) frequently. For example, when the application is distributed, or when the application uses underlying data storage and processing systems.

Extend the protections of policy enforcement system to include the entire application rather than a single process. You can do this by developing new wrapers and shims for popular systems like memcached or Amazon S3, modifying existing systems to track and combine policies as they process data like SQL databases.

Alternatively, help us improve and evaluate a new Sesame-based system for enforcing policies in distributed and micro-service-based applications, by applying this new system to realistic applications.

We read a paper on evaluating the usability of DP tools in the class, which studies how data practitioners use existing DP tools and libraries, and how effective these tools are at helping practitioners correctly apply DP and understand its various parameters and guarantees.

Design a similar study to evaluate existing systems and their usability and effectiveness with application developers. For example, evaluating 2-3 existing MPC frameworks, or similar IFC systems.

Alternatively, you can help us continue development of Carousels, a resource estimation tool that aims to help non-experts implement correct and efficient MPC programs, and evaluate the effectiveness of this tool via a user study.

If you are considering a project of this kind, we suggest you take a look at the DP tools paper. We will hold your project to a similar standard in terms of study design, methodology, and analysis, although we will clearly expect that you will have far fewer participants.

Note that the study design needs to be completed several weeks ahead of project presentations, so as to give enough time for the study participants to complete the study, and have enough time to analyze the collected data and form conclusions.

DELF and K9db assist applications comply with the GDPR right to deletion. However, the systems have some limitations. You can make them better!

1. Investigate an alternative design to K9db that does not create duplicate copies for records that are jointly owned, e.g., using wrapped encryption keys.
2. Extend K9db to support account and data recycling, by setting a time-to-live for pieces of data, and automatically deleting unused data that exceeds that threshold.
3. Investigate how to assist applications delete user data effectively when that data may have already been used to train machine learning models.
4. Investigate transative data deletion across organizations, e.g., when an organization shares data with other services or organizations, or sells the data to third party brokers.

These ideas may entail extending K9db's open-source implementation. Familiarity with or a willing-less to learn C++ is helpful.

Feel free to come up with your own ideas. We will help you tease these ideas apart and scope them properly. Come to office hours and tell us about a paper you are really excited by or a problem that you find motivating, and we can take it from there!