subject: [WikiEN-l] Preloading template in new articles

body:
Would anyone object to preloading a references section in every new article?
For example, when a user searches for a topic and clicks the big "Create
this article" link, the user will be shown a page like this:
http://en.wikipedia.org/w/index.php?title=Testing...testing...testing
<http://en.wikipedia.org/w/index.php?title=Testing...testing...testing&actio
n=edit&preload=Template:Article+starter>
&action=edit&preload=Template:Article+starter.

The text of this template is at [[Template:Article starter]].

--Mets501


list: wikitech-l

source: pipermail-mbox

from_name: William Allen Simpson

subject: [Wikitech-l] identity management (was: MD5 Password Encryption)

body:
Start a new thread,

Neil Harris wrote:
 > Actually, digital identity management is more important than ever, and
 > this time it looks like it's going to be done right. SUL is an important
 > part of helping make that happen for Wikipedia and all of its attendant
 > projects.
 >
I agree, wearing two hats: the operations and security communities....

Good engineering practices often require stepwise refinement.

Single User Login may have been originally envisioned for convenience,
but the ease of use and project-wide consistency can also encourage
better security practices.

I agree that changes to the login procedure can wait until SUL is
deployed, as long as enhancements are well planned beforehand.

Speaking to elements of the recent thread, I'd prefer SSL instead of
home-grown challenge-response algorithms.  As I'm the author of several
well-known challenge-response protocols, and an experienced network
operator, I can speak to the difficulty of proper implementation and
operation!  Use the existing tools, where the problems are understood
and mitigated on a world-wide basis.

I also agree with Ivan (and others) that there is no technical problem
with MD5 as a salted hashing algorithm in this instance.  But I do prefer
some flexibility toward future use of other algorithms for diversity.

I suggest that the software default to MD5 (as now), but the presence of
the "sha1:" prefix indicate the alternative.  It seems reasonable to
design a migration path for the future, and that migration code should
be well tested before migration occurs.

I don't agree that sha256 be used until that is a standard part of the
software package.  Experience has shown the folly of relying on
insufficiently deployed and tested security implementations.


from_name: Gregory Maxwell

subject:
[Wikitech-l] Session cookie theft. Was: identity management (was:
	MD5 Password Encryption)

body:
On 1/23/07, William Allen Simpson <william.allen.simpson at gmail.com> wrote:
[snip]
> Speaking to elements of the recent thread, I'd prefer SSL instead of
> home-grown challenge-response algorithms.
[snip]

On this subject...  Wrapping the login site via SSL sounds like a
dandy idea, and it sidesteps the whole mess of cert issues if with SUL
we were to use a single login portal domain.

However, then we've just pushed the problem back to session cookie
theft.  Sure, it would still be an improvement since a passive
attacker (at say Wikimania...) couldn't sit back and gather passwords,
but better still might be possible.

What the current industry best-practices with respect to binding
session data to a client's IP? Do web browsers switch IPs too often
for this to be acceptable (AOL?)?

At some point it might make sense to talk about all logged in user
sessions being SSLed... the overwhelming majority of the computational
load of SSL is the RSA stuff for signatures which would need to happen
once per login if we went the SUL login page behind SSL route.. After
that it's just symmetric crypto which isn't astoundingly expensive.

Were we to move logged in users into SSL all sorts of threats just go
away. Of course there is the little matter of plain squid not
supporting SSL offloading like some of the commercial reverse proxy /
acceleration solutions which would have to be resolved...


list: wikien-l

from_name: Brion Vibber

subject:
[WikiEN-l] Nofollow back on URL links on en.wikipedia.org
 articles for now

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeff Raymond wrote:
> Brion Vibber wrote:
>
>> Indefinite. I'd prefer to see actual improvements (whitelisting, fading,
>> flagging and approval system, etc) rather than just turn it off one day,
>> though.
>
> Why aren't we treating nofollow like the spam blacklist?

To be useful it needs to function on a whitelist approach, and the
further details of whitelisting (explicit, implicit, exceptions,
approvals, flagging, moderation, visibility, logging) have yet to be
worked out.

If you intend to actually work on this issue, please step up in the tech
channels.

- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtl7cwRnhpk1wk44RAqflAKC0/X8weAEh3RBdCW0m6JMNrd93JACgloRA
LqeiXKf9PN2HvzObEEUP/2Y=
=20CK
-----END PGP SIGNATURE-----


body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brion Vibber wrote:
> Jeff Raymond wrote:
>> Brion Vibber wrote:
>
>>> Indefinite. I'd prefer to see actual improvements (whitelisting, fading,
>>> flagging and approval system, etc) rather than just turn it off one day,
>>> though.
>> Why aren't we treating nofollow like the spam blacklist?
>
> To be useful it needs to function on a whitelist approach, and the

Oh, and also the current spam blacklist system is dreadful. It's hard to
maintain, very fragile (easily breaks due to not-quite-right regular
expressions) and tends to combine "really obvious spam that no one
wants" with "annoying stuff that we're tired of seeing on Wikipedia",
making sharing of the blacklist with other wikis difficult.

Volunteers for reworking the blacklisting system are also welcome over
in the tech channels. :)

- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtmHTwRnhpk1wk44RAp5YAJ99Q3VMmOYyBwUZKpcmnxXbYUHBugCggaCI
NrK29XYL/F4ywQMzXUnAd5g=
=QuSd
-----END PGP SIGNATURE-----


from_name: Alphax (Wikipedia email)

subject: [Wikitech-l] slowness today

body:
Nick Jenkins wrote:
<snip>
> "Don't torture cute kittens and then bury them alive"
>

That's a perfectly normal behaviour! :-P

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 542 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20070123/d01ce90d/attachment.pgp>


from_name: Earle Martin

subject:
[WikiEN-l] Nofollow back on URL links on en.wikipedia.org
	articles for now

body:
On 22/01/07, Matthew Brown <morven at gmail.com> wrote:
> On 1/21/07, geni <geniice at gmail.com> wrote:
> > Hmm an I evil for enjoying this:
>
> Lots of fun.  Anyone caught our friend MyWikiBiz posting in the first one?

It gets better:
http://www.seomoz.org/blogdetail.php?ID=1648&jump_to_comment=14979

Also, I noticed this on another site: a spammer admits spamming
articles and gives a clue as to what they are. Anyone care to try
tracking this down and nuking it?

http://www.networkworld.com/community/?q=node/10642#comment-60436

--
Earle Martin
            http://downlode.org/
http://purl.org/net/earlemartin/


from_name: Neil Harris

subject: [WikiEN-l] In the news...

body:
Oskar Sigvardsson wrote:
> On 1/22/07, Neil Harris <usenet at tonal.clara.co.uk> wrote:
>
>> Given some of the other stories linked on this page, I think this is
>> more likely to be satire than news.
>>
>> -- Neil
>>
>
> I thought that was pretty obvious from the story itself :)
>
> --Oskar
>
>
>
Understatement: it's an English thing.

-- Neil

>
>
>


from_name: Platonides

subject: [Wikitech-l] MD5 Password Encryption

body:
Brion Vibber wrote:
> There was some muttering at the time that just using HTTPS is safer and
> it's not worth the bother. Agreement? Disagreement?

Probably HTTPS is safer, though JS challenges are easier to implement.
Still, the https server needs to send the user back to the 'normal' page
with some token, as it can't set the logged cookie.
The http protocol was enhaced with some response codes 'changing to
secure mode', so it might be feasible produce the login over https with
the same server but i don't know the state of current implementations
(both client and server), could be tricky.

As SUL will change the authentication schemas, close accounts, etc. it
IS the appropiate moment to change hashes on the 'joined' accounts, set
a login https server, etc.


body:
On 23/01/07, Earle Martin <wikipedia at downlode.org> wrote:
> It gets better:

http://blog.outer-court.com/archive/2007-01-22-n21.html

"ZOMG WIKIPEDIA IS STEALING OUR LINKS!!!1!1one"

When did people start believing there was some sort of moral
obligation for a site that they link to to give them some sort of
kickback via a third party's link-rating system (i.e., PageRank)?

Note to J. Random Nobody (who may well be reading this list via links
to the archive from similarly outraged windbags^Hbloggers), we didn't
*ask* you to link to us, ergo we owe you nothing.

In amusement,

Earle

--
Earle Martin
            http://downlode.org/
http://purl.org/net/earlemartin/


from_name: Sören Auer

subject:
[Wikitech-l] [ANN] dbpedia.org - Querying Wikipedia like a Semantic
	Database

body:
Hi all,

Do you know all mayors from towns elevated higher than 1000m, all
sitcoms set in New York, or all philosophers that were influenced by
Friedrich Nietzsche?

Wikipedia contains information required for answering such questions,
but has the problem that its constricted search capabilities only allow
very limited access to its valuable knowledge-base. The Semantic Web
still lacks a critical mass of RDF data online and up-to-date terms and
ontologies are missing for many application domains.

The dbpedia.org project approaches both problems by extracting
structured information from Wikipedia and by making this information
available on the Web. dbpedia.org allows you to ask sophisticated
queries against Wikipedia (like the ones mentioned above) and to link
other datasets on the Web to dbpedia data.

dbpedia.org features at the moment:

* two large extracted datasets for different purposes
* a SPARQL endpoint and a data browser
* a visual query builder

More information about the project can be found at:

           http://dbpedia.org

Since it is a first effort to make these available to a larger audience,
we appreciate any feedback, comments and ideas for improvements.

On behalf of the dbpedia.org collaborators

S?ren Auer, Chris Bizer, Richard Cyganiak, Georgi Kobilarov, and Jens
Lehmann


from_name: Kutler, Christopher

subject:
[Wikitech-l] Wanted Pages Wiki Page: How to add explanatory text to
	it

body:
Hi,

Apologies if this question has been answered before or that it is on the main Wikimedia FAQ and I've missed it, but could someone let me know how I can edit the Special Wiki Page called "Wanted Pages". I want to add a bit of explanatory text which explains the purpose of the Wanted Pages special page.

Thanks very much in advance

Chris Kutler

Please don't print this e-mail unless you really need to.

---------------------------------------------------------------------------------

National Archives Disclaimer

This email message (and attachments) may contain information that is confidential  to The National Archives.  If you are not the intended recipient you cannot use, distribute or copy the message or attachments.  In such a case, please notify the sender by return email immediately and erase all copies of the message and attachments.  Opinions, conclusions and other information in this message and attachments that do not relate to the official business of The National Archives are neither given nor endorsed by it.

------------------------------------------------------------------------------------


from_name: geni

body:
On 1/23/07, Earle Martin <wikipedia at downlode.org> wrote:
> Also, I noticed this on another site: a spammer admits spamming
> articles and gives a clue as to what they are. Anyone care to try
> tracking this down and nuking it?
>
> http://www.networkworld.com/community/?q=node/10642#comment-60436
>

Done.  Rember http://en.wikipedia.org/wiki/Special:Linksearch makes
this fairly easy.

--
geni


from_name: Andrew Gray

