Last modified: 2013-11-15 10:52:36 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T57887, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 55887 - Using Google Translate for a Wikipedia page causes forceHTTPS session cookies to be placed
Using Google Translate for a Wikipedia page causes forceHTTPS session cookies...
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
CentralAuth (Other open bugs)
unspecified
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-18 17:40 UTC by Carolina wren
Modified: 2013-11-15 10:52 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Carolina wren 2013-10-18 17:40:58 UTC
I had originally filed this as a reopening of bug 54626 (comment 9 https://bugzilla.wikimedia.org/show_bug.cgi?id=54626#c9 ) as I was uncertain what had triggered it.  Now I know.  When I translate a wikipage with Google, that is when the forceHTTPS cookies are being set despite that breaking my preferences.

In case this affects things, at the time I do that, I am not signed in to Google, but I am signed in to Wikipedia.  When I translate the webpage on Goggle that is when I first get the popup message:
"Central login
You are centrally logged in as <username>. Reload the page to apply your user settings."
That also is likely when the fifteen unwanted cookies are placed.
Comment 1 Carolina wren 2013-10-18 17:57:10 UTC
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.
Comment 2 Andre Klapper 2013-11-08 15:24:00 UTC
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?
Comment 3 Carolina wren 2013-11-08 16:57:31 UTC
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.
Comment 4 Andre Klapper 2013-11-08 17:49:50 UTC
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?
Comment 5 Jesús Martínez Novo (Ciencia Al Poder) 2013-11-08 17:54:54 UTC
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?
Comment 6 Andre Klapper 2013-11-08 18:12:54 UTC
Gotcha. CC'ing csteipp due to the idea of CSRF.
Comment 7 Carolina wren 2013-11-08 20:55:09 UTC
(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.
Comment 8 Carolina wren 2013-11-08 20:58:59 UTC
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.
Comment 9 Chris Steipp 2013-11-08 22:52:38 UTC
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.
Comment 10 Carolina wren 2013-11-10 22:06:08 UTC
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.
Comment 11 Andre Klapper 2013-11-11 11:39:04 UTC
"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...
Comment 12 Carolina wren 2013-11-12 07:19:41 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links