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.orgview_html.php?sq=Envato&lang=en&q=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.orgview_html.php?sq=Envato&lang=en&q=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)
← Back to Technology report