back
Frequently Asked Questions



Does the demo require installing a Chrome extension?

Yes.

Will this work only on Chrome?

The approach is general that it could be ported to any browser. The current implementation works only on Chrome.

Is this open-source?

Yes.

Is this a browser extension or a browser?

This is a browser extension.

What data does it encrypt?

It encrypts data from textboxes and input fields in web forms.

It decrypts data from any HTML element, like a div or a span, not only textboxes and input fields.

What does the code verifier do?

It reads Arc code sent by the server and does all sorts of things with it internally, but the main two are:
  • it checks all data access operations. If the server sends code that would steal unencrypted or decrypted data, the code verifier forbids that code from running.

  • it automatically generates code that automatically decrypts data when a page loads. And it also automatically generates code that automatically encrypts data when a web form is submitted.

    The user does no manual work to encrypt or decrypt.
How does using an extra language help?

It makes it easy to write the code verifier. Parsing Lisp is easier than parsing Javascript, and verifying a smaller language grammar is less work.

Does the code verifier run on the client?

Yes. It runs inside the browser extension, on the client.

How does the browser extension get updates?

There's nothing in Joan that updates the browser extension. If you download the browser extension from the Chrome store, then naturally the browser extension is updated from the Chrome store. The goal is to not need to update the browser extension though.

When I say Joan helps update web apps, I mean it's easy to change in the web app the fields that should be encrypted without needing the user to update the browser extension.

Can the government "persuade" you to update the extension in a way that compromises the verifier?

Yes. This is the same problem browsers, operating systems, and generally both software and hardware have.

If the server gets hacked can an attacker decrypt data?

Unless the browser extension itself has security flaws, no.

If I enter data in a web form, I typically trust the server. Why would I want to give a server encrypted data if I'm the only one who can decrypt the data?

Because a server can get hacked even if you trust it.

You are also not the only one who may give a server encrypted data. Anyone who wants to send you a message may give a server encrypted data. A friend who doesn't want to trust the server can encrypt a message intended for you, store it on the server, and have you download and decrypt it. Like web-based encrypted email.

The halting problem is going to prevent your verifier from being reliable. It will produce either false negatives or false positives (or it will hang).

Some of this is true and some of it seems unlikely. The code verifier is not an interpreter and therefore doesn't evaluate code. It neither needs to nor attempts to determine if a program will halt.

What the code verifier does is transform code. It determines if a program reads or writes data in forms, and generates new code for reading and writing in forms to happen safely. It also checks for unsafe data access operations during this transformation, but it never evaluates the code to do that.

Unless there is a design flaw or bug in the code verifier, there is no possibility for producing false negatives: you can't execute evil code that steals decrypted or unencrypted data. There is no theoretical limitation like the halting problem that makes this type of safe code execution impossible.

There is also proof more general safe code execution is possible. But the code verifier does nothing this complicated.

False positives are possible though, because the code verifier's checks are overprotective. This is a limitation in the implementation. Instead of keeping a separate symbol table per basic block or per function, a single symbol table is kept over the whole program. If the plugin turns out to be so overprotective in practice that it becomes unusable, then this limitation can be corrected.

The halting problem is more general than that. A corollary of the halting problem is that it is not generally possible to determine a large variety of useful properties of a program. You should read this.

This doesn't affect Joan.

The link above assumes a program only has a buffer overflow if and only if it reaches a buffer overflow when executed. This excludes programs that contain buffer overflow code but never reach that code because of, say, an infinite loop before the code.

This means the claim in the link "Guaranteeing the safety of array bounds and deciding program termination are equivalent in difficulty" is valid only under a narrower definition and phrased with broad language. The intended claim is "Guaranteeing a buffer overflow will be reached and deciding program termination are equivalent in difficulty". That's a valid claim.

You cannot guarantee a program will reach a buffer overflow.

You can guarantee a program will never reach a buffer overflow.

If we try to match the definition intended in the link above, Joan can't guarantee that visiting a web page will lead to data in the page to be encrypted if the server did not flag the data to be encrypted or if the program hits something like an infinite loop. And Joan can't guarantee the data will be decrypted if the server did not flag the data to be decrypted or if the program hits something like an infinite loop. The server has to cooperate.

But if the server doesn't cooperate, Joan still alerts the user. If the the server doesn't flag the data to be encrypted the input fields change to have a red background and an alert pops up on the page.