On Fri, Aug 23, 2013 at 3:43 PM, Risker <risker...@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. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
