[liberationtech] Addressing Imbalances in Communications via Cryptographic Redaction

[Brian Dickens]

> I'm not sure that you ought to allow people to see the number of
> redacted characters.  I know this looks like a nice user experience,
> but in other contexts, people have been able to use this information
> to more readily guess the content of what was redacted.

Thanks.  Point understood, and addressed in the video.  (e.g. "and the
killer is [XXX]" where it's a small set and Bob is one of finite
possibilities.)

While understanding the problem, I kind of want redactions to be
proportional to the amount of missing information.  I mention how you
can't redact line feeds etc, because a key goal is to get a notion of
how much information is public vs. non-public...and I didn't want you
to be able to "redact the edge of the paper".  Hence each paragraph
break splits out independent redactions, for example.

So far I've considered the length issue to be the concern of savvy
users; pad it if you feel the need.  (e.g. "and the killer is
[******it's Bob, that's who!*****]").  Perhaps there could be a
minimum redaction width in policy space for some applications.  Or
perhaps it would allow you to skew the redaction weighting, so that
you had to reach some kind of overall transparency w.r.t. amount of
redactions but push some weight into shorter portions to lengthen them
while shortening larger ones.

I'm certainly interested in talking to anyone from EFF about this.
The code is modular, shares crypto between the client and server
(since it's all JavaScript), dependencies are tightly controlled, and
it is well commented:

https://github.com/hostilefork/blackhighlighter/blob/master/jquery-blackhighlighter/jquery-blackhighlighter.js