Flag from Chat implementation

[magisch]

Based on a chat conversation starting here

I propose new functionality for FDSC (or a new userscript that works like FDSC and does this) that:

1. Adds a button to Smokey reports in chat.
2. On clicking that button, pops a confirmation dialog (optional)
3. When confirmation is obtained, casts a spam flag against the post in the report, using the SE Api
4. Sends tpu- feedback to Metasmoke in the same way FDSC does.

Reason for this FR:

In an exceeding number of cases, the fact that a report is spam is super obvious even from the title and chat message. If a report trips 8 filters and starts with "Celesta Male Enhancement" there is no possible way that that report could possibly be a FP. Having a "Flag and feedback this from chat" button would be nice to save time and the work of opening an obvious spam post before flagging it.

Would have to be subject to caution, though.

Also helpful for those of us who don't want to visit certain SE sites (like gaming.SE) at work, if we had a button from chat (could still view the post on MS).

Some examples of reports for which this would be exceedingly useful (Posts where you really don't need to open them to know they're spam):

[ SmokeDetector | MS ] Bad keyword in body, bad keyword in title, link at end of body, pattern-matching website in body: Fall Skin Care Tips For Dry Skin by flahertyianae on drupal.SE

[ SmokeDetector | MS ] Bad keyword in body, bad keyword in title, blacklisted website in body, link at end of body, pattern-matching website in body: The antiaging remedy properties of these substances by jakgafoyici on askubuntu.com (@ThomasWard)

[ SmokeDetector | MS ] URL in title, bad keyword in body, bad keyword in title, pattern-matching website in body, pattern-matching website in title: quicksupplementfact.com/testo-ultra-es/ by eyemr kipa on apple.SE

[Cerbrus]

Case in point:

One doesn't need to open that to know that it's a TP. It'd be very convenient to be able to flag & feedback that at the press of a button (with confirmation to catch accidental clicks)

[ArtOfCode-]

I'm reluctant to do this. Yes, there is plenty of spam that can be solidly identified from the title alone. But, should anyone ever take objection to our work, we can still say "humans look at every post" - which may not be true with this implemented.

Open to discussion, though. Thoughts?

[magisch]

@ArtOfCode- Humans do look at every post, even with this. Some human consciously decided after seeing information on a post to flag it as spam. Maybe you could implement this only working for posts hitting at least 150 score or something, although that'd complicate things. Maybe make this not available to absolutely everyone.

Comes down to: Do you trust flaggers in this room to not misuse this?

[Cerbrus]

@ArtOfCode- @honnza had an idea for that:

"add the post body into the confirmation dialog"

Which would significantly increase the complexity of the confirm dialog, but would make users look at the post.

[ArtOfCode-]

@magisch I trust Charcoal people, yes. I don't trust meta-type people. "But how can you tell if it's spam without looking at the post?! You're making decisions that could apply penalties to legitimate users because their title looked weird!!1!11!eleven" We know it ain't true, but it wouldn't take a veteran meta-lawyer to at least spread some concern.

@Cerbrus @honnza This idea, I like.

However it's done, this should probably be a new script rather than FDSC - FDSC is all about the flag dialog, so this might be scope creep.

[j-f1]

Maybe call it FIRE: Flag Instantly, Really, Electronically — that way there’s AIM & FIRE.

[ArtOfCode-]

Alternatively, you can have Flag Integrations for Relays Electronic

[Cerbrus]

Fairly Instant Reduction Effort

[ArtOfCode-]

For Immediately Removed Effluent

[j-f1]

We could also do what the people who invented UTC did:

Coordinated Universal Time (French: Temps universel coordonné) [is] abbreviated to UTC ^source

It makes no sense in any language now.

[angussidney]

I'm sorta against this for the same reasons as @ArtOfCode- - we don't want to be labelled as a flagging ring who flags without looking at things.

If we do end up making a userscript to do this, at least require the post to reach the default autoflagging threshold 280.

[Undo1]

I'm also probably against doing this from chat, but I have considered sending manual flags from metasmoke. For me, a metasmoke pageload + 1 click is much faster than an SE pageload + 3 clicks to flag (or keyboard shortcuts, which I always get messed up on anyway).

[honnza]

The next step would be to display said metasmoke page in a pop-up rather than a separate tab

On Wed, Feb 22, 2017 at 9:55 PM, Parker Erway notifications@github.com wrote:

I'm also probably against doing this from chat, but I have considered sending manual flags from metasmoke. For me, a metasmoke pageload + 1 click is much faster than an SE pageload + 3 clicks to flag (or keyboard shortcuts, which I always get messed up on anyway).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Charcoal-SE/userscripts/issues/43#issuecomment-281800718, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwF_bQ8tpE592825vREuMH1diMVeaf7ks5rfKDDgaJpZM4MIakm .

[Cerbrus]

