bchimp's comments

This assumes we blocked people for no reason just to engage them, or that there was some automated blocking or something. At the time, all this stuff was manual, so once someone was blocked, it was because there was a real problem.

Now, every once in awhile we would get the "johnny logged into my computer and did it, not me." For technical and privacy reasons, we can't really block people, just computers. So, ya, they stayed blocked.

Is it perfectly fair? Nope. But simplifying a TOS definitely cut down on arguing with people, which was a win for us.

The paper (and I only read the abstract) is interesting, but as others have noted, fairly obvious.

One thing that seems to be an assumption is that the "company" needs to provide the explanation. I think it is even better if the user provides the explanation. The assumption a user can't provide it is probably because we've all seen Terms of Service agreements that are totally opaque.

Back in the day when I was doing a bit of admin work, I decided to simplify our TOS, and then when I had to block someone, I just kicked the ball back into their court: "If you would like your account restored, please point out in the TOS what rule you violated." It worked better than expected. People that cared enough about their access to the system usually figured it out pretty quickly, and we got the knowledge that they actually read the TOS to some degree. They got their account restored and that was the end of it. Repeat offenders at that point were willfully causing problems, so we just left them blocked.

Obviously this only works if a human can understand your TOS. Another interesting line of questioning might be "at what complexity level is your TOS useful in shaping behavior and where does it just become a legal shield."

Even Apple, with its distaste for background processing, lets you declare an app with "VOIP" mode or something, where iOS manages the socket for you. You get access to simple server-based signaling, and as a bonus, you get to avoid the whole push-notification system.

Google just seems to have glommed everything into FCM. In the FCM console, push-notifications are really treated as a user-engagement/advertising thing. Throttling and spam prevention makes sense for that.

Maybe Android has something like the iOS VOIP mode that doesn't involve annoying the user with scary battery notifications, but I couldn't come up with anything at the time.

For my use case, the volume of messages was not an issue. This isn't a huge app that is pushing out tons of notifications. We're talking 10's or 100's a day, maybe.

In fact, it didn't matter at all once the initial notification was visible whether follow-on notifications were displayed. Possibly the fact that I was locally dropping the notifications (because the user didn't need them), the system counted those as "notification that weren't interacted with, so I'm going to slow you down at the server."?

I have no idea, and no way to find out, since FCM is pretty opaque at this point.

I agree, it isn't normal, and I was scratching my head at the time as to why FCM would deliver the messages near instantly on older android models. The delayed delivery happened on Oreo+ phones. Oddly, I also noticed Whatsapp not delivering messages in a timely fashion (even when I had it opted out of battery saving). Background notifications in general started acting odd for Oreo+ phones.

> There's not enough context here ...

Sadly, actually getting context you can use to debug something like this from FCM is nearly impossible. The end result is you just take a WAG and hope for the best when the app gets in the field.

This has been true for awhile once they forced apps to use API26 or higher (if you want to be listed in the Play store, and really, there is no other place if you want decent exposure.)

I had a similar experience switching from "real background" to using FCM. I understand the battery saving motivation, but the problem is that the performance of the google service is terrible. The response time of my simple notification system was nearly instantaneous, but OK google, I'll play your game. I put together something that used FCM and it can take 15 or 20 MINUTES to get even a "high priority" message from FCM.

Reading the google docs, apparently google will deprioritize notifications that are shown but "not intereacted with" in a timely manner, so that is another source of delay.

I think the crux of the matter is that notifications have multiple purposes: signaling, and advertising, etc. Google hasn't provided a way for an app to declare its use case. So, you get policies to prevent notification spam creeping in and messing with basic app signaling functionality.

In the end, I kept both my "in-house" notifications for use by older Androids, and a kluge that uses FCM in addition, with some hacks to get somewhat better FCM performance. I live with the notification in Oreo+ and just tell users to ignore it (but honestly, I don't think users care that much.)