On Mon, Aug 10, 2015 at 6:23 PM, Gergo Tisza wrote:
> tl;dr should OAuth [1] (the system by which external tools can register to
> be "Wikimedia applications" and users can grant them the right to act in
> their name) rely on community-maintained description pages or profile forms
> filled by app
As many OAuth tools are semi-automated, they're prime candidates for being
interesting ways to help our most active users make contributions on mobile
devices while they're on the go. The OAuth workflow is pretty poorly
designed for this at the moment, but it has a lot of potential.
Generally, mob
On Tue, Aug 11, 2015 at 11:11 AM, Legoktm
wrote:
> I assume these wiki pages would be some kind of structured
> ContentHandler pages? We could restrict editing those fields to the
> application owners then?
>
By wiki pages I meant wikitext pages. I think in terms of benefits and
drawbacks Conten
OK, this sounds like a level of sensitivity greater than what I think is
appropriate for a standard wiki page, and possibly greater than for
standard admin "full protection". If Special:* is the only or best way to
achieve that, so be it.
Pine
On Tue, Aug 11, 2015 at 2:11 PM, Gergo Tisza wrote:
To refocus the discussion on OAuth (no superprotect and copyright issues
here please :), the field with legal relevance is the privacy policy of the
application (and maybe its terms of service if we add such a thing in the
future). Any time you use, say, CropTool, the tool operator has access
to ch
I'm not sure about that, but let's take the Superprotect discussion to a
different thread if we're going to continue on that subject. (:
Back to the subject of Oauth. Legoktm assuming that Superprotect isn't
applied, can you think of a way to protect the relevant pages in wiki page
format that wou
Well, therein lies the problem. If a "community" goes rogue, and wants to
selectively change the copyright terms for their project, stewards (under
the current standards of behaviour) would pretty much be obligated to do
that - even though it's contrary to a lot of other things. We can't put
volu
Yeah, the same thought crossed my mind. Unfortunately, superprotect has
such a well-earned negative reputation in the community that I don't think
it will ever be welcomed even in situations like this where it might be
sensible. An alternative might be to devolve the superprotect right to
stewards,
Il 11/08/2015 20:10, Risker ha scritto:
On 11 August 2015 at 13:07, Mr. Stradivarius wrote:
On Wed, Aug 12, 2015 at 1:44 AM, Pine W wrote:
Would keeping sensitive pages in wikitext format under "full protection"
(meaning that only local administrators can edit) be sufficient?
This is aski
Hi,
On 08/10/2015 06:23 PM, Gergo Tisza wrote:
> tl;dr should OAuth [1] (the system by which external tools can register to
> be "Wikimedia applications" and users can grant them the right to act in
> their name) rely on community-maintained description pages or profile forms
> filled by applicati
On 11 August 2015 at 13:07, Mr. Stradivarius wrote:
> On Wed, Aug 12, 2015 at 1:44 AM, Pine W wrote:
>
> > Would keeping sensitive pages in wikitext format under "full protection"
> > (meaning that only local administrators can edit) be sufficient?
> >
>
> This is asking for trouble. Even if all
Ok, it sounds like using a Special:* for OAuth info would be prudent.
That's unfortunate for usability reasons, but the security considerations
appear to be more important.
Pine
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wi
On Wed, Aug 12, 2015 at 1:44 AM, Pine W wrote:
> Would keeping sensitive pages in wikitext format under "full protection"
> (meaning that only local administrators can edit) be sufficient?
>
This is asking for trouble. Even if all our admins acted sensibly all the
time - and if you've been aroun
Given that MediaWiki namespace pages are already admin-only, not really.
On 11 August 2015 at 12:44, Pine W wrote:
> Would keeping sensitive pages in wikitext format under "full protection"
> (meaning that only local administrators can edit) be sufficient?
>
> Pine
> On Aug 11, 2015 9:38 AM, "Oli
Would keeping sensitive pages in wikitext format under "full protection"
(meaning that only local administrators can edit) be sufficient?
Pine
On Aug 11, 2015 9:38 AM, "Oliver Keyes" wrote:
> I am familiar with other incidents myself, and would not consider
> moving away from the existing system
I am familiar with other incidents myself, and would not consider
moving away from the existing system "premature optimization". I would
consider it "sanity". We exist in a situation where wikis can
individually customise, say, the copyright release associated with
edits. Changing that is A Good Th
On Mon, Aug 10, 2015 at 11:43 PM, Pine W wrote:
> We currently have editable pages on Wikimedia sites with important legal
> strings, and AFAIK no one has caused a noteworthy incident by editing or
> vandalizing them.
There are several cases that I'm aware of where legally-significant text
was
We currently have editable pages on Wikimedia sites with important legal
strings, and AFAIK no one has caused a noteworthy incident by editing or
vandalizing them. (Cc'ing Maggie to ask for verification.) However, the
term "attack vector" gets my attention. Is there a way to keep the pages in
wiki
tl;dr should OAuth [1] (the system by which external tools can register to
be "Wikimedia applications" and users can grant them the right to act in
their name) rely on community-maintained description pages or profile forms
filled by application authors?
---
Hi all,
I would like to r
19 matches
Mail list logo
