I would suggest against it. If we have them, then we could be responsible for anything that happens with the account. With the SE API, there are some limits. For instance, we can't do things like change the login credentials for the account. It's a whole other level of security risk for just the benefit of retracting flags. Some people, who have chosen to have low autoflag conditions, eating a small number of declined flags isn't that bad.
If it's really that big of a deal, we can have a userscript/extension which retracts the flags when it sees that FP/NAA feedback is given on a post the user autoflagged.
[ SmokeDetector | MS ] Bad keyword in body, bad keyword in title, link following arrow in body, pattern-matching product name in body, pattern-matching product name in title, +4 more (593): How To Use Bio X Keto Diet Supplement? by Jones Michalse on communitybuilding.SE
@Makyen Problem is, much as we'd like it to be otherwise, those are still 'Charcoal flags'. Skeptical site mods don't see "someone asked the system to flag iffy stuff", they see "the system flagged iffy stuff"
Seems like there's a way somewhere to hit a practical 0% autoflag FP rate, since we're fast at classifying these
ideally, we wouldn't worry about this at all and instead get a better classifier.
@Undo MS having the Smokey credentials, in some semi-secure way, is within reason. Doing so has significantly less security issues than holding credentials for multiple users. Unfortunately, you'd need to hold the actual credentials in a way that MS could access them in plain text, because MS has to send them to SE. While the credentials might be encrypted when stored, the ability to decrypt has to exist within MS, which means that an attacker has that capability if MS is compromised.
@Makyen There's a way around this, that I've wanted to build for tokens since forever: Run a separate service, accessible only by MS over the network, that supports exactly two operations: (1) add credential, (2) do [thing] with credential.
Define [thing] to include only the stuff you know you want - casting and retracting flags - and metasmoke doesn't need to (and can't) know secrets.
Esp. in an environment with multiple developers and deployers, it's probably good to do something like that.
Really not concerned about that aspect. Put up a big scary red thing, if SE actually complains (they wouldn't), we say "awesome, please add this minor thing to the API"
You can enter the following in the console to wipe FIRE's localStorage values and start over: localStorage.removeItem('fire-user-data'); localStorage.removeItem('fire-user-sites'); localStorage.removeItem('fire-sites');
And re-load all pages/tabs which currently have FIRE running.
For a project I'm working on, it'd be nice to be able to retract flags through the API.
We allow people to retract flags from the web. Could this functionality be extended to the API? It could work such that you receive a 'Retract Flags' option on calls to /questions/{id}/flags/options, then pas...
@DavidPostill As @ArtOfCode has mentioned, similar things have been reported by users of various security/privacy extensions. IIRC, privacy badger has definitely been the culprit for some users, but there have been others which have caused problems by blocking requests. Was your testing from typing in the URL to the URLbar, or from JavaScript in the console?
Looks like NobodyNada/Raspberry Pi has been operating fine in standby for about an hour now, which indicates that it's not experiencing the problem which was causing the other SD instances to come out of standby. However, it's running a very old version of SD (Jul 26). Unless the problem is generally gone on the MS side, that it's working correctly on an old version of SD tends to indicate that it was a recent change to SD which is causing the problem.
This could easily be tested by bringing NobodyNada/Raspberry Pi out of standby and !!/pulling the current version to check if it exhibits the problem that the other instances were. However, I'm unlikely to be ale to actually resolve it and we humans/developers tend to like to see examples of the problem ourselves, so someone who knows Python and could fix the problem should probably perform that test. (cc @iBug)
@iBug Given that it's easy to test, it seems like it would be a good idea to just test. If we do, then we can be sure it's A) not still happening and B) not due to a change in SD's code. If it's not still happening, then can bring up all the other instances.
The best way to test would probably be for you to bring up your instance and see if it stays in standby. If yours stays in standby, then it's not happening. If yours continues to repeatedly comes out of standby, and NobodyNada/Raspberry Pi doesn't then it's in SD's code, or some other difference between the two instances.
@Machavity You are not a privileged user. Please see the privileges wiki page for information on what privileges are and what is expected of privileged users.
@Makyen That pattern looks like it's already caught by Pattern-matching website in body and Pattern-matching website in answer; append -force if you really want to do that.
CI on 2f2cfbe succeeded. Message contains 'autopull', pulling...
@WELZ Yes, but we were discussing if the post was FP or TP. The difference was that @Machavity was calling it TP because he felt it had been seen before. I was calling it FP, because it looked like this was just the first case of the user asking for something on their site. Thus, to me it just looked like a bad question.
