Thanks for taking the time to report this!

Please clarify if this is about reading via HTTPS, about logging in via HTTPS, or about both, what happened at which stage, and what you expected instead.

Hello. I went there to read. I hadn't been there I think since the time of introduction of forced HTTPS for anonymous editors because on all wikis I had visited prior I already changed the option to not force it on me. I was logged in already by the time the bug occured via Central Auth. So, after I went there (via insecure link, BTW), I noticed I was on secured connection. I tried to switch back to HTTP, then realized I might have never opted out, so I went to preferences and changed that, after I did the usual deletion of all ForceHTTPS cookies and logging in-out. I expected to be able to read the wiki using insecure connection after that. Instead the server still forces me to use secure one.

P. S. In fact, what I expected, when I change the preference setting, it should have an effect immediately, without the user even touching such sacred things like cookies. Why doesn't this work like that?

In T91352#1081698, @KPu3uC_B_Poccuu wrote:

Instead the server still forces me to use secure one.

For what? Reading? Logging in?

Reading.

I don't know what "reading" means. However, I confirm http://ru.wiktionary.org redirects to https://ru.wiktionary.org when logged out. That's expected: T91044.

Maybe preferences need to be clarified? There is no way to disable HTTPS, so any relevant checkbox should be greyed out.

Ugh, what? It forces while logged in. Change the title back.

It forces while logged in.

The summary is not saying the contrary. Or do you mean that you are *not* redirected to https when logged out?

@KPu3uC_B_Poccuu: A step by step explanation, with one step per line and what you see in that moment and what you expected, could be helpful. Obviously there is still confusion what this report is about.

• Opened a wiki page via insecure link. It opened in a secure connection (expected: still insecure connection).
• Tried to change the URL to get back to insecure. Got redirected to secure (expected: insecure connection).
• At this point I discovered my preferences are set to "Always keep on secure connection" or whatever is the exact wording. Turned it off.
• Repeated #2. Same results.
• Logged out. Deleted all ForceHTTPS cookies.
• Logged in. Checked no such cookies are present.
• Repeated #4-6 several times. No luck.

Hi, @KPu3uC_B_Poccuu, redirecting insecure HTTP to HTTPS for anonymous users is expected. Using HTTPS by default for anonymous users was the consensus of the Russian Wikipedia community.[1] The reason that you cannot use insecure HTTP is that we have enabled HTTP Strict Transport Security (HSTS) on Russian Wikimedia projects. I repeated your steps on IE 11, which does not support HSTS, and I could use insecure connection when logged in. There should be no way to use HTTP on all other browsers.

So in order to avoid the confusion, the solution here should be to remove the "Always keep on secure connection" option from Russian Wikimedia projects, as @Nemo_bis suggested.

[1] https://meta.wikimedia.org/wiki/HTTPS/Beta_program

OMG. I've said multiple times: I WAS DAMN LOGGED IN.

In T91352#1094773, @KPu3uC_B_Poccuu wrote:

OMG. I've said multiple times: I WAS DAMN LOGGED IN.

Oh, sorry then.

In T91352#1094773, @KPu3uC_B_Poccuu wrote:

OMG. I've said multiple times: I WAS DAMN LOGGED IN.

Oh, sorry then.

Change 194856 had a related patch set uploaded (by Nemo bis):
Hide "prefershttps" preference on HSTS domains (ru): it has no effect

https://gerrit.wikimedia.org/r/194856

What the hell is going on really? What does it mean "it has no effect"??? You can opt out of secure connection in Russian wikiprojects as a registered user. That's what my current preference across all Wikimedia projects is.

Now the same thing is going on on Russain Wikipedia, except this time I have no cookies to delete.

In T91352#1095598, @KPu3uC_B_Poccuu wrote:

What the hell is going on really?

Does https://ru.wikipedia.org/wiki/HSTS clarify? See yourself:

$ curl -Is https://ru.wikipedia.org | grep Strict-Transport-Security
Strict-Transport-Security: max-age=15768000

T91044#1074315 explains with more detail.

No, it doesn't, because you are just wrong. I don't know what business you have to do working on Wikimedia projects, but it seems you know too little and have poor reading comprehension. Because you ignored half of my statements and thus missed the fact you can freely opt out of forced HTTPS as a registered user on Russian Wikimedia projects.

What grounds do you have to state otherwise? The old beta program? Are you kidding me?

In T91352#1098719, @KPu3uC_B_Poccuu wrote:

I don't know what business you have to do working on Wikimedia projects

I have a user page where you can find out.

you can freely opt out of forced HTTPS as a registered user on Russian Wikimedia projects.

What makes you think so? All evidence points to the contrary (I just tried again). You *were* able to opt out, but this stopped being true some days ago.

