On Mon, Oct 25, 2010 at 11:59 PM, MZMcBride z@mzmcbride.com wrote:
George Herbert wrote:
The current WMF situation is becoming "quaint" - pros use secure.wikimedia.org, amateurs don't realize what they're exposing. By professional standards, we're not keeping up with professional industry expectations. It's not nuclear bomb secrets (cough) or missile designs (cough) but our internal function (in terms of keeping more sensitive accounts private and not hacked) and our ability to reassure people that they're using a modern and reliable site are falling slowly.
I don't understand what you're saying here. Most Wikimedia content is intended to be distributed openly and widely. Certainly serving every page view over HTTPS makes no sense given the cost vs. benefit currently.
As Aryeh notes, even those who act in an editing role (rather than in simply a reader role) don't generally have valuable accounts. The "pros" you're talking about are free to use secure.wikimedia.org (which is already set up and has been for quite some time). If there were a secure site alternative, I think you'd have a point. As it stands, I don't see what's very quaint about this situation.
It'd be great to one day have http://en.wikipedia.org be the same as https://en.wikipedia.org with the only noticeable difference being the little lock icon in your browser. But there are a finite amount of resources and this really isn't and shouldn't be a high priority.
If the goal is to reassure people that they're using a "modern and reliable site," there are lot of other features that could and should be implemented first in my view, though the goal itself seems a bit dubious in any case.
MZMcBride
I have no objection to us serving http traffic, especially as default to logged-out users. There's security sensitivity, and then there's paranoia.
But I would prefer to move towards a logged-in user by default goes to secure connection model. That would include making secure a multi-system, fully redundantly supported part of the environment, or alternately just making https work on all the front ends.
Any "login" should be protected. The casual "eh" attitude here is unprofessional, as it were. The nature of the site means that this isn't something I would rush a crash program and redirect major resources to fix immediately, but it's not something to think of as desirable and continue propogating for more years.