Talk:HTTPS

From Meta, a Wikimedia project coordination wiki
Jump to: navigation, search

Organisation of the content page[edit]

Here are the thoughts which drived my writing/expansion of the content page.

I follow wikitech-l and wikitech-ambassadors since many years (less for the latter :) and I have difficulties to track the various topics. I’m interested in the HTTPS topic and I find both the technical and community people should be involved in this question, hence a job for a wikitech ambassador.

I find this page should be a portal/hub -- still better it is presently -- explaining the general topic, the various questions involved (better than only the keywords presently), the past and coming deployments, and a collection of pointers about the state of the discussion (wikitech-l and bugzilla mainly for this topic).

Any thoughts about this organisation?
(Perhaps we can use this section -- with subsections -- to discuss specifically about the organisation, and let the other sections about true HTTPS questions.)
~ Seb35 [^_^] 09:34, 18 August 2013 (UTC)

Be bold. :-) --MZMcBride (talk) 16:40, 18 August 2013 (UTC)
Hi Seb35. Thanks for the dump. I am a little concerned, though, that people who are pointed to this page due to the planned Wednesday deploy of SecureLogin by default won't know where to begin; it's a little text heavy without much "what is going on, what this means for you" in simple and brief language. I hope you don't mind, but I'm going to Be bold and drastically rearrange this page to address the most common questions and conerns from users who are having problems with HTTPS. I'm going to keep much of what you wrote, just re-arrange, mostly. Thanks again! Greg (WMF) (talk) 22:49, 19 August 2013 (UTC)
Hi, thanks a lot for the rewritting, it’s better now with these simple explanations. I removed my paragraph about PRISM since you better summarised it in the introduction; I hesitated about adding a link, but it could distract the reader. ~ Seb35 [^_^] 12:14, 20 August 2013 (UTC)

Soft HSTS (HTTP Strict-Transport-Security)[edit]

I wrote an extension for MediaWiki to enable HSTS on a per-user basis. The rationale behind is to let the privacy-conscious users to opt-in to HTTPS-everytime (for all compatible browsers) independently of their current connected or unconnected status, and at the same time not force the other users to use HTTPS (particularly if they use to live in a HTTPS-unfriendly environment as the China).

I find such an extension would be worth to be installed on the Wikimedia projects (in the first times on the test wikis and then the MediaWiki wiki) to balance between the advantages and drawbacks of HTTPS, as well as slowly increase the HTTPS load of the servers. HSTS coming with a high constraint (fatal error in case of bad TLS/HTTPS connection), I find it could be tested with increasing expiration times (1 hour; 1 day; 2 weeks; 1 month) with some volunteers during the next year to test if all works correctly (e.g. the users will obligatorily complain if their old browser’s cipher suite or SSL 3.0 is removed).

~ Seb35 [^_^] 17:03, 18 August 2013 (UTC)

I misunderstood the deployment planned for August 21, 2013; I thought it was only the log-in page. This extension becomes almost useless if all HTTP traffic is 301-redirected to HTTPS, or it could be tweaked to remove the user preference and be activated for all logged-in users in order to remove the 301-redirect-over-HTTP step which can still be MITMed/spied. ~ Seb35 [^_^] 18:18, 18 August 2013 (UTC)
And the extension is now updated to give the server administrator the possibility to force anonymous and/or logged-in users to have a STS header, or to let the logged-in users choose if they want one. ~ Seb35 [^_^] 20:06, 18 August 2013 (UTC)

Load script from home wiki[edit]

En.wiki is my homewiki, and in all other projects I have this in my vector.js:
mw.loader.load( '//en.wikipedia.org/w/index.php?title=User:Edokter/MenuTabsToggle.js&action=raw&ctype=text/javascript' );

This fails in modern browsers as a XSS-violation when in HTTPS. Are there any provisions where the several Wikimedia domains are trusted with regard to eachother? Edokter (talk) — 09:56, 20 August 2013 (UTC)

I don’t know well XSS, but this syntax works for me (Opera 12.16, I have it in my en.wp common.js). Else I see on mw:ResourceLoader/Migration guide (users)#Migrating user scripts it is recommanded to keep importScript instead of switching to mw.loader to avoid problems; perhaps you can try with importScript. Else what browser+version do you have? ~ Seb35 [^_^] 12:41, 20 August 2013 (UTC)
I see en:User:Edokter/MenuTabsToggle.js itself calls mw.loader.load with 'http' explicitly specified, and Firefox 23.0 here complains about the mixed content due to that. Try making that protocol-relative as well? Anomie (talk) 13:47, 20 August 2013 (UTC)
A bug in Chrome (or was it IE?) prevents use of protocol-relative stylesheets in the .load method. XSS stands for 'Cross-site scripting'. Most moders browsers block loading scripts form another domain when you are on a secure connection. The only way to allow secure cross-site scripts to load is by whitelisting those domains in the certificate. That is what my question partains to: does our certificate has such a whitelist? Edokter (talk) — 20:47, 20 August 2013 (UTC)
Independently of XSS, about the HTTP/HTTPS in the scripts and problems with protocol-relative, you can use some script like
mw.loader.load( window.location.protocol+'//en.wikipedia.org/w/...' );
(ref) ~ Seb35 [^_^] 22:03, 20 August 2013 (UTC)
Seb35's solution is what I most commonly see for addressing this issue, so that's probably a good solution in this case. Edokter, the enwiki certificate has most of the other domains in the Subject Alternative Name. I personally haven't encountered the issue with the browsers I user, but I'll see if I can reproduce if you let me know what you're using. CSteipp (talk) 22:42, 26 August 2013 (UTC)
HTTPS has just kicked in and to my surprise, all my scripts seem to load from en.wiki just fine. Edokter (talk) — 22:09, 28 August 2013 (UTC)

Excluded language[edit]

Please add ckb wikipedia to excluded language. All sysops of ckb.wiki are from Iran and we can not access to wikimedia projects via HTTPS.--Calak (talk) 19:01, 20 August 2013 (UTC)

What is the exact list of the excluded languages: is it only zh and fa? Or are there also the other Chinese languages: yue/zh-yue, wuu, gan, cdo, nan/zh-min-nan? +those of Iran? Is there a gerrit patch about the config? ~ Seb35 [^_^] 20:25, 20 August 2013 (UTC)
Please see bug 52846, these wikis mostly used in Iran and have same problem: fa, ckb, mzn, glk, ku. I don't know any thing about Chinese languages.--Calak (talk) 20:34, 20 August 2013 (UTC)
The current plan is to exclude based on the IP/location of the user, not the language wiki. This means that users from eg China will be able to login to English Wikipedia over HTTP if needed. Greg (WMF) (talk) 23:40, 21 August 2013 (UTC)