This makes no sense. I have never met such incompetent developer. I filed a bug about HTTPS occasionally being forced even if you opted out. You reproduced the bug on your end somehow but instead of fixing it you declared it intentional even if it's against the official Wikimedia policy regarding HTTPS and the fact that you can still access the wikis via HTTP when the bug doesn't occur, as a developer I assume you must know the policy well. You now remind me of Valve fixing a bug in their game by officially calling it intentional after 2 years of silence on that matter.

@KPu3uC_B_Poccuu: Apart from all previous unfortunate misunderstandings in this ticket, please see https://www.mediawiki.org/wiki/Phabricator/Etiquette : there is no need to get personal here or assume roles of people. Instead, there is a software behavior that's not what you expected and clarifying and getting exact steps to reproduce took a while. Thanks for your understanding.

Okay, I'll calm myself down. Still, I believe the root of the misunderstandings is not in me being unclear, but reading my comments only partially.

There is no need to blame yourself or others. The "root of the misunderstanding" is simply a partial communication (I think WMF has plans to fix that later).

I'm not aware of the existence of the "official Wikimedia policy regarding HTTPS" which you mentioned, but I've updated the informative page that Meta-Wiki has on the topic.

Okay, tell me, do you still consider this is not a bug and why the title is still misleading. And, for the record, I honestly don't know what to expect from this ticket anymore. Maybe it will get fixed. Most likely, as it stands, nothing will be done. But there are also chances that HTTP will be blocked completely on some grounds I have no clue of, and I 'd rather not.

Even better title would be "Occasionally, projects enforce HTTPS regardless of user settings". It occurs from time to time on all projects I participate in, just that Russian Wiktionary was the one I had trouble when reporting this.

You can edit the title with "Edit Task".

If you can also reproduce it on e.g. http://en.wikipedia.org then there is something we don't know yet.

@KPu3uC_B_Poccuu: You cannot use Russian Wikimedia projects without HTTPS at this time; the cookie will not have any effect. Resolving as invalid unless you can reproduce the issue in other projects.

Why?

A Russian Wikipedia community member implemented a JavaScript redirect to send Russian Wikipedia traffic to HTTPS in August 2014, so most Russian Wikipedia traffic has been going over HTTPS since last year. A similar hack was in place in Russian Wikinews. The resulting configuration was vulnerable to man-in-the-middle attacks, as it depended on users first loading the insecure version. It also caused a major performance hit for users due to the double-loading. In consultation with Russian Wikimedia community members, consistent with our long term HTTPS rollout objectives, and consistent with the pre-existing request to participate in the HTTPS beta, we superseded the hack with a server-side redirect and HSTS as a secure and consistent default configuration for all Russian language projects.

I'm curious what your concerns are about HTTPS and whether they can be addressed? Why do you want to opt-out?

The question is, why do you feel you have the right to decide instead of me whether to use it. I explicitly opted out, and you should comply with that. When I first heard about HTTPS rolling out on Wikimedia projects, I myself raises concerns about the possibility it will negatively impact my access and capability to participate, and several users supported me. We were told we will be able to opt out, and indeed for a while it had been working great, albeit sometimes this bug occurs, and now you say you lied to us or what? If some dumbass admin on those projects decided he is the smartest being in the entire world, why do I have to suffer?

I have slow and unstable and limited by quota connection to Internet. And no, it's not going to improve because of where I live. HTTPS has additional payload and uses precious time and bandwidth up, can't be cached by proxy servers or compressed by Opera Turbo. Enough? So, please, don't forget your promises, and keep my ability to use HTTP intact, and fix this bug. Thanks for attention and understanding.

I have slow and unstable and limited by quota connection to Internet. And no, it's not going to improve because of where I live. HTTPS has additional payload and uses precious time and bandwidth up, can't be cached by proxy servers or compressed by Opera Turbo. Enough? So, please, don't forget your promises, and keep my ability to use HTTP intact, and fix this bug. Thanks for attention and understanding.

See T86666 and T35890 -- we're very aggressively optimizing HTTPS performance (SPDY also introduces additional compression). Are you able to quantify the performance difference, by comparing en.wikipedia.org on an HTTP connection vs. ru.wikipedia.org on an HTTPS connection?

While we take the performance concern seriously and are willing to continue to investigate it with you to ensure you have the best possible experience on HTTPS, at this time we will not revisit the configuration issue. I'm closing this ticket as invalid, because the reported behavior is the intended one with the exception of the checkbox needing to be hidden.

Change 194856 merged by jenkins-bot:
Hide "prefershttps" preference on HSTS domains (ru): it has no effect

https://gerrit.wikimedia.org/r/194856