Wikimedia Bugzilla is closed!

A little further testing seems to indicate that the fault only occurs when I translate a page on a Wikipedia language version for which I have not yet changed my user preference on to not using HTTPS.

Hi Carolina! Sorry that nobody has taken a look at this report yet and given feedback.

What is the exact order of steps to follow to reproduce this problem?

I need to be globally logged in with Wikimedia (which is always).

I need to do a Google translation of a Wikimedia page. When I do that, the upper right area, briefly shows the "Create account" stuff then it will after a second or two recognize I'm globally logged in and show the usual "Carolina wren Talk Preferences Watchlist Contributions Log out" options.

If this is for a site which I've specified that my user preference is to not use HTTPS, everything is fine.

If this were for a site which I had not specified my user preference is to not use HTTPS, that is when the problem occurs. (With accounts automatically set up whenever I visit another version while globally logged in, I've managed to accrue over 100 such per site accounts despite being active on only a few, so I haven't preemptively tried to change the preference for all of them.)

The problem does not occur if I simply visit the untranslated page on a site I haven't yet set the preference for.  While that page, as expected, uses HTTPS, it does not set the fifteen forceHTTPS cookies for commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary that are set if I view that same page via Google Translate.

Note that Google seems to have tweaked what it is doing so that I'm no longer getting the in-window Central Login message when I view the translated page, but I'm still getting the unwanted cookies, and the Central Login message shows when I next view a Wikimedia page directly.

1. Using Google Chrome 30, not logged in on google.com, logged in on en.wikipedia.org.
2. "Always use a secure connection when logged in" is enabled on https://en.wikipedia.org/w/index.php?title=Special:Preferences#mw-prefsection-personal
3. I go to http://translate.google.com/
4. I paste http://en.wikipedia.org/wiki/Home_Nations in the text field
5. I choose (translate to) "Spanish"
6. I click the "Translate" button

RESULT:
In the upper right corner, for a moment I see "Create an account" etc in Spanish. After two seconds, I see my user name there.


Please pardon my ignorance, but which exact problem does this create with the cookies?

Being automatically logged-in while you're viewing the page from an untrusted (non-WMF) domain is scary at least.

Would it be possible for us to suffer a CSRF attack because of this?

Gotcha. CC'ing csteipp due to the idea of CSRF.

(In reply to comment #4) 
> Please pardon my ignorance, but which exact problem does this create with the
> cookies?

My own problem is that by placing the cookies, they override my explicitly set preference to not use HTTPS on en.wikipedia etc.,  In order to get back to not being forced to using HTTPS, I have to both manually delete the cookies and then log back out and back in.

Just to clarify:  I have the "Always use a secure connection when logged in" set to off, not on as Andre did.  I want to use HTTP, not HTTPS.  I do not need the security features of HTTPS for my own use and HTTPS uses more bandwidth.

This is something of a bug/feature of google translate. Google gets the html from the site (anonymously) and presents that html in an iframe on googleusercontent.com. Since you're not logged in, the javascript on the page (running in the googleusercontent.com domain) pings loginwiki and the target wiki and, and "logs in" to the target wiki (even though you're actually already logged in..). After that succeeds, that javascript replaces the html div with your username, which it can do on googleusercontent's html since it's same domain.

Unfortunately for Carolina, we use the preferences for the target wiki when the login protocol runs, and as she mentioned, the default preference there is to enable https, and we set the forceHTTPS cookie at that point.

So unfortunately, the only way to get around this for Carolina is to update the preference across wikis.

Let me present a scenario ask if this is indeed what would happen.  If were logged out of wikimedia and then visited a site where I have not set the preference as I desired and then for some odd reason, logged in there, would I get the cookies set? If I understand you correctly, it would.

In that case, the bug is that while you have a preference to allow a person to choose "Always use a secure connection when logged in" (an option which which is now by default always enabled unless one chooses opt-out)  there is no option to specify "Never use a secure connection when logged in".

Incidentally, when I first noticed the problem I tried manually editing the cookies to have a value of "0" instead of "1" in hopes they were a boolean flag, but that didn't work, but perhaps you should consider doing that.

However you choose to implement it, it sounds like you need to replace the kludge you used to enforce Wales' privacy fears with one that allows those of us who don't share them to opt out globally, instead of having to make us opt out potentially hundreds of times.

"Wales' privacy fears" (I don't consider such comments very helpful) didn't play much of a role when planning https://meta.wikimedia.org/wiki/HTTPS , and there are no plans to spend much time on corner cases...

I could have been far more acerbic than I was, but I also didn't think it would have been helpful, especially since that boat has already floated.  Still, I do hope you'll eventually fix this, since it looks like the proper fix would be to provide a much needed global method to specify HTTPS use instead of the kludgy per site basis.  I can't think of any reason why anyone would want to use HTTPS on some Wikimedia sites and not use it on others.