body:
On 20/01/07, Brion Vibber <brion at pobox.com> wrote:
>
> Having been requested by Jimmy to do so, and having seen a fun rumor of
> a "search engine optimization world championship" contest targeting
> WP[1], I've gone ahead and switched rel="nofollow" back onto URLs in
> en.wikipedia.org's article namespace.
>
> (Better heuristic and manual flagging tools for URLs would of course be
> super; anyone interested in working on integrating such support into
> MediaWiki should swing on by the tech channels and give a shout.)

Quick question (since I haven't seen it addressed below) - is this
temporary for the duration of the current optimisation contest, or
indefinite?

--
- Andrew Gray
  andrew.gray at dunelm.org.uk


body:
On 23/01/07, geni <geniice at gmail.com> wrote:
> Done.  Rember http://en.wikipedia.org/wiki/Special:Linksearch makes
> this fairly easy.

Thanks. I need to peruse [[Special:Specialpages]] a bit more, it seems.

--
Earle Martin
            http://downlode.org/
http://purl.org/net/earlemartin/


from_name: Jay R. Ashworth

subject: [Wikitech-l] License status of MW screenshots.

body:
On Tue, Jan 23, 2007 at 04:03:55PM +1100, Stephen Bain wrote:
> When you start mixing stuff you complicate things. If I were to take a
> screenshot of a page on Wikipedia, for example, the text of the page
> would be GFDL (unless there are some quotes or something in the text,
> which would be fair use), the MediaWiki elements would be GPL, the
> browser window could be anything (if you're in Firefox, for example,
> then the picture of the browser interface is under the Mozilla Public
> Licence). The skins that come with MediaWiki are GPL just like the
> rest of MediaWiki.
>
> So unfortunately you can't get PD screenshots of MediaWiki. The best
> you can do is GPL screenshots, but only if you show only GPL content
> in it and either cut out the browser interface or use a GPL browser.

Someone vastly misunderstands the nature of copyright law, I think.

(Though, admittedly, IANAL, either.  I just play on on the net.)

If I create a screenshot of a browser page on my computer displaying
wikipedia, there is *one* copyright involved: *mine*.  The image is not
a derivative work of the browser, the OS, or the website.  Therefore,
none of those people's copyrights apply, and therefore by induction, no
licenses are necessary.  I created an image, and I own its copyright.

The situation is pretty much identical to my *taking a photograph* of
the screen displaying said browser.

If I want to use that image for *commercial advertising*, there msy be
some issues with respect to model releases for pictures of identifiable
people, or trademarks (though this is even less clear), but -- and
particularly if the destination of the image is pedagogy -- underlying
copyrights don't, that I am able to determine, have anything whatsoever
to do with it.  Trademark law doesn't say you can't reproduce the
trademark, it says you can't make money off it, or confuse other people
about who it refers to.

I'm sufficiently confident of this that I'd say "don't worry about it"
in a public place, unless I'm contradicted by an attorney whose
practice is in copyright law.

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274


body:
On Tue, Jan 23, 2007 at 01:29:04PM -0500, Jay R. Ashworth wrote:
> > So unfortunately you can't get PD screenshots of MediaWiki. The best
> > you can do is GPL screenshots, but only if you show only GPL content
> > in it and either cut out the browser interface or use a GPL browser.
>
> Someone vastly misunderstands the nature of copyright law, I think.
>
> (Though, admittedly, IANAL, either.  I just play on on the net.)
>
> If I create a screenshot of a browser page on my computer displaying
> wikipedia, there is *one* copyright involved: *mine*.  The image is not
> a derivative work of the browser, the OS, or the website.  Therefore,
> none of those people's copyrights apply, and therefore by induction, no
> licenses are necessary.  I created an image, and I own its copyright.

And, to be clear about the point at hand: I the creator of that image
can then license it's copyright under anything I feel like.

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274


from_name: Jeff Raymond

body:
Brion Vibber wrote:

> Indefinite. I'd prefer to see actual improvements (whitelisting, fading,
> flagging and approval system, etc) rather than just turn it off one day,
> though.

Why aren't we treating nofollow like the spam blacklist?

-Jeff


from_name: · Firefoxman

body:
Looks like a good idea, might want to ask a dev to do it on WikiTech-I or an
admin.

On 1/23/07, Mets501 <mets501wiki at gmail.com> wrote:
>
> Would anyone object to preloading a references section in every new
> article?
> For example, when a user searches for a topic and clicks the big "Create
> this article" link, the user will be shown a page like this:
> http://en.wikipedia.org/w/index.php?title=Testing...testing...testing
> <
> http://en.wikipedia.org/w/index.php?title=Testing...testing...testing&actio
> n=edit&preload=Template:Article+starter>
> &action=edit&preload=Template:Article+starter.
>
>
>
> The text of this template is at [[Template:Article starter]].
>
>
>
> --Mets501
>
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>

--
en:User:Firefoxman

This user is.


subject: [Wikitech-l] MD5 Password Encryption

body:
Rob Church wrote:
> On 23/01/07, Brion Vibber <brion at pobox.com> wrote:
>
>> There was some muttering at the time that just using HTTPS is safer and
>> it's not worth the bother. Agreement? Disagreement?
>>
>
> What infrastructure changes would it require for us to start migrating
> to HTTPS, at least during the login process?
>
>
> Rob Church
>
>
>
You will need one IP address per HTTPS server name, since you cannot
virtual-host HTTPS: however, there's nothing to stop a single machine
from having as many IP addresses as desired, and thus as many HTTPS
servers as desired. This also means that load-balance cannot "look into"
the encrypted HTTPS connection to see where to send the traffic to: it
will have to go by the destination IP address. However, HTTPS can still
be load-balanced, you just need a different external IP address for each
visible service, and one internal IP address for each HTTPS service on
each server within the load-balancing cloud.

A lot of this could, of course, be made much simpler if you only had a
single HTTPS server URL for login in each project, such as
https://login.wikipedia.org/ -- this would fit rather well with the
unified login idea.

The servers would need to have their certificates signed by a well-known
CA, or browsers will complain (as, for example, occurs with
https://wikitech.leuksman.com). Ideally, images, style sheets and other
media within the login pages should also be served over HTTPS, ideally
from the same server, or some browsers will complain.

HTTPs has a small but significant per-session overhead to perform the
initial authentication and key exchange (but not per-hit, since the
authentication information can be cached between multiple connections
within the same session.) There is also a small extra overhead for all
data passed over the encrypted connection, which has to be
compressed/decompressed and encrypted/decrypted on the fly as necessary;
however, this last is going to be pretty unimportant if all you use it
for is to serve login pages.

-- Neil


from_name: Ivan Krstić

subject: [Wikitech-l] MD5 Password Encryption

body:
Gerard Meijssen wrote:
> This discussion /is /about changing the security. Changing it because
> the need is felt for the current system to be improved.

No, the discussion is about changing the present system because the
original poster didn't understand what he was talking about.

--
Ivan Krsti? <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D


subject:
[Wikitech-l] Session cookie theft. Was: identity management
 (was: MD5 Password Encryption)

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gregory Maxwell wrote:
> As I said before.. SSL makes it all the issues go away.  As a long
> term project we should probably figure out how to make SSL work for
> us, and not waste time with hacks. Any other path will result in us
> reinventing SSL poorly.

You mean like this?

http://assl.sullof.com/assl/

:D

- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtoguwRnhpk1wk44RAurWAJ9Qbym+fvfLRsYWqyGOrHyX17EIuQCeJ94l
EZQn4kCwpW+8BUqH3KND0FQ=
=eQhI
-----END PGP SIGNATURE-----


from_name: Simetrical

body:
On 1/23/07, Jay R. Ashworth <jra at baylink.com> wrote:
> Someone vastly misunderstands the nature of copyright law, I think.
>
> (Though, admittedly, IANAL, either.  I just play on on the net.)
>
> If I create a screenshot of a browser page on my computer displaying
> wikipedia, there is *one* copyright involved: *mine*.  The image is not
> a derivative work of the browser, the OS, or the website.  Therefore,
> none of those people's copyrights apply, and therefore by induction, no
> licenses are necessary.  I created an image, and I own its copyright.
>
> The situation is pretty much identical to my *taking a photograph* of
> the screen displaying said browser.

Well, I can say that that's certainly not how Wikipedia interprets
copyright in such works.  Screenshots of copyrighted programs are
generally considered fair use, because the layout/coloring/general
appearance of the browser is deemed creative.  Whether this is the law
I don't know, but certainly a photo of a copyrighted work is
derivative of it (if even that).


subject:
[Wikitech-l] [MediaWiki-CVS] SVN: [19612]
	trunk/phase3/maintenance/cleanupSkin.php

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hashar wrote:
> This script pass through all users and change their skins from 'oldSkinName'
> to 'newSkinName'. There is NO validation about the new skin existence!
> Made on an original idea by Fooey (freenode)

I would strongly recommend generalizing this to update any given option,
rather than skins and nothing but skins.

- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtokEwRnhpk1wk44RAnp7AJ48kw8YakW0Ac+10W3uuCw6dfY3iwCgkhMT
HNYpyZpIQdXI61m6ZFk92vw=
=pqyN
-----END PGP SIGNATURE-----


subject: [Wikitech-l] MD5 Password Encryption

body:
Anthony wrote:
> On 1/23/07, Gerard Meijssen <gerard.meijssen at gmail.com> wrote:
>
>> Hoi,
>> Actually I will not lay off on Single User Login. The reason is quite
>> simple. Some things that are important to me will not happen until AFTER
>> Single User Login. It is all well and good that everyone comes up with
>> the most nifty things and all kinds of functionality that HAS to be
>> implemented because you are volunteers too. In the mean time some rather
>> basic stuff does not get done. If this drives you mad, fine. Fix the
>> issue - help Brion implement SUL !
>>
>> The promised date for SUL was end of January 2005. It is now a year late.
>>
>> Thanks,
>>     GerardM
>>
>>
> I couldn't agree with this more.  Single User Login is a pretty
> useless feature.  It was a neat dream back in 2001 or whenever
> passport.com came out, but it really is rather useless.  But...there
> are so many other useful features that are being ignored because they
> aren't scheduled to be implemented until *after* SUL.
>
> I really wish the board would fix the issue and tell Brion to just
> drop the whole idea of Single User Login.  You know, Firefox (like
> probably all the other browsers) has this nifty feature that stores
> your username and password for each site, so you only have to type in
> your password once.
>
> By the way, January 2005 was *two* years ago, not one.
>
> Anthony
>
>
>
Actually, digital identity management is more important than ever, and
this time it looks like it's going to be done right. SUL is an important
part of helping make that happen for Wikipedia and all of its attendant
projects.

-- Neil


body:
Also, who would be able to modify it? I don't think that we should make it
publicly editable, but I don't think we should have to bug admins every time
I want to add a link to a site not already in the list. Maybe we should have
somthing like the auth we have for the #wp-v channel, or semiprotect the
page.

On 1/23/07, Brion Vibber <brion at pobox.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jeff Raymond wrote:
> > Brion Vibber wrote:
> >
> >> Indefinite. I'd prefer to see actual improvements (whitelisting,
> fading,
> >> flagging and approval system, etc) rather than just turn it off one
> day,
> >> though.
> >
> > Why aren't we treating nofollow like the spam blacklist?
>
> To be useful it needs to function on a whitelist approach, and the
> further details of whitelisting (explicit, implicit, exceptions,
> approvals, flagging, moderation, visibility, logging) have yet to be
> worked out.
>
> If you intend to actually work on this issue, please step up in the tech
> channels.
>
> - -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFtl7cwRnhpk1wk44RAqflAKC0/X8weAEh3RBdCW0m6JMNrd93JACgloRA
> LqeiXKf9PN2HvzObEEUP/2Y=
> =20CK
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>

