Default policy for third-party cookies in Firefox

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Default policy for third-party cookies in Firefox

Seb35
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Default policy for third-party cookies in Firefox

Platonides
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Default policy for third-party cookies in Firefox

Brion Vibber
In reply to this post by Seb35
On Tue, Mar 19, 2013 at 6:38 AM, Seb35 <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Default policy for third-party cookies in Firefox

Brion Vibber
In reply to this post by Platonides
On Tue, Mar 19, 2013 at 7:52 AM, Platonides <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Default policy for third-party cookies in Firefox

Chris Steipp
On Tue, Mar 19, 2013 at 8:57 AM, Brion Vibber <[hidden email]> wrote:
> On Tue, Mar 19, 2013 at 7:52 AM, Platonides <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Default policy for third-party cookies in Firefox

Greg Grossmeier-2
In reply to this post by Seb35
<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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Default policy for third-party cookies in Firefox

Luke Welling WMF
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 <[hidden email]>wrote:

> <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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Default policy for third-party cookies in Firefox

Jon Robson
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=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
<[hidden email]> 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 <[hidden email]>wrote:
>
>> <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
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
Jon Robson
http://jonrobson.me.uk
@rakugojon

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Default policy for third-party cookies in Firefox

Platonides
In reply to this post by Chris Steipp
On 19/03/13 17:41, Chris Steipp wrote:

> On Tue, Mar 19, 2013 at 8:57 AM, Brion Vibber <[hidden email]> wrote:
>> On Tue, Mar 19, 2013 at 7:52 AM, Platonides <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Default policy for third-party cookies in Firefox

Platonides
In reply to this post by Jon Robson
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=query&titles=Photo&project=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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Default policy for third-party cookies in Firefox

Brion Vibber
In reply to this post by Jon Robson
On Tue, Mar 19, 2013 at 11:21 AM, Jon Robson <[hidden email]> 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=query&titles=Photo&project=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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Default policy for third-party cookies in Firefox

Jonathan Mayer
In reply to this post by Platonides
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Default policy for third-party cookies in Firefox

Brion Vibber
On Tue, Mar 19, 2013 at 11:58 AM, Jonathan Mayer <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Default policy for third-party cookies in Firefox

Jonathan Mayer

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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Default policy for third-party cookies in Firefox

Jon Robson
>> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Default policy for third-party cookies in Firefox

Jonathan Mayer
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Default policy for third-party cookies in Firefox

Jonathan Mayer
In reply to this post by Jonathan Mayer
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l