Hey @tom ,
Just to cover myself, this information is being provided in my personal capacity as a cybersecurity guy. This should not be taken as an official response from inSided, nor is it security advice.
Personally, I’d recommend just removing inSided from the entire app for security reasons. The inSided API is not intended to be used for something like this and if I were to crack open your app and grab the inSided API Key for your community, I could do a LOT of horrible things with it. The lack of reporting UGC would literally be the least of your problems - especially since that precious API Key would LITERALLY make me an unstoppable Super Admin.
My strongest advice is to remove all inSided related code and functionality from your app ASAP and revoke the inSided API Key you used to power the app with.
Once you know that ALL inSided code has been removed from the app, you can submit an updated version of the app to the Play Store and request an appeal/review to clear the policy violation. If Google is satisfied that there’s no further UGC in the app, they’ll grant the appeal and allow the update to go out.
Hey @Blastoise186
Personally, I’d recommend just removing inSided from the entire app for security reasons. The inSided API is not intended to be used for something like this and if I were to crack open your app and grab the inSided API Key for your community, I could do a LOT of horrible things with it. The lack of reporting UGC would literally be the least of your problems - especially since that precious API Key would LITERALLY make me an unstoppable Super Admin.
Ofc we have not been as stupid as to embed the insided API key into our app The latest community posts are provided by a service. The app simply asks the service for the latest posts via GET HTTP, the service is responsible for authenticating and responding with a list of the latest posts.
Ah ok, that’s good then. I’ve seen way too many people fall into that trap, it’s become my default stance for a lot of things.
I think this one might therefore sound like a good Idea suggestion. Are you able to access https://community.insided.com/ideas ?
Nope, I don’t have access to ideas.
Gotcha. It sounds like you are a verified customer but I’m not an inSided employee myself so I can’t verify your status or grant you the customer roles.
But I do know a few inSided staff who do have that power. Could I borrow some of it @Julian @Alistair FIeld ?
Thanks for looping me in here, @Blastoise186. @tom, welcome to our community and thanks for sharing your feedback. You should have access to our ideas section now. Could you post your request there please? I could also convert this to an idea, should you prefer this.
Will converting this to an idea will help get an estimate for when we’ll get this functionality in the API?
Hey @tom (great name btw ) - so i’m wondering if the following workaround works for your integration perhaps?
Content can be moved into a private category via the API with one of the move endpoints: https://api2-eu-west-1.insided.com/docs/community/#operation/moveArticle - this then mirrors how the platform works where 'flagged' content is moved into a certain category that only moderators + above can see.
The category just needs to have the appropriate permissions set where normal registered users cannot see the content.
Hi Tom
It’s a good idea, but I think it has a few downsides
- It doesn’t flow with the actual flagging workflow that we’ve trained our moderators on, so it would be another process to their already busy workload.
- It means a bad actor user could theoretically flag lots and lots of topics very quickly and make the forum very confusing where topics disappear.
- When you actually add the API method we need to make more changes
The above would work for “Block this post” but wouldn’t work for the “Block this user” as posts from the same user might still be visible.
Will converting this to an idea will help get an estimate for when we’ll get this functionality in the API?
Yes and no: While the product team surely will post a response and give some insights as to if and how we could be realizing this, they probably will not share a clear ETA before they actually have added it to their roadmap. We currently plan ahead roughly 3 months in advance (when it comes to specific features).
Due to the amount of requests & the way we plan ahead, it is impossible for them to make such an indication unless it is either super important for many customers & urgent. So you most likely will hear an ETA once the improvement will be planned as part of our development cycles.
Ok well I think if any of your other customers do a native app integration they will hit the same app store rules as us. I hope this helps with your prioritisation decisions
Hi @tom
Without going into the already discussed inSided functionalities, wanted to zoom a bit into that Google message.
- Provides an in-app system for reporting objectionable UGC and users, and takes action against that UGC and/or user where appropriate;
- Provides an in-app system for blocking UGC and users;
To me this does not imply that the resulting action has to be automated. So the following might be enough? A button to report, which send an email to moderators, which triggers a manual review within 48 hours.
@bas Hey, in terms of what they actually mean, I can only point you towards the policy itself and this single page course which outline what they expect the functionality to do.
Inside that course it outlines
-
Allow users to flag or report other users for potential violations.
-
Allow users to flag or report potential violating content.
-
Allow users to remove or block abusive users or users in general for any reason.
Certainly the flagging and reporting can have a manual follow up, but we have taken the “remove” and “block” to mean that as I user once I’ve blocked it then I shouldn’t see it anymore. That’s certainly the way that larger social networks work.
I don’t disagree with your assessment, just wondering if there is a quickwin for you to not get the app removed :)
The “quick win” has been to removed insided from our apps, which is obviously not ideal for our users
Ok well I think if any of your other customers do a native app integration they will hit the same app store rules as us. I hope this helps with your prioritisation decisions
Of course I agree that this is quite relevant for our prioritisation. We’ve already flagged this to our product team, so that they are aware of it.
Hello,
Just to follow up, do I need to do any more to make sure it’s in the future consideration, does this post need to be officially converted to an “idea”
Thanks
You could create and Idea if you’d like to. :)
It might actually be worth doing so that regulars like myself have something to refer to (and you get credit for it!)
Ok, I guess I’ll copy and paste the issue again then