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 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
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
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
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’
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
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
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
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
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
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
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
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
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
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
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
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
17 matches
Mail list logo
