Re: [Wikitech-l] Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)
On Fri, Jul 24, 2009 at 2:52 AM, Brianna Laugherbrianna.laug...@gmail.com wrote: 2009/7/24 Aryeh Gregor simetrical+wikil...@gmail.com: On Thu, Jul 23, 2009 at 2:20 AM, Brianna Laugherbrianna.laug...@gmail.com wrote: All the potential problems posed are ones that Wikipedia faces every day just because it lets people edit, period. I don't see how doing it via an API adds some massive new risk. Well. If you had some way to clearly distinguish which automated tool made the edit, Yay! I dunno, a third input box name=botname? input type=hidden name=botname / -- -- ℱin del ℳensaje. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)
On Fri, Jul 24, 2009 at 2:23 AM, Teioscar.vi...@gmail.com wrote: I dunno, a third input box name=botname? input type=hidden name=botname / I'm talking about in the case of a possibly malicious service, and only if it's using OAuth (or whatever). Presumably if it's using OAuth the user already gave it some unique identification token that we can just revoke, so I don't think the hard part here would be the identification itself. The hard part would be the rest: making it immediately obvious to everyone that a given change was made through a specific web service, and allowing admins to block such services easily. And implementing something like OAuth to begin with. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Watchlistr.com, an outside site that asks for Wikimedia passwords
On Fri, Jul 24, 2009 at 2:24 AM, Tim Starlingtstarl...@wikimedia.org wrote: There's plenty of ways to attack watchlistr without fully compromising the server. The point is that a system that allowed stealing the logins of hundreds of Wikipedia users if you managed to compromise a third-party website run to unknown security standards is unacceptable. *Even* if it's set up so you really do have to be able to run arbitrary code as the web user to get the data -- and in this case security appeared to be even lower. Malice is also a concern in the general case, although it might not be a concern here. So any solution that allows either of the following is unacceptable: 1) The compromise of a(n additional) third-party party run to unknown security standards could result in many Wikipedia user accounts being taken over. 2) A third party becoming malicious could result in many Wikipedia user accounts being taken over. Hopefully my watchlist-reading code will be deemed acceptable. I'm reminded (by Domas, of course) that watchlists are actually a very expensive operation, so I wouldn't be entirely surprised if this gets $wgMiserModed away before or shortly after deployment, when users start requesting 400 wikis' watchlists every fifteen minutes. I wish there were some good solution to this. How do other sites handle giant numbers of users watching changes to zillions of pages? Throwing hardware at it? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)
On Wed, Jul 22, 2009 at 10:05 PM, Brianna Laugherbrianna.laug...@gmail.com wrote: [snip] I can imagine someone building an alternative edit interface for a subset of Wikipedia content, say a WikiProject. Then the interface can strip away all the general crud and just provide information relevant to that topic area. Sweet. I look forward to the bright future where I can create an enhanced AJAX edit-box for MediaWiki then throw it up with a bunch of ads and private-data-collection and avoid the pesky problem of open sourcing my code and contributing it back to the MediaWiki codebase in order to get it widely used. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Speak up people
On Fri, Jul 24, 2009 at 10:05 AM, dan nessett dness...@yahoo.com wrote: So far no one has responded to Brion's comments about how parserTests should be modified. You are the customers. What do you want? My two cents: Remove the chronically failing tests and file them as bugs in bugzilla. As each bug is fixed, its corresponding parser test can be put back in. -- Remember the dot http://en.wikipedia.org/wiki/User:Remember_the_dot ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)
2009/7/24 Gregory Maxwell gmaxw...@gmail.com: On Wed, Jul 22, 2009 at 10:05 PM, Brianna Laugherbrianna.laug...@gmail.com wrote: [snip] I can imagine someone building an alternative edit interface for a subset of Wikipedia content, say a WikiProject. Then the interface can strip away all the general crud and just provide information relevant to that topic area. Sweet. I look forward to the bright future where I can create an enhanced AJAX edit-box for MediaWiki then throw it up with a bunch of ads and private-data-collection and avoid the pesky problem of open sourcing my code and contributing it back to the MediaWiki codebase in order to get it widely used. This is again something that OAuth can help with. Applications have to register with the service provider before they start using OAuth the API. That gives the service provider an opportunity to set certain requirements, such as 1) the application must be open source and/or 2) the application must not do certain things such as collect XYZ data. You could also require applications to not have any ads, although I don't feel we have a moral obligation to protect our users from advertisements from API-using applications. As for contributing back to MediaWiki (implicitly for use on Wikimedia sites), as I said before, there is necessarily a high barrier to having an extension enabled on a Wikimedia site, and something of a requirement of general across-the-board usefulness (rather than only being applicable to one topic area, as an example). Toolserver apps are an example of how interesting and useful things can be separate to MediaWiki and complement it. There are also other third parties such as Wikiscanner, Wikirage, WikiDashboard, WikiChanges, WikiMindmap and WikipediaVision, to name a few. That is the bright present. Brianna -- They've just been waiting in a mountain for the right moment: http://modernthings.org/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