--
en:User:Firefoxman

This user is.


from_name: Sage Ross

body:
On 1/23/07, Earle Martin <wikipedia at downlode.org> wrote:
> On 22/01/07, Matthew Brown <morven at gmail.com> wrote:
> > On 1/21/07, geni <geniice at gmail.com> wrote:
> > > Hmm an I evil for enjoying this:
> >
> > Lots of fun.  Anyone caught our friend MyWikiBiz posting in the first one?
>
> It gets better:
> http://www.seomoz.org/blogdetail.php?ID=1648&jump_to_comment=14979
>
> Also, I noticed this on another site: a spammer admits spamming
> articles and gives a clue as to what they are. Anyone care to try
> tracking this down and nuking it?
>
> http://www.networkworld.com/community/?q=node/10642#comment-60436
>
> --
> Earle Martin
>             http://downlode.org/
> http://purl.org/net/earlemartin/
>

I like this one:
http://www.smomashup.com/how-wikipedia-killed-the-internets/2007/01/23/

The complaint is that, once the (barely notable) entry on [[Social
Media Optimization]] stops giving PageRank value to the blog-post
origin of the term, then the Wikipedia article will surpass the blog
entry as the first Google result for "social media optimization".
Breaks my heart.

-Sage


from_name: Gerard Meijssen

subject: [Wikitech-l] MD5 Password Encryption

body:
Anthony schreef:
> On 1/23/07, Gerard Meijssen <gerard.meijssen at gmail.com> wrote:
>
>> Hoi,
>> Actually I will not lay off on Single User Login. The reason is quite
>> simple. Some things that are important to me will not happen until AFTER
>> Single User Login. It is all well and good that everyone comes up with
>> the most nifty things and all kinds of functionality that HAS to be
>> implemented because you are volunteers too. In the mean time some rather
>> basic stuff does not get done. If this drives you mad, fine. Fix the
>> issue - help Brion implement SUL !
>>
>> The promised date for SUL was end of January 2005. It is now a year late.
>>
>> Thanks,
>>     GerardM
>>
>>
> I couldn't agree with this more.  Single User Login is a pretty
> useless feature.  It was a neat dream back in 2001 or whenever
> passport.com came out, but it really is rather useless.  But...there
> are so many other useful features that are being ignored because they
> aren't scheduled to be implemented until *after* SUL.
>
> I really wish the board would fix the issue and tell Brion to just
> drop the whole idea of Single User Login.  You know, Firefox (like
> probably all the other browsers) has this nifty feature that stores
> your username and password for each site, so you only have to type in
> your password once.
>
> By the way, January 2005 was *two* years ago, not one.
>
> Anthony
>
Hoi,
I have my dates wrong then; January 2006 it is.

I do disagree that SUL is a useless feature .. I operate with over 100
user profiles within the Wikimedia Foundation and I hate it. It leads to
practices that from a security pov are horrible. I am quite happy that
things wait until after SUL but I am not happy that it takes so long. I
also thing it bad that there is this feature creep that prevents
relevant things from getting done.

I do agree that it would be good when the board helps with some
prioritisations. I am afraid that many things will get on the backburner
as a result and THIS is something that people will not like. Yet again a
situation where people do not realise what they ask for ?
Thanks,
    GerardM


from_name: Tim Starling

subject: [Wikitech-l] HTTPS virtual hosting (was Re: MD5 Password Encryption)

body:
Neil Harris wrote:
> You will need one IP address per HTTPS server name, since you cannot
> virtual-host HTTPS: however, there's nothing to stop a single machine
> from having as many IP addresses as desired, and thus as many HTTPS
> servers as desired. This also means that load-balance cannot "look into"
> the encrypted HTTPS connection to see where to send the traffic to: it
> will have to go by the destination IP address. However, HTTPS can still
> be load-balanced, you just need a different external IP address for each
> visible service, and one internal IP address for each HTTPS service on
> each server within the load-balancing cloud.

HTTPS does support virtual hosting. You can have certificates with
wildcards, e.g. *.wikipedia.org, and you can even have certificates that
list multiple second-level domains. In theory we could even support
https://en.wikipedia.org/, by having LVS pass the traffic off to an SSL
proxy cluster, which forwards to the Florida squids via a secure tunnel.

-- Tim Starling


body:
How would I go about doing that?

On 1/23/07, Brion Vibber <brion at pobox.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Brion Vibber wrote:
> > Jeff Raymond wrote:
> >> Brion Vibber wrote:
> >
> >>> Indefinite. I'd prefer to see actual improvements (whitelisting,
> fading,
> >>> flagging and approval system, etc) rather than just turn it off one
> day,
> >>> though.
> >> Why aren't we treating nofollow like the spam blacklist?
> >
> > To be useful it needs to function on a whitelist approach, and the
>
> Oh, and also the current spam blacklist system is dreadful. It's hard to
> maintain, very fragile (easily breaks due to not-quite-right regular
> expressions) and tends to combine "really obvious spam that no one
> wants" with "annoying stuff that we're tired of seeing on Wikipedia",
> making sharing of the blacklist with other wikis difficult.
>
> Volunteers for reworking the blacklisting system are also welcome over
> in the tech channels. :)
>
> - -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFtmHTwRnhpk1wk44RAp5YAJ99Q3VMmOYyBwUZKpcmnxXbYUHBugCggaCI
> NrK29XYL/F4ywQMzXUnAd5g=
> =QuSd
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>

--
en:User:Firefoxman

This user is.


from_name: Gwern Branwen

body:
"Mets501" <mets501wiki at gmail.com> writes:

> Would anyone object to preloading a references section in every new article?
> For example, when a user searches for a topic and clicks the big "Create
> this article" link, the user will be shown a page like this:
> http://en.wikipedia.org/w/index.php?title=Testing...testing...testing<http://en.wikipedia.org/w/index.php?title=Testing...testing...testing&actio
> n=edit&preload=Template:Article+starter>
> &action=edit&preload=Template:Article+starter.
>
>
>
> The text of this template is at [[Template:Article starter]].
>
>
>
> --Mets501

How would this work if you just wanted to make a redirect? Further,
would this get in the way of anything useful automated tools, like
bots or popups or...?

--
Gwern
Inquiring minds want to know.


from_name: David Gerard

subject: [Wikitech-l] The Ideal Wiki Software

body:
On 23/01/07, Rob Church <robchur at gmail.com> wrote:

> > To discuss this (what I find an interesting) question, I've set up a page at
> > http://meta.wikimedia.org/wiki/MediaWiki_Ideal

> Why, oh why are people still creating *software* pages on Meta? We've
> got the http://www.mediawiki.org domain; we're trying to move anything
> MediaWiki related *away* from Meta, to leave more room for all that
> Foundation bickering, and so we know where we stand.
> I also think this page is a little redundant. We don't want wiki pages
> cataloguing feature requests; we have a bug/enhancement tracker for
> that purpose.

It's more of a blue-sky discussion. A lot of this stuff won't be
concrete enough to be a feature request for a while.

- c.


body:
Most good bots use a direct conection to the server, so that is not a
problem. Popups should not have any effect, since they do not do anything
with new pages as far as I know.

On 1/23/07, Gwern Branwen <gwern0 at gmail.com> wrote:
>
> "Mets501" <mets501wiki at gmail.com> writes:
>
> > Would anyone object to preloading a references section in every new
> article?
> > For example, when a user searches for a topic and clicks the big "Create
> > this article" link, the user will be shown a page like this:
> > http://en.wikipedia.org/w/index.php?title=Testing...testing...testing<
> http://en.wikipedia.org/w/index.php?title=Testing...testing...testing&actio
> > n=edit&preload=Template:Article+starter>
> > &action=edit&preload=Template:Article+starter.
> >
> >
> >
> > The text of this template is at [[Template:Article starter]].
> >
> >
> >
> > --Mets501
>
> How would this work if you just wanted to make a redirect? Further,
> would this get in the way of anything useful automated tools, like
> bots or popups or...?
>
> --
> Gwern
> Inquiring minds want to know.
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>

--
en:User:Firefoxman

This user is.


subject:
[Wikitech-l] HTTPS virtual hosting (was Re: MD5 Password
	Encryption)

body:
Lane, Ryan wrote:
>> HTTPS does support virtual hosting. You can have certificates
>> with wildcards, e.g. *.wikipedia.org, and you can even have
>> certificates that list multiple second-level domains. In
>> theory we could even support https://en.wikipedia.org/, by
>> having LVS pass the traffic off to an SSL proxy cluster,
>> which forwards to the Florida squids via a secure tunnel.
>>
>
> From what I've read HTTPS does not support name-based virtual hosting,
> only IP based virtual hosting, as the SSL connection happens before the
> request is made. So, if you have two virtual hosts such as:
>
> <Virtualhost en.wikipedia.org>
> ...
> </Virtualhost>
>
> <Virtualhost de.wikipedia.org>
> ...
> </Virtualhost>
>
> The first virtual host will always be used as the server has absolutely
> no clue, when the connection is made, which virtual host it needs to
> use.
>
> I believe this is the point Neil was trying to make.

The same is true of unencrypted HTTP. The server has no idea, when the
connection is made, what virtual host will be required. That only comes
when the client sends the Host header.

The issue is that with HTTPS, the server has to send a certificate before
the client sends the Host header. The certificate has to match the hostname.

See http://wiki.cacert.org/wiki/VhostTaskForce for a discussion of the
various ways of achieving this.

-- Tim Starling


subject: [WikiEN-l] something to look out for

body:
On 1/23/07, Jimmy Wales <jwales at wikia.com> wrote:
> http://www.opinioneditorials.com/guestcontributors/rcurry_20070123.html
>
> "The research behind the new discoveries by the cryptologist Dr. Rex
> Curry (author of "Swastika Secrets") is referenced on Wikipedia and in
> the vexillological group Flags Of The World (FOTW)."
>
> http://rexcurry.net/wikipedia-the-free-encyclopedia.html
>

What is new from:

http://lists.wikimedia.org/pipermail/wikien-l/2006-November/056515.html
--
geni


from_name: George Herbert

