Page MenuHomePhabricator

Links in MediaWiki emails should respect the user's https preference
Open, LowPublic

Description

Author: jack.sns

Description:
The email I received from Chinese Wikipedia. All the link are http, not https.

Sometimes Wiki project send some E-mail to users and some of them have links, some links are https but some of them are not. For example, the Chinese Wikipedia send email to me about some article change but the link in the mail are all http. I usually https and when I click the link, I will log out. In addition, it's not safe. I think all the links should be https to make the connection safer. I hope someone can solve this problem. Thanks!


Version: unspecified
Severity: enhancement

Attached:

Details

Reference
bz39676

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:11 AM
bzimport added a project: HTTPS.
bzimport set Reference to bz39676.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Aug 27 2012, 2:54 AM

This sounds like a duplicate of bug 29898.

I think it's more a dependency: "when user has enforced https for browsing the wiki, the mail sent to this user should use https://".

Adding SSL tracking bug, and 28989 dependency.

jack.sns wrote:

I know evey page of each wiki project support https. So why not enforce using https in Wiki? It's much safer and more convenient (especially for some environment with sensorship).

(In reply to comment #3)

I know evey page of each wiki project support https. So why not enforce using
https in Wiki? It's much safer and more convenient (especially for some
environment with sensorship).

No, this has to be a user choice. Please consider http://www-uxsup.csx.cam.ac.uk/~jw35/courses/using_https/html/x183.htm

jack.sns wrote:

Maybe you're right, but I can find nowhere to choose. In addition, how to make wikipedia send email with https links to me?

(In reply to comment #4)

(In reply to comment #3)

I know evey page of each wiki project support https. So why not enforce using
https in Wiki? It's much safer and more convenient (especially for some
environment with sensorship).

No, this has to be a user choice. Please consider
http://www-uxsup.csx.cam.ac.uk/~jw35/courses/using_https/html/x183.htm

Yes it has to be a choice, but that document is probably not relevant. Lets see the 4 points:

  • 1) Browsers: Though, they'll have to figure it out because the web is moving on. Many services (including GMail, Twitter and Facebook) are already on HTTPS by default. And some don't even (want to) provide a way to disable that. All they serve over HTTP is a redirect.
  • 2) Certificates: Not relevant, we already have them and we'd keep them regardless, for people that would opt-in. And allowing the option to use HTTPS is much more important than having the option to not use HTTPS. Though we will probably allow both, no reason not to allow HTTP
  • 3) Firewalls: Again, though. The web is moving on. Many services (think: Bank websites, PayPal etc.) are already HTTPS only. Natural selection will take place and people will use services that aren't in the last century. This is inevitable.
  • 4) Server encryption overhead: This used to be a problem, but I think the big boys have proven years ago that HTTPS can be efficient as well. If anything, it is a server side issue we'll have to take care of. But I think this is no longer a problem.

At some point we will make HTTPS a default on wmf-wikis, so users that didn't choose for HTTPS will get it. However keeping a user preference to opt out after it has become the default is easy to implement. Sure, if some people (whatever the reason) don't want HTTPS, no point in forcing it :)

Is this an automatic watchlist notification email? Can you post it as text so people can translate it more easily?

Seb35 added a comment.Sep 4 2013, 9:29 PM

For continuity of the discussion this is currently discussed on wikitech-l
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/72418

Seb35 added a comment.Sep 4 2013, 10:08 PM

Some days ago I tried to census the automatic emails with links in MediaWiki (which are concerned by this bug):

  1. email confirmation emails: links to confirm or invalidate the email address (User::sendConfirmationMail with messages 'confirmemail_body*', uses Title::getCanonicalURL),
  2. password reminder: general link to the wiki (SpecialPasswordReset::onSubmit with messages 'passwordreset-emailtext-*', uses Title::getCanonicalURL; previously LoginForm::mailPasswordInternal with message 'passwordremindertext', uses $wgCanonicalServer),
  3. initial password email: general link to the wiki (LoginForm::mailPasswordInternal with message 'createaccount-text', uses $wgCanonicalServer)
  4. new message email: link to talk page (EmailNotification::composeCommonMailtext, uses Title::getCanonicalURL, this function is designed to make the message as most as possible recipient-neutral for performance reasons),
  5. watchlist emails: links to pages and diffs (idem to the new message email),
  6. user to user email: but no link in the current messages.

