Last modified: 2014-11-17 09:56:07 UTC
Created attachment 11010 [details] 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!
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.
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
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.