The converse isn't the case: if I then visit my preferences page over insecure http and re-check the preference "Always use a secure connection when logged in", upon saving preferences I'm redirected to the secure site, and all my subsequent attempts to access over http are redirected (good!). Even though I don't have the forceHTTPS cookie set, even though I didn't log out and back in.

I ran into this as well when testing. really confusing.

The help message might be the way to go. Because the preference isn't the only thing that determines whether the user is put over HTTPS or not.

(In reply to comment #0)

It's happening because my UserLogin sets $wgCookiePrefixforceHTTPS to true,
and
changing the preference does NOT clear this cookie. I have to logout, after
logging back in (which redirects to secure page), I can then access other
pages
over http.

Correct. Your cookies, and their security, are setup on login, not preference updates. So you would have to re-login to see the effect.

A help notice would probably be the best way to handle it. The alternative is to reset all the user's cookies on a preference update, which I don't think is something we want to do.

(In reply to comment #3)

The help message might be the way to go. Because the preference isn't the
only
thing that determines whether the user is put over HTTPS or not.

This is also true. If the preference is unchecked, we'll always set your cookies insecure, but we will redirect back to https if you came from an https page when you clicked login. So yeah, I think a warning message is really the only way we can sanely manage this.

Change 81531 had a related patch set uploaded by Chad:
Add help message to prefershttps

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

Although it is true the cookie is removed when log out, I tried many times and it is never removed (with Opera 12.16 and Firefox 20.0). By investigating I see when I log out from a wiki (here frwiki) that the forceHTTPS cookie has a Secure attribute:

Set-Cookie: frwikiforceHTTPS=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; secure; httponly

I wonder if this secure attribute doesn’t prevent the user-agent to modify/delete the non-secure cookie; I quickly searched in the RFC 6265 (cookies) but didn’t find anything about the interactions between secure and non-secure cookies. If this bug really comes this fact, the User::clearCookie have to be changed to receive an argument to clear explicitely-unsecure cookies.

As a side fact, I see there are two forceHTTPS cookies when you connect to Wikipedia: one set by frwiki (domain fr.wikipedia.org) and one set by login.wikimedia.org (domain .wikipedia.org); I don’t know how this interacts with this bug.

Login from the specific wiki (here frwiki):

Set-Cookie: frwikiforceHTTPS=true; expires=Sat, 28-Sep-2013 00:49:37 GMT; path=/; httponly

Continuation of the login, from login.wikimedia.org:

Set-Cookie: frwikiforceHTTPS=1; expires=Sat, 28-Sep-2013 00:49:37 GMT; path=/; domain=.wikipedia.org; httponly

Change 81614 had a related patch set uploaded by Seb35:
Set a non-secure attribute when clearing a cookie

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

I confirm experimentally that removing the Secure attribute to the forceHTTPS cookie correctly delete the cookie when log out (on Opera 12.16 and Firefox 20.0). A step to really confirm this is to dive into the source code of Firefox, or perhaps try to better examinate the RFC 6265.

(I should have tested it before submitting the gerrit patch, sorry, it’s the first gerrit patch I submit.)

I was mistaken, sorry, a non-secure cookie can be deleted by a corresponding secure cookie. I just tried again with Opera and Firefox and they are really deleted (I probably worked too late last night), as it seems to be confirmed by the function nsCookieService::GetCookieStringInternal [1] in Mozilla (I guess it’s this one, although not sure). Therefore my gerrit patch is not useful, apart if some browsers search their internal database with exactly the same value for the secure attribute.

The bug in Wikimedia environment stays but only because the .wikipedia.org cookie is not deleted (the local one is deleted). By the way I should have open a new bug since it is a bit different than the original description, I read too quickly the description, sorry. This specific bug is 53536.

[1] http://mxr.mozilla.org/mozilla-central/source/netwerk/cookie/nsCookieService.cpp

Thanks for the research Seb35. In most browsers, cookies with the same name will overwrite each other, even with different security, but there could be some browsers that don't. If you see any that follow that behavior, we could add your patch in. Otherwise, I think I'll focus on getting bug 53536 fixed.

Change 81614 abandoned by Seb35:
Set a non-secure attribute when clearing a cookie

Reason:
This change was integrated in the more general change I3c16ff92781e1a72346058ae3838d8fc47019d55

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

Is this fixed and deployed now?

I don't know about deployed, but definitely fixed.

Please add a second preference:

• Never use a secure connection (HTTPS) when logged in.

for those who wish totally the converse.

(In reply to comment #14)

Please add a second preference:

Please file separate requests as separate tickets (though I can imagine this request to be a WONTFIX as I'm not convinced how large the userbase would be for adding yet another preference.)

(In reply to comment #15)
Well Facebook gets this right with a single choice,
so once this is working right on Wikipedia (yet?) one will be enough...