The classical function to create the full non-relative URLs in these functions is Title::getCanonicalURL, which uses by default a protocol PROTO_CANONICAL, id est (i.e.) the protocol defined by wgCanonicalServer. All public Wikimedia wikis have for now http as canonical protocol (and probably a lot of MediaWiki wikis also).

One non-satisfactory solution would be to simply switch the canonical protocol to HTTPS, but this would make emails received by Chinese users non-functionnal for them (this choice is currently discussed on wikimedia-l for the Wikimedia projects, but given this bug is related to MediaWiki, the solution should be a bit more general). It could be added for #1 #2 #3 an other argument in Title::getCanonicalURL to give the mailer functions an opportunity to have their own decision logic, based on the recipient; for instance to take into account $user->getBooleanPreference('prefershttps') [note: current discussion about this bug on wikitech-l highlights the fact that this preference is on for https-blocked users in China; it’s just hidden to the user].

For #4 #5 it is more difficult (if possible) to include any recipient-based logic since the messages are designed to be recipient-neutral to permit bulk mailing (and it is very important to speed as much as possible the sending for bulk mails because the volumes are high -- I administer a ML server). I don’t see a solution apart a rewrite of the function EmailNotification::composeCommonMailtext to create two versions of a same message (HTTP and HTTPS), although this would imply performance issues on major wikis.

For #3 the initial password email (user account created by an administrator) and the initial email confirmation (email registrated in the new account form), I have doubts if the user preference should be taken into account since the user never logged in, so probably the better solution is to follow the canonical protocol.

