Unescaped JSON in LP.client.cache

Already manually deployed to lpnet/edge/staging/qastaging.

From the merge proposal:

> If IE did not exist then we could use XHTML, where <script> is
> PCDATA and the escaped JS would have entities expanded. But HTML's
> <script> is CDATA, so we have to live with some over-escaped values
> in the cache. Despite how bad this sounds, it won't affect URLs, and
> it worked fine until this vulnerability was introduced a month ago.

You have a better understanding of this than I do it seems; I did not
appreciate the PCDATA/CDATA difference between HTML and XHTML before.

Could the use of JSONEncoderForHTML, which I wrote a long time ago,
from simplejson (see bug 684430) work correctly for all situations? I
worry that escaping using &...; is going to silently corrupt data
along the line. Is that a genuine concern? If so, are we just
accepting it?

We don't yet have a recent enough version of simplejson to get
JSONEncoderForHTML, but the core of it is this very trivial bit of
code:

    json = simplejson.dumps(...)
    json = json.replace('&', '\\u0026')
    json = json.replace('<', '\\u003c')
    json = json.replace('>', '\\u003e')

We could chuck this into the webservice:json formatter and be done
with it.

I've harped on about this before, but there has been little
concern. Perhaps, like me, people are looking for someone else with
more knowledge to give a nod. Should we JFDI?

If there is a genuine possibility of data corruption I think we should
treat bug 684430 as Critical.

I noticed that bug during the postmortem this evening, and I plan to look at upgrading simplejson tomorrow.