body:
On 1/23/07, David Gerard <dgerard at gmail.com> wrote:
> On 23/01/07, Oskar Sigvardsson <oskarsigvardsson at gmail.com> wrote:
>
> > Still, my main argument still stands. It's condescending and rude, and
> > that's not how we should treat our new users, let alone our
> > experienced ones who are going to have to see that damn notice every
> > damn time they start an article. I just think that that is not the way
> > we should be treating new users.
> > I know I would never have joined if I had been greeted by a bunch of
> > reference-fanatic dudes who didn't have any patience with people who
> > didn't quite get how wikipedia works.
>
>
> Unfortunately, not doing so is likely to see their article zapped,
> which is a much less n00b-friendly experience.
>
> Yet another person just popped onto IRC asking how to create an
> article that wouldn't get killed on sight. I said "write a few
> paragraphs, add good references." "How should I format the
> references?" "Not important. Just have them. Trust me - after dredging
> through lame garage band articles on Special:Newpages, you'll cry at
> the wikibeauty of an article that actually has its refs."
>
> Surely it's polite to let them know rather than give great big warning
> notices but no clues.

I thought about this, looked at it, thought some more...

Not really condescending, I think, and a good reminder.  I'd wait
until tomorrow to make it live, but I say go for it if no good
objections come up by tomorrow...

--
-george william herbert
george.herbert at gmail.com


list: foundation-l

from_name: Husky

subject: [Foundation-l] The Ideal Wiki Software

body:
Many of these have already been mentioned, but just to sum it up:

* Better search functionality (esp. with images, some kind of gallery view),
maybe on the basis of tagging or category keywords.
* A more user-friendly editing interface. This might need some serious
interaction models to avoid a WYSIWYG interface that doesn't quite work.
Having a nifty AJAX editing interface might be pretty cool, but it will
probably need some serious work to make it as responsive as Writely / Google
Docs. However, it could really enable less tech-savvy people to write more
and better formatted texts.
* A simpler system for templates/themes. Maybe not necessary for
Wikimedia-related projects (because they are all using Monobook anyway), but
for customization of other users a template system such as in Wordpress (
www.wordpress.org) would be handy.

-- Hay Kranen / [[User:Husky]]

On 1/23/07, Brianna Laugher <brianna.laugher at gmail.com> wrote:
>
> On 23/01/07, Titoxd at Wikimedia <titoxd.wikimedia at gmail.com> wrote:
> > Speaking from the technical side, there is a hurdle with the "vastly
> > improved searches" that are requested, at least on one aspect.
>
> Retrieving the results is one thing. Improving how they are displayed
> is something that could be improved on too. For example we lack a
> gallery-based search. (Special:Newimages only searches on image
> titles. The functionality is there, so why not extend it to image
> descriptions?)
>
> > As for categories: date of page creation is not stored in the tables
> right
> > now; that would be ideally something for the page table. The time a page
> > included in a category is already stored (or at least, there is room for
>
> > it), so that may be easier to do in the future. Dynamic sort tables have
> > issues with older browsers, but maybe a sortby can be done by the server
> as
> > well. These things do require a considerable amount of coding and
> testing,
> > though.
>
> Well, that's why it's my vision, and not my requests for next week. ;)
>
> cheers,
> Brianna
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l
>


list: wikimedia-l

subject: [Foundation-l] The Ideal Wiki Software


from_name: Alphax (Wikipedia email)

subject: [WikiEN-l] a few new wrinkles in the external link issue

body:
Stephen Bain wrote:
> On 1/22/07, Jeff Raymond <jeff.raymond at internationalhouseofbacon.com> wrote:
>> 1) If we're going to blindly attach "nofollow" to all the external
>> links, why are we allowing Wikia links to be propped up artificially?
>> Are we in the business of conflict of interest now?
>
> I'm not completely sure what you mean, but I think you're asking why
> nofollow is applied to links to pages hosted at Wikia. The answer to
> that is that MediaWiki treats external links [1] differently to
> interwiki links, and nofollow is only applied to external links.
>
> So if my wikitext had [http://de.wikipedia.org/wiki/Hauptseite] I
> would get an external link, with nofollow, but if I had
> [[w:de:Hauptseite]] I would get an interwiki link without nofollow.
>
> This is sort of a bug, since there are many many sites which can be
> linked to this way: http://meta.wikimedia.org/wiki/Interwiki_map
>

... which is why it's an inter-WIKI map, and is protected.

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 542 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20070123/441eae85/attachment.pgp


from_name: Stan Shebs

body:
Jay R. Ashworth wrote:
>> http://commons.wikimedia.org/wiki/Commons:Licensing#Screenshots
>> Screenshots are copyrighted if the displayed program or operating system
>> is copyrighted. For a detailed discussion see
>> http://www.jisclegal.ac.uk/publications/copyrightalexmorrisson.htm
>>
>
> The terrible truth about laywers, courtesy of the late Mark MacCormack,
> is that they'll tell you what's *safe*, not what's *reasonable*.
>
I'm pretty sure Apple is very proud of its Aqua widgets, and equally
sure they'll be after you with a thousand lawyers if you try to claim
their graphical designs are owned by you because they happen to be
visible in a screenshot you made. If you successfully fend them off, let
me know, I could use a bunch of textures, and clipping them from WoW
screenshots will save me a lot of time, not to mention Blizzard's
artists have better technique than I can muster.

Stan


body:
> How would this work if you just wanted to make a redirect? Further,
> would this get in the way of anything useful automated tools, like
> bots or popups or...?

Experienced users are the ones who make redirect pages, and they will know
that you obviously don't need refs for a redirect and will remove the
section.  I think the benefits of this far outweigh this one problem.

I also don't expect to add this temple every time someone clicks on a
redlink, but rather only when they click the big redlink that appears when a
search yields no results.  This is very easy to do by simply editing
[[MediaWiki:Noexactmatch]].

--Mets501


body:
Oh, so you are an admin already. *looks jealously*

On 1/23/07, Mets501 <mets501wiki at gmail.com> wrote:
>
> > How would this work if you just wanted to make a redirect? Further,
> > would this get in the way of anything useful automated tools, like
> > bots or popups or...?
>
> Experienced users are the ones who make redirect pages, and they will know
> that you obviously don't need refs for a redirect and will remove the
> section.  I think the benefits of this far outweigh this one problem.
>
> I also don't expect to add this temple every time someone clicks on a
> redlink, but rather only when they click the big redlink that appears when
> a
> search yields no results.  This is very easy to do by simply editing
> [[MediaWiki:Noexactmatch]].
>
> --Mets501
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>

--
en:User:Firefoxman

This user is.


from_name: Neil Harris

subject:
[Wikitech-l] HTTPS virtual hosting (was Re: MD5
	Password	Encryption)

body:
Tim Starling wrote:
> Lane, Ryan wrote:
>
>>> HTTPS does support virtual hosting. You can have certificates
>>> with wildcards, e.g. *.wikipedia.org, and you can even have
>>> certificates that list multiple second-level domains. In
>>> theory we could even support https://en.wikipedia.org/, by
>>> having LVS pass the traffic off to an SSL proxy cluster,
>>> which forwards to the Florida squids via a secure tunnel.
>>>
>>>
>> From what I've read HTTPS does not support name-based virtual hosting,
>> only IP based virtual hosting, as the SSL connection happens before the
>> request is made. So, if you have two virtual hosts such as:
>>
>> <Virtualhost en.wikipedia.org>
>> ...
>> </Virtualhost>
>>
>> <Virtualhost de.wikipedia.org>
>> ...
>> </Virtualhost>
>>
>> The first virtual host will always be used as the server has absolutely
>> no clue, when the connection is made, which virtual host it needs to
>> use.
>>
>> I believe this is the point Neil was trying to make.
>>
>
> The same is true of unencrypted HTTP. The server has no idea, when the
> connection is made, what virtual host will be required. That only comes
> when the client sends the Host header.
>
> The issue is that with HTTPS, the server has to send a certificate before
> the client sends the Host header. The certificate has to match the hostname.
>
> See http://wiki.cacert.org/wiki/VhostTaskForce for a discussion of the
> various ways of achieving this.
>
> -- Tim Starling
>
>
>
And, once the various browsers and CAs have all sorted out the different
ways of generating and handling these wildcard and multi-name certs in a
fully interoperable way, the problem will have been solved. But for the
moment, I believe that this currently isn't the case: although, if there
is a way to do this across all the currently-deployed browsers, I'd be
interested to hear about it.

-- Neil


body:
Yep :-)
And when I figure out a way for it to only preload that template in the main
namespace, I'm going to add it.

--Mets501

-----Original Message-----
From: wikien-l-bounces at lists.wikimedia.org
[mailto:wikien-l-bounces at lists.wikimedia.org] On Behalf Of . Firefoxman
Sent: Tuesday, January 23, 2007 3:43 PM
To: English Wikipedia
Subject: Re: [WikiEN-l] Preloading template in new articles

Oh, so you are an admin already. *looks jealously*

On 1/23/07, Mets501 <mets501wiki at gmail.com> wrote:
>
> > How would this work if you just wanted to make a redirect? Further,
> > would this get in the way of anything useful automated tools, like
> > bots or popups or...?
>
> Experienced users are the ones who make redirect pages, and they will
> know that you obviously don't need refs for a redirect and will remove
> the section.  I think the benefits of this far outweigh this one problem.
>
> I also don't expect to add this temple every time someone clicks on a
> redlink, but rather only when they click the big redlink that appears
> when a search yields no results.  This is very easy to do by simply
> editing [[MediaWiki:Noexactmatch]].
>
> --Mets501
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>

--
en:User:Firefoxman

This user is.
_______________________________________________
WikiEN-l mailing list
WikiEN-l at lists.wikimedia.org
To unsubscribe from this mailing list, visit:
http://lists.wikimedia.org/mailman/listinfo/wikien-l


from_name: Stephen Bain

body:
Firstly, TINLA, and brace yourself.

On 1/18/07, Mark Clements <gmane at kennel17.co.uk> wrote:
> This pops up every so often at www.mediawiki.org, particularly in relation
> to the public domain help pages that we are trying to compile.
>
> What is the correct license for screenshots of MediaWiki?  Are we able to
> distribute them along with the PD help pages (when we get to that stage)?
> Currently they are variously tagged as GFDL, PD, (c) WMF and possibly
> others.

The simple answer is that MediaWiki is GPL, so screenshots of a plain
old MediaWiki install, with no other things in it, are GPL.

> Are there any considerations that may cause some screenshots to be under one
> license and some under another?  E.g. if the screenshot includes the MW logo
> or certain interface text does it affect how it can be licensed?  What about
> the different skins?

When you start mixing stuff you complicate things. If I were to take a
screenshot of a page on Wikipedia, for example, the text of the page
would be GFDL (unless there are some quotes or something in the text,
which would be fair use), the MediaWiki elements would be GPL, the
browser window could be anything (if you're in Firefox, for example,
then the picture of the browser interface is under the Mozilla Public
Licence). The skins that come with MediaWiki are GPL just like the
rest of MediaWiki.

