Wikipedia talk:Wikipedia Signpost/2015-06-10/Technology report
Discuss this story
Regarding the https: would have been nice if I'd seen this before my my bot to go belly up for a day. 
Magog the Ogre (t • c) 18:53, 13 June 2015 (UTC)
- You will all be free, we will make you! While I support the idea of "https everywhere" enforcing it imposes computational overhead on people who may not want that, and so it is a bit sad.
- All the best: Rich Farmbrough, 19:06, 13 June 2015 (UTC).
- Given the nature of some authoritarian governments to snoop on their users, this might be for the best. Low tech users in Hong Kong could read about the three ts without worry of anyone know about it (for example). Magog the Ogre (t • c) 20:43, 13 June 2015 (UTC)
- Most things we do cause some computational overhead. Some people don't want the overhead associated with javascript, and would be fine if we just didn't have it. Some people would be fine if the site still looked like this. Other's want different things. We should be evaluating costs vs benefits, as opposed to some absolute "there is some overhead". From my view, the cost is minimal (I'm not sure if anyone has actually quantified the performance difference, although it would vary quite a lot between different people. It would be interesting to see what it is. I personally can't tell the difference). There is a reasonable argument that when people visit wikipedia, they implicitly assume that they are only talking to wikipedia, and that we have a responsibility to take reasonable precautions to prevent what they're looking at from falling into other people's hands (Not just https, but they also assume for example that we don't sell data to third parties). Without enforcing HTTPS for everyone, there are various tricks (ssl stripping attacks) a malicious person could use in order to trick someone who wants to view in https to view in http. So its not just about forcing it on people who don't want it, but ensuring that people who do want it, actually get it. Bawolff (talk) 22:02, 13 June 2015 (UTC)
- Well said, Bawolff. Spot on.--Elvey(t•c) 23:02, 13 June 2015 (UTC)
- Most things we do cause some computational overhead. Some people don't want the overhead associated with javascript, and would be fine if we just didn't have it. Some people would be fine if the site still looked like this. Other's want different things. We should be evaluating costs vs benefits, as opposed to some absolute "there is some overhead". From my view, the cost is minimal (I'm not sure if anyone has actually quantified the performance difference, although it would vary quite a lot between different people. It would be interesting to see what it is. I personally can't tell the difference). There is a reasonable argument that when people visit wikipedia, they implicitly assume that they are only talking to wikipedia, and that we have a responsibility to take reasonable precautions to prevent what they're looking at from falling into other people's hands (Not just https, but they also assume for example that we don't sell data to third parties). Without enforcing HTTPS for everyone, there are various tricks (ssl stripping attacks) a malicious person could use in order to trick someone who wants to view in https to view in http. So its not just about forcing it on people who don't want it, but ensuring that people who do want it, actually get it. Bawolff (talk) 22:02, 13 June 2015 (UTC)
- Given the nature of some authoritarian governments to snoop on their users, this might be for the best. Low tech users in Hong Kong could read about the three ts without worry of anyone know about it (for example). Magog the Ogre (t • c) 20:43, 13 June 2015 (UTC)
- It is important to note something where more people will read it – some of the losses people endure, for example the loss of drop-down lists for form fields like "edit summary", are easily fixed by upgrading to the most recent versions of their software, such as Win8.1 and IE-11. This will help ensure a smoother, more seamless HTTPS editing experience. Best of Everything to You and Yours! – Paine 02:05, 14 June 2015 (UTC)
- Https only means other language Wikipedia's aren't translatable in Google Translate anymore :( 80.176.129.180 (talk) 09:05, 14 June 2015 (UTC)
- Hmm? Seems to work for me https://translate.google.com/translate?hl=en&ie=UTF8&prev=_t&sl=en&tl=fr&u=https://en.wikipedia.org/wiki/Special:BlankPage Bawolff (talk) 11:14, 14 June 2015 (UTC)
- Actually, i can't see how that could be: Google refuses to translate secure sites:
File:Google translate HTTPS.pngUgh, cannot upload that image here, since "You must be logged in to upload files", so here it is: http://i60.tinypic.com/2przqz8.png -- 82.76.227.135 (talk) 09:41, 26 June 2015 (UTC)
- Actually, i can't see how that could be: Google refuses to translate secure sites:
- Hmm? Seems to work for me https://translate.google.com/translate?hl=en&ie=UTF8&prev=_t&sl=en&tl=fr&u=https://en.wikipedia.org/wiki/Special:BlankPage Bawolff (talk) 11:14, 14 June 2015 (UTC)
- Is it possible to opt out of the https?--The Theosophist (talk) 22:43, 14 June 2015 (UTC)
- No. For HSTS to work properly, we can't have an opt out. Bawolff (talk) 02:55, 15 June 2015 (UTC)
- @Bawolff: Then it would have been better if users had been asked about it before it was implemented. Now that we have a separate wiki only for conducting elections, this could have been a great opportunity to use it...--The Theosophist (talk) 02:28, 16 June 2015 (UTC)
- There's a lot of things regarding the communications about HTTPS deployment that could have been better, imo. Bawolff (talk) 04:19, 16 June 2015 (UTC)
- @Bawolff: Then it would have been better if users had been asked about it before it was implemented. Now that we have a separate wiki only for conducting elections, this could have been a great opportunity to use it...--The Theosophist (talk) 02:28, 16 June 2015 (UTC)
- I don't see this as absolute. If a user with account sets an opt out, then the server can suppress the HSTS header for that user. The only requirement then is for the user to be identified before the session commences. This will be the case if the session is initiated after sign-on which would apply if you came from a different WM site. I'm not sure that HSTS has much value in avoiding SSL-stripping attacks. All the best: Rich Farmbrough, 22:22, 15 June 2015 (UTC).
- Also would require that user never visits anything on the domain not part of the authentication system, has never been opted in to https at any point, has never viewed the site logged out, has never shared the computer with someone who is opted in, doesn't visit any redirecting domains which are handled before user-authentication, and that we don't use HSTS preloading (I think but don't know, that the plan is to eventually have HSTS settings for wikipedia preloaded into chrome et al). Bawolff (talk) 22:44, 15 June 2015 (UTC)
- I don't see this as absolute. If a user with account sets an opt out, then the server can suppress the HSTS header for that user. The only requirement then is for the user to be identified before the session commences. This will be the case if the session is initiated after sign-on which would apply if you came from a different WM site. I'm not sure that HSTS has much value in avoiding SSL-stripping attacks. All the best: Rich Farmbrough, 22:22, 15 June 2015 (UTC).
- I am tentatively supportive of this, but what will be the page seen by those who don't have https support? Will it be some form of 404 or will we have an informative SOPA-like page about why and whats? --Piotr Konieczny aka Prokonsul Piotrus| reply here 01:57, 15 June 2015 (UTC)
- It would probably depend on your web browser (We don't control the error, its the web browser that makes the error). Probably not something friendly. I'd expect something like "The protocol https is not supported". I'm not even sure where you can find something that doesn't support https now a days (With the exception of maybe some unix command line tools which are sometimes compiled with https disabled) Opera ≤ 4 and Internet Explorer ≤ 6 are the only ones listed at Transport_Layer_Security#Web_browsers without out support for a new enough version of HTTPS. For example, on IE6 (which i just happen to have installed because reasons) the error is: "The page cannot be displayed", followed by in very small letters, "Cannot find server or DNS Error" and "If you are trying to reach a secure site, make sure your Security settings can support it. Click the Tools menu, and then click Internet Options. On the Advanced tab, scroll to the Security section and check settings for SSL 2.0, SSL 3.0, TLS 1.0, PCT 1.0.". On the other hand, lwp-request (a command line program used for debugging sometimes) gives me "LWP will support https URLs if the Crypt::SSLeay module is installed. More information at <http://www.linpro.no/lwp/libwww-perl/README.SSL>." Bawolff (talk) 02:54, 15 June 2015 (UTC)
- Shouldn't it be possible (and easy) to redirect anyone with problematic connection to a page that briefly explains that error and directs the reader to further resources? I think it would be the responsible thing for us to do. Particularly given that people affected by this are likely in need of most help (elderly, impoverished, otherwise digitally illiterate). --Piotr Konieczny aka Prokonsul Piotrus| reply here 03:04, 15 June 2015 (UTC)
- Its really not the easiest thing to detect on the server side in a low latency (let alone secure) way. The best way I could think of would be to load something in HTTPS, check to see if that's successful and if so load the HTTPS page, otherwise load the help page (And prey the browser you're checking has js support). But that would add a lot of delay to loading wikipedia as you'd have to run the check before loading the page. And it probably wouldn't work if the followed a direct link to https, which is more and more likely as rel="canoncial" tag takes affect. IE6 is the most modern browser that doesn't have TLS 1.0 enabled by default (And really the only one of any consequence at all). It was released 13 years ago, and most modern websites work poorly in it. Bawolff (talk) 05:18, 15 June 2015 (UTC)
- I'm not aware of any problem I will have because of this change. I do know http links would give me the way Wikipedia looks if I'm not signed in, but I fixed links I send myself in emails. Someone's solution to upgrade to IE11 may not work for me because I haven't gotten an automatic update since IE9. And I didn't like that one. It has a glitch that may have caused what looks like vandalism when I tried to edit.— Vchimpanzee • talk • contributions • 18:25, 15 June 2015 (UTC)
- Not being logged in if browsing to http is no longer an issue (Since its impossible to browse to normal http). As long as you are fine with the edit summary no longer having autocomplete, IE9 should also be fine. Bawolff (talk) 19:31, 15 June 2015 (UTC)
- That part gets on my nerves, so I'd rather not have it.— Vchimpanzee • talk • contributions • 20:59, 15 June 2015 (UTC)
- Not being logged in if browsing to http is no longer an issue (Since its impossible to browse to normal http). As long as you are fine with the edit summary no longer having autocomplete, IE9 should also be fine. Bawolff (talk) 19:31, 15 June 2015 (UTC)
- I'm not aware of any problem I will have because of this change. I do know http links would give me the way Wikipedia looks if I'm not signed in, but I fixed links I send myself in emails. Someone's solution to upgrade to IE11 may not work for me because I haven't gotten an automatic update since IE9. And I didn't like that one. It has a glitch that may have caused what looks like vandalism when I tried to edit.— Vchimpanzee • talk • contributions • 18:25, 15 June 2015 (UTC)
- Its really not the easiest thing to detect on the server side in a low latency (let alone secure) way. The best way I could think of would be to load something in HTTPS, check to see if that's successful and if so load the HTTPS page, otherwise load the help page (And prey the browser you're checking has js support). But that would add a lot of delay to loading wikipedia as you'd have to run the check before loading the page. And it probably wouldn't work if the followed a direct link to https, which is more and more likely as rel="canoncial" tag takes affect. IE6 is the most modern browser that doesn't have TLS 1.0 enabled by default (And really the only one of any consequence at all). It was released 13 years ago, and most modern websites work poorly in it. Bawolff (talk) 05:18, 15 June 2015 (UTC)
- Shouldn't it be possible (and easy) to redirect anyone with problematic connection to a page that briefly explains that error and directs the reader to further resources? I think it would be the responsible thing for us to do. Particularly given that people affected by this are likely in need of most help (elderly, impoverished, otherwise digitally illiterate). --Piotr Konieczny aka Prokonsul Piotrus| reply here 03:04, 15 June 2015 (UTC)
- It would probably depend on your web browser (We don't control the error, its the web browser that makes the error). Probably not something friendly. I'd expect something like "The protocol https is not supported". I'm not even sure where you can find something that doesn't support https now a days (With the exception of maybe some unix command line tools which are sometimes compiled with https disabled) Opera ≤ 4 and Internet Explorer ≤ 6 are the only ones listed at Transport_Layer_Security#Web_browsers without out support for a new enough version of HTTPS. For example, on IE6 (which i just happen to have installed because reasons) the error is: "The page cannot be displayed", followed by in very small letters, "Cannot find server or DNS Error" and "If you are trying to reach a secure site, make sure your Security settings can support it. Click the Tools menu, and then click Internet Options. On the Advanced tab, scroll to the Security section and check settings for SSL 2.0, SSL 3.0, TLS 1.0, PCT 1.0.". On the other hand, lwp-request (a command line program used for debugging sometimes) gives me "LWP will support https URLs if the Crypt::SSLeay module is installed. More information at <http://www.linpro.no/lwp/libwww-perl/README.SSL>." Bawolff (talk) 02:54, 15 June 2015 (UTC)
- Nice?! After so many people helped to build it into what it now is, you lock out many who could use it.— (user & occasional editor) 16:14, 16 June 2015 (UTC) — Preceding unsigned comment added by 72.251.104.22 (talk)
- Do you have actual examples of people who this change locks out, preferably with evidence to back it up (This is a serious question. If HTTPS-only is locking people out, we need to know who and how many people). Bawolff (talk) 05:21, 17 June 2015 (UTC)
- What do you need examples for? There are people (myself included) who, as you yourself said earlier, prefer a no-JS no-SSL access to information without regard to style. (Or privacy? WHAT privacy?! I'm not sending you any sensitive data at all.) And on occasion i use OffByOne for exactly that. Now it suddenly can't browse en.wp anymore... (By the way, do all mobile browsers support HTTPS?) Although the number of people affected is admittedly very low, so i guess it's understandable if you won't care about them. (i'm sure you will likewise understand if i also won't care about you anymore -- my 4k+ edits are a mediocre contribution at best anyway.) -- 82.76.227.135 (talk) 14:40, 20 June 2015 (UTC)
- Do you have actual examples of people who this change locks out, preferably with evidence to back it up (This is a serious question. If HTTPS-only is locking people out, we need to know who and how many people). Bawolff (talk) 05:21, 17 June 2015 (UTC)
Everywhere
[edit]Looks like all wikis are now https-only! :D Bawolff (talk) 05:20, 17 June 2015 (UTC)
- I do understand why the opt-out is not possible now that we have become https-only. What I do not understand is why we needed to become https-only when all people who wanted to be on https could just opt-in. Could you explain this to me?--The Theosophist (talk) 01:32, 19 June 2015 (UTC)
- While, ultimately the WMF made the decesion, and they've been exceptionally secretive to what their actual reasoning was. However, the reasons why I support this change:
- Reduce (or at least make more costly) the ability of a nation state actor to do bulk surveillance (or perhaps even an evil ISP). While ultimately https doesn't totally prevent surveillance, it does make non-targeted bulk surveliance more difficult. No longer could someone just have a computer program that scans every web request for some keyword, and report who is looking at websites with that keyword. Making https-only helps with that, as then the people with "something to hide" can blend in with the people who don't care about https.
- Prevent nations from selectively censoring Wikipedia. Some countries try to do this. HTTPS makes it a censor the entire thing, or none at all. This raises the stakes of censoring Wikipedia. The hope would be that such an entity would not be willing to censor the entire thing. While China and Russia are talked about here, there's also places like UK back in 2008. A similar concern is instead of censoring Wikipedia, a country could simply replace an article with a POV version. I suspect censorship prevention is the primary motivation for this change (See for example some of the comments on Wikimedia-l, and the mere fact that WMF legal is handling the announcements instead of treating it as a normal tech announcement).
- Prevent SSL stripping attacks on people who are opt-ed in. A country could make a giant proxy server that sits in the middle of the user and Wikipedia. Wikipedia connects to this proxy server over HTTPS, proxy server connects to user over HTTP, user is probably none the wiser. Thus users who want HTTPS won't be getting it, and further if someone made such a scheme, it could make passwords/session tokens vulnerable to eavesdroppers, where they can take over users accounts (See Firesheep). It doesn't have to be a country to do this, an average person could do this, in order to steal user passwords. This is the threat HSTS is designed to prevent (especially if preloaded into browser). I suspect this is also one of the major deciding factors for doing HTTPS-only.
- Attitudes in the tech community are shifting. Revelations about the NSA has caused many shifts among programmers in regards to encryption. While hardly universal, a growing number of tech people feel that the entire web should be https, and that a site oporator is being negligent in protecting their users if the site is not https-only. This obviously doesn't explicitly play into the reasons for going https-only, but may have affected some of the decision makers. For example, consider how the eff reacted to the switch. The language they use seems to indicate that switching https-only is a moral thing to do.
- Performance. This is going into more wild speculation, and I don't have any hard numbers to back this up, but SPDY, which is only available over HTTPS, is supposed to improve latency in loading websites. HTTPS-only may have partially been a move to improve the load time of Wikipedia pages.
Bawolff (talk) 08:03, 19 June 2015 (UTC)
Well, I suppose that these are (and should remain) above the average editor's interests.--The Theosophist (talk) 09:00, 19 June 2015 (UTC)
- It's a bit like most websites not supporting old browsers. They don't give opt-in to people with new browsers. If you don't keep up with certain necessary changes (like upgrading your computer and software), you may end up not being able to use the Internet. HTTPS is one of those must-implement techs, after all. --Piotr Konieczny aka Prokonsul Piotrus| reply here 04:33, 24 June 2015 (UTC)
← Back to Technology report