Last modified: 2010-11-23 02:46:27 UTC
Greetings. The HTTPS interface at [https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page] is not fulfilling its purpose. Content of Wikipedia is free to the general public, and is obviously not the reason for the encryption. The reason is, of course, user privacy. Wikipedia user is (or should be) protected against any possible eavesdroppers who might be trying to find out what pages he is looking at. Reasons may range from personal to political, but the secure access is obviously a necessity - otherwise it wouldn't be an option. Therefore, I need to point out that accessing images in articles is bypassing the secure server. In other words, if the user's browser(s) are not manually set up so as to not request these images, an eavesdropper listening to his requests would know exactly which ones those are. It is then only a matter of cross-matching the "File links" info from the images' description pages to find out which article the user has been viewing. For the sake of those who really need this feature, I marked it "critical". To solve this, the image references should be rewritten - for example, a header-modifying PHP script on an HTTPS server could be used. Also, none of the internal links should lead to non-secure pages (eg. image description pages are still delivered via an ordinary HTTP server - clicking to enlarge can also leak info). If this is not feasible for some reason (increase in traffic over HTTP?), images should then be delivered only on request, and they should be disabled by default. I urge the developers to keep an extra eye to other things that may leak information (such as AJAX). Thanks for hearing me out. --Luka Marčetić
Images aren't served over HTTPS on purpose, not accident.
*** This bug has been marked as a duplicate of bug 16822 ***
(In reply to comment #1) > Images aren't served over HTTPS on purpose, not accident. You have told me nothing. I still don't know the reason why, and it is still a security problem. Now this can be truly resolved by taking care of the leak, or you can wait until browsers start warning about this and in the mean while compromise the users' privacy while pretending to be secure.