So unfortunately you can't get PD screenshots of MediaWiki. The best
you can do is GPL screenshots, but only if you show only GPL content
in it and either cut out the browser interface or use a GPL browser.
You could also create a screenshot with the MediaWiki interface and
some other free content in it (like Wikipedia content) and the result
would be that there would be different licences for different parts of
the picture.

The last point is the logos. The Wikipedia logo, among others, is not
under a free licence so you really can't show that in a screenshot if
you want the image to be freely licenced. The MediaWiki logo, IIRC,
still has a fairly iffy copyright status, noone seems to know whether
it is PD or GPL. But that may have been resolved since the last time I
read about it.

Lastly, here's a few examples:

http://commons.wikimedia.org/wiki/Image:Accueil-Safari-Alibaba.png
French WP in Safari. The Safari elements are LGPL, MediaWiki elements
are GPL and the WP content is GFDL.

http://commons.wikimedia.org/wiki/Image:Aide_FR_Metadata_image.png
Only shows MediaWiki elements, entirely GPL (the metadata shown is
probably not eligible for copyright).

--
Stephen Bain
stephen.bain at gmail.com


body:
On Tue, Jan 23, 2007 at 02:15:02PM -0500, Simetrical wrote:
> On 1/23/07, Jay R. Ashworth <jra at baylink.com> wrote:
> > Someone vastly misunderstands the nature of copyright law, I think.
> >
> > (Though, admittedly, IANAL, either.  I just play on on the net.)
> >
> > If I create a screenshot of a browser page on my computer displaying
> > wikipedia, there is *one* copyright involved: *mine*.  The image is not
> > a derivative work of the browser, the OS, or the website.  Therefore,
> > none of those people's copyrights apply, and therefore by induction, no
> > licenses are necessary.  I created an image, and I own its copyright.
> >
> > The situation is pretty much identical to my *taking a photograph* of
> > the screen displaying said browser.
>
> Well, I can say that that's certainly not how Wikipedia interprets
> copyright in such works.  Screenshots of copyrighted programs are
> generally considered fair use, because the layout/coloring/general
> appearance of the browser is deemed creative.

Fair use of *what*?

>                                                Whether this is the law
> I don't know, but certainly a photo of a copyrighted work is
> derivative of it (if even that).

Derivative is a word with a fairly specific definition as a term of art
in copyright law.  TTBOMK, only two very narrow categories of
things-you-can-photograph require care on the part of the photographer:
Fine Art, and architectural renderings (ie: fancy buildings :-)

I'm off to read the article someone linked to now.

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274


body:
On Tue, Jan 23, 2007 at 09:59:14PM +0100, Platonides wrote:
> Jay R. Ashworth wrote:
> > Someone vastly misunderstands the nature of copyright law, I think.
> >
> > (Though, admittedly, IANAL, either.  I just play on on the net.)
> >
> > If I create a screenshot of a browser page on my computer displaying
> > wikipedia, there is *one* copyright involved: *mine*.  The image is not
> > a derivative work of the browser, the OS, or the website.  Therefore,
> > none of those people's copyrights apply, and therefore by induction, no
> > licenses are necessary.  I created an image, and I own its copyright.
>
> Then, why does commons interpret it otherwise?

Because they listened to the lawyers advising the librarians who wrote
that page, in the UK?

And incidentally, that reliance on Bridgman v Corel seems completely
out of whack to me; the case doesn't appear to speak, at all, to the
issue at hand.

> http://commons.wikimedia.org/wiki/Commons:Licensing#Screenshots
> Screenshots are copyrighted if the displayed program or operating system
> is copyrighted. For a detailed discussion see
> http://www.jisclegal.ac.uk/publications/copyrightalexmorrisson.htm

The terrible truth about laywers, courtesy of the late Mark MacCormack,
is that they'll tell you what's *safe*, not what's *reasonable*.

That's what that UK site tells me.  It wasn't written, so far as I can
see, by an attorney, and it doesn't cite cases.

Clearly, this issue is at the point where the Foundation needs to go
pay an IP attorney for a formal written opinion that he'll back up --
in detail, stating exactly what the copyright in a screenshot created
by J. Random User is, by analogy to any other way that image could be
created.

I'm sure we can find a couple, if we look.

I recommend paying for the opinion, even if someone offers to give it
out pro bono; that's how people pay their mailpractice and E&O
insurance, and one wants to be able to rely on it.

Notwithstanding that, there are several on Ask.Metafilter, as well,
where I'm heading to post a query.

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274


body:
Neil Harris wrote:
> Tim Starling wrote:
[...]
>> See http://wiki.cacert.org/wiki/VhostTaskForce for a discussion of the
[...]
> And, once the various browsers and CAs have all sorted out the different
> ways of generating and handling these wildcard and multi-name certs in a
> fully interoperable way, the problem will have been solved. But for the
> moment, I believe that this currently isn't the case: although, if there
> is a way to do this across all the currently-deployed browsers, I'd be
> interested to hear about it.

The interoperability table in the article I linked to has three methods
that work in the current versions of the major browsers, two of which work
in the older versions as well, and one of which that works with every
client they tested. What's the problem?

-- Tim Starling


from_name: Gregory Maxwell

subject:
[Wikitech-l] Session cookie theft. Was: identity management
	(was: MD5 Password Encryption)

body:
On 1/23/07, Platonides <Platonides at gmail.com> wrote:
> A session cookie will expire. A password probably not, would allow to
> change password, etc.

Yes. Session cookies don't also let someone get into your bank account
(true for many folks).. etc.

> It could be less acceptable to normal users if each time they switch on
> their computer had to type their password :S

True.

> Ideally, that sesion cookie would be a shared secret stored by the
> browser, used to compute the (edit) tokens.
> AFAIK this is unfeasible as today, unless you force a custom browser.

All we need to do is add a kerberos agent to the browser.... and.. :)

Actually, JS can read and cookies, and thereby use them as a
datastore.  Based on prior threads about JS based challenge
response... it would actually be possible to do this.. but only with a
ton of JS hackery.   (I.e. client side JS computes
cookie=H(uid+password) and stores it as a cookie server also stores
this, server would occasionally challenge the client to compute
H(cookie+counter) ... but without server authentication there is no
way to prevent an active MTM attacker from using the client as an
oracle).

> Another approach could be changing the session cookie too fast (e.g.
> each 3-4 requests), so a cookie theaft couldn't reuse an old cookie.

As I said before.. SSL makes it all the issues go away.  As a long
term project we should probably figure out how to make SSL work for
us, and not waste time with hacks. Any other path will result in us
reinventing SSL poorly.


