Telemetry

[GaryMatthews]

I got a rude shock when i found out telemetry exists in the docker images and its not documented on the website (or at least searchable) let alone seams to be missing options to turn it off. ill be purging/crippling it in any way i can until i find or build my own replacement and wont be trusting the docker images or code.

[mudler]

that's just trolling. there is no such thing as telemetry built-in in LocalAI and no information is collect of anywhat.. It just happens to support otel https://opentelemetry.io/. You can see your local stats generated by the instance by hitting the /metrics endpoint. That's it. Maybe you are confusing to that feature?

[mudler]

I'll give the benefit of doubt here - and agree that the /metrics can be not wanted by anyone, but that's not the problem the OP was refering to. WE DO NOT COLLECT DATA. STOP NONSENSE PLEASE.

IF you don't want to expose the /metrics endpoint outside, is enough to configure properly a reverse proxy and disallow/allow explicitly endpoints to be accessed from outside. For sake of semplicity I'm adding a flag in #3945 to disable it.

[GaryMatthews]

Thank you! That's all i needed from you. there is telemetry data i stumbled on stored on the file system in the docker containers i am using and it should not be collected and stored or accessible without an opt in for it. the biggest issues is when an instance is exposed to the internet that data is exposed and that's unwanted data collected and accessible and specifically requiring a proxy to stand in the middle is not an acceptable means of protection. the api should simply refuse 403 or 401 and the data not exist unless specifically opted into it. I am not a go programmer so when i went digging and couldn't find anything that disables it i spat the dummy and especially as i am using it openly via a proxy but through an authorisation layer to pass through p2p related federated and federated use. Unchecked and unauthorised access to telemetry is also a potential vector for attack as in this case a few counters for each api call well as unsupervised data collection provides information to target and to lock onto . Please note that i did not accuse you of directly correcting the telemetry but that it is enabled, not opted into and not documented. i also found a reference to a telemetry.py module somewhere in my search for this but didn't find a file matching file in the sources. i didn't realise it used go census and open telemetry libraries either until after posting this issue and since i am not a go programmer and not specifically familiar with them or the dependant libraries i make my assumptions that they are in the business of collecting telemetry data and without going over the source to confirm it is just another way to let telemetry or anything else in the backdoor. enabling it with LOCALAI_TELEMETRY=1 REBUILD=1 is a far better option. pulling code in an verifying the sources is also a safer option then allowing REBUILD in a remote container to fetch new sources from the internet. Thanks for listening!

[mudler]

Got it - I just want to make it clear for anyone else stumbling into this - we do not collect any data, because as it was phrased originally it was more a direct attack. Remember this is an open source project, community built by people giving away their free times, if something doesn't please you you can always open up as PR and help in fixing it. That's why I push back comments that are simply using a tone that doesn't resonates with this.

The PR now provides a flag that lets disable the /metrics point entirely. I will cut a release soon and should be available in the next release.

Probably we should opt-in to have a "production" flag rather then disabling the entrypoint, but that's something we can do along the lines in the future after we collect a list of the options and defaults that we can suggest for production use.
However, for production I'd suggest to run LocalAI behind a reverse proxy and have total control of the routes you are going to expose. P2P features are not having production-grade support yet, even if we are getting there.