Page MenuHomePhabricator

Anonymous access to pads
Closed, DeclinedPublic

Description

Author: clement

Description:
If a page can be edited by anybody, it should be the same for the relative pad(s). There is a huge UX gap between:

  • clicking a link to a page and starting to collaborate
  • clicking a link to a page and starting to write and understanding this is not real time collaboration and asking around and finding out registration is necessary and registering and coming back to the page to finally start collaborating.

Version: unspecified
Severity: enhancement

Details

Reference
bz39425

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:54 AM
bzimport set Reference to bz39425.
bzimport added a subscriber: Unknown Object (MLST).

I think this is a question of the following:

  1. Can I handle conflicts in usernames on the Etherpad side?
  2. Can I still provide an appropriate way to deal with vandals (especially in the context of bug 39424, where we suggest only having one session per page)?
  3. Even if the answers to the above are "yes", is it unreasonable to assume that people who are interested in collaborating will have an account anyway, or at least willing to get an account so they can collaborate?

If the answer to any of those questions is "no", I think we'll stick with the current system. If we can come up with a way around each of those issues, maybe I can do anonymous authentication.

clement wrote:

I see your points, I think my use cases differ from the project's.

1.1. Yes. I would imagine using the user's IP as it's done now for regular edits.
1.2. No. Duplicate IP... will be a pain but I optimistically hope Etherpad already handles conflicts.

2.1. Yes. As all sessions (1..N) still remain public, vandalism can still happen whatever the case.
2.2. Yes. Creating an account takes few seconds (assuming the vandal is used to vandalism, which is the majority) compared to the delay to recognize and block a vandal.
2.3. Yes. Blocking a user usually involve blocking its IP too.
2.4. Yes. Pad vandalism has few interest compared to the regular reason for vandalism (SEO, ads, rewriting history...).
2.5. No. A bot spamming all the opened pad to display live ads could be of some value. But I doubt the developers of such a tool would struggle with automatic signup long.
2.6. No. Nothing can beat the autoconfirmed group which is hard to join for vandal.

3.1. No. If you see pads as an advanced feature that the elite use for high end collaboration.
3.2. Yes. If you see pads as a cool feature that finally makes mediawiki dynamic and fast. A feature that enables confirmed users to invite newbies and show them how fun mediawiki can be. A feature that enables everybody on the planet to talk lively, freely, and easily.
3.3. No. I got carried away. It might be easier and more realistic to evolve from a solid elite tool.

I'm sorry my answer is long and not very helpful. I understand anonymous authentication is a lot of work. I just hope it will be developed one day.

For 1, I have added a test for this in my list of things for today's stress test.

For 2, currently the session admin (whoever created the session) can kick users who are trouble. So there is *something* to be said about the current method. I guess I can see that there's less motivation for vandalism, though. Hm.

For 3, I think your .1 and .3 are a bit more valid, but I can definitely see that, in the future, .2 has a lot of merit. I'll keep it in mind for the future, I guess :)

Don't worry about long answers, it was interesting and very helpful that you hashed out your ideas. Thanks very much.

Dzahn added a comment.Aug 9 2013, 11:08 AM

I have always wondered how an IP address is supposed to be more anonymous than a pseudonym.

Aklapper lowered the priority of this task from Low to Lowest.Jan 16 2015, 6:52 PM
Aklapper added a subscriber: Aklapper.
MarcoAurelio closed this task as Declined.Jun 21 2018, 11:05 AM
MarcoAurelio added a subscriber: MarcoAurelio.

Mass-declining open tasks for EtherEditor per T197698: Archive the EtherEditor extension.