@Undo1 / @angussidney: Wouldn't those concerns be covered by:

"add the post body into the confirmation dialog" (https://github.com/Charcoal-SE/userscripts/issues/43#issuecomment-281635698)

[angussidney]

@Cerbrus Even still, for posts with lower weight, context is everything.

[Cerbrus]

This FR is more intended for the obvious spam that really doesn't require a page load, @angussidney. So, if there could be a weight requirement before the button is available, that would pretty much cover the concerns here, I think.

[JC3]

Not that I have much say here, but I share the reluctance expressed above. No matter the intent, if the button is present, it will be pressed. So adding a weight threshold seems to mostly fix that (or make it use the same criteria as the auto flags, that seems to make the most sense).

That said it doesn't seem like there's a problem with having enough people to get rid of posts, does it? If you don't want to visit the site somebody else will probably get it, especially after that Smokey meta post attracting more people. It's been shown already (in that post) that deletion times are at record lows so it doesn't seem like there's real motivation for any added slightly-risky convenience. I mean sure having to visit the site for obvious spam is inconvenient but is it hurting the system as a whole?

[Cerbrus]

^{(First of all, I'm sorry if this comes across as aggressive. I'm a nice wolf, I'd just really like this ;-) )}

So, even if there's a weight restriction, and the popup renders the reported question /A, that still doesn't cover it? There doesn't need to be "something hurting the system" for a feature request to be valid. This isn't about getting rid of spam faster, this is just for the user's convenience.

Open in a new tab -> Open flag dialog -> select "spam" -> Enter -> Close tab, or Open in a new tab -> MF1Enter -> Close tab Versus Open dialog with reported post -> Select "accept" (/ "reject" for false positives)

If people abuse this, it is their SO accounts that will receive a flag ban. As @angussidney explained in chat, invalidating all of a user's feedback is relatively trivial.

---

Now, for the constructive part:

I was thinking of writing a separate userscript specifically for this feature, so it has a separate API key which could also be revoked from MS's side. A separate userscript would require implementing the parsing of smokey's messages again. As a workaround, I figured it might be possible to allow separate userscript to register event handlers in AIM.
This would mean the new userscript would only have to add the button, popup and related events, without having to worry about (/re-implement) parsing SD reports, preventing code duplication. However, that would create a dependency on AIM, which opens yet another can of worms...

Altogether, I think we can secure this enough.
We could even limit it to only be accessible after feedback has been provided by someone. That way, you'll always have user feedback before anyone can use the "convenient flag" dialog.
(That user feedback could still be a blind "tpu-" from chat, but at least there's plenty of transparency there)

Sure, it takes some effort to implement, and sure, it's all just for convenience. But it'd be awesome :D

[JC3]

By the way, regardless of anything else, you'd never want to show such a button for answers, since they display the title of the question in the message, which is not the post of interest.

[j-f1]

@Cerbrus You can just set a new attribute on autoflagging.decorate:

/*!
 * “Spec” for methods of autoflagging.decorate:
 * Takes an element to update.
 * data is from the API.
 * Properties:
 * * location [required] ("before" | "after") Where to add the element if it
 *   doesn’t exist
 * * key [optional] The key that must be present on the data. The value of
 *   this key is passed as the second parameter.
 * * el [optional] the name of the element to create.
 */

^source

[magisch]

@Undo1 I'd very much like an implementation from MS too. Have a "Flag as spam" and a "Flag as Abusive" button show up on MS pages that aren't recorded deleted yet. Would save us from actually visiting the spam.

[ArtOfCode-]

@magisch That can be done; pretty easy, actually, since we already have write tokens.

[magisch]

@ArtOfCode- This could actually be of tremendous use to people, for a few reasons:

• SE appends question titles to urls, so some people refrain from clicking questions "Alpha Testo Force ProX" or something to avoid having that in their browser history. "metasmoke.erwaysoftware.com/posts/208584" is super innocous by comparison.

• Metasmoke frequently loads faster then SE does, especially when not using adblock, due to bouncing advertisements.

• When loading the post on MS, you get more information, like hidden links and reasons why it was caught. This is why sometimes people open the MS link on posts they're not sure about. This eliminates that extra step.

[Cerbrus]

@j-f1: I figured out how to "Extend" AIM, from your comment earlier, basically:

autoflagging.decorate.fire = function ($fire, data) {

How can I tell if the reported post is a question or a answer, from data? (Aside from manually parsing the link's contents)

[j-f1]

@Cerbrus There’s no way AFAIK. You could either post a feature-request on metasmoke or search for /a/ in the link.

[ArtOfCode-]

metasmoke does it by looking for /a/ in the link, so you might as well do that in client-side code

[Cerbrus]

Yea, that's what I'm doing now, @ArtOfCode-.

I've worked on the userscript for this a little.

[Cerbrus]

Since 🔥 FIRE has come alive, This issue can probably be closed, right?