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:
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/