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?

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

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.

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.

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.

In T41676#1372691, @jayvdb wrote:

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.

In T41676#1534806, @Mdann52 wrote:

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.

In T41676#1534806, @Mdann52 wrote:

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.

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

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

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.

I don't think there is https preference now.

As this issue is a general MediaWiki issue, not related to any Wikimedia Chinese Project since all email send from Wikimedia now are HTTPS as the canonical protocol, hence removing Chinese-Sites.

I suspect this bug is invalid/decline-able at this point.

The links will follow $wgServer (in WMF is prot-rel) or $wgCanonicalServer (in WMF is https)

If any wiki is sending HTTP links when it's a HTTPS only wiki, that's a local config issue, or maybe some odd specific code hardcoding HTTP. Should be fixed in seperate tasks

In T41676#5372307, @RazeSoldier wrote:

I don't think there is https preference now.

Indeed. I think we had something for a while... but 8 years is a long time ago. There's certainly no preference to respect in current versions of MW

There is still a 'prefershttps' in MediaWiki, but it is hidden when $wgForceHTTPS is true since rMWc75eef91bf27046ca (T256095).

Currently (1.41) $wgForceHTTPS is false by default, so there may be still MediaWiki installations with no mandatory HTTPS. This task should probably be part of a general task "Prepare MW to be HTTPS-by-default but optionally HTTP-if-specifically-requested" (but imho even in this scenario the per-user preference prefershttps should be removed).