Closed gurple closed 1 year ago
wat? there is no analytics data in the app. The only function that allows receiving an external IP and checking for the update. You can see that in the codebase or just by viewing what request is sent via the network.
on what basis did you decide that there are any analytics data? If you open a ticket like this please give some proof of your word.
All options that require external API could be easily disabled by:
I base that on app's clear connections being established such as: https://api.serhiy.io/v1/stats/release/latest?macOS=13.2.0:443, etc.
My issue is not that this occurs. It's not uncommon at all. Similar kinds of activity is exhibited by applications that use the Sparkle frameworks. The reason it comes to my attention is due to TrendMicro agents automatically flagging and blocking this traffic as malicious based on rules in their deployed signatures.
Yes, this endpoint returns information about the latest release as you can see. I don't use any library for updates. As I say, if you don't want to have updates you can easily disable that in the settings.
There are only 2 endpoints that can be called:
There are no more calls to the server in the app. Give me know If someone has an idea of how these functions could be realized without a server.
As I said, I find this neither objectionable, unwarranted, nor undesirable per se. I'm not here because the network activity takes place. Rather, it's much more due to TrendMicro flagging your app's traffic as malicious. Or more specifically, they are flagging your personal API infrastructure or FQDN as malicious. Perhaps it's due to your addresses like 2606:4700:3037::ac43:a364 and 104.21.81.187 not providing reverse name resolution. I don't know what their scoring methods are. But you're in their crosshairs (or is it Cloudflare that is?)
Connections to https://api.github.com/repos/exelban/stats/releases/latest are not similarly flagged.
A cheap and ugly method to determine the public IP address using already trusted infrastructure might be the output of something like: dig +short ip @dns.toys or specifically for IPv4 dig +short txt ch whoami.cloudflare @1.0.0.1
Anyway, I like your app. I'm not here to toy with your combative style. I want to help you somehow avoid having your work and personal reputation potentially tarnished by the security industry. TrendMicro does not like your serhiy.io domain. There are many many individuals and companies out there who use TM's signatures in their network and endpoint monitoring infrastructure.
I was speculating that, perhaps, by clearly expressing what Stats does across the network, when, why, (and how to disable each condition) and allowing the user to opt in prior to the network communication) then fears might be alleviated. I was thinking that this missing first-launch behavior might be treated as a bug.
You can see this by inputting 'https://api.serhiy.io/v1/stats/release/latest' on https://global.sitesafety.trendmicro.com
As of this moment it returns a 'Dangerous' scoring. The onus is on you to rectify that.
With that, I think I'm done here.
ok, thanks. I send them feedback. I don't know anything about this company. Maybe they will change the score)
@gurple TrendMicro changed the api.serhiy.io
domain name scoring. Now it's reported as safe.
Good news there. It will probably take a while for that the cascade out to all the devices that embed the signatures. It'd also be nice to understand why your backend got flagged as such. You might want to inspect the backend's sec. posture and ensure everything's up-to-date and ship-shape. Who knows? Maybe some silly php/java script cryptominer file snuck its way in for a little while and was found by the spiders. Cheers
TrendMicro is classifying connections to api.serhiy.io as malicious phishing or C&C backends and triggering SIEM alarms.
I can see that there was a some argument in the past over usage metrics being collected by the application and delivered to the developer's personal API infrastructure without first collecting approvals from the enduser. Perhaps this is the reason for the classification?
At any rate, it seems to be particularly bad form and needlessly damaging to Serhiy's reputation to be collecting telemetric data like this without clarification and prior explicit approval from the end-user.
I'll treat and file this as a bug due to oversight.