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-h...
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