[Advocacy Advisors] steganize PRC stoplist?

[James Salsman]

In general, steps to protect readers and editors from surveillance and
interruption in internet service because of the content they select is
probably not advocacy, but when the cause is deliberate government
intrusion, there certainly is an advocacy element. And in this instance
it absolutely is, because there are Chinese civil liberties groups which
have been stridently demanding a much more drastic approach:
https://en.greatfire.org/blog/2013/jun/wikimedia-foundation-says-it-doesnt-hold-chinese-readers-any-less-regard-we-disagree

But I will also take this to bugzilla and try to submit a proposed patch.
Per https://queue.acm.org/detail.cfm?id=2405036 which Leslie Carr
posted to wikimedia-l concerning the https filtering problem in PRC,
the Great Firewall has TCP packet text "deep" inspection which is
limited in certain ways because of high volume processing requirements.
I'm certain that general HTML to text parsing would be a huge and
difficult enhancement for it. I was recently in Shanghai and able to
confirm that it couldn't respond to strings with null <span> tags, or
hexideximal entity codes, although it does sense each type of UTF-8,
-16, and -32 encodings.

But having said that, I hope people will consider the public messaging
implications of openly automatically protecting over a billion Internet
users from surveillance in the context of the PRISM questions. It would
set a great example and perhaps inspire people to look for many simple
work-arounds able to be deployed nimbly instead of hand-wringing over
"the" best solution when a series of seperate approaches might better
serve to protect readers from surveilance trigger keywords.


On Thursday, June 20, 2013, Amgine wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 19/06/13 05:16 PM, James Salsman wrote:
> > How do people feel about inserting null <span> tags in between the
> > characters of the strings triggering surveillance and censorship
> > listed on http://cs.unm.edu/~jeffk/tom-skype/ ?
> >
> > This could most easily be accomplished during page rendering, and
> > would require a code change. I think it would be an easy code
> > change which most PHP programmers experienced with Mediawiki could
> > accomplish in less than a week, but.... let's just say some of my
> > estimates haven't always been in the ballpark.
>
>
> I don't have any strong feelings one way or another, although it would
> be exceptionally simple to work around this proposed method.
>
> On the other hand, it isn't an Advocacy Advisor's topic imo. That
> would be a MediaWiki enhancement, which can be submitted at the
> bugzilla.[1]
>
> Amgine
>
> [1] https://bugzilla.wikimedia.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/advocacy_advisors/attachments/20130620/4a28c7ad/attachment.html>