I use an open source SPAM call blocker (Yet another call blocker), which works fairly OK by querying a local spam phone number database.
Recently Google Play decided to display a permanent notification prompting me to uninstall that "dangerous" app because it could "damage" my device. It's impossible to disable this notification.
This app hasn't been updated in years. It has no ads. The only network request it makes is a GET to update the local DB.
My theory is that Google has decided to take into account generated revenue in their risk assessment algorithm. That would explain why FOSS apps are getting the axe while the dodgy commercial call blockers that upload your call history to their servers are still up.
It has a pretty bad set of permissions, which are necessary for it to function, but still scary for Google algorithms. Google doesn't know that its GET request doesn't get orders from a botnet and leaks sensitive data the app has access to.
Also, if the app hasn't been updated for years, chances are that it targets and outdated version of Android, which works, but is considered suspicions by Google as it is also a way to bypass some security checks in recent Android versions.
There are probably many other criteria but I think these are the most likely.
Not saying it is a good thing, but it explains the reasoning. I wish Google did human reviews and not rely that much on their bots, but then that's what Apple does, and it is even more locked down. Maybe try F-Droid, it is an alternative app store dedicated to open source.
> Google doesn't know that its GET request doesn't get orders from a botnet and leaks sensitive data the app has access to.
And yet the only reason Google won't add internet access as a revocable permission is their ad business.
Chrome constantly scans your harddrive in a way you can't easily turn off, and it's not for your safety: it's for the safety of their ad business to try to catch malware that engages in click fraud. If you have media or backup drives it just constantly adds wear to them.
>Chrome constantly scans your harddrive in a way you can't easily turn off, and it's not for your safety: it's for the safety of their ad business to try to catch malware that engages in click fraud. If you have media or backup drives it just constantly adds wear to them.
Is this true? Chrome is open source so someone should be able to point out the code that is doing that. What is the source of this info if not the code?
> Chrome periodically scans your device to detect potentially unwanted software. In addition, if you have opted in to automatically report details of possible security incidents to Google, Chrome will report information about unwanted software, including relevant file metadata and system settings linked to the unwanted software found on your computer.
> System information includes metadata about programs installed or running on your system that could be associated with harmful software, such as: services and processes, scheduled tasks, system registry values commonly used by malicious software, command-line arguments of Chrome shortcuts, Windows proxy settings, and software modules loaded into Chrome or the network stack.
This is interesting, I didn't know Chrome did this. But it doesn't back up the claim that "[i]f you have media or backup drives [Chrome] just constantly adds wear to them." Does anyone have anything on that?
As pointed out above, Chrome no longer does this... but adding wear is a natural consequence of any hard drive scanning process. SSDs are rated for a certain number of read/write cycles, and every time a block is read, it adds wear.
Even spinning rust wears out eventually. Not knowing any details about how often Chrome did this, it is hard to say just how significant this wear would be compared to other normal uses of the media. But it is clear that wear would occur to some degree.
Thank you for clarifying that! I should have known that. So perhaps it wouldn't cause any meaningful drive wear, if the system didn't do a lot of writes. Still consumes CPU and power, though.
Yeah, I mentioned media/backup drives since those are usually HDD rather than SSD. I didn't realize Chrome had stopped doing it now though. To disable it was a crazy number of steps with admin permissions.
Not only does it add wear, it slows down other processes. People notice this after OS updates where the system re-indexes the volume after the update completes. It's also why most indexing processes do it late night or while the system is idle. For an app like a browser to do it is just rude.
Right, I understand about wear, but my point is that the behavior described in the links doesn't indicate that Chrome was scanning backup or media drives - only things like the registry, files directly related to Chrome, etc. If I have a drive with a bunch of random files on it, Chrome wasn't scanning those, was it?
When I realized that Microsoft Defender sends sample files for further inspection without keeping a history of the files I opted to just install Linux and move on. This alone gives me more reason to just only use Firefox exclusively like I always have been.
Anecdotally, Chrome used to pin my hard drive at 100% usage until I killed a process called "software_reporter_tool.exe." I still have a version of the binary located at "%localappdata%\Google\Chrome\User Data\SwReporter\107.294.200" last modified 2022-11-02.
I’m not an android user but from what I've understood is that Google is desperate to deprecate apps that were compiled for earlier Android SDKs before they introduced more iOS-style privacy APIs
The exact reason I am planning to dump Android entirely. Every new Android version is worse than the previous and enforces new compliance measures. Exceptionally developer-unfriendly and increasingly reliant on centralised cloud APIs for features as basic as push notifications.
Another topic is how aggressively anti-freedom Android has gotten with the standard practice of root detection. It feels like more tech overall is becoming a walled garden as of late.
Suddenly, they started doing this? I don't rely on Google Play in any capacity, but it is terrifying. Anyone not determined enough to sideload a third party app store or apps in general will find themselves unable to use a substantial amount of projects that relied on outdated SDK or just couldn't keep the pace, even if the code is out there and can be audited.
Right, they had a deadline for apps that required them to update the target SDKs or the apps would be removed from the Store.
Mine was mid-last year. It was a huge pain, since my apps are really a PWA with a wrapper around it and is updated through the web. This means that I hadn't update the apps in the app store in a few years, as it wasn't necessary.
And of course, the wrapper I was using (cordova) didn't support some things from the new SDK, so I had to upgrade to a new major version. Anyway, it was a huge pain to upgrade all that for no functional changes for the end user, for the 10-ish open source apps I built and maintain.
Slightly off-topic, but Android does now support a much better method for submitting PWAs[1] that I'll move to the next time Android requires me to update the target SDK of every app. Hopefully, they'll continue supporting that and it won't require new submissions after that.
This is the most likely reason for that app to get a warning like that. They have made a lot of changes to their 3rd party app security model that would require apps to be updated, even if they were well-behaved under the old model. It's unfortunate that could not have been done with forward compatibility.
I have an app in the Play store and starting in June I have to get a D-U-N-S number, have a phone & email for users to contact me, a phone & email for Google to contact me and documents to verify my identity and my business.
I think last year or so there was an issue where Microsoft Teams broke the phones ability to dial 911 in certain situations. It was something about Teams taking over the dialer or something? I can't recall exactly. Google understandably took a huge amount of flak from users for that and the FCC got involved. It was fixed, but the reputational hit was significant and I'd bet they're a lot more aggressive with any apps that interact with the phone/dialer in general now. Especially ones that aren't being consistently updated.
As a lifelong Android user, I jumped to Apple after repeated 911 failures were identified. Bugs happen, but Google did not prioritize fixing them. I recall one issue has been open for months. Evidently ensuring 911 is working does not fit into a promotion packet.
Fake security is a big problem to those of us who are concerned with
real security.
Mischievous and dishonest use of "security" as an cover by policy
bullies, profiteers and other gangsters is as much a threat as worms,
viruses, zero-days, phishing scams, data leaks all other kinds of
actual security problem.
Not least because it weakens rational expectations and evaluations of
security and substitutes blind trust in (obviously untrustworthy)
entities.
Sadly, It's a powerful lever because the average person knows so little
about computer security and is easily bamboozled by scare-mongers.
Indeed, many phishing and malware scams start with a pop-up saying;
"Security Risk! You must update now!"
It is a form of extremely dangerous disinformation. For companies like
Google to engage in it for profit is treacherous and reckless.
You have to realise when a large tech company says "security", they mean their security from your attempts to defend yourself. E.g. most of the locking down of devices isn't to make it harder for attackers who want your data (which would defeat their own objectives) but to keep things like DRM keys from you.
Absolutely right. This is what I called "Zero Sum Security" (your
security is my insecurity), and written about here [0] and discussed
with Bruce Schneier.
It's a sure sign of an underlying toxic and abusive relationship.
>they mean their security from your attempts to defend yourself
No, they don't. They are protecting against malicous actors or at the most buggy software doing bad things on accident.
>most of the locking down of devices isn't to make it harder for attackers who want your data
Advances in this area definitely has been happening. The move to apps getting their own sandbox and having to be explicitly granted permission to access files outside the sandbox definitely helps against this. No longer can malware just read and upload all of one's browser history and malware. Even if an attacker got physical access to the device they would not be able to just dump what's stored either due to encryption.
>to keep things like DRM keys from you
This should be pretty self explanatory, but of the security of DRM keys is bad then attackers can dump unprotected versions of the content which is against what creators that have elected for DRM want to have happen with their works.
In the first and second part, you've simply defined the very bad actors who want your data as the good guys.
On the third point, we are in agreement. They want to make sure that when content right hoarders want to remove the content from the service you've paid for and move it to another service you now have to pay for all over again, you can't just keep a copy of what you already paid for. That's what I meant, keeping the device secure against you, who paid for it.
I would even go so far (as I recently said on Mastodon) that nowadays using Aurora over the Google Play Store is safer since it doesn't display ads for other apps just above the search results for the app one is looking for. If one isn't paying attention or running on autopilot (it happens) one might click on the ad and install some malware.
I completely agree. There are some serious dark patterns in the play store where scammers can buy top billing over the item you searched for, pushing the real app below the fold.
Do you log in with your google account? I understand that doing this could get one banned from the google polity. The anonymous log in doesn't have search working, last time I tried.
Edit: the trick I found was to search on google.com in the browser, then click on the link until it gives you the option to open in aurora v/s play store.
100 times over. It is possible to run Graphene then install DuckDuckGo browser then install F-Droid, then install Aurora, then you can have a de-Googled phone!
It's just a PR game of shifting blame. Who's responsible of all those privacy issues on mobile? Google's own ad machine powered by the GMS running as privileged user or the apps? They chose quickly.
Both companies response to the press has been to blame the apps again and again hoping that it would be enough to continue what they are doing.
Occasionally they even blame the users directly, the play store page on install displays "Safety starts with understanding how developers collect and share your data"
Per the amount of access they have some shit tier third parties will steal more privacy as they won't give a damn about it. Most people don't mind the ad company measuring your general profile of interests but really don't want people to read their messages.
I've found that as long as the bootloader can be unlocked and I can install a custom ROM, there's virtually no reason to obtain root. GrapheneOS is good enough on its own that I've had no desire to use root.
Some things are difficult to do without root depending on the ROM. Accessing displays' highest brightness mode at will, using a file manager that can actually see and manipulate every file on the device, using custom gesture utilities, altering over-underscan settings, undervolting the SoC, etc.
When people say "root", they usually mean "unlock the bootloader". "A device I can root" fundamentally means "a device whose bootloader can be unlocked".
Though, Google banning unlocked devices from using Google Pay was a really user-hostile decision.
This has been happening to a bunch of XMPP apps recently, and as a maintainer of another one (which closely based on Conversations) I'm fearing the worst next time I submit an update.
The worst part is the lack of communication from Google about what they think the problem is. There are plenty of apps that do actually upload contact lists to servers (hi WhatsApp, etc.), and they are still listed on the store.
Many XMPP apps do request the contacts permission, but this is to (on the client side only) allow storing XMPP addresses in your phone's address book and reusing your existing contact pictures, etc. This is explained within the app, and granting the permission is entirely optional.
Especially tiktok is still live, and there it's super obvious they upload the contact list. First: they ask you.
More importantly though: you don't even need to search for someone or someone's phone. You open the app and get 3 people suggested you never even knew had a tiktok account.
Really really creepy when you just exchanged numbers with someone and you can see all their 50 tiktoks. Happened to me with a girl I matched online - funny for me to see her videos, for her it was super creepy.
The difference here is tiktok surfaces their tracking to the user in a friend-suggestion feature.
Facebook (and others im sure) absolutely do the same thing. It's just that on facebook there is no attribution to how they generated the suggestion when the person appears on the 'people you might know' feed
Could they simply be buying advertising databases which have possible connections for your name and ASL/phone number? Like the CIA and FBI seem to be doing. Plus likely your friends just give it whatever information it ask for so they already have your info anyway?
TikTok is buying data from almost everywhere. I browse to almost any site (on my desktop) and within minutes I am seeing ads on TikTok (on my phone) for the same/similar products.
This happens the other way around as well (and is why, imho, both Android and iOS should flat out remove the capability from their platforms) - if TikTok knows your phone number for whatever reason, and the OTHER person uploads their contacts with you in it, that's enough to create the connection and start prompting you to friend them.
Right, I can deny contact uploading all day long, as long as a bunch of people that have my number upload theirs to foostter it quickly paints a social graph where I'm† precisely pinpointed even though I did not interact with foostter.
† Or a hash but that's barely pseudonymous. The social graph alone could constitute PII as it could easily identify me unequivocally, but here's no way for me nor anyone outside foostter to know what happens internally, let alone request erasure.
Then I'd argue that the actual problem is only having a permission to access the contacts, and not limiting what the app can do with them. Of course, limiting what an app can do with data that it already has access to is an interesting technical problem (and AFAIK not one Android is currently set up to handle)...
See, that's probably where you're going wrong: I doubt a human looked at any of these apps and thought "this is suspicious".
Instead, I think Google is using some kind of AI for determining this stuff. The only human component I expect to be present would be people working to prevent large apps that do upload your contacts to the cloud (WhatsApp and friends) from getting flagged automatically.
They did the same thing to our messaging app where I work.
Claimed we were uploading contacts and removed our app; we definitely don't upload contacts, that's a fact; the infra is also self-hosted so where would we be uploading them to?
They only way we got them to allow it back was to add a privacy-policy notice to say that we upload contacts and why, despite the fact we actually don't...
Google and Apple need to be regulated and have their "oversight" of what software can be deployed to mobile devices removed.
Google and Apple's role is to defend users. This nanny state solution is not the only way to accomplish that, and in fact, they only do this to extract as much value as possible from the marketplace.
I fear that battle is lost; as we can see with Apple's response to EU regulation, it'll be all malicious-compliance, and even without that, the sheer scale of the status-quo means the chances of any alternative gaining traction is all but lost.
An alternative app store gripping the mass-market is unlikely; a new entrant into the Android-iOS duopoly is unlikely, Google/Apple actually giving a shit about the apps and developers making the software to rake in cash for them is _unlikely_.
Having been in the mobile-app-development space since the beginning of Android and iOS, I've given up. I don't use my personal developer accounts any more, and I don't do "mobile" at work any more.
I didn't mean it was up to chance, it is technically quite hard to keep in check.
At most places the most serious bit is some sort of compliance checks with vendors. And while that might carry legal consequences it's technically a pinky-promise. Nothing in the system enforces it in any way.
Unless one does some technical analysis on every version of every deps one uses, a dep (maybe via one of its deps) can get compromised and how/when will anyone notice it?
It is a technical challenge, and almost impossible for small devs. If you have a process in place to tackle this I'd love to learn about it, even if it has to stay in general terms.
Yours is a good question, and probably one of the places I'd look first. It doesn't deserve to be downvoted. Too many developers just yeet rando dependencies into their app without even remotely vetting/auditing them.
> the infra is also self-hosted so where would we be uploading them to?
...? How does self-hosted make a difference in this scenario? Uploading means it's leaving the phone, regardless of the destination. It could be going to your server or AWS or anywhere else, and I would consider it being "uploaded".
In this context, self-hosted probably means that the user/org hosts the service that the app connects to. i.e. Element connecting to your own matrix home server, or something like next/ownCloud.
"Google has just removed #Conversations_im from the Play Store because they think we are uploading the user’s contact list. We don’t."
and
"To be clear: They didn’t just reject an update. They outright removed the app entirely. Otherwise my plan B would have been to remove the contacts permission which is used to display the name and profile picture locally if the XMPP address matches an entry in the users address book."
That's a bit funny since i get notifications on my phone from google assistant (which I've disabled) about birthdays of my contacts, and I've explicitly disabled contacts access for all google apps on my phone.
My guess, the contacts are synced to the cloud, and the message came from Gmail or the Google Contact-Webservice and Assistant is just the icon in the middle.
It builds a database of users’ contacts. Probably in violation of GDPR but they have a constitutional exception for that in Sweden (“utgivningsbevis”).
Talk with Google, usually this stuff can be resolved. Their bots flag stuff because of reasons. Yes, sometimes it's BS, but often there's something that you have missed to clarify.
Lol this must be a bigger joke than the app being removed in the first place.
I never heard of anyone who was able to talk to anyone at Google. HN is full of folks getting apps suspended, locked out of their Google account and so on... Not being able to talk to someone is sometimes actually the only problem (though we all know the app store has much more issues than just that)
I also really like to joke about Google Play and their policies.
But: Often it does help to simply write them! Yesterday at 16:56 our update got rejected, at 17:51 I submitted an appeal and at 18:33 they accepted the appeal and the update got approved.
If you have an ads account they cold call you and email you constantly lol. Can they help me get back into my gmail account that I have the username/password/recovery email for? No.
My guess is it's a fully automatized decision which at best upholds the pretense of being appealable but in practice is not.
I.e. they checked 1. uses contact permission 2. doesn't have in their privacy policy that they process/upload/store the contacts => must be malicious so kick it.
probably they don't want to bother to have to consider if contacts are actually uploaded or not and just blindly assume they are
problem with that is a lot of privacy friendly apps do exactly that, access contacts for convenience features but not upload it
Although it will only be fully in force as of March 6th, this sounds like an obvious violation of the European Union's new Digital Markets Act to me.
Article 6.12 states: "The gatekeeper shall apply fair, reasonable, and non-discriminatory general conditions of access for business users to its software application stores", whereas nothing about their decision is fair & reasonable.
Furthermore: "For that purpose, the gatekeeper shall publish general conditions of access, including an alternative dispute settlement mechanism.", while it sounds like no serious appeals procedure was offered.
Now, how to actually enforce this in a procedure that won't take years to complete is a different question..
Conversations is on F-Droid so there is no reason to get it from the Play store. This goes for all free software apps, get them from F-Droid or similar free software repos and free yourself from the manipulations by the likes of Google/Apple/Microsoft/Amazon/etc.
Yes, I understand this limits the reach to those who know about F-Droid (et al) but given the way XMPP has been pushed out by the aforementioned corporate entities it is likely that those who use XMPP already know about and use F-Droid.
The Conversations developer also highlighted that a significant portion of his income comes from Play store.
So a reminder that F-Droid features donation links on app listings that support it (including Conversations), allowing you to discover how to donate directly to the developer (no percentage fee is taken by Google that way, too).
Tell them about F-Droid then. Tell them they can find a bunch of apps which are less likely to sell their soul to the highest bidder. I did tell mine, all of them installed F-Droid - it is just another app after all - and most use a number of apps from there, things like Nextcloud and DavX and, yes, Conversations.
I am not entirely sure, but I believe the F-Droid version uses a different push technology, which can lead to slightly different app behavior/compatibility/battery usage. I used it for some years, but I switched to the Play Store version at some point.
Never having used the version on the play store I can not compare the two but I know the version on F-Droid works fine with messages arriving in time. Battery usage is minimal, under 1% with regular usage.
There is a an extensive comparison of power consumption by messaging apps out there somewhere on the 'net but I can not find it at the moment. In that test Conversations ended up as the 'best' (using the least amount of power) while Skype and Facebook Messenger ended up worst if I'm not mistaken.
Luckily, it's not like iOS and you can still download an APK or use F-Droid. My impression is that most people who are using these rather obscure communication methods would be able to find the app somewhere else.
The developer relies on the income from Goolge Play Store to keep working on it though:
"I understand that most of my audience here on Mastodon is more ideology aligned with F-Droid but the app sales on Google Play store have contributed significantly to me working (almost) full time on #Conversations_im.
Pretty surprising that you can make money off of a free software app like this, I always thought almost nobody would actually pay for it on Google Play store.
I hope he can work it out with Google. Conversations is the best Android XMPP client I know of.
Indeed, I don't really do video calls. For audio calls I use my phone, since I can move around. Maybe the web client https://mov.im/ can do video calls on Windows?
Even on iOS, none of them have UI as good as Conversations' (Android).
I was using XMPP only for some notifications (through a small bot) and it was nice while on Android. But when I moved to iOS I just stopped using XMPP because I didn't want to use any of the available clients.
The best method is to install the F-Droid version and donate directly to the developer. Google takes a 30% cut on Play purchases. In the case of Conversations, Daniel has an account on Liberapay: https://liberapay.com/iNPUTmice/
This definitely helps the developer but as they said (https://gultsch.social/@daniel/111930342452832163) they much prefer having Conversations being available to non-techy people than relying on the hardcore fans
oof that hurts more than the app removal, it also took away most of his income. Surely he can find a human being somewhere that can help appeal it? No HN googlers with contacts?
F-Droid is a mess too. Apart from the unclear organizational status at this point and the associated drama, they also are super keen on plastering "anti-features" on apps with very vague criteria and no grace period. Organic Maps was for example, first accused of ads whereas it just had clearly communicated referral links to hotels on Kayak, then somebody came up with an idea it promotes non-free network services (i.e. the goddamn map download CDN in an otherwise offline app)
Anti-feature warnings on F-Droid do not affect your ability to install an app in any way, they are just there to inform users. Also the assessment of Organic Maps seems correct to me?
How long before Google just completely locks all third party developers out? That seems like a likely outcome at this point. It’s only a matter of time before they start rent seeking on their developers, like Twitter and other tech companies in decline.
Another datapoint for the enshitification of Android.
Recently, I have encountered problems with Tasker, because Google has removed another set of abilities from Android for the sake of "security". Which for means there is less and less reason to use Android, which kinda sucks..
It's used by a lot of the big commercial platforms because it's well understood and has libraries for every system and language ever invented just about. Eg. Zoom and Jitsi both use XMPP (Zoom for Chat, Jitsi for chat and signaling), WhatsApp used to just have their entire backend be an off the shelf XMPP server, Cisco Jabber which is still popular in "enterprise" uses it, etc.
And for other individuals just wanting to talk with their parents it's just a chat app, they don't care if it's XMPP or not, Conversations is just really nice to use.
With privacy minded folks and people who think we should just agree on using the IETF internet standard for instant messaging instead of 5 different proprietary messaging apps and 3 apps based on experimental "open" protocols (which are ultimately controlled by a single entity and never standardized).
To be fair, IETF standardization of XMPP was somewhat afterthought, and further extensions (XEPs), which are necessary for modern clients, are not IETF standardized.
Standardizing the core concepts + the extensibility of XMPP was absolutely necessary to achieve the necessary protocol agility I think. Requirements have changed a LOT since 1998 and we still have innovative and modern XMPP clients, maintained by the community, mostly in their free time without any need for millions of dollars of VC money.
Without standardization, there can be no interoperability and without agility any IM protocol will soon be outdated. I think XMPP is a success story because it realized this, but it's a success story that isn't told very often.
And fruit s few years after that they stop had a page about their commitment to open messaging standards and federation... They finally took that down.
What is most infuriating, that when you actually want to remove app from app store - you cannot do it easily from Google Play Console. As far as I read you have to contact support and jump through other hoops. It's probably easiest way to add malware and hope Google removes your app much faster.
IMHO we clearly need more nonprofits that take up those cases and cover legal costs. At least get on their nerves, like the guy who singlehandedly sued Instagram because they canceled his restaurant. Noyb successfully showed how this can work for GDPR, we need something similar for digital markets and platforms.
All those platforms only can make so much money because AI makes critical decisions and they can even claim not to be liable. If they make so much money with you it would at least seem reasonable that you get a human contact.
which makes it very clear that the only reason PWA where still allowed by apple was to try to avoid monopoly marked regulations
the fact that they seem to remove them without any warning make it clear how much they care about they users (i.e. not at all, it's all about money, which should be obvious but needs to be said in case of apple as they managed to convince people otherwise)
Well if you can get punch cards over smoke signals connected to a serial port somehow, you could do UUCP over it.
> I'm waiting until you have fees to open a jpg. Pay-per jpeg. PPJ
Imagine a future where all video is cloud based and is rendered by remote GPU farms and you are charged per pixel rendered (PPR). Moving your mouse will incur changes.
Fellow humans, there are alternatives to Google and Apple! Your neck need not be under anyone's boot! You don't even need to give up any functionality:
Data service:
The simplest thing is to buy a prepaid SIM and top it off with cash. The lovely people over at /r/nocontract maintain a big spreadsheet so you can filter by various properties of the available contracts.
Another way to go is to pay for a postpaid plan with a virtual credit card (VCC) like at privacy.com. It won't be linked to your name at the telco, but of course privacy.com knows who you are. There is also Abine Blur, and some others.
Yet a third way to go, which is nascent, is buy an eSIM with crypto. You can also buy prepaid VCCs with crypto.
An interesting new choice is PGPP https://invisv.com/pgpp/ who rotate your IMSI and do some other cool stuff. It works by e-sims.
All these methods make you /pseudo/nymous, but obviously you're still identifiable by subscriber number and possibly IMEI, to put aside correlational things like your traffic profile. You can help this problem by routing everything through a VPN. Then you're pseudonymous but the cell carrier knows nothing about you other than that you use a VPN. Pay for the VPN with crypto. Of course now the VPN provider knows your traffic, but you're much more anonymous to them than you are to a telco. You make your choices. Defense in depth. Etc.
OS:
GrapheneOS: https://grapheneos.org/ Very much like Calyx, but extra-hardened and with no MicroG. No involvement with Google at all by default. You can make a secondary profile in which you install Google Play Services to set up an environment where you can run unprivileged Play services + whatever crapware you need that requires them. Unprivileged here means it's like any other app: if you don't give it access to your location, it won't know where you are. If you end the profile session when you leave, Play Services stops running and stops talking to Google.
CalyxOS: https://calyxos.org/ Privacy-respecting Android distribution that replaces Google spyware with MicroG, so you can have your cake and eat it too. Most everything will work as you're used to, but it does still talk to Google to make that happen.
LineageOS: https://lineageos.org/ The successor to CyanogenMod, will work with many different phones. More privacy and control than stock Android.
There are also many others: Sailfish, Replicant, e
Hardware:
CalyxOS and GrapheneOS run best on Pixels. The path of least resistance is to get one of these phones and run GrapheneOS with Google Services installed in one profile or other.
Not very relevant to Conversations. The app is available on F-Droid, no need to buy a new phone or install a alternative OS (even if you should). The point here is that this is a major blow to the developer whose income is dependent on Google Play purchases.
XMPP as a protocol is pretty much dead on Android with all the battery optimisations in the newer versions. You can't get a decent user experience unless you integrate it with Firebase.
These are surely not purely client-side XMPP... clients, though? In order for you to receive push notifications, some server somewhere is connecting as you in order to relay the messages through GCM.
No need for a relay. The actual XMPP servers nowadays support GCM natively. The client generates a GCM token and just hands that to the XMPP server. The server doesn't have to send actual message content either, it can just be a "wake up, there's a new message" ping the app can handle specially.
Many apps do that, it allows the app to stay connected which (perhaps counter-intuitively) is more efficient for realtime apps. It's entirely optional though, and even if the app has such a notification it can be hidden. On some ROMs however, even the notification does not suffice and the app gets killed anyway. Thanks to push notifications, it still works.
In any case, this is the choice of a specific implementation, and not something inherent to XMPP. Your original comment said that integration with Firebase was needed, and I wanted to point out that it is already integrated.
This was quite the opposite for me. Main reason my wife and I used XMPP for several years was because Conversations was the only app to get timely notifications on both googled and de-googled Android. And this worked until at least Android 11. At the time, Riot.im (now Element) either drained my battery checking for notifications without Google Play Services, or seemed to work fine, but did not get notifications in time even with Google Play Services.
What you're describing also has been true for iOS for a while. Apps cannot do long-polling and require a push notification server (usually provided by the app maker, e.g: siskin, snikket, chatsecure), and that adds another point of failure.
Yes. Once an Android device goes into doze mode, there is nothing an app can do to sync in the background.you have to somehow extend your xmpp to route some messages via firebase which I believe whatsapp is doing
Besides what MattJ100 wrote above, by itself this is also not true. You can tell Android to not optimize Conversations and allow it to run in the background. It will work just fine with a (usually idle) TCP connection. But for the typical user, having to instruct them to do this is cumbersome, and integrating with Firebase is easier. It does come with its own concerns w.r.t. privacy, both for the payload as well as metadata exchanged.
I've been so full of missing and delayed notifications I just bought an iPhone, which has zero issues with it, with zero configuration.
Still, as I made a few really small android apps in the past, this has been a sticking point for me for years.
Is it possible to write an app that can notify at ANY time? Let's say I want to monitor my self-hosted infrastructure. On an iPhone I get e-mail alerts right away. On Android, some ring exactly at the time I pick up the cursed phone.
I checked for every possible consumer facing configuration option (deep sleep exclusion, background service allowed, etc.) and I found zero reliable options.
Ntfy.sh seems to work perfectly on stock Android without firebase/GSF. I do have "unrestricted" enabled in app settings but it doesn't seem to impact battery life in a noticeable way. I never missed any notifications.
Once you leave AOSP-land it can be more tricky, https://dontkillmyapp.com/ has more info if you're interested.
> Even disabling the system battery restrictions does not save the app from being killed. Let's find out, if it is a bug or a feature... Here you can read more details
I have Samsung s21; after years of fighting it (3 samsungs) I'm welcome to a bug explanation
It solved "delayed notifications" for me, for certain: I still have original Samsung next to iPhone and it's clear as day:
- iPhone rings, Samsung nothing
- I wait few minutes just to be sure and pick up Samsung - immediately after picking it up the notification shows up, with the exact timestamp of the moment I picked it up
I think this is because iphone has never allowed background apps to hold open persistent connections, yet android does but with device and power-state specific limitations.
So the iphone version of any xmpp app has to use apples notification service, but the android version of the same app might try to use a direct connection (saving the app developer a lot of server costs), even though on many models of phone it only works when the device is charging for example.
Most android devices do that - sleep-state an application and it won't tell you anything until you actively pick up the device and use it. Been like that since I had my Kyocera DuraForce Pro on Android 6 or 7.
Yes, and there is an option to opt-out of that list. I did enable that.
I'll phrase my issue differently: Is there any way to have reliable notification delivery that are time critical? Is actually calling the only 100% reliable option, as the PagerDuty does?
Push notifications via play services are the only reliable way. They work even with battery saver on (but not extreme battery saver, unless the app is excluded).
Note that you can only have one push notification reliably per user interaction. So once you have sent a notification, further ones won't be reliably delivered until the user interacts with your app in some way.
UnifiedPush distributors such as ntfy.sh seem to work pretty well, in my experience. They don't seem to affect battery life much (at least according to system graphs) and they work well.
Recently Google Play decided to display a permanent notification prompting me to uninstall that "dangerous" app because it could "damage" my device. It's impossible to disable this notification.
This app hasn't been updated in years. It has no ads. The only network request it makes is a GET to update the local DB.
My theory is that Google has decided to take into account generated revenue in their risk assessment algorithm. That would explain why FOSS apps are getting the axe while the dodgy commercial call blockers that upload your call history to their servers are still up.