update of automated editing tools[edit]

Are pywikipediabot, autowikibrowser, etc, now https compliant? It would be extremely disruptive to implement this change without automated editing tools being able to accommodate it. DavidLeighEllis (talk) 19:24, 20 August 2013 (UTC)

According to this message (just sent), pywikipediabot was updated for HTTPS and the pywikipediabot users must update their code with the last version. ~ Seb35 [^_^] 21:27, 20 August 2013 (UTC)
Please let me know (preferably via IRC or email, greg at wikimedia.org) if you see any tools that are not ready as soon as possible. Thanks! Greg (WMF) (talk) 23:42, 21 August 2013 (UTC)

Commons, Wikidata and SUL[edit]

Won't this create lots of trouble for people in China and Iran who need to upload an image to Commons or modify an interwiki link on Wikidata?

  • Commons: You must be logged in to upload an image. If HTTPS is unavailable and mandatory, then you can't log in.
  • Wikidata: It is possible to edit links without logging in, so I suppose that you can edit as an IP using HTTP? This however reveals your IP for everyone to see. Editing over HTTP also reveals your IP address, but only to anyone who is wiretapping you at the same time as you are accessing the Internet.
  • SUL: Logs you in automatically if you visit another project. Doesn't this mean that Chinese and Iranian users will have to log out in order to read an article in another language? This could be very inconvenient if you at the same time need to be logged in on Chinese or Iranian Wikipedia.

You can presumably access HTTPS by using VPN or TOR and you can disable login on selected projects by changing your cookie settings. However, lots of users probably don't know how to do this and the result will instead be that logging in will be disabled. I am personally able to use HTTPS and have HTTPS Everywhere installed, but I understand that lack of unencrypted HTTP for logged in users may cause lots of problems to users in some countries. --Stefan2 (talk) 19:49, 20 August 2013 (UTC)

The current plan is to redirect based on the IP/location of the user, not based on language wiki. This should alleviate this issue as we'll whitelist users from China and Iran initially, along with potentially some locations that have a hard time using HTTPS. Greg (WMF) (talk) 23:44, 21 August 2013 (UTC)

HTTPS problem[edit]

Hello. Now we can't access to all WM projects (except Meta, Commons and Incubator)!--Calak (talk) 19:54, 20 August 2013 (UTC)

  • I guess Meta, Commons, and Incubator should all be excluded from the forced https until the "GeoIP" functions are available, in order not to cause any problems there for Iranian or Chinese users who e.g. want to complain here on Meta about https problems, are active with uploading files on Commons, or active in test-projects in their language on Incubator. --MF-W 20:01, 20 August 2013 (UTC)

Now Bugzilla, MediaWiki and Wikidata have not any problem, but all WM projects are out of access. Now I am sysop on ckb wikipedia an I can't open even one page! What are we suppose to do?--Calak (talk) 20:07, 20 August 2013 (UTC)

Please see the "Help!" section of the subject-space page. IRC is fastest. :-) --MZMcBride (talk) 21:23, 20 August 2013 (UTC)
I'm confused, Calek, can you honestly not access "even on page" *right now*? We haven't made any changes yet. Greg (WMF) (talk) 23:45, 21 August 2013 (UTC)

why Chinese languages are excluded?[edit]

I think Chinese wikipedian community has made it clear that all Chinese language(Classical Chinees, Wuu chinese etc) should not be convert into https version, but here I see nothing. can somebody tell me why please? as A classical Chinese editor, I will no longer be able to do my work if it is true that Meta forget their promises.


Benjamin Jiperus (talk) 23:04, 20 August 2013 (UTC)

See also bugzilla:52846#c12 and try to get a complete list of the languages. --Stefan2 (talk) 23:12, 20 August 2013 (UTC)

The Chinese community has given a list, on that list, it shows what kind of Chinese language should not be https, that also include Tibetan, another Sino-Tibetan language that will be influenced. because most of the native speakers are located in China where HTTPs isn't an easy option. we have already got restrictions from Communist party. https is no help to us. ----Benjamin Jiperus (talk) 23:16, 20 August 2013 (UTC)

Leave choice to users[edit]

Please let users choose which transport they want to use. --Purodha Blissenbach (talk) 23:06, 20 August 2013 (UTC)

  • This. It will be complete crap if I will be forced to edit through HTTPS, it's slow on my instable connection. And FYI, forcing users should be only last resort, and I see no reason to change to HTTPS voluntarily. KPu3uC B Poccuu (talk) 02:32, 21 August 2013 (UTC)

Please leave the choice to user, this is so wrong to force people to use HTTPS if they want to stay connected. --PierreSelim (talk) 05:19, 21 August 2013 (UTC)

You can turn off HTTPS in the preferences. As of now I don’t see it, I guess it will be deployed in some hours at the same time HTTPS will become mandatory. ~ Seb35 [^_^] 06:33, 21 August 2013 (UTC)
Keep in mind that that will only disable the secure browsing and secure editing features; log-in remains only HTTPS even if that preference is selected. Risker (talk) 08:12, 21 August 2013 (UTC)
That should be enough for my JavaScript bot and for web-debugging. I'd prefer if I don't have to make my browser trust the Fiddler certificate. -- Rillke (talk) 08:11, 22 August 2013 (UTC)


Is there anyway to make the opting out of HTTPS a global preference? I tend to go to the foreign language wikis to get more extensive articles about subjects of greater import to that language community, and I'm having to manually go to the preferences page the first time I visit them after the change and to opt out of HTTPS for that wiki. That has been and remains my biggest gripe about the HTTPS switchover. Carolina wren (talk) 02:31, 12 September 2013 (UTC)

Translation[edit]

Hi. Why neither this page nor global message delivery post isn't/wasn't translatable? Do you think everybody on the planet is at least en-2? Althought I try to AGF but I can't consider it another way than not respect to local not English communities who are not obliged to learn English. WMF should never do that way again. --Base (talk) 23:26, 20 August 2013 (UTC)

Basically this is now possible in a manual way, although I’m personaly relunctant to use the Translated extension because the page is not stable and would ask frequent re-translations, but if someone wants to set up it, just do. I asked the Meta admins to change the link in the banners (I would be very happy if someone could do that!). I sent a message to the translators-l mailing list about this translation. ~ Seb35 [^_^] 13:02, 21 August 2013 (UTC)

