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
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
On Tue, Mar 19, 2013 at 7:52 AM, Platonides platonides@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
On Tue, Mar 19, 2013 at 8:57 AM, Brion Vibber brion@pobox.com wrote:
On Tue, Mar 19, 2013 at 7:52 AM, Platonides platonides@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.
On 19/03/13 17:41, Chris Steipp wrote:
On Tue, Mar 19, 2013 at 8:57 AM, Brion Vibber brion@pobox.com wrote:
On Tue, Mar 19, 2013 at 7:52 AM, Platonides platonides@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).
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
On Tue, Mar 19, 2013 at 11:58 AM, Jonathan Mayer jmayer@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:
- On login/logout, test whether third-party cookies are disabled. (For example, try to set/read/clear a cookie on wikitestthirdpartycookies.org.)
- 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
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
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!!
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+?
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
On Tue, Mar 19, 2013 at 6:38 AM, Seb35 seb35wikipedia@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
<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
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 greg@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 Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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=query&titles=Photo&project=... 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 lwelling@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 greg@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 Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 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
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
- 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).
- 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=query&titles=Photo&project=... 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.
On Tue, Mar 19, 2013 at 11:21 AM, Jon Robson jdlrobson@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
- Takes away the inconvenience of having to login across multiple sites
- 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=query&titles=Photo&project=... 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@lists.wikimedia.org