To conclude:
A) resolve this bug for #1 and #2 could be easily done, but it could block/make more difficult the reception of emails for https-blocked users (they will have to change the protocol);
B) I find not really justified the implementation of this bug for any message sent to the user before his/her first connection (e.g. #3);
C) the resolution of this bug is quite challenging (although possible) for watchlist emails and any other impersonal bulk email (#4 and #5).

Same problem with Wikidata notification emails. Lack of https leads to some people being logged out when following the link. As soon as they press another link https is restored and their logged back in. See: https://www.wikidata.org/wiki/Wikidata:Project_chat#Staying_logged_in

(In reply to comment #10)

Same problem with Wikidata notification emails. Lack of https leads to some
people being logged out when following the link. As soon as they press
another
link https is restored and their logged back in. See:
https://www.wikidata.org/wiki/Wikidata:Project_chat#Staying_logged_in

That sounds like a separate issue, bug 53538.

There are always going to be HTTP links to Wikipedia, from search engines, social networks, etc. Thus, we need to make sure (on our side) logged in users are redirected to HTTPS in such cases.

Chris said there "The remaining fixes will be deployed with 1.22wmf16". 1.22wmf16 hit all non-Wikipedia sites (including Wikidata) today, so it may be fixed.

(In reply to comment #11)

There are always going to be HTTP links to Wikipedia, from search engines,
social networks, etc. Thus, we need to make sure (on our side) logged in
users
are redirected to HTTPS in such cases.

Being logged in and clicking a http:// link in a MediaWiki notification email I do get redirected to https://.

So should this ticket be closed as WONTFIX as there are no plans to make the links in the email itself http:// ?

(In reply to comment #12)

So should this ticket be closed as WONTFIX as there are no plans to make the
links in the email itself http:// ?

Do you mean "to make the links in the email itself https://"?

I don't necessarily think it should be WONTFIXed. I was just pointing out that if they do visit/attempt to visit HTTP, it should behave correctly.

We still may want to change emails to be HTTPS at some point. This particularly makes sense for emails targeted towards logged in users, such as watchlist and Echo (including talk page) notifications, and email verification. This is logical since logged in users are now sent to HTTPS while logged in by default.

However, there are issues that complicate things. E.g. in blacklisted countries (China, Iran), logged in users are not HTTPS by default, and there is also a user preference ("Always use a secure connection when logged in") that can be turned off.

Seb35 added a comment.Dec 10 2013, 8:44 PM

With the present configuration on Wikimedia wikis, this could be almost WONTFIXed; but in the details privacy-conscious users will prefer https links from the beggining: if you have any http link there is a chance you get spied (security), and they also expect a https link (usability). So I am in favour of keeping this bug open until proper resolution, although this one will be quite complicated.

Since bug 29898 was fixed, isn't this an easy MediaWiki bug? We already vary emails based on preferences (particularly language), it's trivial to modify (or wrap) getCanonicalURL.

jayvdb renamed this task from Links in MediaWiki emails should respect the user's prefershttps preference to Links in MediaWiki emails should respect the user's https preference.Feb 3 2015, 9:15 PM
jayvdb set Security to None.
MC8 added a subscriber: MC8.
Glaisher added a subscriber: Glaisher.
jayvdb added a subscriber: jayvdb.Jun 17 2015, 3:44 AM

As my emails from Wikimedia now contain https://, and I am guessing that MediaWiki uses http:// in emails that only have a http server, I think this is now either fixed or WONTFIX-able.

As my emails from Wikimedia now contain https://, and I am guessing that MediaWiki uses http:// in emails that only have a http server, I think this is now either fixed or WONTFIX-able.

That's because the canonical URL changed. This is till a valid MediaWiki issue.

Mdann52 closed this task as Resolved.Aug 13 2015, 1:23 PM
Mdann52 claimed this task.
Mdann52 added a subscriber: Mdann52.

Fixed with move to https only

Krenair reopened this task as Open.Aug 13 2015, 1:30 PM
Krenair added a subscriber: Krenair.

No.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 13 2015, 1:30 PM
Mdann52 removed Mdann52 as the assignee of this task.Aug 13 2015, 1:37 PM

From the emails I've received from Wikipedia, this is the case, I may be misreading though...
Unless this includes user-sent emails (which we can't enforce), I can't see what needs attention here...

From the emails I've received from Wikipedia, this is the case, I may be misreading though...

Yes, because Wikipedia now uses https as the canonical protocol, and you can't get to it via http.

Unless this includes user-sent emails (which we can't enforce), I can't see what needs attention here...

What Krenair is saying is that this should be fixed for all MediaWiki installations out there, regardless of the protocol combo they use, not just WMF ones.

Restricted Application added a project: Operations. · View Herald TranscriptFeb 23 2016, 6:13 PM
BBlack added a subscriber: BBlack.

This is apparently now about MediaWiki, not about Wikimedia emails (as we're all-HTTPS), so I'm removing the Ops/Traffic tags.

Restricted Application added a project: Traffic. · View Herald TranscriptJun 2 2016, 6:45 PM
Restricted Application added a subscriber: TerraCodes. · View Herald Transcript
BBlack removed a subscriber: BBlack.Jun 2 2016, 6:45 PM
Restricted Application added a project: Operations. · View Herald TranscriptJun 2 2016, 6:45 PM

right, HTTPS implies Traffic, have to remove all 3....

Krinkle removed a subscriber: Krinkle.Jun 2 2016, 10:37 PM
Restricted Application added a project: Traffic. · View Herald TranscriptAug 5 2016, 11:40 AM
BBlack moved this task from Triage to Watching on the Traffic board.Oct 4 2016, 12:47 PM
Restricted Application added a project: Operations. · View Herald TranscriptOct 4 2016, 12:47 PM
Restricted Application added a subscriber: Cosine02. · View Herald Transcript
Dzahn added a subscriber: Dzahn.Oct 4 2016, 12:51 PM

The "Phabricator_maintenance" user re-added the project HTTPS. Then herald re-added Traffic and Operations. This is not correct, the ticket is nowadays just about Mediawiki itself. I don't want to get into edit warr-ing over the tags.

Dzahn added a subscriber: Yurik.Oct 4 2016, 1:11 PM
BBlack moved this task from Watching to BadHerald on the Traffic board.Oct 4 2016, 1:27 PM
Shizhao closed this task as Invalid.Fri, Jul 26, 4:06 AM
Shizhao added a subscriber: Shizhao.

The problem is no longer present

Shizhao changed the task status from Invalid to Resolved.Mon, Jul 29, 3:18 AM
Shizhao moved this task from Backlog to Closed on the Chinese-Sites board.
Aklapper reopened this task as Open.Mon, Jul 29, 8:36 AM

@Shizhao: With which version of MediaWiki did you test this, on which exact website?

I don't think there is https preference now.

Dzahn removed a subscriber: Dzahn.Mon, Jul 29, 7:03 PM
Shizhao moved this task from Closed to Backlog on the Chinese-Sites board.Wed, Jul 31, 3:38 AM