According to Google, #Conversations_im is now also collecting users’ email addresses.
Pretty much the exact same thing that happened to Quicksy about a month ago¹ is now also happening to Conversations.
An app update I submitted ~48 hours ago passed review without any issues. A subsequent update just now, which contained very minor bug fixes, was rejected because I failed to declare that I’m collecting email addresses.
Someone or something at Google started to hallucinate that #Quicksy is collecting the user's email address and would not approve the app update until we declared that in our data policy.
The sign up process in Quicksy hasn't changed in 7 years. I don't even know where the user would enter their email address and I'm not aware of an API that collects this automatically.
One of the main reason I do not publish my apps on the Play Store is to avoid Google's unproductive process, and to not have anything to do with their obscure reviews.
that sucks. Whatever LLM (or worse, human) they're using to do this obviously needs to be trained a thing or two about the difference between email addresses and JIDs 🙄
I admitted to collecting email addresses because it is the fastest way to get the release out, and now I’m appealing the decision. Let’s see where this is going. Spoiler: very likely nowhere. Google doesn’t make mistakes.
Are you certain that they actually mistook XMPP addresses for e-mail addresses? Perhaps they're just referring to those e-mail addresses collected by some XMPP servers when signing up or something similar?
my best guess is that it is both automated analysis and click workers. Some automated tool probably flags any input form of type email address and then a screenshot or something is shown to some poor $1/day worker in some poor country with the prompt 'can the user enter an email address here' and they can't and don't want to understand the context.
(sometimes the rejection takes too long for it to just be 'AI')
Google rejected my appeal and included this helpful screenshot to demonstrate that Conversations is collecting email addresses.
Extending this logic means that any app with a free form text field is technically collecting users social security numbers. Because the user could potentially enter that.
the indentations that your keyboard makes while you are slamming your face into it must be hurting. I'm sorry you have to go through this - again. I've got mad respect for your patience over the years. Not sure if I could bring that, to be honest.
I submitted a version that does that. Speaking from experience these shenanigans rarely work and always create more work (make change, bump version, upload, wait for feedback). But let's wait and see.
Yeah, of course they'll just type @hotmail.com and reject it again.
This kind of thing would have been easier if XMPP didn't have that no-SRV fallback behavior, if SRV records were always required, so you could tell by the existence of SRV records whether a domain was a valid XMPP domain without connecting to the fallback address.
I really don't think you should have to, but if you split it into "username" and "XMPP server" would that help, or do you think it would annoy / confuse users too much?
when the field is empty, the placeholder (text in the background) shows `username@example.com`. The field also validates what appears like e-mail addresses. I think that this might have confused them.
When entering a domain that does not exist, Conversations shows "server not found" immediately. When entering a domain that does exist, but is not associated with an XMPP server, Conversations freezes for some time. Maybe that timeout should be reduced?
I would suggest filling the compliance paperwork stating that your app collects XMPP addresses (as stated in the field label), which may look like e-mail addresses but are actually not, unless an identical e-mail address exists.
I think you should mention in the appeal that you don't collect jabber id because it's only stored locally on the device and used to authenticate with origin xmpp server, so the app doesn't collect anything.
S1m
in reply to Daniel Gultsch • • •This is exactly this kind of obscure review I'm talking about
infosec.exchange/@S1m/11510762…
S1m (@S1m@infosec.exchange)
Infosec ExchangeHippo 🍉
in reply to Daniel Gultsch • • •Ærion
in reply to Daniel Gultsch • • •caravantravellers 🌈
in reply to Daniel Gultsch • • •Daniel Gultsch
in reply to Daniel Gultsch • • •Pixelcode 🇺🇦
in reply to Daniel Gultsch • • •Nicoco
in reply to Pixelcode 🇺🇦 • • •Daniel Gultsch
in reply to Nicoco • • •my best guess is that it is both automated analysis and click workers. Some automated tool probably flags any input form of type email address and then a screenshot or something is shown to some poor $1/day worker in some poor country with the prompt 'can the user enter an email address here' and they can't and don't want to understand the context.
(sometimes the rejection takes too long for it to just be 'AI')
Daniel Gultsch
in reply to Daniel Gultsch • • •Google rejected my appeal and included this helpful screenshot to demonstrate that Conversations is collecting email addresses.
Extending this logic means that any app with a free form text field is technically collecting users social security numbers. Because the user could potentially enter that.
Lutin Discret
in reply to Daniel Gultsch • • •Guus der Kinderen
in reply to Daniel Gultsch • • •J👀
in reply to Daniel Gultsch • • •Zash
in reply to Daniel Gultsch • • •Daniel Gultsch
in reply to Zash • • •Zash
in reply to Daniel Gultsch • • •Yeah, of course they'll just type @hotmail.com and reject it again.
This kind of thing would have been easier if XMPP didn't have that no-SRV fallback behavior, if SRV records were always required, so you could tell by the existence of SRV records whether a domain was a valid XMPP domain without connecting to the fallback address.
Tagomago
in reply to Daniel Gultsch • • •Steven Reed
in reply to Daniel Gultsch • • •talpa
in reply to Daniel Gultsch • • •algol
in reply to Daniel Gultsch • • •The AI (lol) just see xmpp addresses like email addresses.
🤯
mimi89999
in reply to Daniel Gultsch • • •when the field is empty, the placeholder (text in the background) shows `username@example.com`. The field also validates what appears like e-mail addresses. I think that this might have confused them.
When entering a domain that does not exist, Conversations shows "server not found" immediately. When entering a domain that does exist, but is not associated with an XMPP server, Conversations freezes for some time. Maybe that timeout should be reduced?
mimi89999
in reply to Daniel Gultsch • • •When Nextcloud had problems with the Play Store, they went public and got quite some media coverage. Maybe Conversations should try the same?
arstechnica.com/gadgets/2025/0…
Google restores Nextcloud user’s file access on Android
Kevin Purdy (Ars Technica)Daniel Gultsch
in reply to mimi89999 • • •Splinux
in reply to Daniel Gultsch • • •he meant public w/ reach...
@mimi89999
sre4ever
in reply to Daniel Gultsch • • •HugoPoi
in reply to Daniel Gultsch • • •txt.file
in reply to Daniel Gultsch • • •crispycat
in reply to Daniel Gultsch • • •uɐıʇsɐqǝs
in reply to Daniel Gultsch • • •is the EU going after PlayStore already?
They forced Google to show a randomized Browser selection dialog during device setup.
Now please forbid PlayStore is preinstalled and show alternative App Sources like Fdroid (and make them be granted the same permissions as Play).
Remember when they removed the "don't be evil"?
RSL
in reply to Daniel Gultsch • • •