List of Chinese Wikipedia[edit]

Please Notice these languages also need to remain http.


Benjamin Jiperus (talk) 23:28, 20 August 2013 (UTC)

Sorry there is two more languages:

Uyghur are Turkish language, a majority of Uighur people lives in the west part of China. Thank you
—The preceding unsigned comment was added by Benjamin Jiperus (talk) 23:49, 20 August 2013 (UTC)

I opened the bug 53144 for tracking this problem and wrote the list you gave (+zh :) ~ Seb35 [^_^] 07:39, 21 August 2013 (UTC)
Sichuan Yi (ii) (16 articles by now) --Geitost diskusjon 07:31, 22 August 2013 (UTC)

Perfect forward secrecy[edit]

Will the new https-including setup have the Perfect forward secrecy property? If not, it would be nice to have. There should be an option to prioritize Diffie-Hellman for key-exchange to achieve this. Wishing you good results for the procedure, good to see that coming. --Methossant (talk) 23:35, 20 August 2013 (UTC)

According to "The future of HTTPS on Wikimedia projects" PFS will not be enabled soon, but it is in the future plans. From the some things I read about PFS this blog post is interesting (activation of PFS by Google) and this one says PFS only cost 15% more in computer time (ECDHE version, because the classical DHE is much more expensive -- 300% more in compute time). But PFS is not completely supported by all modern browsers: IE support lacks, Opera only have DHE; Chromium and Firefox have full support. ~ Seb35 [^_^] 07:05, 21 August 2013 (UTC)
If you have any news in this regard, you want to upgrade to something like quantum cryptography? João bonomo (talk) 20:06, 11 September 2013 (UTC)

Unable to edit Wikidata[edit]

It says to report trouble here.
I have not been able to edit Wikidata while logged in for the past couple of days.
The [edit] buttons all appear initially, then they vanish.
Varlaam (talk) 00:36, 21 August 2013 (UTC)

