Re: [Wikitech-l] FlaggedRevs at www.mediawiki.org
On Mon, 18 Mar 2013 22:48:52 -0700, Dmitriy Sintsov ques...@rambler.ru wrote: Hi! I cannot check out my own Extension:GoogleMapsFn manual page changes at mediawiki.org. Changes are pending few days already. Can someone do that? http://www.mediawiki.org/w/index.php?title=Extension:GoogleMapsFnoldid=648005diff=cur Dmitriy All you need is the coder flag which any coder can give you. I reviewed the changes and gave you coder. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FlaggedRevs at www.mediawiki.org
On Tue, Mar 19, 2013 at 2:32 AM, Daniel Friesen dan...@nadir-seen-fire.comwrote: All you need is the coder flag which any coder can give you. I reviewed the changes and gave you coder. If possible, could I get the flag as well. I've run into the same problem before. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FlaggedRevs at www.mediawiki.org
What is your Username?, My crystal ball is still getting repaired. On Tue, Mar 19, 2013 at 4:52 PM, Tyler Romeo tylerro...@gmail.com wrote: If possible, could I get the flag as well. I've run into the same problem before. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FlaggedRevs at www.mediawiki.org
On Mon, 18 Mar 2013 23:52:47 -0700, Tyler Romeo tylerro...@gmail.com wrote: On Tue, Mar 19, 2013 at 2:32 AM, Daniel Friesen dan...@nadir-seen-fire.comwrote: All you need is the coder flag which any coder can give you. I reviewed the changes and gave you coder. If possible, could I get the flag as well. I've run into the same problem before. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com Done (Parent5446). You should really list your name, etc... on your userpage for comparison. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Markus Glaser elected Chair of the Wikimedia Chapters Association Council
Volunteer developer Markus Glaser https://www.mediawiki.org/wiki/User:Mglaser has been elected chair of the Wikimedia Chapters Association Council http://lists.wikimedia.org/pipermail/wikimedia-l/2013-March/124665.html , which will cut down on his code reviewing availability. ;-) Congratulations, Markus. Please do let this list know if there's something WCA will be doing regarding technology development or skillshare for chapters! https://meta.wikimedia.org/wiki/Wikimedia_Conference_2012/Documentation/Day_2/Coordinating-projects -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Default policy for third-party cookies in Firefox
Hello, According to [1] and [2], Firefox 22 (release June 25, 2013) will change the default third-party cookie policy: a third-party cookie will be authorized only if there is already a cookie set on the third-party website. This would break most of the automatic login on sister projects on Wikimedia websites, since the page just after the log in will no more set cookies of sister projects, and you will have to manually log in to each domain (of level wikipedia.org, not of level de.wikipedia.org) -- I tested with Firefox 16. What could be done to mitigate this effect? According to [1] Safari already have this policy; is there some workaround already in place for Safari users? I don’t see other solutions than displaying some warning to the Firefox/Safari users (via JavaScript). [1] http://webpolicy.org/2013/02/22/the-new-firefox-cookie-policy/ [2] https://developer.mozilla.org/en-US/docs/Site_Compatibility_for_Firefox_22 ~ Seb35 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] open positions at WMF
On 19/03/13 00:54, Sumana Harihareswara wrote: Thomas, thank you for writing to us and mentioning that you're available for work! I'd love for you to take a look at the Wikimedia Foundation's job openings. For most of them, telecommuting is fine. That's a bit misleading, as only a couple of them offer a remote position (out of 19) Oh, and I noticed that you have some OTRS expertise -- could you maybe check out https://bugzilla.wikimedia.org/show_bug.cgi?id=22622 and let us know if you have some free time to volunteer your help? :-) Is it really something where volunteers can help? I thought it wasn't possible (private mail concerns blocking volunteer action). BTW, why is WMF looking for a WordPress Developer? I think that if we outgrew the current blog, the way to go would be to mediawikize it, not to make something new still based in WP. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Reminder: Next Bugday: March 19 15:00-21:00 UTC
Reminder: This starts soon, and you're welcome to join at any time. andre On Thu, 2013-03-14 at 14:20 -0500, Valerie Juarez wrote: Hello everyone! Please join us on the next Wikimedia Bugday: Tuesday, March 19, 15:00-21:00UTC [1] in #wikimedia-dev on Freenode IRC [2] We will be triaging bug reports in the LiquidThreads component [3]. The idea came up on the wikitech-l mailing list [4]. While LiquidThreads is not actively developed anymore it is still popular and deployed in many places. We will be focusing on cleaning up, improving the quality of these reports, and retesting some of them on mediawiki.org or test2.wikipedia.org. Everyone is welcome to join, and no technical knowledge needed! It's an easy way to get involved in the community or to give something back. This even is part of a weekly QA activity [5], so we encourage you to triage throughout the week and record your activity on the bug day etherpad [6]. This information and more can be found here: https://www.mediawiki.org/wiki/Bug_management/Triage/20130318 For more information on Triaging in general, check out https://www.mediawiki.org/wiki/Bug_management/Triage I look forward to seeing you there! Valerie [1] Timezone converter: http://www.timeanddate.com/worldclock/converter.html [2] See http://meta.wikimedia.org/wiki/IRC for more info on IRC chat [3] https://bugzilla.wikimedia.org/buglist.cgi?action=wrapcomponent=LiquidThreadsproduct=MediaWiki%20extensionsresolution=---list_id=186677(216 bugs) [4] http://lists.wikimedia.org/pipermail/wikitech-l/2013-February/066847.html [5] https://www.mediawiki.org/wiki/QA/Weekly_goals [6] http://etherpad.wmflabs.org/pad/p/BugTriage ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Default policy for third-party cookies in Firefox
On 19/03/13 14:38, Seb35 wrote: Hello, According to [1] and [2], Firefox 22 (release June 25, 2013) will change the default third-party cookie policy: a third-party cookie will be authorized only if there is already a cookie set on the third-party website. This would break most of the automatic login on sister projects on Wikimedia websites, since the page just after the log in will no more set cookies of sister projects, and you will have to manually log in to each domain (of level wikipedia.org, not of level de.wikipedia.org) -- I tested with Firefox 16. What could be done to mitigate this effect? (...) [1] http://webpolicy.org/2013/02/22/the-new-firefox-cookie-policy/ [2] https://developer.mozilla.org/en-US/docs/Site_Compatibility_for_Firefox_22 ~ Seb35 Copying Jonathan Mayer. Background information: When you log into eg. en.wikipedia.org, you get cookies logging you into not only *.wikipedia.org but also *.wiktionary.org, *.wiktionary.org, *.wikibooks.org, commons.wikimedia.org, etc. Obviously, that uses third-party cookies. Firefox 22 will block our single-login (unless you are already logged on the other project, which would be the case in which you would already have cookies there). If it can't be corrected, we will have to publicise this fact quite well, as I expect many complaints of Unified login doesn't work. Jonathan, do you have any suggestion? An idea to fix it would be to take advantage of the new certificate which includes all projects, by having firefox detect that the ‘third-party site’ belong to the same entity, since they share the https certificate (we would need to enable https to all logins, but that was planned, anyway). Regards ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Default policy for third-party cookies in Firefox
On Tue, Mar 19, 2013 at 6:38 AM, Seb35 seb35wikipe...@gmail.com wrote: According to [1] and [2], Firefox 22 (release June 25, 2013) will change the default third-party cookie policy: a third-party cookie will be authorized only if there is already a cookie set on the third-party website. This would break most of the automatic login on sister projects on Wikimedia websites, since the page just after the log in will no more set cookies of sister projects, and you will have to manually log in to each domain (of level wikipedia.org, not of level de.wikipedia.org) -- I tested with Firefox 16. What could be done to mitigate this effect? According to [1] Safari already have this policy; is there some workaround already in place for Safari users? I don’t see other solutions than displaying some warning to the Firefox/Safari users (via JavaScript). We're already seeing this on mobile (especially with Safari). Definitely needs fixing... Putting a login cookie on a central site and fetching some kind of token over a CORS request might work... but I'm not sure how fun this is going to be to fix. :P -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Default policy for third-party cookies in Firefox
On Tue, Mar 19, 2013 at 7:52 AM, Platonides platoni...@gmail.com wrote: An idea to fix it would be to take advantage of the new certificate which includes all projects, by having firefox detect that the ‘third-party site’ belong to the same entity, since they share the https certificate (we would need to enable https to all logins, but that was planned, anyway). I'm pretty sure Firefox won't detect this condition; the security model is based on domains, not SSL certificates. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Default policy for third-party cookies in Firefox
On Tue, Mar 19, 2013 at 8:57 AM, Brion Vibber br...@pobox.com wrote: On Tue, Mar 19, 2013 at 7:52 AM, Platonides platoni...@gmail.com wrote: An idea to fix it would be to take advantage of the new certificate which includes all projects, by having firefox detect that the ‘third-party site’ belong to the same entity, since they share the https certificate (we would need to enable https to all logins, but that was planned, anyway). I'm pretty sure Firefox won't detect this condition; the security model is based on domains, not SSL certificates. I hadn't heard of this technique to get around the issue, but if there is an exception for it, we're already doing this in our certs, so it would already be fixed. If that fails, any solution that lets us keep the cookies with httponly set is preferred. Has anyone tested firefox to see if it will accept third-party cookies loaded from: * iframes * ajax + cors * 301, 302, meta refresh, or javascript redirects I don't really want to play cat and mouse with Mozilla, but it would be nice to know if we have options. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Default policy for third-party cookies in Firefox
quote name=Seb35 date=2013-03-19 time=14:38:40 +0100 Hello, According to [1] and [2], Firefox 22 (release June 25, 2013) will change the default third-party cookie policy: a third-party cookie will be authorized only if there is already a cookie set on the third-party website. These two bugs are related to this: https://bugzilla.wikimedia.org/show_bug.cgi?id=45578 https://bugzilla.wikimedia.org/show_bug.cgi?id=45452 -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] IRC office hour on Tue March 19th, 1700 UTC, about Bug management
Reminder: This starts now. If you'd like to know how to better find information in Bugzilla that interests you, if you have ideas and criticism how to make Bugzilla better, this is the time for it! (And if you cannot make it, feel free to send me a private email, or wait for the next office hour next month.) andre On Thu, 2013-03-07 at 14:41 +0100, Andre Klapper wrote: Hi everybody, on Tuesday 19th 17:00 UTC[1], there will be an IRC Office Hour in #wikimedia-office about Wikimedia's issue tracker[2] and Bug management[3]. Add it to your calendar and come to ask how to better find information in Bugzilla that interests you, and to share ideas and criticism how to make Bugzilla better. andre [1] https://meta.wikimedia.org/wiki/IRC_office_hours [2] https://bugzilla.wikimedia.org [3] https://www.mediawiki.org/wiki/Bug_management -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Default policy for third-party cookies in Firefox
If you want to play cat and mouse, a good reference for things that work is http://samy.pl/evercookie/ It's mostly targeted at a single domain stopping users from deleting cookies, but some of the same things should break cross domain security too. I'm not sure that end of web ethics is where we want to go in general but sleazy is a spectrum and depends on intent so there may be useful inspiration in it. Luke On Tue, Mar 19, 2013 at 12:56 PM, Greg Grossmeier g...@wikimedia.orgwrote: quote name=Seb35 date=2013-03-19 time=14:38:40 +0100 Hello, According to [1] and [2], Firefox 22 (release June 25, 2013) will change the default third-party cookie policy: a third-party cookie will be authorized only if there is already a cookie set on the third-party website. These two bugs are related to this: https://bugzilla.wikimedia.org/show_bug.cgi?id=45578 https://bugzilla.wikimedia.org/show_bug.cgi?id=45452 -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Default policy for third-party cookies in Firefox
Chris: On the latest iPhone cookies were not accepted from iframes from sites that were not visited. You had to physically visit the site by following a link or typing the url into the address bar first. We are currently investigating whether meta refresh etc can help here - although that's not ideal. For our projects that would result in over 13 redirects - a horrible user experience!! Correct me if I'm wrong but the 2 problems that CentralAuth solves are 1) Takes away the inconvenience of having to login across multiple sites 2) Allows communication between wiki sites via CORS that require authentication. I'm guessing openid / oauth will solve #1 ? An idea I've banded around to solve #2 would be to allow wikis to access other projects via the api. e.g. http://en.wikipedia.org/w/api.php?action=querytitles=Photoproject=commons would allow a developer to access the page Photos on wikimedia.commons.org rather than having to resort to a CORS request (ie. it would route the query to the database for commons rather than wikipedia) For api requests that require credentials it would send the credentials of the current project (in this case wikipedia). Is that something that is feasible? (FWIW I actually dislike that CentralAuth currently logs me into various projects that I never use such as wiktiversity...) On Tue, Mar 19, 2013 at 10:32 AM, Luke Welling WMF lwell...@wikimedia.org wrote: If you want to play cat and mouse, a good reference for things that work is http://samy.pl/evercookie/ It's mostly targeted at a single domain stopping users from deleting cookies, but some of the same things should break cross domain security too. I'm not sure that end of web ethics is where we want to go in general but sleazy is a spectrum and depends on intent so there may be useful inspiration in it. Luke On Tue, Mar 19, 2013 at 12:56 PM, Greg Grossmeier g...@wikimedia.orgwrote: quote name=Seb35 date=2013-03-19 time=14:38:40 +0100 Hello, According to [1] and [2], Firefox 22 (release June 25, 2013) will change the default third-party cookie policy: a third-party cookie will be authorized only if there is already a cookie set on the third-party website. These two bugs are related to this: https://bugzilla.wikimedia.org/show_bug.cgi?id=45578 https://bugzilla.wikimedia.org/show_bug.cgi?id=45452 -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Default policy for third-party cookies in Firefox
On 19/03/13 17:41, Chris Steipp wrote: On Tue, Mar 19, 2013 at 8:57 AM, Brion Vibber br...@pobox.com wrote: On Tue, Mar 19, 2013 at 7:52 AM, Platonides platoni...@gmail.com wrote: An idea to fix it would be to take advantage of the new certificate which includes all projects, by having firefox detect that the ‘third-party site’ belong to the same entity, since they share the https certificate (we would need to enable https to all logins, but that was planned, anyway). I'm pretty sure Firefox won't detect this condition; the security model is based on domains, not SSL certificates. I hadn't heard of this technique to get around the issue, but if there is an exception for it, we're already doing this in our certs, so it would already be fixed. It was an idea I *made up* that firefox *could* implement to detect that the two domains are owned by the same entity, and so relax the «ignore third-party cookies» rules. It scales quite well for other types login cookies (eg. flickr.com and yahoo.com) but doesn't open a hole for advertising companies (eg. example.com and google-analytics.com). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Default policy for third-party cookies in Firefox
On 19/03/13 19:21, Jon Robson wrote: Chris: On the latest iPhone cookies were not accepted from iframes from sites that were not visited. You had to physically visit the site by following a link or typing the url into the address bar first. We are currently investigating whether meta refresh etc can help here - although that's not ideal. For our projects that would result in over 13 redirects - a horrible user experience!! Correct me if I'm wrong but the 2 problems that CentralAuth solves are 1) Takes away the inconvenience of having to login across multiple sites Yes. Typical usecase: you logged in to wikipedia, but then go to Wikimedia Commons to upload a photo → No need to log in again (this is also problematic for newbies, as it's counterintuitive). 2) Allows communication between wiki sites via CORS that require authentication. We aren't using CORS right now. I'm guessing openid / oauth will solve #1 ? Not really. That could solve the one password for all sites problem, but as that's done at server level, that would still work. It won't fix the you are logged in, then you opened another page [from a different project] and you aren't. An idea I've banded around to solve #2 would be to allow wikis to access other projects via the api. e.g. http://en.wikipedia.org/w/api.php?action=querytitles=Photoproject=commons would allow a developer to access the page Photos on wikimedia.commons.org rather than having to resort to a CORS request (ie. it would route the query to the database for commons rather than wikipedia) For api requests that require credentials it would send the credentials of the current project (in this case wikipedia). Is that something that is feasible? We had that in query.php and moved away from it. Feasible, but not going to happen. (FWIW I actually dislike that CentralAuth currently logs me into various projects that I never use such as wiktiversity...) But perhaps you do use meta.wikimedia and wikipedia. Although some preference for which sites you want to be logged in could help to control the proliferation of sites there. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Default policy for third-party cookies in Firefox
On Tue, Mar 19, 2013 at 11:21 AM, Jon Robson jdlrob...@gmail.com wrote: Chris: On the latest iPhone cookies were not accepted from iframes from sites that were not visited. You had to physically visit the site by following a link or typing the url into the address bar first. We are currently investigating whether meta refresh etc can help here - although that's not ideal. For our projects that would result in over 13 redirects - a horrible user experience!! Correct me if I'm wrong but the 2 problems that CentralAuth solves are 1) Takes away the inconvenience of having to login across multiple sites 2) Allows communication between wiki sites via CORS that require authentication. #2 is a more recent addition, which we're using in mobile for photo uploads, but it wasn't an original target. #1 has two components: A) can use the same username password to log in everywhere B) only log in once, and have it apply on our other sites A) is achieved with a central database for user credentials B) is achieved within domains (*.wikipedia.org) by setting a cookie that works across subdomains (still safe) B) is achieved *across* domains by using special trigger images to set third-party cookies (now endangered) I'm guessing openid / oauth will solve #1 ? Not really, we'd probably want to keep using the same backend central user database for CentralAuth. An idea I've banded around to solve #2 would be to allow wikis to access other projects via the api. e.g. http://en.wikipedia.org/w/api.php?action=querytitles=Photoproject=commons would allow a developer to access the page Photos on wikimedia.commons.org rather than having to resort to a CORS request (ie. it would route the query to the database for commons rather than wikipedia) For api requests that require credentials it would send the credentials of the current project (in this case wikipedia). Is that something that is feasible? I did some experimentation a couple weeks ago with this, using a sort of HTTP proxy mode that passed through the CentralAuth session token cookies. This turned out to be a dead-end because we needed edit tokens for the foreign site, and we weren't getting a consistent *local* session on the other side of the proxy between requests. This could perhaps be solved in a few ways: * store the session edit token in the global CentralAuth session instead of the per-wiki session * use session state on the proxying wiki to store proxied-wiki's local session cookies * direct DB access to the other sites (possibly something could be rigged up that takes over the proxy before MediaWiki configures, and switches configurations to match the target site?) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Default policy for third-party cookies in Firefox
I just tested the behavior in Safari and Firefox Nightly and found that (as expected): 1) Single sign-on from a fresh browser session doesn't work. The user is not logged into other wiki* sites. 2) Single sign-on works for wiki* sites that the user has previously logged into. 3) Single sign-out works. I didn't mind the UX, but I could imagine some user annoyance. Here's an easy fix for Safari, Firefox 22+, and any browser with third-party cookies entirely disabled: 1) On login/logout, test whether third-party cookies are disabled. (For example, try to set/read/clear a cookie on wikitestthirdpartycookies.org.) 2) If a browser has third-party cookies disabled, do a series of first-party redirects to set or clear wiki* site cookies. (Google does something similar for google.com/youtube.com.) While on the topic of wiki* logins, do y'all have any plans to implement HTTPS for password submission? My lab surveyed implementations on top websites not long ago and found that Wikipedia is one of very few to still use plaintext for credentials. Best, Jonathan On Tuesday, March 19, 2013 at 7:52 AM, Platonides wrote: On 19/03/13 14:38, Seb35 wrote: Hello, According to [1] and [2], Firefox 22 (release June 25, 2013) will change the default third-party cookie policy: a third-party cookie will be authorized only if there is already a cookie set on the third-party website. This would break most of the automatic login on sister projects on Wikimedia websites, since the page just after the log in will no more set cookies of sister projects, and you will have to manually log in to each domain (of level wikipedia.org (http://wikipedia.org), not of level de.wikipedia.org (http://de.wikipedia.org)) -- I tested with Firefox 16. What could be done to mitigate this effect? (...) [1] http://webpolicy.org/2013/02/22/the-new-firefox-cookie-policy/ [2] https://developer.mozilla.org/en-US/docs/Site_Compatibility_for_Firefox_22 ~ Seb35 Copying Jonathan Mayer. Background information: When you log into eg. en.wikipedia.org (http://en.wikipedia.org), you get cookies logging you into not only *.wikipedia.org (http://wikipedia.org) but also *.wiktionary.org (http://wiktionary.org), *.wiktionary.org (http://wiktionary.org), *.wikibooks.org (http://wikibooks.org), commons.wikimedia.org (http://commons.wikimedia.org), etc. Obviously, that uses third-party cookies. Firefox 22 will block our single-login (unless you are already logged on the other project, which would be the case in which you would already have cookies there). If it can't be corrected, we will have to publicise this fact quite well, as I expect many complaints of Unified login doesn't work. Jonathan, do you have any suggestion? An idea to fix it would be to take advantage of the new certificate which includes all projects, by having firefox detect that the ‘third-party site’ belong to the same entity, since they share the https certificate (we would need to enable https to all logins, but that was planned, anyway). Regards ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Default policy for third-party cookies in Firefox
On Tue, Mar 19, 2013 at 11:58 AM, Jonathan Mayer jma...@stanford.edu wrote: I didn't mind the UX, but I could imagine some user annoyance. Here's an easy fix for Safari, Firefox 22+, and any browser with third-party cookies entirely disabled: 1) On login/logout, test whether third-party cookies are disabled. (For example, try to set/read/clear a cookie on wikitestthirdpartycookies.org.) 2) If a browser has third-party cookies disabled, do a series of first-party redirects to set or clear wiki* site cookies. (Google does something similar for google.com/youtube.com.) This would add potentially dozens of redirects on first visit by an anonymous user, which is probably not a good user experience. :( While on the topic of wiki* logins, do y'all have any plans to implement HTTPS for password submission? My lab surveyed implementations on top websites not long ago and found that Wikipedia is one of very few to still use plaintext for credentials. HTTPS is already available, but it's not yet forced. The ops guys are being conservative about making sure we can handle the traffic, but it's on the way. :) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Default policy for third-party cookies in Firefox
Brion Vibber brion at pobox.com writes: On Tue, Mar 19, 2013 at 11:58 AM, Jonathan Mayer jmayer at stanford.edu wrote: This would add potentially dozens of redirects on first visit by an anonymous user, which is probably not a good user experience. :( I'm suggesting using redirects just during the login flow, not on the first visit. If that proves to be a crummy UX, then you might try a redirect only through wikipedia.org on login or first visit. Jonathan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Default policy for third-party cookies in Firefox
On Tue, Mar 19, 2013 at 11:58 AM, Jonathan Mayer jmayer at stanford.edu wrote: This would add potentially dozens of redirects on first visit by an anonymous user, which is probably not a good user experience. :( I'm suggesting using redirects just during the login flow, not on the first visit. If that proves to be a crummy UX, then you might try a redirect only through wikipedia.org on login or first visit. Note 30* redirects do not count as visits to sites at least on iPhone (so probably Safari as well). This would mean using meta refreshes or javascript redirects - this would be a lousy experience!! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Default policy for third-party cookies in Firefox
Jon Robson jdlrobson at gmail.com writes: Note 30* redirects do not count as visits to sites at least on iPhone (so probably Safari as well). This would mean using meta refreshes or javascript redirects - this would be a lousy experience!! I *think* there may have been an old Safari bug where cookies wouldn't set on a 30* redirect. Have you checked that this behavior still occurs in Safari 6+? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Announcing the Wikimedia Iconathon 2013
The Wikimedia Foundation is partnering with the Noun Project[1] to do a public service Iconathon. The goal of this event is to generate 30-40 icons for the public domain, with the intent of primarily using them on Wikimedia Foundation projects. The event is open to the public in an effort to bring talented designers and civic-minded individuals into the process. The event will be held on April 6, 2013 at the Wikimedia Foundation headquarters in San Francisco. All icons will be released under a public domain license. We want your help and input! For more information, including a list of the icons we're working on, please visit one of three places: * http://meta.wikimedia.org/wiki/Iconathon_2013 * http://en.wikipedia.org/wiki/Wikipedia:Iconathon_2013 * http://www.mediawiki.org/wiki/Events/The_Noun_Project_Iconathon Please stop by one of these pages and share your thoughts and ideas. [1] http://www.thenounproject.com --- Brandon Harris, Senior Designer, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Gerrit Wars™: a strategy-guide
In a little over a month I will have been a MediaWiki developer for a full year. Some unpleasantness earlier today provided a good occasion to reflect on some of what I've learned since last spring. I have decided to do so publicly, in my characteristic obnoxious and attention-seeking manner. The upshot of MediaWiki being so thoroughly crufty is that there is never any shortage of places that need some love. There is no shortage of opportunities to have an impact. It is entirely possible to work at a rapid clip and get a lot done, as long as you are prepared for the possibility that any specific project could hit a blocker and be stalled for a while. When the path forward is blocked, let the matter drop for a while and turn your attention to something else. Come back to it with a fresh and open mind. That is how you win: not with overwhelming firepower, but with lots of patience and a light touch. Having a sense of humor helps, too. -- Ori Livneh ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Gerrit Wars™: a strategy-guide
Ori Livneh wrote: When the path forward is blocked, let the matter drop for a while and turn your attention to something else. Come back to it with a fresh and open mind. That is how you win: not with overwhelming firepower, but with lots of patience and a light touch. Having a sense of humor helps, too. Amen. :-) When I look at the people who manage to stay around for a long time, they're the ones who are capable of assuming good faith and occasionally walking away when things get heated. Wiki diplomacy happens at about the same rate as non-wiki diplomacy, I've found. Sometimes you have to be a little bit more non-profit and a little bit less tech. ;-) Congrats on your first MediaWiki developer birthday! To many more birthdays in the years to come. MZMcBride P.S. mailman: there's a non-ASCII character in the subject line. Attack! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deployment Highlights - 2013-03-15 (NOW WITH LIGTNING DEPLOYS!)
On a much more important issue, I choose the Mighty Thor[1] to show my allegiance. Curious if any of you are going with Raiden[2]? [1]: http://www.youtube.com/watch?v=7rnTpR4M1ZI [2]L https://en.wikipedia.org/wiki/Raiden_(Mortal_Kombat) terry chay 최태리 Director of Features Engineering Wikimedia Foundation “Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment.” p: +1 (415) 839-6885 x6832 m: +1 (408) 480-8902 e: tc...@wikimedia.org i: http://terrychay.com/ w: http://meta.wikimedia.org/wiki/User:Tychay aim: terrychay On Mar 18, 2013, at 12:19 PM, S Page sp...@wikimedia.org wrote: On Fri, Mar 15, 2013 at 9:38 PM, MZMcBride z...@mzmcbride.com wrote: Looks pretty good. My only tweak was changing the IRC channel to #wikimedia-tech [from #wikimedia-deployments]. It's an old and established channel and seems like a perfect fit for this. :-) How to deploy[1] tells us to Join #wikimedia-operations and #wikimedia-tech on Freenode and be available before and after all changes, so I added #wikimedia-operations. It's where bots show and log deploy messages, and it's where the people who'll have to clean up the wreckage hang out. Feel better, Greg. [1] https://wikitech.wikimedia.org/wiki/How_to_deploy_code ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Default policy for third-party cookies in Firefox
Jonathan Mayer jmayer at stanford.edu writes: I'm suggesting using redirects just during the login flow, not on the first visit. If that proves to be a crummy UX, then you might try a redirect only through wikipedia.org on login or first visit. Jonathan Another alternative you might consider: make single sign-on optional. A slight delay in user experience might then be both avoidable when unwanted and more palatable when selected. Jonathan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
