Making WordPress.org

Opened 3 years ago

Last modified 3 years ago

#5937 new enhancement

Extend the possibility for leaving a plugin or theme review

Reported by: clorith's profile Clorith Owned by:
Milestone: Priority: normal
Component: General Keywords:
Cc:

Description

Disclaimer: This is for sharing an extended idea, and is not an absolute solution, or implementation guide.

Now that we've got the formalities out of the way, currently to write a review for a plugin or theme on WordPress.org, you need to create an account, this is fine, but since WordPress.org does not have SSO (Single Sign On), it means users need yet another account, this is a barrier for many.

With the addition of Application Passwords, we could investigate other avenues to help plugin and them e authors encourage reviewing their solutions, there are pros and cons to this of course, which I'll get back to shortly.

If an anonymous user goes to write a review, ask them for their WordPress website URL as well. When the review is submitted, it would then be possible to validate their site, _and_ that they have the plugin or theme installed before leaving a review. After the validation is done, the token should be removed from WordPress.org, as there's no scenario where we would want to sit on the potential access to who knows how many sites.

One drawback is that anyone leaving a negative review is unlikely to have the plugin or theme still installed, I think the contrast could be drawn that they'd then not have a problem making an account to share their disapproval in the first place.

Alternatively, the app password request could be used to authenticate against a website, grab their account e-mail, and use it as an avenue to create (and approve) their account with WordPress.org in as smooth a transition as possible.

Regardless of approaches, it would need to pass through abuse detection of some form, like anything else, what options do we have to prevent abuse here? Anyone can spin up a WordPress site fairly easily these days, what potential abuse do we envision, and how do we work against each of these?

This could be used to signup under temporary emails we would normally filter out.
Any normal signup flow precautions should be applied like before

Someone could spam reviews for plugins or themes via single use sites.
Should we detect high activity on plugin or theme reviews/forums in the first place to trigger a "slow down" or similar for ensuring nobody is being targeted? (probably a different ticket, but a potential fix)

Those were two quick thoughts to get the discussion rolling.

Change History (1)

#1 @dd32
3 years ago

This is just me thinking aloud, nothing solid or set in stone here, there are a number of things related to this that I've removed as unrelated.

Regardless of how it's implemented, this is something that I've talked with various people over the years multiple times, many plugins/themes get next to no reviews, which negatively affects WordPress.org's ability to use review data for ranking/search/sorting/highlighting purposes.

We could also benefit from it for things like Blocks, Patterns, and Photos shown directly within the editor where we'll unfortunately need a way to allow someone to flag/report items directly from their editor instance, even if they don't have a WordPress.org account.

There are a number of ways we could offer this including:

  • oAuth flow against their site, which potentially means us having an access token for their site temporarily..
  • Private .org API which allows a WordPress site to submit reviews/flags about an item, with a callback built in so that .org can verify that the site who is who it said it is.
  • Private .org API which is the same as above, but returns a special URL which can be presented to the user in an iframe, allowing them to review an item:
    • (Name + Email or Login button) + Site (hard-coded) + Item (plugin X, hard-coded) + Review Text
    • For "high risk" reviews/browsers/whatever it can then go to pending + email confirmation
    • if it's deemed "low risk" published as-is until flagged by someone (effectively, public unless anyone logged in says "uhh" at which point it goes to modlook)

Now that I think about it more, the final option there is probably the most ideal for a review, while the second is probably the best for a "flag this item" action.

We have some flags we can use here, not all of which will be super helpful..

  • Whether the site has submitted reviews before, Whether the Name+Email provided has submitted them before, etc.
  • reCaptcha is in use on WordPress.org login, but misses a bunch of things. If we had an iFrame that the review was submitted through we'd be able to validate that.
  • On login, we have some heuristics around email addresses, manual blacklists, and a few other tools which could be leveraged. That would allow extra heuristics to be applied to what will effectively be a public "comment" that's not as easily accessed as comment forms..
  • Akismet, since as I just realised, it's effectively a comment..
  • WordPress.org stats can probably give some kind of "Is Site URL A in good standing" based on how long the site's hashed ID has existed, there's bound to be some clashes but few enough to matter.
Note: See TracTickets for help on using tickets.