Home

Jeeves

It is increasingly important for applications to protect user privacy. Unfortunately, it is often non-trivial for programmers to enforce privacy policies. We have developed Jeeves to make it easier for programmers to enforce information flow policies: policies that describe who can see what information flows through a program. Jeeves allows the programmer to write policy-agnostic programs, separately implementing policies on sensitive values from other functionality. Just like Wooster's clever valet Jeeves in Wodehouse's stories, the Jeeves runtime does the hard work, automatically enforcing the policies to show the appropriate output to each viewer.

From what I gather, Jeeves takes Aspect Oriented approach to privacy. This is of course not a new idea. I presume that many of the classic problems with AOP would apply to Jeeves. Likewise, using information flow analysis for handling privacy policies is not an new idea. Combining the two, however, seems like a smart move. Putting the enforcement at the run-time level makes this sound more practical than other ideas I have heard before. Still, I personally think that specifying privacy policies at the end-user level and clarifying the concept of privacy at the normative, legal and conceptual levels are more pressing concerns. Indeed, come to think of it: I don't really recall a privacy breach that was caused by a simple information flow bug. Privacy expectations are broken on purpose by many companies and major data breaches occur when big databases are shared (recall the Netflix Prize thing). Given this, I assume the major use-case is for Apps, maybe even as a technology that someone like Apple could use to enforce the compliance of third-party Apps to their privacy policies.

I haven't looked too closely, so comments from more informed people are welcome.

Jeeves is implemented as an embedded DSL in Scala and Python.

By Ehud Lamm at 2014-02-26 18:33 | DSL | Scala | Software Engineering | other blogs | 9971 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Jeeves, AOP, and Privacy Enforcement

Thanks for posting.

You're right that Jeeves takes a similar approach as AOP by separating out policy enforcement as a cross-cutting concern. Jeeves is different than existing AOP approaches, which allow the programmer to hook in code at specific control flow points. Information flow requires a tighter coupling with the language semantics: in order to prevent implicit flows (information leaks through conditionals involving sensitive values), we need to be able to hook policy enforcement code at every conditional. A problem with classical information flow is this inability to hook into all points of the target program. Jeeves gets around this by having a language semantics designed to propagate different "views" of values of interest and simulating executions on all views. Because Jeeves has this enhanced runtime, the programmer can rely on the runtime to show the appropriate results to each viewer even when they come from complex computations on the original sensitive values.

You're right that big data breaches typically don't occur as information flow bugs in the application. (Although there are occasional leaks where you can deduce X by searching Y on a site like Facebook...) There are, however, many bugs that happen because of gaps between enforcing policies in the runtime and enforcing policies in the database. To that end we're currently working on extending Jeeves guarantees across the web framework: for instance, across the database interface.

Happy to further clarify.

By jeanyang at Wed, 2014-02-26 20:59 | login or register to post comments

I should have said something

I should have said something about the "views" or facets approach. I think that makes a lot of sense.

The problem I have with the "deduce X by searching Y" thing is that I think the problem goes beyond enforcing information flow. Suppose I want a reporting system to allow a user to get aggregate statistics (e.g., average salaries) for a set of records the user searches for, yet I want to block users from knowing the salary of an individual. Well, what happens when the user is clever enough to search for a group that consists of a single individual that they can identify through other means? How do you prevent this from happening?

By Ehud Lamm at Wed, 2014-02-26 21:59 | login or register to post comments

Differential privacy

There's a lot of work in differential privacy that's focused on giving reasonable answers to this question. It works better than you might think.

By Sam Tobin-Hochstadt at Sun, 2014-03-02 02:19 | login or register to post comments

Any specific references I

Any specific references I should check?

By Ehud Lamm at Sun, 2014-03-02 15:42 | login or register to post comments

References

I just found out differential privacy has a Wikipedia page, which does not seem unreasonable.

Given my own area of interest, the works on differential privacy (DP) I know most about may not be representative of what's out there; they are:

- Benjamin Pierce's group at UPenn, with in particular a lot of work on language-based DP; the short story being that maybe existing type systems for information-flow control can be re-interpreted to give reasonable DP analyses
- Gilles Barthes' group at MSR, working on mechanized formalization of DP (and all things security)

By googling I found that Benjamin Pierce had 2012 slides that provide an overview of the topic, with references, mentions of those two lines of work, and others. That's probably a good starting point.

By gasche at Sun, 2014-03-02 16:02 | login or register to post comments

Information flow and differential privacy

You are right that for this aggregate salary example, information flow would simply disallow individual salaries from flowing to the viewer, which is more restrictive than we would like. For this reason it would be useful to look at how we can incorporate differential privacy constructs (for expressing these kinds of conditionally-permitted flows) into Jeeves. This is something I'm interested in adding to Jeeves--and that I think is possible to do by extending the current machinery with additional kinds of constraints. Happy to hear your thoughts.

By jeanyang at Thu, 2014-02-27 14:49 | login or register to post comments

I think is possible to do

I think is possible to do by extending the current machinery with additional kinds of constraints.

Can you say a little more about this?

By Ehud Lamm at Fri, 2014-02-28 09:21 | login or register to post comments