This article tells nothing useful.
Thanks for the feedback and sorry they were hard to find!
What? The drive to remove errors is with machines, not humans. Machines can be built which detect and fix human errors. Why is this a flawed premise? One need only look at the history of programming language innovations to see all the successful examples of errors being eliminated.
It is certainly a worthy goal to reduce errors. To not do so would be silly. But expecting errors to go to zero is not a worthy goal because there are always errors.
No, but it's pedantic to generalize "remove errors" to "remove all errors". Actually, scratch that. It's just plain wrong.
Far better to build a redundant system that is prepared for the errors instead of building an efficient system expecting no errors.
Redundant systems only deal with certain classes of errors. You're making the same mistake you accuse the author of making.
Edit: oops - I meant to reply to the parent...
One question for you: On slide 10 you show "state of the art" as a bunch of conditional logic guarding the returned values and "Jeeves" as just a simple properly lookup.
Do you know if Facebook's "state of the art" is as you are describing it in this slide, or do you think they have a proprietary framework similar to Jeeves that they use internally to abstract away all of these details (and potential liability)?
Seem that they would, but I thought you might have some first-hand knowledge you could share given the background research you must have done in order to get to the point.
It's my understanding that large companies will create proprietary frameworks that help manage privacy policies on data. Programmers will typically be required to follow certain coding discipline when working with sensitive values so that they're calling library functions to manage policies. To my knowledge, however, these libraries deal with access control (who can access a specific piece of information) rather than information flow (how information may flow through a system).
Now here's the difference between access control and information flow--and why we need a language (or at least a DSL). When you only have access control, you're trusting the programmer to tell you correctly at one point where a piece of data is going. Even if a sensitive location value is used in a bunch of search queries, the result of which is shared as a status (that becomes visible to many people with different levels of access), the programmer is responsible for asking for the right level of access when accessing that location. With the complex policies we're starting to see in modern applications, managing this is becoming increasingly burdensome for developers. That's why were looking at how to automatically handle information flow: the system tracks how sensitive values are used in order to make sure the values--and resulting computations--are flowing only to those with appropriate permissions. While it's relatively simple to hook access control into existing programming models, automatically handling information flow requires enhancing the language semantics (especially for conditions and function calls) to track additional information.
Automatically managing information flow the way Jeeves does significantly relieves programmer burden, but can be computationally expensive. Much of our research these days is about how to make this more efficient so that companies can one day put this sort of mechanism into their production systems.
Happy to answer additional questions!
"When you only have access control, you're trusting the programmer to tell you correctly at one point where a piece of data is going."
Right, that pretty much sums it all up, and I have my suspicions (independent of your response) that something like Jeeves could add value even to a "state of the art" company like Facebook :)
I'll be watching your project with great interest and may even follow up with you "offline" once I dig in some more, because I think you're really onto something of great importance. Any sufficiently complex enterprise system eventually needs something not too different from what you're working on here...
> Jeeves is a programming language for automatically enforcing privacy policies. We have implemented it as an embedded domain-specific language in Python.
I'm guessing the PR person writing the original post thought "Programming Language" sounded better.
An embedded domain-specific language is a language with its own semantics that has been grafted onto another language. For instance, Jeeves is embedded in Python. We can use Jeeves as a Python library, but when we're using Jeeves functions, the program behave like Jeeves programs rather than vanilla Python programs. (In this case, it means that the runtime tracks different possible views of sensitive values and computations done on them.) When programmers use the @jeeves decorator and the Jeeves API, the programs look like Python programs and can even use Python built-in functions and libraries, but the Jeeves library is doing work behind the scenes to make the programs behave differently.
Please submit the original source. If a blog post reports on something they found on another site, submit the latter.