On Fri, Aug 23, 2013 at 3:43 PM, Risker <risker.wp(a)gmail.com> wrote:
No it doesn't change the security consideration.
What changes is the
recognition that the problem may actually be bigger than initially thought.
Everyone knew about China and Iran. Probably nobody knew about Pakistan,
Indonesia, Philippines, India, etc - all of which have multiple language
projects. Even just HTTPS logins may be a challenge for some of these
countries, and it gives the WMF reason to consider how to better support
them just so everyone is protected and isn't left with the choice of
editing by IP or not editing at all.
Hi Risker,
We made a mistake in publishing those numbers. We hadn't fully vetted
the numbers, and after they went out, we discovered a flaw in our
methodology that meant we were likely overcounting (probably
drastically) the number of HTTPS failures we would see in practice.
I'm going to quote Tim Starling's internal analysis below. My
apologies to Tim to forwarding without permission, though I doubt he
would object.
The main point is that we shouldn't draw too many conclusions about
the data. It was useful in seeing where we are being blocked (China
and Iran), but the numbers <15% probably shouldn't be counted to draw
any conclusions about problems in other countries.
Rob
Tim Starling wrote:
The test used
upload.wikimedia.org, at a time when
the
browser would already have a keepalive connection open to port 80 but
not port 443. Client-side aborts caused by navigating away from the
page are not logged, and so if the HTTP request completes earlier than
the HTTPS request, this opens a window for a systemic error in the
results. If the user navigates away after the completion of the HTTP
request, but before the completion of the HTTPS request, this would be
logged as an HTTPS failure.
My theory two days ago was that the size of the window would be the
time it took the browser to do the connection setup, or possibly the
whole request. But it occurs to me now that the browser may have its
maximum number of concurrent connections open when the test starts. So
the request might be queued by the browser until a connection slot
opens up. That queue wait time might depend on network bandwidth, as
well as RTT.
If both the HTTP and the HTTPS tests used a hostname which is unlikely
to have a keepalive connection open, and if the order of the two tests
was randomized rather than always sending the HTTP request first, then
I think you would get closer to accurate results. However, actual
performance differences between HTTPS and HTTP would still cause a
systemic error.