body:
>> I don't know much about preloading templates in edit boxes, but could
>> you put an if statement in the template so it's blank if outside the
>> main namespace? {{if|{{{NAMESPACE}}}=""|<references>||}} or something
>> (I can't remember the syntax for if statements).
>
> I've looked up the syntax. I think it should be:
>
> {{#if:{{NAMESPACE}}|| [your code here] }}

That would work generally but when you're talking about preloading, whatever
is in the template source code is exactly what goes in the edit box; nothing
is parsed, nothing can be commented out, etc.

--Mets501


body:
> I'd much prefer it if we didn't do this, it seems kinda....I don't
know....assholeish.
> You know, shoving things down peoples throats. It has an element of
WP:BITE in it, I
> think. Also, I think it will > be fairly ineffective (people will simply
ignore it, or
> be confused since the comment tag is fairly obscure for the average user),
and it will
> mess with the "purity" of the edit box (not much of an argument, but still
;)
>
> Why not simply include it in the text that's above the edit box more
prominently? Like,
> bold it and make it 2 points bigger than the rest.
>
> --Oskar

It already is included in the text above the edit box, but it's not enough.
New users don't know how to add references, and therefore just ignore the
whole thing.

--Mets501


from_name: Rune Kg

subject:
[Wikitech-l] Using gallery tag in templates doesn't render any
	output

body:
Why wont this work?

<gallery>
Image:{{{1|default.jpg}}}
</gallery>

Very weird. I'm on 1.8.2. Any ideas?

Rune.

_________________________________________________________________
Ta' p? udsalg ?ret rundt p? MSN Shopping:  http://shopping.msn.dk  - her
finder du altid de bedste priser


subject: [WikiEN-l] Mircosoft paying people to edit

body:
On 23/01/07, Mathias Schindler <mathias.schindler at gmail.com> wrote:

> We say (for a good reason): "So fix it" to people who spot a mistake
> in a Wikipedia article. Telling "So don't fix it" especially to the
> people familiar with a topic is simply annoying (IMHO). In the end,you
> will not prevent MS from paying 3rd parties to contribute to Wikipedia
> but you will prevent them from disclosing it.

I just did a press phone call to IDG where I expressed our
disappointment at Microsoft feeling it had to act in an underhanded
round-the-back manner - pointing out that if they made a donation,
they'd have gained goodwill, they'd have gotten goodwill, it would
have been tax deductible and their articles would have had a decent
NPOVing from it anyway. "Give the money straight to US, dammit!"

- d.


subject: [WikiEN-l] Preloading template in new articles

body: Why is the page protected if nothing links to it?


body:
On 1/23/07, Tels <nospam-abuse at bloodgate.com> wrote:
> Does that mean if I take a screeshot of "gcc -v" it is copyrighted? What if
> I copy & paste that text, is it still copyrighted?

I'd guess probably not, since it's purely informative and not what
might be called creative expression.  But I don't really know.

On 1/23/07, Jay R. Ashworth <jra at baylink.com> wrote:
> Fair use of *what*?

Of the software's graphical interface.  Positioning of elements and
choosing exact designs (such as the type of curve, font and color
selection, etc.) can be copyrightable.  Probably the element
positioning alone isn't copyrightable, though . . . Word has a
WordPerfect menu mode and vice versa, for instance, IIRC.

> Derivative is a word with a fairly specific definition as a term of art
> in copyright law.  TTBOMK, only two very narrow categories of
> things-you-can-photograph require care on the part of the photographer:
> Fine Art, and architectural renderings (ie: fancy buildings :-)

There is generally no distinction at all between fine art and any
other creative work in US copyright law.


subject:
[WikiEN-l] Gosh darn it,
	those spammers^Wmarketers will show us what for

body:
On 1/23/07, David Gerard <dgerard at gmail.com> wrote:
> http://www.marketingpilgrim.com/2007/01/campaign-to-reduce-wikipedias-pagerank-to-zero.html
>
> I'm quaking in my boots.
>
> - d.

Don't worry, it's not even the real Andy Beal.  The real Andy Beal was
in Berkeley in the 80s and 90s.

--
-george william herbert
george.herbert at gmail.com


from_name: Marc Riddell

subject: [WikiEN-l] Uploading images

body:
Everyone / anyone,

Real quick, short question. Are their any copyright or other issues involved
in uploading photos or other images from the Find-a-Grave site?

Thanks,

Marc Riddell


body:
Tim Starling wrote:
> Neil Harris wrote:
>
>> Tim Starling wrote:
>>
> [...]
>
>>> See http://wiki.cacert.org/wiki/VhostTaskForce for a discussion of the
>>>
> [...]
>
>> And, once the various browsers and CAs have all sorted out the different
>> ways of generating and handling these wildcard and multi-name certs in a
>> fully interoperable way, the problem will have been solved. But for the
>> moment, I believe that this currently isn't the case: although, if there
>> is a way to do this across all the currently-deployed browsers, I'd be
>> interested to hear about it.
>>
>
> The interoperability table in the article I linked to has three methods
> that work in the current versions of the major browsers, two of which work
> in the older versions as well, and one of which that works with every
> client they tested. What's the problem?
>
> -- Tim Starling
>
>
Both methods have their own drawbacks and advantages.

The problem with multi-name certs is all the other platforms: mobile
phones and embedded web browsers, HTTP client libraries for
Java/Python/Perl etc, bizarre things like man-in-the-middle HTTPS
proxies (yes, they're out there)... until you've tried it, you don't
know if its going to work, unlike using IP addresses to select the cert
to be sent, which is known to work for all HTTPS-speaking clients.

Of course, this doesn't mean you shouldn't do the multi-name cert thing;
the wiki page suggests it should just work for all the major browsers,
which implies that it should just work for something like 99% of all web
users, just that it's going to need a lot of testing before it goes
live, and then providing fallback to plain HTTP login for all clients
which cannot handle this, most probably based on user-agent strings.

-- Neil


from_name: Brianna Laugher

subject: [Foundation-l] The Ideal Wiki Software

body:
On 23/01/07, Virgil Ierubino <virgil.ierubino at gmail.com> wrote:
> In an ideal world, what features would the ideal Wiki Software have, and
> what would it be like?

I have outlined some of my hopes for the future of MediaWiki in
file/image management (ie. the Commons) in comments on this bug:
http://bugzilla.wikimedia.org/show_bug.cgi?id=3712

I dream of a MediaWiki II that is actually designed to manage media -
like the name implies. :)

Vastly improved and more flexible search would also benefit all wikis.
There is a hella lotta potential for improving options when working
with categories, too (for example, I envisage a drop-down list with
options for the sort key - date page created, date added to category,
page name (alphabetical - current default), date page was last edited.
etc.

cheers,
Brianna
user:pfctdayelise


subject: [Foundation-l] The Ideal Wiki Software


from_name: · Firefoxman

subject: [WikiEN-l] Uploading images

body:
What is it?

On 1/23/07, Marc Riddell <michaeldavid86 at comcast.net> wrote:
>
> Everyone / anyone,
>
> Real quick, short question. Are their any copyright or other issues
> involved
> in uploading photos or other images from the Find-a-Grave site?
>
> Thanks,
>
> Marc Riddell
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>

--
-en:User:Firefoxman


body:
It?s protected in preparation for being preloaded on the edit pages if enabled.  This won?t show up in WhatLinksHere.

From: ? Firefoxman [mailto:enwpmail at gmail.com]
Sent: Tuesday, January 23, 2007 4:54 PM
To: Brian Salter-Duke; English Wikipedia; Mets501
Subject: Re: [WikiEN-l] Preloading template in new articles

Why is the page protected if nothing links to it?


subject: [WikiEN-l] Uploading images

body:
> Everyone / anyone,
>
> Real quick, short question. Are their any copyright or other issues
involved
> in uploading photos or other images from the Find-a-Grave site?
>
> Thanks,
>
> Marc Riddell

I believe that the copyright is still with the uploader to that website.  It
says the website doesn't assume copyright, but I don't think that means that
the images are automatically in the public domain (see
http://www.findagrave.com/disclaimer.html)
--Mets501


subject: [WikiEN-l] Uploading images

body:
on 1/23/07 5:05 PM, ? Firefoxman at enwpmail at gmail.com wrote:

> What is it?

It is the photo of Kansas Governor Joan Finney. I'm wanting to add it to her
Article page, and wasn't sure of the policy regarding that particular site.

Thanks,

Marc


body:
On 1/23/07, Brion Vibber <brion at pobox.com> wrote:
> You mean like this?
>
> http://assl.sullof.com/assl/

Dear lord.  Thanks a lot for showing me this, I don't think I'm going
to be able to sleep tonight.

RSA encryption on my system with the RSA implimentation they are using
takes about 200ms.. Thats a lot faster than I would have expected.


subject: [WikiEN-l] Uploading images

body:
on 1/23/07 5:16 PM, MacGyverMagic/Mgm at macgyvermagic at gmail.com wrote:

> When was that picture taken?

There is no date that I can see on it. However, I just found the email
address of the person who submitted the photo to the Find-a-Grave site. I
don't know if he is the person who actually took the picture, or simply
submitted it.

Thanks,

Marc


subject: [WikiEN-l] Uploading images

body:
Well, try to contact him and ask him the folowing:

   1. If he took the photo or has the rights to it
      1. If no, does he know the person who does, or is it expired
      already?
   2. Will he release the rights to it, or put it in a commons licence?

On 1/23/07, Marc Riddell <michaeldavid86 at comcast.net> wrote:

> on 1/23/07 5:16 PM, MacGyverMagic/Mgm at macgyvermagic at gmail.com wrote:
>
> > When was that picture taken?
>
> There is no date that I can see on it. However, I just found the email
> address of the person who submitted the photo to the Find-a-Grave site. I
> don't know if he is the person who actually took the picture, or simply
> submitted it.
>
> Thanks,
>
> Marc
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>

--
-Firefoxman


from_name: Mathias Schindler

body:
On 1/23/07, bbatsell <wikipedia at theskeptik.com> wrote:

> Although I absolutely agree with the sentiment (and think we should
> clean up any POV problems in the article), my answer to your question
> would be, "when people are being paid by the subject to do so", which
> in my opinion is a clear [[WP:COI|conflict of interest]].

I certainly dispute the fact that an ECMA standard (propsal) is a
subject, nor it can pay anyone; extending the COI even to people not
affiliated with the subject behind a topic will end up with another
conflict of interest: We do want the best people familiar with a
subject to contribute to Wikipedia.

We say (for a good reason): "So fix it" to people who spot a mistake
in a Wikipedia article. Telling "So don't fix it" especially to the
people familiar with a topic is simply annoying (IMHO). In the end,you
will not prevent MS from paying 3rd parties to contribute to Wikipedia
but you will prevent them from disclosing it.

Mathias


subject: [WikiEN-l] Uploading images

body:
on 1/23/07 5:31 PM, ? Firefoxman at enwpmail at gmail.com wrote:

> Well, try to contact him and ask him the folowing:
>
> 1. If he took the photo or has the rights to it
> 1. If no, does he know the person who does, or is it expired
> already?
> 2. Will he release the rights to it, or put it in a commons licence?

Thanks, I will.

I'll let you know what he says.

Thanks again,

Marc


body:
Gregory Maxwell wrote:
> Were we to move logged in users into SSL all sorts of threats just go
> away. Of course there is the little matter of plain squid not
> supporting SSL offloading like some of the commercial reverse proxy /
> acceleration solutions which would have to be resolved...

As I said in my post with subject "HTTPS virtual hosting", you can use LVS
to redirect HTTPS requests to wherever you like. We're using apache as an
HTTPS reverse proxy for secure.wikimedia.org, but there's plenty of other
open source solutions to try if that doesn't prove to scale well enough.

-- Tim Starling


from_name: Mark Clements

subject: [Wikitech-l] MD5 Password Encryption

body:
"Tels" <nospam-abuse at bloodgate.com> wrote in
message news:200701231852.29592 at bloodgate.com...
>
> What function you actually use for H(), may it be MD5 or SHA1, is
> practically irrelevant here, tho, but when you migrate to such a scheme,
> you might as well use SHA256 instead of MD5 (even if it is just to quiten
> all the "MD5 is insecure" cryers :)
>

In security, doing things because "you might as well" is an incredibly bad
idea!  A security system should only be changed to be a _better_ security
system (and even then after it has been proven to be better). _Never_
because it's 'probably not worse'!

- Mark Clements (HappyDog)


from_name: Edward Z. Yang

subject: [Wikitech-l] MD5 Password Encryption

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aw, come on, why is there so much contention about such a simple issue?
And yes, I did slip when I started talking about birthday attacks. Sorry
about that.

- From the way I see it, then, the primary objections with migrating are
that:

* All this hashing and salting tomfoolery makes no difference because
the only way an attacker could possibly get the hashes is if they hacked
into the server or a developer with full-read access pulled the hashes.
* The current way is not broken, because there have been no pre-image
attacks developed for MD5
* Effort spent on migration would be better spent on HTTPS
* The security benefit is miniscule, compared to other possible
strategies such as encouraging strong passwords
* And that I have no clue what I'm talking about (I like to think that I
at least have some clue)

There are some periphery issues surrounding SHA256:

* SHA-256 is not as widely deployed, so it might have some fatal
weaknesses. (it's unlikely, though, because it is still based off of SHA-1)
* SHA-256 would require a pure-PHP implementation which might have bugs
(Due to the avalanche effect, however, any bug should be glaringly
obvious. Furthermore, the algorithm is small enough so that a full code
audit would not be difficult to do (think <15kb))

My arguments for migrating are:

* Defence in depth: it is true that there are a number of elements that
already potentially should "solve" the problem, but this argument taken
to the extreme would mean there would be no need to hash or salt the
password at all: after, anyone who has access to the database could just
change it themselves! But I'm sure most reasonable people here agree
that hashing the password is better than no protection at all, even if
it doesn't seem to make a difference.
* It saves effort later: By adding support for multiple hashing
techniques, and building the framework necessary to migrate these
hashes, we reduce the cost of any other hash migrations we have to do in
the future down. If done properly, a future migration could be done by
specifying a new hash function, and the code from the previous migration
would do all the work.
* It is forward thinking: attacks against hashing schemes never grow
worse: they only get better, as processing power, memory capabilities
and knowledge of attacks increase.

It's no problem if we don't, of course. The strangeness of MediaWiki's
current hash function should, for now, prevent people from using rainbow
tables to find the password (even though you reduce entropy by
double-hashing). But, as I said, defense in depth!

Now, about that password security indicator...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtpl9qTO+fYacSNoRAgr0AJ9cmGiUrIgl3fsfYG6N3tV47s4uswCeM4t2
ZueoZtM8ppOe2v1I7ZTrDLU=
=CKBM
-----END PGP SIGNATURE-----


body:
On 1/23/07, Alphax (Wikipedia email) <alphasigmax at gmail.com> wrote:
> Stephen Bain wrote:
> >
> > This is sort of a bug, since there are many many sites which can be
> > linked to this way: http://meta.wikimedia.org/wiki/Interwiki_map
>
> ... which is why it's an inter-WIKI map, and is protected.

I meant that it's a bug in the sense that someone with, say, a Wikia
wiki can evade having nofollow on links to them by changing external
links to interwiki links.

--
Stephen Bain
stephen.bain at gmail.com


from_name: Tels

subject: [Wikitech-l] MD5 Password Encryption

references:
<ep3pau$lg0$1@sea.gmane.org>
	<45B58624.1070903@solarsail.hcs.harvard.edu>
	<e692861c0701222010t47db3e68ue716f565cfca5c98@mail.gmail.com>

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moin,

On Tuesday 23 January 2007 05:10, Gregory Maxwell wrote:
> On 1/22/07, Ivan Krsti? <krstic at solarsail.hcs.harvard.edu> wrote:
> [snip]
> > Generally, the only password hashing scenario in which the choice of
> > algorithm makes a difference at all is an offline attack once the
> > password table has been compromised, at which point, the difference
> > between one algorithm and the next is nothing more but how long you can
> > hold off a brute-forcing attacker. And for that, without preimage
> > attacks, the known MD5 and SHA-1 flaws make about zero difference for
> > any practical purpose.
>
> Ivan is right on in his statements here.
[snip]

I agree that changing the hashing algorithm is unnec. here.

But:

> (/me waits for someone to notice my above H(s +'-'+H(P)) above and cry
> about the minor precomputation a smart attacker can do to reduce the
> workload from 2*users*passwords MD5s to passwords + passwords*users
> MD5s)

Actually, if you want to strengthen the password-hash table against some
offline brute-force/dictionary attacks, you should hash them with a
function that takes a long time per test, but still not enough time to slow
down the log-in servers.

Something like

	hash = H(password);
	for (0..100) { hash = H(hash); }

What function you actually use for H(), may it be MD5 or SHA1, is
practically irrelevant here, tho, but when you migrate to such a scheme,
you might as well use SHA256 instead of MD5 (even if it is just to quiten
all the "MD5 is insecure" cryers :)

Best wishes,

Tels

- --
 Signed on Tue Jan 23 18:45:25 2007 with key 0x93B84C15.
 View my photo gallery: http://bloodgate.com/photos
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Don't worry about people stealing your ideas. If your ideas are any
 good, you'll have to ram them down people's throats." -- Howard Aiken

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRbZLXXcLPEOTuEwVAQIsVgf/TT7IievMKYiO46duA3FvZCrJjh5incDb
BxRZ8YX7CXqXfoVuYKY2lQfztSg0yb1Z1Eyr9Z/ELrKZqEmcQIUOVCNOWcjSKesT
c0Rg3p/FTx1Q/Yds7LMO/YZpLy3Fz0Ow5HgDyH+0BGNuaz90nwClpJ3J8kosbL6q
sHGm2in15JmRtRiNwQPJ77NpNQWkFAbB8E7WUh/PATSfGficA4lClKSyYxZlAugq
V1wo91/3FbSdfcOvOCpDXZRVUOATIlQU0Uig9+dWpeiFa6CP6sPk3pS3bP3feCvU
b2I2vYDuvnb59Wxa+PNEQRrCjOk5X9Bqab3qqTMqwdZce24k3WWh2w==
=rn3c
-----END PGP SIGNATURE-----


subject: [Foundation-l] The Ideal Wiki Software

body:
On 23/01/07, Titoxd at Wikimedia <titoxd.wikimedia at gmail.com> wrote:
> Speaking from the technical side, there is a hurdle with the "vastly
> improved searches" that are requested, at least on one aspect.

Retrieving the results is one thing. Improving how they are displayed
is something that could be improved on too. For example we lack a
gallery-based search. (Special:Newimages only searches on image
titles. The functionality is there, so why not extend it to image
descriptions?)

> As for categories: date of page creation is not stored in the tables right
> now; that would be ideally something for the page table. The time a page
> included in a category is already stored (or at least, there is room for
> it), so that may be easier to do in the future. Dynamic sort tables have
> issues with older browsers, but maybe a sortby can be done by the server as
> well. These things do require a considerable amount of coding and testing,
> though.

Well, that's why it's my vision, and not my requests for next week. ;)

cheers,
Brianna


subject: [Foundation-l] The Ideal Wiki Software


from_name: Nathan Noblet

body:
Message: 9
Date: Mon, 22 Jan 2007 17:20:25 -0800
From: "George Herbert" <george.herbert at gmail.com>
Subject: [WikiEN-l] Microsoft offering to pay people to edit WP
       articles
To: "English Wikipedia" <wikien-l at lists.wikimedia.org>
Message-ID:
       <38a7bf7c0701221720s2526bfc9x267b55bae89fb0e7 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Found on Slashdot:
http://www.oreillynet.com/xml/blog/2007/01/an_interesting_offer.html

Targeted articles was apparently:
 http://en.wikipedia.org/wiki/OOXML

--
-george william herbert

I think we should protect it.


from_name: David Gerard

body:
On 23/01/07, Jeff Raymond <jeff.raymond at internationalhouseofbacon.com> wrote:
> Brion Vibber wrote:

> > Indefinite. I'd prefer to see actual improvements (whitelisting, fading,
> > flagging and approval system, etc) rather than just turn it off one day,
> > though.

> Why aren't we treating nofollow like the spam blacklist?

The spam blacklist failed to disincentivise spammers in general;
nofollow is already making them feel like their hard work was wasted.
GOOD.

- d.


from_name: Gerard Meijssen

subject: [Wikitech-l] MD5 Password Encryption

body:
Mark Clements schreef:
> "Tels" <nospam-abuse at bloodgate.com> wrote in
> message news:200701231852.29592 at bloodgate.com...
>
>> What function you actually use for H(), may it be MD5 or SHA1, is
>> practically irrelevant here, tho, but when you migrate to such a scheme,
>> you might as well use SHA256 instead of MD5 (even if it is just to quiten
>> all the "MD5 is insecure" cryers :)
>>
>>
>
> In security, doing things because "you might as well" is an incredibly bad
> idea!  A security system should only be changed to be a _better_ security
> system (and even then after it has been proven to be better). _Never_
> because it's 'probably not worse'!
>
> - Mark Clements (HappyDog)
Hoi,
This discussion /is /about changing the security. Changing it because
the need is felt for the current system to be improved. So when you have
the option between several choices where one is theoretically
substantially better, it is worth the consideration. As many people have
mentioned it pays to use well tested, well known algorithms. As many
people have mentioned, it pays to double check that the implementation
is done perfectly. Public perception about security is important. When
people think that something is not secure, they are a step closer to
proving that something is not secure.
Thanks,
     GerardM


from_name: Rob Church

subject: [Wikitech-l] MD5 Password Encryption

body:
On 23/01/07, Gerard Meijssen <gerard.meijssen at gmail.com> wrote:
> simple. Some things that are important to me will not happen until AFTER
> Single User Login. It is all well and good that everyone comes up with

Like what?

> basic stuff does not get done. If this drives you mad, fine. Fix the
> issue - help Brion implement SUL !

Is Wikimedia going to pay me to do it?

> The promised date for SUL was end of January 2005. It is now a year late.

Well, thank god we're not operating on the Microsoft release cycle then.

Rob Church


subject: [Wikitech-l] MD5 Password Encryption

references:
<ep3pau$lg0$1@sea.gmane.org> <200701231852.29592@bloodgate.com>
	<ep5jl1$umr$1@sea.gmane.org>

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moin,

On Tuesday 23 January 2007 19:20, Mark Clements wrote:
> "Tels" <nospam-abuse at bloodgate.com> wrote in
> message news:200701231852.29592 at bloodgate.com...
>
> > What function you actually use for H(), may it be MD5 or SHA1, is
> > practically irrelevant here, tho, but when you migrate to such a
> > scheme, you might as well use SHA256 instead of MD5 (even if it is just
> > to quiten all the "MD5 is insecure" cryers :)
>
> In security, doing things because "you might as well" is an incredibly
> bad idea!  A security system should only be changed to be a _better_
> security system (and even then after it has been proven to be better).
> _Never_ because it's 'probably not worse'!

I agree with you in principle, but please note that I advocated the
switch "as well" because:

* SHA256 is generally considered a more secure hash (or it would be silly to
switch)
* after changing the core algorithm, you must evaluate the security of the
new system, so you might as well *consider* switching the  hash function,
because then you need to do the switch only once and the evaluation only
once, too. You know, as to not having to redo this in a few months when the
next attack on MD5 comes (this time affecting your system)

Of course, you evaluation might also result in "there is no need to switch
anything".

Best wishes,

Tels

- --
 Signed on Tue Jan 23 21:24:46 2007 with key 0x93B84C15.
 View my photo gallery: http://bloodgate.com/photos
 PGP key on http://bloodgate.com/tels.asc or per email.

 "In 1988, Jack Thompson ran against Janet Reno for DA of Dade County:
 Thompson's unique campaign message was that Reno was unfit for the job
 because, as a closeted lesbian with a drinking problem, she was great
 candidate for blackmail by the criminal element. Jack never explained
 why this remained a threat even after he exposed her 'secret'. Reno
 cruised at the polls."

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRbZvwncLPEOTuEwVAQIynwf+MmY1t2EshWeGQjY/YhP6nHis6XiEkNvs
fk9iKXdoA9JmghXepVU5uZZ+Aetnw/C4RNkTnAzy3JX1lxeScxD7NXsr4tByFwru
2U7zj+DpmsEfzDiBhzCNZETkrnj4fVXs+knaTTxfQPv8WhhzWVARe1jKN8qBYdw2
DzuapzI2jEEejdrn+jD0P8OzA6SJvNvftoPvzB6WQoaR1RGTkNe8AkKd5HcAr7Kq
Qv/w/hu17FNnWaNzg11NJi+ujoKZcQXzPXVF+o5PyATMk6FqMG0tWeg2gKFz5cWz
vMtHGYwZu0Pt49Ad3i9+DbE1008DOsZhkRNpQ+ED6FbRyCqshZQyZQ==
=yP4d
-----END PGP SIGNATURE-----


from_name: Thomas Dalton

body:
> And when I figure out a way for it to only preload that template in the main
> namespace, I'm going to add it.

I don't know much about preloading templates in edit boxes, but could
you put an if statement in the template so it's blank if outside the
main namespace? {{if|{{{NAMESPACE}}}=""|<references>||}} or something
(I can't remember the syntax for if statements).


body:
> I don't know much about preloading templates in edit boxes, but could
> you put an if statement in the template so it's blank if outside the
> main namespace? {{if|{{{NAMESPACE}}}=""|<references>||}} or something
> (I can't remember the syntax for if statements).

I've looked up the syntax. I think it should be:

{{#if:{{NAMESPACE}}|| [your code here] }}


body:
> That would work generally but when you're talking about preloading, whatever
> is in the template source code is exactly what goes in the edit box; nothing
> is parsed, nothing can be commented out, etc.

In that case, you may have to ask the devs...


subject:
[WikiEN-l] [[Ecma Office Open XML]] and [[OpenDocument]] - good
	editors needed

body:
http://en.wikipedia.org/wiki/Ecma_Office_Open_XML
http://en.wikipedia.org/wiki/Talk:Ecma_Office_Open_XML

I've spent this evening working on press stuff relating to this. The
article is now at a much better (IMO) title. (I compare it to
[[JavaScript]] being the article about the Netscape/Mozilla version of
the language, but [[ECMAScript]] being the article about the
standardised version.)

Now it needs clueful editors who both know the subject area and
understand NPOV to keep it in order. We need to recover it from
advocates and anti-advocates and make it something informative for the
readers. You know how it is.

Mathias Schindler and I have been doing press about this, and also
talking to the Microsoft OOXML guys. Doug Mahugh from MS is on the
talk page, and does understand that editing the article himself would
be a conflict of interest and the talk page is the right place to edit
from.

http://en.wikipedia.org/wiki/OpenDocument also needs a similar degree
of attention.

With the amount of press attention this is getting, I expect both
articles to be features in a month ;-)

- d.


body:
On 23/01/07, Rune Kg <rune_kg at hotmail.com> wrote:
> Why wont this work?
>
> <gallery>
> Image:{{{1|default.jpg}}}
> </gallery>

A complete and utter guess, but we probably treat <gallery> as a
built-in parser hook extension, which means that the gallery building
code isn't passed text with parameters and so forth resolved.

Potentially straightforward to fix...

Rob Church


subject: [Wikitech-l] [MediaWiki-CVS] SVN: [19610] trunk/phase3

body:
On 23/01/07, leon at svn.wikimedia.org <leon at svn.wikimedia.org> wrote:
> * Added an option to make Linker::userToolLinks() show the contribs link
>   red when the user has no edits. Linker::userToolLinksRedContribs() is an
>   alias to that which should be used to make it more self documentating.

Oh, gross. Boolean parameters are horrible and meaningless less than a
month down the line when plastered all over calling code in this
fashion.

Rob Church


from_name: Platonides

body:
Jay R. Ashworth wrote:
> Someone vastly misunderstands the nature of copyright law, I think.
>
> (Though, admittedly, IANAL, either.  I just play on on the net.)
>
> If I create a screenshot of a browser page on my computer displaying
> wikipedia, there is *one* copyright involved: *mine*.  The image is not
> a derivative work of the browser, the OS, or the website.  Therefore,
> none of those people's copyrights apply, and therefore by induction, no
> licenses are necessary.  I created an image, and I own its copyright.

Then, why does commons interpret it otherwise?

http://commons.wikimedia.org/wiki/Commons:Licensing#Screenshots
Screenshots are copyrighted if the displayed program or operating system
is copyrighted. For a detailed discussion see
http://www.jisclegal.ac.uk/publications/copyrightalexmorrisson.htm


from_name: Andrew Gray

subject: [WikiEN-l] Uploading images

body:
On 23/01/07, Marc Riddell <michaeldavid86 at comcast.net> wrote:
> Everyone / anyone,
>
> Real quick, short question. Are their any copyright or other issues involved
> in uploading photos or other images from the Find-a-Grave site?

Photos on find-a-grave are, unless explicitly stated otherwise, going
to be copyrighted by the contributors with all rights reserved. There
are almost certainly copyright issues :-)

--
- Andrew Gray
  andrew.gray at dunelm.org.uk


references:
<eome6p$10k$1@sea.gmane.org>
	<20070123182904.GH4627@cgi.jachomes.com>
	<ep5sv2$4ur$1@sea.gmane.org>

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moin,

On Tuesday 23 January 2007 21:59, Platonides wrote:
> Jay R. Ashworth wrote:
> > Someone vastly misunderstands the nature of copyright law, I think.
> >
> > (Though, admittedly, IANAL, either.  I just play on on the net.)
> >
> > If I create a screenshot of a browser page on my computer displaying
> > wikipedia, there is *one* copyright involved: *mine*.  The image is not
> > a derivative work of the browser, the OS, or the website.  Therefore,
> > none of those people's copyrights apply, and therefore by induction, no
> > licenses are necessary.  I created an image, and I own its copyright.
>
> Then, why does commons interpret it otherwise?
>
>
> http://commons.wikimedia.org/wiki/Commons:Licensing#Screenshots
> Screenshots are copyrighted if the displayed program or operating system
> is copyrighted. For a detailed discussion see
> http://www.jisclegal.ac.uk/publications/copyrightalexmorrisson.htm

Does that mean if I take a screeshot of "gcc -v" it is copyrighted? What if
I copy & paste that text, is it still copyrighted?

*confused*

best wishes,

Tels

- --
 Signed on Tue Jan 23 22:15:03 2007 with key 0x93B84C15.
 View my photo gallery: http://bloodgate.com/photos
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Die deutsche Zensoren  - - - - - - - - - - - - - - - - - - - - - - - -
 - - - - - - - - - - - - - - - - - - - - - - - - - - - Dummk?pfe - - - -
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 - - - - - - - - - - - - - - -." Heinrich Heine

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRbZ7CncLPEOTuEwVAQLtBgf+I2M1XO+goahtgyH7a8GcmC1C1SXpeL5n
jsU7CS814w4bI7wxs2k/8Dx4wahFQLtLrQjMa08mD8/ho1BGHK1NGGtxTdCtNZb2
5IFE3RsTheUOMNJEDHIUa1prTniFKMYto2YTAFLyKf19/yU4i9AQV/RdRM9GapyG
zP8NGnYgxDspUDglPSmUThBr5sV3bonrzeJrGrH0YDtTlkQ8RaDhO+5C7xGtKONA
ZVKm7yxciu1XU+fiSYz4T1nGDm8L1iyBYvpGxloEfmusjr/Y+KDhdQYpFKgfWB6c
P2tEfvQbuhIuqI7sMnmV86V+8VaJAYMaeAzsM1FhqMeS9lt7JatN+A==
=KK+f
-----END PGP SIGNATURE-----


body:
Gregory Maxwell wrote:
> On this subject...  Wrapping the login site via SSL sounds like a
> dandy idea, and it sidesteps the whole mess of cert issues if with SUL
> we were to use a single login portal domain.
>
> However, then we've just pushed the problem back to session cookie
> theft.  Sure, it would still be an improvement since a passive
> attacker (at say Wikimania...) couldn't sit back and gather passwords,
> but better still might be possible.
A session cookie will expire. A password probably not, would allow to
change password, etc.

> What the current industry best-practices with respect to binding
> session data to a client's IP? Do web browsers switch IPs too often
> for this to be acceptable (AOL?)?
It could be less acceptable to normal users if each time they switch on
their computer had to type their password :S

Ideally, that sesion cookie would be a shared secret stored by the
browser, used to compute the (edit) tokens.
AFAIK this is unfeasible as today, unless you force a custom browser.

Another approach could be changing the session cookie too fast (e.g.
each 3-4 requests), so a cookie theaft couldn't reuse an old cookie.


references:
<eome6p$10k$1@sea.gmane.org> <ep5sv2$4ur$1@sea.gmane.org>
	<200701232215.54116@bloodgate.com>

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moin,

On Tuesday 23 January 2007 22:15, you wrote:
> Moin,
>
> On Tuesday 23 January 2007 21:59, Platonides wrote:
> > Jay R. Ashworth wrote:
> > > Someone vastly misunderstands the nature of copyright law, I think.
> > >
> > > (Though, admittedly, IANAL, either.  I just play on on the net.)
> > >
> > > If I create a screenshot of a browser page on my computer displaying
> > > wikipedia, there is *one* copyright involved: *mine*.  The image is
> > > not a derivative work of the browser, the OS, or the website.
> > > Therefore, none of those people's copyrights apply, and therefore by
> > > induction, no licenses are necessary.  I created an image, and I own
> > > its copyright.
> >
> > Then, why does commons interpret it otherwise?
> >
> >
> > http://commons.wikimedia.org/wiki/Commons:Licensing#Screenshots
> > Screenshots are copyrighted if the displayed program or operating
> > system is copyrighted. For a detailed discussion see
> > http://www.jisclegal.ac.uk/publications/copyrightalexmorrisson.htm
>
> Does that mean if I take a screeshot of "gcc -v" it is copyrighted? What
> if I copy & paste that text, is it still copyrighted?

NVM me, I just read the linked article instead of the very short summary you
pasted into the mail :D

best wishes,

Tels

- --
 Signed on Tue Jan 23 22:18:34 2007 with key 0x93B84C15.
 Get one of my photo posters: http://bloodgate.com/posters
 PGP key on http://bloodgate.com/tels.asc or per email.

 "The flow chart is a most thoroughly oversold piece of program
 documentation." -- Frederick Brooks, 'The Mythical Man Month'

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRbZ72HcLPEOTuEwVAQL7Igf9EF54Qq+Hk2+8o/MlaIUmm3Y7S2idax43
US3X5c18MUnVB55g9dcFNCvwYHjeh0Grysnb6lfYKY5cxeTgJLGZ5eYuc6J8Z/fO
+iaL/40W9UwJ3t+VipuHRsXet2Q3RUd3FzsaGPf7uQeFrzloQm+kANtepeUsoPEt
He9aQwFlZhqhPalnEwFSm/Jf+f3eAVNjkmOuCRVUYPtmrVH4+ZSbF5X91xfJIYLq
ioyt6LatjzoeY8ewnfY/zNoc5laNlg5VTDGHAxI5afOiXcaBHitWayiNukbV+u85
fVIoPxSAZBGFDhFqJu1YZaiA6DuBS7JbdyaArlfWVDB/HJxPeygGqA==
=3lOs
-----END PGP SIGNATURE-----


from_name: Jay R. Ashworth

body:
On Tue, Jan 23, 2007 at 03:40:16PM -0800, Stan Shebs wrote:
> Jay R. Ashworth wrote:
> >> http://commons.wikimedia.org/wiki/Commons:Licensing#Screenshots
> >> Screenshots are copyrighted if the displayed program or operating system
> >> is copyrighted. For a detailed discussion see
> >> http://www.jisclegal.ac.uk/publications/copyrightalexmorrisson.htm
> >>
> >
> > The terrible truth about laywers, courtesy of the late Mark MacCormack,
> > is that they'll tell you what's *safe*, not what's *reasonable*.
> >
> I'm pretty sure Apple is very proud of its Aqua widgets, and equally
> sure they'll be after you with a thousand lawyers if you try to claim
> their graphical designs are owned by you because they happen to be
> visible in a screenshot you made.

If Apple could find a lawyer who could successfully argue that, because
I was *exhibiting* a screenshot of an application that *happened* to be
running on a desktop managed with their icon set, that I was "trying to
claim their graphical designs are owned by me" -- such exhibition
simply *does* *not* make that claim.

>                                       If you successfully fend them off, let
> me know, I could use a bunch of textures, and clipping them from WoW
> screenshots will save me a lot of time, not to mention Blizzard's
> artists have better technique than I can muster.

And as an end-user, you can do with any of those things anything you
want to, as long as you don't try to distribute them, make money off
them, or explicitly claim them as your own.

Copyright and trademark law is what it *is*, not what inside counsel of
largr corporations *tell* you it is.  They aren't *your* lawyer, you
shouldn't rely on them.

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274