Hi Varlaam, I doubt this is due to the HTTPS (the topic of this Talk: page) as nothing has changed yet :-). I've reported it to the WikiData team in this bug report. Greg (WMF) (talk) 05:07, 22 August 2013 (UTC)
Greg, thanks for pointing this our way. Varlaam, can you give a bit more info? Browser used? Operating system? Can you try switching off your gadgets and see if there is some interplay? --denny (talk) 09:30, 22 August 2013 (UTC)
I agree with Greg that it shouldn't be the HTTPS. You try disabling all your gadgets, then re-enable each individually to try to figure out if any is the problem. I remember some time ago a script caused a similar issue for me. If this doesn't help (if you still have the issue with all gadgets off, even after clearing your browser's cache, the extra information Denny asked for might be of some help.  Hazard-SJ  ✈  23:25, 22 August 2013 (UTC)

Copy editing notes[edit]

  • Please add a link to some formal statement or roadmap or approved plan that says "[t]he continued work to improve the security and privacy of Wikimedia project users is a stated goal of the Wikimedia Foundation". (I'm not doubting it's true, but a footnote/reference helps.)
  • It might also be useful to link to some internal or external site that confirms the use of Wikipedia as a site useful for tracking.
  • I recall some discussion on how images would be handled with HTTPS enabled, but wasn't technically competent enough to follow the conversation. Are there any issues with images that will change the effectiveness of the HTTPS login and browsing? If so, and since we have a huge number of non-Commons pages with images on them, it would be appropriate to mention this.
  • Also appropriate to mention any other situations where HTTPS may not be as effective as expected.

Risker (talk) 05:29, 21 August 2013 (UTC)

1. no idea about that
2. added a Jimmy Wales’ tweet with an image (perhaps the journal article is better, don’t know)
3 and 4. I guess you are speaking about the traffic analysis, allowing an attacker to guess the page you are reading by collecting the sizes of the pages, images, and ressources from all pages and comparing it afterwards to some specific request you made; if so, I think it is too technical and specific for being worth to be mentioned here (but it’s because of this fact I wrote in the introduction "you can have a reasonable expectation that nobody knows what pages you are visiting").
~ Seb35 [^_^] 13:22, 21 August 2013 (UTC)

A request of resolution[edit]

Here is all I know(forgive my English):

  • Chinese Wikipedian have send a list of Chinese language(that are not suitable for https) while the meeting was still going 2 weeks ago.I wasn't at the meeting, people who was there told me Wikimedia Foundation would take into account Chinese languages(for example Wuu, Cantonese and Classical.etc)
  • Now people are telling me except Chinese(standard), other dialects and Classical Chinese will still use https.
  • this is not what we expected.
  • I hope what is promised(if there is a promise made by Wikimedia Foundation) will be carried out.
  • If I am wrong about what I say, please tell me the actual situation of converting into https version.

thank you----Benjamin Jiperus (talk) 09:34, 21 August 2013 (UTC)

Hi Benjamin. Sorry for the confusion. The current status, as described on HTTPS, is that users from countries where HTTPS is not an option (specifically, China and Iran) will not be redirected to HTTPS but instead will stay on HTTP. Thus, if you are a Chinese user access English Wikipedia, you will still be able to login and view everything because you will be going over HTTP (as you're computer is based in China). Hope that clarifies, let me know if it doesn't. Greg (WMF) (talk) 20:18, 27 August 2013 (UTC)

Which documents?[edit]

The preamble of this article mentions: "The Wikipedia project was referenced in several documents as a specific source for tracking users' behavior online". Which documents are referenced here? Was it discussed somewhere? -- Ace111 (talk) 13:31, 21 August 2013 (UTC)

This was raised by Risker two sections above; I just added a link to one document I know, but I don’t know others. ~ Seb35 [^_^] 13:37, 21 August 2013 (UTC)
Jimbo's twitter post refers to a NSA slide from Guardian with a question: "Why are we interested in HTTP?" and an answer "Because nearly everything a typical user does on the Internet uses HTTP", followed by examples of web sites such as Facebook, Yahoo, Twitter, myspace, CNN, mail.ru, Wikipedia, Google and Gmail. I don't think this is a proper reference for Wikipedia as a specific source for tracking users' behavior. -- Ace111 (talk) 14:55, 21 August 2013 (UTC)
I remembered some people in the discussions (on wikitech-l probably) with a similar opinion. I don’t have real opinion myself if this constitutes an evidence or not; but it’s the only thing I know that people refered for this claim, but obviously perhaps there are others I missed. ~ Seb35 [^_^] 22:19, 21 August 2013 (UTC)

privacy concerns with images embedded in pages, served by Commons[edit]

Is HTTPS fully supported as well for images hosted on Commons (if Commons does not have HTTPS support for now), when these images (most often thumbnailed) are embedded in Wikipedia pages ? Can you warranty that noone will know which Wikipedia you are consulting (including in Talk pages) if they embed these images in an unique way ? It is easy to deduce which pages you are reading if you can track the images embedded in them. Commons should then support HTTPS, including on the images server (but there's a huge scalability problem because Commons is extremely large and the thumbnail image servers have lots of work to do, probably much more than wikis themselves).

Also a good thing to do would be to mutualize ALL WMF wikis on the same base domain, so that we could use the same logon domain and remain in it, even when navigating on foreign wikis (it would require only a new design for paths; e.g. allowing transparent remapping of

http(s)://(projectlangcode).(wikipedia).org/wiki/(pagename)

to

http(s)://www.wikimedia.org/(wikipedia)/(lang)/wiki/(pagename)

One bug advantage would be the unification of security, simplification of navigation. In fact we would just connect via HTTP or HTTPS to a single proxy with a single URL:

https://wikimedia.org/logon

and then all navigation would occur within the same domain within the same session, to request any number of pages or images, from any wiki of the foundation. only within this encrypted HTTPS session would the legacy URLs be requested. This proxy domain would connect directly to any one of the existing Squid proxies, forwarding internally the requests to the appropriate project wiki and image servers (or other services, including Worpress blogs, IRC channels, submission APIs, etc. that are compatible with HTTP proxies).

But the users won't see now any change in their address bar that will only show

https://wikimedia.org/logon

during their navigation across pages, projects and services. Even when they will right click a link, they will be show anonymized URLs encrypted with their current secure session keys (e.g. https://go.wikimedia.org/(base-64 encoded encrypted string containing the service/project/language/page?get parameters). Note that the proxy delivering an HTML wiki page could transform as well these links using short URLs specific to the session, to make the base-64 strings short (the proxy would cache the URLs from the original page to build short URLs specific to the session and not comparable across users, using a simple SHA1 digest of the full URL, encrypted with the private session key, so that the delivered HTML pages would only contain relative links like "/(short base64 string)")

The base-64 encoding is suggested, but a larger encoding alphabet could make the string even a bit shorter, similar to those strings used on services like TinyURL. As well the non-encrupted string could be cached internally with a mapping to make them even shorter (based on usage statistics) for frequently accessed URLs. The encryption of these short URLs would still remain private and specific to each user session.

Note that this encyption of URLs does not require to deliver any encryption key to the client, it is purely internal to the proxy that manages the encryption/devyption keys internally. Also this encryption will not increase the length of short URLs.

verdy_p (talk) 19:51, 21 August 2013 (UTC)

Commons and upload.wikimedia.org (where images are actually served from) support HTTPS. All of our projects have fully supported HTTPS for quite some time now.--Ryan Lane (WMF) (talk) 01:08, 29 August 2013 (UTC)

Loss of browser history[edit]

I just had cause to use Internet Explorer and it seems as though it was not saving history for https pages. I have not investigated fully but if I was forced to use Internet Explorer, I would prefer to be subject to snooping by the NSA than lose my browsing history. RHaworth (talk) 21:07, 21 August 2013 (UTC)

Impossible Log out[edit]

Since tonight, I can not log out. It's some feature of https? --ŠJů (talk) 20:50, 22 August 2013 (UTC)

I usually use the secure login and have never had that problem, so I wouldn't say it's a feature. Did you try going to Special:UserLogout, at least o the secure server? 72.252.242.170 23:20, 22 August 2013 (UTC)
The page Special:UserLogout appeared and the login from the top of the page dissappeared but in 1 or 2 second appeared again. However, the bug seems to be eliminated now. --ŠJů (talk) 00:53, 23 August 2013 (UTC)

http/https link embedded in wiki text using the link tool …[edit]

… does not work. If you select the link tool, and paste an url, it should be stripped off the protocol to get protocol relative urls automatically. At least for WP links like this (completely arbitrary): https://de.wikipedia.org/w/index.php?title=Benutzer_Diskussion:Koordinatenfreak&diff=118605869&oldid=118178984 the link tool shall strip the protocol. Adding //de.wikipedia.org/w/index.php?title=Benutzer_Diskussion:Koordinatenfreak&diff=118605869&oldid=118178984 to the link tool will create //de.wikipedia.org/w/index.php?title=Benutzer_Diskussion:Koordinatenfreak&diff=118605869&oldid=118178984 (url with prefix http:////de.wikipedia.org). Furthermore the wiki text (protocol relative url) //de.wikipedia.org/w/index.php?title=Benutzer_Diskussion:Koordinatenfreak&diff=118605869&oldid=118178984 should autolink like the non-protocol-relative-url does. --Herzi Pinki (talk) 23:02, 22 August 2013 (UTC)

API[edit]

Is this going to affect browser logins only, or will pure API sessions (those that occur outside a browser environment) be affected as well? This, that and the other (talk) 09:17, 25 August 2013 (UTC)

This is only for browser logins, the api does not force a redirect CSteipp (talk) 22:47, 26 August 2013 (UTC)

Causing problems[edit]

I have disabled this in my preferences, as the default left me totally unable to edit, or even view, Wikipedia. (Every time I clicked on a link, or even typed in a url, I was switched to an https url, with a popup window "couldn't parse page name from url ...". Previously, if directed to an https page, I have had to remove the s in order to open the page, but the new change made this impossible. Eventually I managed to open my preferences, find the relevant entry, and uncheck the tick; now everything works smoothly again.

I have no idea what is causing the problem; whether it is my Wikipedia gadgewts, my Firefox add-ons, or my security settings. Nor do I feel inclined to experiment and see what tweaks, if any, would resolve the problem. But it is clear to me that this change should not become a default, or be made mandatory, since this would certainly lock out readers and editors.

If anyone responds to this, please inform me at my talk page on English Wikipedia; I have never before visited Wikimedia. RolandR (talk) 00:13, 29 August 2013 (UTC)

I'm pretty sure this is due to a script you have installed (as I indicated on the VPT thread). I fixed it. ^demon (talk)
That doesn't seem to have resolved the problem. I re-enabled the secure login in my preferences, and again started to get the "couldn't parse page name" pop-up. Which of my scripts might be causing this? RolandR (talk) 10:56, 29 August 2013 (UTC)
In fact, this seems to have made the problem worse; now, although I have unticked the checkbox in Preferences, every link defaults to https, and I am unable to open any page easily. Please help! 86.186.105.211 11:10, 29 August 2013 (UTC)
If you wish to change the HTTPS setting back to HTTP, try going to [1] or [2].
If you wish to fix the problem, try going to w:User:RolandR/monobook.js and w:User:RolandR/vector.js and change "http://" to "//" everywhere on the pages. The JS files can only be edited by you or by an administrator at English Wikipedia.
If this doesn't help, then it probably means that something is wrong in one of the scripts that you are importing. --Stefan2 (talk) 12:31, 29 August 2013 (UTC)

Hello,

I also have some problems. First, I didn't get the images until I clicked to access a Commons page and validate the security certificate; now solved. But it seems the scripts don't work. I have no personnalised JS or CSS (the /monobook.js page or the like don't exist).

Any clue?

Cdang (talk) 13:46, 29 August 2013 (UTC)

Google Translate[edit]

When I paste "https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Gadgets" into either http://translate.google.com/ or https://translate.google.com/ I get the message:

Google Error
Sorry, this URL is invalid
http://fr.wikipedia.org:443/wiki/Sp%C3%A9cial:Gadgets

But when I paste the regular "http://fr.wikipedia.org/wiki/Sp%C3%A9cial:Gadgets", it translates it fine. Can someone attest that this is a Wikimedia problem and, if so, submit a bug about it? - dcljr (talk) 08:37, 29 August 2013 (UTC)

Looks like a bug in the google tool to me... Apparently it has existed for years already. Perhaps WMF operations can tickle their google contacts a bit. TheDJ (talk) 11:52, 29 August 2013 (UTC)
I've had this problem ever since I started using HTTPS (a while ago). It's a problem with Google Translate. @Snowolf: didn't you write to a mailing list about this last year? PiRSquared17 (talk) 18:55, 31 August 2013 (UTC)
I did. I don't think they ever replied to me. Snowolf How can I help? 22:09, 31 August 2013 (UTC)
Hmm. Maybe now that Wikimedia is going HTTPS for all logged-in users on all projects, they'll get more pressure to do something about it. - dcljr (talk) 01:26, 2 September 2013 (UTC)

I work for Google, and got the following answer from Google Translate team:
"Currently, the Google proxy-based web translation cannot translate HTTPS pages. It's a known limitation, and we'd like to remove that limitation."

OK, well, there's a very easy fix for that… - dcljr (talk) 02:23, 17 September 2013 (UTC)

HTTPS#Various small problems[edit]

I added this section to help users particularly with script problems or certificate problems. Be bold at rewriting it or adding issues, I have only my own experience of HTTPS problems or those reported on the village pumps (although always difficult to precisely understand what is wrong and consider solutions).

For the scripts I guess this is quite important and many editors could wonder why their scripts suddently do no more work, see these few searches: [3] (search the exact case loadJS), [4], [5], [6]; even, some users call external scripts (sometimes the destination server don’t support https). For these scripts, I don’t know what exactly should be prefered, is it importScriptURI? not mw.loader.load?

About the Authority certificate (DigiCert High Assurance EV Root CA), is there known issues with the devices which don’t have it in their certificate repository? I use to see it on the Internet and with my browsers (Opera, Firefox), but perhaps there are exotic devices or browsers or operating systems or combinaisons of these ones which don’t recognize it. ~ Seb35 [^_^] 19:15, 29 August 2013 (UTC)

Help Needed: Problems due to Secure site change[edit]

I'm not even sure how I found my way here to this page, but I am in desperate need of help, as nothing I have tried has made any real difference. Rather than repeat what I've already written over at Wikipedia, I am going to re-post my own initial comment, followed by the entire contents of the discussion that ensued when I created a new section under the same heading I've used here -- which I think may be useful for other editors to read. Cgingold (talk) 07:08, 2 September 2013 (UTC)

I) My browser history is absolutely integral to how I do things on the internet. When my browser history first disappeared, I assumed that the problem was somewhere on MY end of things. I racked my brain, I checked everything -- all to no avail. I had no idea that Wiki had switched over to secure pages, so I was really at my wits' end until I just by chance finally noticed that little "https" in the URLs. <Light bulb goes on> I then spent an hour googling a variety of search strings in hopes of finding something that would help resolve the problem. Again to no avail. Finally, I came here [to the Village Pump - technical] to see if anybody had raised the issue.

Wikipedia discussion at Village Pump (technical) talk page[edit]

  • ALL EMBEDDED LINKS ARE FOR WIKIPEDIA

As other editors have already made note of, the change-over to Secure URLs is causing problems for a lot of us. I've already explained above how upsetting it was to have my Wikipedia browsing history suddenly disappear. I mistakenly thought that unchecking the setting in my preferences had taken care of the problem. Not So. It turns out that when I specify one of the normal/non-secure Wikipedia URLs, the software no longer recognizes me as a logged-in user -- iow, the pages display as they do for any anon. IP user (and as I discovered by accident, my IP address shows up in the edit history, as one would expect). But as soon as I go to a secure URL, everything goes back to normal -- and that's without having to log in again; iow, it keeps me logged in, as it should. But those secure pages don't show up in my browser history, no matter what I do. Yes, I've changed & re-changed my preference setting and logged back in several times. And I've also looked for the trouble-making cookies that were mentioned above -- but curiously, I don't seem to have ANY cookies for Wikipedia, even though it is one of the few sites where I expressly allow them by default. <sigh> Any help on this would be hugely appreciated! Cgingold (talk) 08:34, 1 September 2013 (UTC)

You don't actually say - either here or at your previous post - which browser you're using. --Redrose64 (talk) 09:56, 1 September 2013 (UTC)
Ah, I was wondering why when I open a new browser window it shows me as not logged in. Kudpung กุดผึ้ง (talk) 09:54, 1 September 2013 (UTC)
Well, if anyone is interested, I am using Ffox 23.0.1 on MacOS 10.8.4. Looks as if the default move to https has thrown more than one spanner in the works. Kudpung กุดผึ้ง (talk) 10:36, 1 September 2013 (UTC)
I too am using Firefox, although under Windows XP. Here's how I successfully went back to http:
  1. Go to Preferences, switch off "Always use a secure connection when logged in" and save
  2. Log out of Wikipedia and close all browser tabs that contain Wikipedia pages - but keep the browser itself open
  3. In the browser menu bar, go to Tools → Options → Privacy
  4. Click the link "remove individual cookies", this opens a new window titled "Cookies" - maximise that, it makes things easier
  5. In the search bar of "Cookies", enter forceHTTPS exactly like that - it's case-sensitive
  6. Highlight a row and click Remove Cookie (the Delete key works on a PC, don't know about a Mac)
  7. Repeat until all are gone, then click Close
  8. Visit http://en.wikipedia.org/wiki/ and log in
You should now be back on http: --Redrose64 (talk) 10:50, 1 September 2013 (UTC)
Thanks for your detailed reply, Redrose64. Hopefully that will be very helpful for any Firefox users who find their way to this page. Unfortunately it doesn't help me, perhaps because I am using IE8 (although they are very similar). I had already tried to find those cookies (they were also mentioned above), but as I noted, I was unable to turn up ANY cookies at all for Wikipedia among the cookies listed in my TIF folder. Very puzzling, to say the least. Cgingold (talk) 12:52, 1 September 2013 (UTC)
Try looking in your Cookies folder. I don't quite understand why, but Internet Explorer's cookies can be found in both "Temporary Internet Files" and "Cookies". – PartTimeGnome (talk | contribs) 20:28, 1 September 2013 (UTC)
  • New Wrinkle - For a time, I was able to move from page to page in the non-secure universe, and at least those pages would show up in my browser history. But something seems to have changed. Now I cannot access ANY non-secure pages -- even when I specify "http" in the address bar of my browser, it just redirects to "httpS", regardless of whether I am logged IN or logged OUT. I think I may be starting to lose my mind. Cgingold (talk) 13:18, 1 September 2013 (UTC)
    • What kind of windows edition do you use  ? It seems that IE in the Windows server and possible professional editions seem to not store anything by default if the user is using https. —TheDJ (talkcontribs) 15:18, 1 September 2013 (UTC)
      • I'm using Windows 7. What's crazy about all of this is that unchecking the new default setting in preferences seems to have no effect whatsoever. To repeat, yes I've logged out and back in multiple times, and the setting remains unchecked. I've also looked and searched for those problem cookies, but cannot locate them, if they're even there at all. And I've never seen a Cookies folder, either. Please keep thinking about this -- your efforts are greatly appreciated! Cgingold (talk) 01:36, 2 September 2013 (UTC)
Update: I can now see my Cookies Folder. It took some doing -- no thanks to Microsoft! -- to find out how to get that folder to display. (It requires un-checking the default setting that hides all "protected operating system files".) Unfortunately, the only Wiki cookies I found were quite innocuous. No sign of those problem cookies that force the browser to use https. So I'm right back where I started: Still no way to get my browser to display non-secure pages -- and still no browser history for Wikipedia. :( Cgingold (talk) 03:12, 2 September 2013 (UTC)

My experience with HTTP links[edit]

The instructions here say, "If a user wants to login, the login will happen over HTTPS… and after they are logged in they stay on the HTTPS version of the Wikimedia site they are using." We-e-ell... I suppose this is technically true, but it doesn't quite work the way most people would expect.

After logging out and logging in again a couple of days ago (on the English Wikipedia) under the new HTTPS regime, I noticed that when following HTTP links to most other Wikimedia wikis from e-mails and bookmarks, I was not showing up as being logged in (was arriving under the HTTP protocol, of course). My bookmarks to the English Wikipedia and Meta seemed to be okay (I have visited those since the changeover, so presumably I already did something to fix the problem there), but if I tried my bookmark to, say, the Italian Wikibooks (to choose a random one I hadn't visited in a while), I showed up as being logged out. Reloading didn't help. Reloading bypassing the cache didn't help. Manually typing in the prefix "https://" in the address bar... that did it. Then I was logged in. (So... I have to actually use HTTPS to "remind" WM that I'm already logged in as a registered user?)

Needless to say, I didn't want to manually type in a protocol every time I visited a new Wikimedia wiki (I help to maintain Wikimedia News, so I have occasion to visit "random" WM wikis all the time)! So I did something I really hate doing: I cleared all my cookies. And all my cookie settings (allow/deny/etc.). And my cache. And my browsing history. And then I closed and reopened Firefox (17.0.7).

After logging in to the English Wikipedia (my "home wiki") again, I found that when I first visited another WM site (in this case, Meta) — via a regular wikilink, no less... not even bookmarks or e-mail links yet — I showed up as not logged in! (And I had to accept a new cookie, which I expected, of course.) Then on to Commons: not logged in! Hey! Whatever happened to SUL?? Okay, so then I reloaded the page. Only then did it tell me "You are centrally logged in… Reload the page to apply your user settings." Okaaay. Reloaded a second time. Fine. But before reloading, I noticed that I was actually already logged in as me after the first reload. Something's screwy here... Finally, by going to another "new" wiki, I noticed that the first and second reloads can be replaced by two "local" page loads of any sort (i.e., following links to other pages on the same wiki). In other words, I'm not logged in when I first bring up a wiki (a Main Page, in particular), but after either reloading or following an internal link, I am logged in. But only then do I get the message about "[applying my] user settings". But at that point that's already been done! Something tells me this is not how it's supposed to work.

So then I tried an old HTTP bookmark (this time to the Czech Wikipedia — remember, I first logged in to the English Wikipedia). Not logged in. Not in HTTPS. Reloading didn't work. Back to where I started. So then I navigate through HTTPS links (via List of Wikipedias) back to the Czech Wikipedia. I am logged in under HTTPS. Okay, back to the List and then to the, oh, Ilokano Wikipedia. I am logged in under HTTPS.

Hmm. Okay, back to an HTTP bookmark to the Ilokano Wikipedia. Nope. HTTP and not logged in. (But I was just here! Don't you recognize me?) Finally, to an HTTP bookmark to the English Wikipedia. This time, mercifully, I show up as logged in under HTTPS.

So, the moral of this story seems to be: If you explicitly log in to a Wikimedia wiki, HTTP links to that wiki will come up as HTTPS and have you logged in. Following links to any other Wikimedia wiki (assuming they're HTTPS) works, but only after reloading or following a link. But visiting any other wiki through an HTTP link, even though you have purportedly been "CentralAuth" logged in to "all" of them, you don't get recognized as being logged in and remain an anon under HTTP. Pretty annoying.

So now I have to go through 820 or so bookmarks changing "http:" to "https:" (not to mention actually visiting all 820 wikis again to set new cookies). Yay. - dcljr (talk) 10:45, 2 September 2013 (UTC)

When I got "You are centrally logged in… Reload the page to apply your user settings.", I checked Special:Preferences and found that the setting for "Always use a secure connection when logged in" was opposite to what I thought it was. Flipping it and saving, then reloading the appropriate page, got things back in synch. It was necessary to do this separately for meta, commons, etc. --Redrose64 (talk; at English Wikipedia) 12:09, 2 September 2013 (UTC)
Is this bugzilla:53538? --Stefan2 (talk) 13:40, 2 September 2013 (UTC)
My original report? Yeah, looks like it (although the thing about the late "centrally logged in" notice isn't mentioned there). I guess we'll see what happens when 1.22wmf16 is deployed (over the next few days). - dcljr (talk) 12:47, 5 September 2013 (UTC)
I've been having some trouble staying logged in between projects (i.e. Commons) for a long time - well before https. But it happens only when I have some scripts enabled (NoScript), and admittedly... I might not have had them all enabled at the start, and so gotten to some state unexpected by the developers. Have you been using the same sort of script control? Wnt (talk) 18:00, 2 September 2013 (UTC)
What browser are you using? If the problem is that you are logged in when you use HTTPS but not when you use HTTP, then you might wish to install HTTPS Everywhere, provided that you use a browser compatible with that. --Stefan2 (talk) 18:20, 2 September 2013 (UTC)

Updates on the Https situation[edit]

[Note: I've copied this from the Village Pump (technical) talk page over at Wikipedia.]

  • Update1 - Hmmm. Has something been tweaked on your end? (i.e. some lines of code at Wikipedia/Wikimedia?) Just in the last hour I discovered that I was able to access Http pages while I'm logged in -- which I was NOT able to do before (except for a very short period over the weekend). They're also showing up in my browser history, as expected. And I can see that HotCat has returned, as well (though I haven't tried using it as of yet). However -- you knew that was coming, didn't you?? -- there's still some work to be done: When I accessed a couple of articles via redirects, they displayed as though I had suddenly logged out, even though I hadn't done so and was in fact demonstrably still logged in! (The links on those pages took me to normal pages that displayed properly.) I'll post another update later on today. Needless to say, I'm keeping my fingers crossed that things won't revert to dysfunctionality in the next couple of hours! Cgingold (talk) 14:48, 2 September 2013 (UTC)
Addendum to Update1: Complicating the picture I described in my update above, I just had a couple of pages accessed via redirects display properly -- but a couple of Category pages displayed improperly, as though I had logged out. So it seems there's no real pattern to whatever the hell is going on. <sigh> Cgingold (talk) 15:33, 2 September 2013 (UTC)
  • Update2 - Okay, it is now many hours later in the day. The positive developments I noted earlier have held up without reverting to the intractable problems I experienced over the weekend. For the most part, I am able to access Http pages and they display properly -- i.e. the Wiki software recognizes that I am logged in. I can also report that HotCat is functioning normally for me -- another major relief. However, there is still a recurring problem that crops up in a seemingly random fashion, causing certain pages to display as though I was not logged in -- even though I can go directly to other pages that display normally, without having had to log in again first. I suspect, however, that these problem pages may not be entirely random -- iow, they may possibly have some feature in common that results in problems with the new software -- mainly because certain pages continue to exhibit this problem every time I access them. Case in point: Category:Biological evolution, which displays as though I'm just an Anon. IP editor every time. Guess that'll do it for now. I hope I've given you techies enough "hints" to make some headway in tracking down the source of the problem. :) Cgingold (talk) 04:32, 3 September 2013 (UTC)

Security information[edit]

When browsing wikipedia (via firefox, if it makes a difference), now in https, getting the security information by pressing the lock icon next to the URL, the browser reports "you are connected to wikipedia.org which is run by (unknown)". Similarly, meta.wikimedia.org is also reported "unknown". When clicking "more information" the browser reports under identity "owner: This website does not supply ownership information". Methinks this warrants correction. 87.68.44.102 10:02, 4 September 2013 (UTC)

I was curious, and checked, 12 days later. Using Google Chrome browser, both the identity and certificate seem proper, as meta.wikimedia.org, using SSL with DigiCert High Assurance CA-3 and 128-bit encryption connection SHA-1. I didn't check the entire CA chain, I confess. --FeralOink (talk) 13:26, 20 September 2013 (UTC)

Wikimedia sites and tracking, documentation[edit]

First, I wanted to mention that HTTPS is working perfectly for me, every time, on every WMf site, with the possible exceptions of Wikidata. Thank you!

Earlier, on 21 August 2013, inquiries were made by Risker

"Please add a link to some formal statement or roadmap or approved plan that says "[t]he continued work to improve the security and privacy of Wikimedia project users is a stated goal of the Wikimedia Foundation". (I'm not doubting it's true, but a footnote/reference helps.) It might also be useful to link to some internal or external site that confirms the use of Wikipedia as a site useful for tracking"

and by Ace111

"The preamble of this article mentions: "The Wikipedia project was referenced in several documents as a specific source for tracking users' behavior online". Which documents are referenced here? Was it discussed somewhere?"

These concerns were acknowledged and action was taken to address them by Seb35

"I just added a link to one document I know, but I don’t know others."

However, I agree with Ace111's subsequent response:

"Jimbo's twitter post refers to an NSA slide via The Guardian with a question: "Why are we interested in HTTP?" and an answer "Because nearly everything a typical user does on the Internet uses HTTP", followed by examples of web sites such as Facebook, Yahoo, Twitter, myspace, CNN, mail.ru, Wikipedia, Google and Gmail. I don't think this is a proper reference for Wikipedia as a specific source for tracking users' behavior."

Jimmy Wales' Twitter message reads as follows:

NSA snooping on what YOU are reading at Wikipedia means I want us to go to SSL sooner. Bastards fuck off. Owly

The Owly-shortened URL directs to this image via The Guardian, which I haven't uploaded, though I guess I should. It is not a COPYVIO, as it is an alleged screen shot of antiquated social media icons in the characteristically MS Paint, circa Win 95 style, of PRISM slides. There is some lettering at the top, in light orange colored font, on a darker orange background, which might say "COMINT" (or maybe HUMINT or NOfORN or one of those other acronyms we've had 4 months with which to become familiar). That isn't suficient as a proper reference for Wikipedia as a specific source for tracking users' behavior, just as Ace111 said. In fact, Jimmy Wales message was directly replied to by Steven Walling

"the Foundation has not received any requests to date" https://blog.wikimedia.org/2013/07/18/wikimedia-foundation-letter-transparency-nsa-prism/

which leads me to wonder whether there were evidence of tracking by the NSA of Wikipedia users and/ or editors et al. Next, even though he sounds full of bravado, the content of Jimmy Wales' Twitter message is rather hostile, specifically,

Bastards fuck off.

Jimmy Wales as an individual is entitled to tell the NSA to fuck of. But using his personal Twitter account as the basis for Wikimedia's decision to transition to SSL, with that particular content, is representing Wikimedia foundation I would think. We don't tell any government entity to fuck of as official policy, I don't think. We didn't tell Khazakhastan to fuck of, nor Syria, nor Libya, nor North Korea, nor the Taliban. I don't need to list further bete-noire perceived countries, as you get the idea. Remember, the NSA is acting as explicitly directed by the elected government of the USA, the executive branch and/ or the Department of Homeland Security. Bad men tell the NSA to do bad things.

I don't want that Twitter message linked in the article, here, please? I fully agree with, and applaud Wikimedia's decision to transition to HTTPS and SSL. If further encryption measures are added in the future, I wouldn't argue against it.

In fact, why is there any need to justify the switch to HTTPS at all? Someone needs to find some non-self-referential external source (or provide better detail from this one, The Guardian article, not Jimmy Wales), or just delete that section entirely, and thus resolve the pesky issue of explaining why SSL is needed. I will take it upon myself to do so, but wanted to explain myself first, and generate discussion, as the AfD folks say! --FeralOink (talk) 01:22, 17 September 2013 (UTC)

Still being forced into using HTTPS on occasion[edit]

Just now, I had to go thru the once every 30 days log in again. And despite having that I do NOT want HTTPS, it forced me into HTTPS and I had go and manually delete the cookies yet again! I understand why you are advocating HTTPS, but they don't apply to me or my use of Wikimedia, so I like to keep things as simple as possible. It's bad enough that each time I visit a Wikimedia site I haven't used since the change I have to go change the preferences for that site to undo the automatic HTTPS, but to have to keep deleting cookies is even worse. Carolina wren (talk) 02:15, 29 September 2013 (UTC)

This sounds like bug 54626, the fix for which should be deployed starting on Thursday, October 3 and finishing up on October 10. Unless it gets pushed out sooner. BJorsch (WMF) (talk) 13:58, 30 September 2013 (UTC)

Preference[edit]

After this program is implemented, will individual contributors still be able to disable HTTPS if so they desire? Gryllida 22:21, 17 September 2014 (UTC)

Why is the above question written in the future tense? This was implemented last year. Individual contributors can disable HTTPS at Special:Preferences#mw-prefsection-personal by unchecking the "Always use a secure connection when logged in" checkbox. --Stefan2 (talk) 22:52, 17 September 2014 (UTC)
I'm referring to the planned change. In October 2014, some projects (not globally; currently this is on Russian Wikipedia) plan to roll out https by default to unregistered contributors. Some others are considering following their example and I'm trying to access the implications of such change. Gryllida 23:03, 17 September 2014 (UTC)

API from contributor's username[edit]

I understand that the program implies that where I visit a page, I will be automatically redirected to HTTPS. Will the same happen for API queries I send from a bot/script? Gryllida 22:21, 17 September 2014 (UTC)

I'm referring to the planned change. In October 2014, some projects (not globally; currently this is on Russian Wikipedia as a result of community consencus) plan to roll out https by default to unregistered contributors. Some others are considering following their example and I'm trying to access the implications of such change. Gryllida 23:04, 17 September 2014 (UTC)

Common HTTPS access issues[edit]

What is the common nature of the HTTPS access issues the https at wikimedia.org folks encounter, as suggested here? I e-mailed them in but got no response. I would like to know who we would be locking out here and why. Gryllida 22:21, 17 September 2014 (UTC)

HTTPS access is or has been blocked by the authorities in some countries (see HTTPS#Excluded Countries). I assume that users in these countries may run into problems if they have to use an HTTPS connection. I do not know if users also may have other problems. --Stefan2 (talk) 22:55, 17 September 2014 (UTC)
I was told that this was addressed by extensive EventLogging tests that didn't reveal trouble of "random crappy ISP setup" sort, but only revealed country-specific issues (and this program is being rolled out outside of these countries as I understand). Would be useful to have some documentation of tests, for reference. Gryllida 22:57, 17 September 2014 (UTC)

Opting out for unregistered contributors[edit]

This is perhaps a slightly useless question, as the folks can use another internet access point to register, and opt out then (if the preference is still available). But is there currently no means to opt out without registering? See also bugzilla:20151. Can we think about it again? To me, a lot of preferences appear to be harmless to expose to IP contributors (HTTPS/HTTP toggle being one of them). Gryllida 22:57, 17 September 2014 (UTC)

To clarify: I'm referring to the planned change. In October 2014, some projects (not globally; currently this is on Russian Wikipedia) plan to roll out https by default to unregistered contributors. Some others are considering following their example and I'm trying to access the implications of such change. Gryllida 23:04, 17 September 2014 (UTC)
Where do I find information about the planned change? I hadn't heard of it until you mentioned it on this talk page.
Users who are not logged in can still change many settings by using a tool such as w:Greasemonkey. However, I realise that this method isn't very user-friendly. I don't know if this method provides a way to opt out from forced HTTPS.
Are you suggesting that some users won't be able to visit any Russian Wikipedia pages (including ru:Special:UserLogin?) unless the users are logged in when the page is accessed? --Stefan2 (talk) 23:28, 17 September 2014 (UTC)
I have no idea what plans Gryllida is talking about, but official plans are at mw:Wikimedia Engineering/2014-15 Goals#Site Operations and Site Architecture.
So far zh.wiki and others had an opt-out from the forced HTTPS for registered users but I seriously doubt there will be any opt-in mechanism for further HTTPS changes. --Nemo 06:06, 18 September 2014 (UTC)
No, they don't plan access changes. Local consensus at Russian Wikipedia. Oh, and they opted in here. Gryllida 09:09, 18 September 2014 (UTC)
Gryllida, Where did you find this date "October 2014", сan you give a link to us? Sunpriat (talk) 20:08, 26 September 2014 (UTC)

Russian Wikinews[edit]

Please, let me know when you turn on HTTPS for Russian Wikinews (diff). --sasha (krassotkin) 07:36, 22 September 2014 (UTC)