Its certainly not pleasant to find out after getting bugged by ca that theres an updated version, that by default, it phones home.


Also, a nit pick from what i can see using just the hash of the guid is certainly not anonymous. Its static. Using entropy upon install to set an identifier in the config to do your daily tracking would have sufficed.

1 hour ago, EDACerton said:

(And also, the reporting doesn’t run immediately on installation, and the setting is clearly shown in the options.)

It depends at what time you happen to install it^^

1 minute ago, Mainfrezzer said:

Its certainly not pleasant to find out after getting bugged by ca that theres an updated version, that by default, it phones home.


Also, a nit pick from what i can see using just the hash of the guid is certainly not anonymous. Its static. Using entropy upon install to set an identifier in the config to do your daily tracking would have sufficed.

It depends at what time you happen to install it^^

I'm not going to debate this any further in the thread... LT is aware of how I handle metrics, I discussed the technique (including the use of the GUID) with them a long time ago.

Not to put too fine a point on it, but -- I didn't even use these plugins before they were deleted. I don't need them. I revived them to be helpful to the community. Having data on how many installs there are, etc. helps me prioritize the personal time that I put into maintaining these plugins for all of you.

2 hours ago, EDACerton said:

Usage reporting in software is commonly opt-out; it’s an accepted technique across the industry.

But what and why are you even collecting? As far as I can see you are hashing the flashGUID, the plugin name, the plugin version and the Unraid version. I really don't know why you would do that and even more ...daily?

I assume you know that you can also ask the GitHub API how much downloads are on the Releases.

As I said:

1 hour ago, EDACerton said:

I'm not going to debate this any further in the thread... LT is aware of how I handle metrics, I discussed the technique (including the use of the GUID) with them a long time ago.

I posted a link to the code. You're welcome to inspect it.

1 minute ago, EDACerton said:

I posted a link to the code. You're welcome to inspect it.

I've edited the post, however your explanation is lacking why, but anyways this means from my side no plugins from EDACerton on my server. :)

Thanks for the explanation.

Please don't add any tracking or monitoring to plugins I've written. CA has the capability to monitor the number of times a plugin gets downloaded that will work for the information you want.

I am not pleased with the move to tracking and monitoring that has been added to my work. I am re-opening the file activity plugin I wrote and maintained and you can remove the "revised" version and re-install my original version using the URL in the first post. It doesn't track you! I'll also resubmit to CA.

I have added a new feature that will let you turn off monitoring SSD devices. Monitoring of file activity was intended to be used to monitor spinner devices and not SSD type devices. Monitoring SSDs overwhelms inotify and is probably the reason for the posts about overwhelming CPU activity.

Inotify is not set up to monitor "access" file events as this again will overwhelm inotify. If you install the cache dirs plugin, access events should not cause disk spin ups.

I am not in a position to provide a lot of support, but I will do what I can for anyone having issues with my latest version.

I’m going to defer to staff on how to handle this.

You chose to delete the original repositories (not even archive them — delete them, specifically to deny users the ability to install them), disrupting users, then returned because you didn’t like work that was done.

Due to some personal circumstances, I am unable to keep the pace I was working with Unraid. I would not resubmit the plugin if I could not maintain it. I said I would not be able to provide a lot of support. A lot of support is provided here by other Unraid users and they do a pretty darn good job of it. I'll provide code fixes as needed. Honestly, this plugin does not require a lot of maintenance.

I made the repositiories Private while I assessed my situation. Probably not the best decision, but I am doing the best I can. If anyone wants a refund, I'd be happy to refund your $0 investment.

If LT chooses not to put it back on CA, that is their decision.

Edited May 24, 20251 yr by dlandon
Typos

I don't see the larger issue, as far as I can tell it was clearly offered in the GUI to disable metrics collection and nothing of any value whatsoever was being transmitted here. So I'm not sure how transmitting a hash of a hash and some application versions is a breach of trust for some here. If you look at https://docs.unraid.net/connect/privacy/ then Unraid itself also records minimal information that aids development, which should be a good thing for everyone.

Ultimately, plugins are free pieces of software, that nobody is forcing you to use, in fact most commercial applications collect far more information and are almost always opt-out (if at all). I can only speak for myself, but I'd rather use a well maintained FOSS plugin that uses metrics to channel development in the right directions, than one where the maintainer one day just up and pulls the repos, leaving users and systems stranded due to whatever circumstances.

I'm always in for getting out the pitchforks, where necessary, but I don't really see the ill intentions or trust being breached here. 🤨

9 minutes ago, Rysz said:

I don't see the larger issue, as far as I can tell it was clearly offered in the GUI to disable metrics collection and nothing of any value whatsoever was being transmitted here. So I'm not sure how transmitting a hash of a hash and some application versions is a breach of trust for some here. If you look at https://docs.unraid.net/connect/privacy/ then Unraid itself also records minimal information that aids development, which should be a good thing for everyone.

Ultimately, plugins are free pieces of software, that nobody is forcing you to use, in fact most commercial applications collect far more information and are almost always opt-out (if at all). I can only speak for myself, but I'd rather use a well maintained FOSS plugin that uses metrics to channel development in the right directions, than one where the maintainer one day just up and pulls the repos, leaving users and systems stranded due to whatever circumstances.

I'm always in for getting out the pitchforks, where necessary, but I don't really see the ill intentions or trust being breached here. 🤨

There isnt a larger issue. The issue at hand was that its a dickmove to display version from EDACerton as update instead of a new plugin and then enable tracking by default. thats all.

The nitpick with the guid is that you can tie all plugins tied to that person/usb.


I personally dont care for the tailscaile one, although its worth noting that that one is something LT has to deal with at some point since its their "official" plugin and they do buisness within the EU. (Not to mention that the "offical" plugin is sending data to 3rd parties")

2 minutes ago, Mainfrezzer said:

There isnt a larger issue. The issue at hand was that its a dickmove to display version from EDACerton as update instead of a new plugin and then enable tracking by default. thats all.

The nitpick with the guid is that you can tie all plugins tied to that person/usb.


I personally dont care for the tailscaile one, although its worth noting that that one is something LT has to deal with at some point since its their "official" plugin and they do buisness within the EU. (Not to mention that the "offical" plugin is sending data to 3rd parties")

Sorry but that's just ridiculous, you may not agree with his collection of information, but there's no realistic scenario in which he could reverse-engineer a one-way cryptographic hash of a meaningless GUID back to that meaningless GUID and then tie that to your person all without having access to LT's own database. Even by strictest EU standards this would 100% be dismissed by anyone somewhat competent with these regulations, and conforms with what many companies and software developers already do without even offering the comfort of opt-out or being transparent about it.

4 minutes ago, Rysz said:

Sorry but that's just ridiculous, you may not agree with his collection of information, but there's no realistic scenario in which he could reverse-engineer a one-way cryptographic hash of a meaningless GUID back to that meaningless GUID and then tie that to your person all without having access to LT's own database. Even by strictest EU standards this would 100% be dismissed by anyone somewhat competent with these regulations, and conforms with what many companies and software developers already do without even offering the comfort of opt-out or being transparent about it.

youre mixing things here.

My nitpick was about the anonymous part. using an install id instead of something that only changes when you swap your usb. Also that hash just a checksum. Could have just used md5. Doesnt matter that in the end, you can see which server has which plugins of yours installed. Thats my personal nitpick with it

The EU part is separate and i honestly dont care since i dont have to deal with it, neither does EDACerton. LT has.

i'd think if LT was worried they wouldn't have been ok with it when EDACerton got the ok to do it.

Edited May 25, 20251 yr by jcofer555

6 minutes ago, jcofer555 said:

i'd think if LT was worried they wouldn't have been ok when EDACerton got the ok to do it.

Again, the issue is still not the stupid flash drive guid.

The issue with the EU is, that LT has slapped their LT-Official on the Tailscail plugin that sends data to a 3rd party by default without aquiring conscent prior to it.

I dont need to mention the horrendous cookie banners do i? (Although to incorportate the constant guid focus of everyone here, its actually a more horrible identifier than the random cookie id you get)

2 minutes ago, Mainfrezzer said:

Again, the issue is still not the stupid flash drive guid.

The issue with the EU is, that LT has slapped their LT-Official on the Tailscail plugin that sends data to a 3rd party by default without aquiring conscent prior to it.

I dont need to mention the horrendous cookie banners do i? (Although to incorportate the constant guid focus of everyone here, its actually a more horrible identifier than the random cookie id you get)

I still don't see how privacy laws would apply here when the data cannot realistically be linked back to a person. A USB stick is not a person. Everyone likes to play data privacy warrior, but it's not as simple as you make it out to be. Nobody is forcing you to use the plugin, it's as simple as clicking a button to remove it.

Not every data collection needs consent, I'm no expert on the topic either but I feel you're just being overly alarmist about this now.

i could only say again i'm sure if LT was worried they wouldn't have been ok with it. i think it's a non issue myself but eh maybe big bad lawsuit is coming

8 minutes ago, Rysz said:

I still don't see how privacy laws would apply here when the data cannot realistically be linked back to a person. A USB stick is not a person. Everyone likes to play data privacy warrior, but it's not as simple as you make it out to be. Nobody is forcing you to use the plugin, it's as simple as clicking a button to remove it.

Not every data collection needs consent, I'm no expert on the topic either but I feel you're just being overly alarmist about this now.

A cookie isnt a person either and neither do you have to use the site the banners are on too, yet theyre still there ;)

Its correct that data collection doesnt need constent, but those are only those that are technically required to make the page/work function (you actually dont need cookies at all but i digress)

As i said before, i dont care about it. I just wanted to mention it, as that one is a specific case.

4 minutes ago, jcofer555 said:

i could only say again i'm sure if LT was worried they wouldn't have been ok with it. i think it's a non issue myself but eh maybe big bad lawsuit is coming

I dont think it will, who knows. At some point we will know i guess.



to get back to the topic of this whole thread.

1 hour ago, Mainfrezzer said:

There isnt a larger issue. The issue at hand was that its a dickmove to display version from EDACerton as update instead of a new plugin and then enable tracking by default. thats all.

that was my only "complaint" i had with this specific plugin.( Im aware that this wasnt EDACertons doing. And to make absolutely clear, i dont hate or dislike him in any shape or form, neither do i have an issue with him having it in plugins in general. ) That has been resolved now, with the original being back up.

I noticed there was an update to the plugin. Thank you for bringing it "back".

7 hours ago, Mainfrezzer said:

Also that hash just a checksum. Could have just used md5.

Actually, no.

Using md5 would not provide privacy like crc32 does. Here's why:

The Unraid flash GUID is 96 bits. md5 provides a 128-bit hash -- so reverse engineering that back to the original GUID would be trivial (since it'll provide a unique hash per GUID).

crc32, however, provides 32 bits of data. That means that, for every 32-bit clientID, there are 2^64 = 18,446,744,073,709,551,616 possible flash GUIDs that it could have come from -- and no way to figure out which one it was.

However, let's be even more particular, since technically the first 32 bits of the flash GUID aren't completely random (they're the USB vendor and device IDs from the flash drive). That leaves us with 2^32 (the total number of flash drive models in existence). For the sake of argument, then, let's go with an absurdly low number and assume that there are only 10 flash drive models in the world. That leaves us with 2^32 * 10 = 42,949,672,960 possible GUIDs. (And in reality, that 42-billion number is actually much, much larger.)

And finally, if we're going to make comparisons to browser cookies, a more accurate analogy would be the User-Agent string that your browser sends with every request, to every web site, which provides the running browser/version and OS of the device.

Edited May 25, 20251 yr by EDACerton

17 minutes ago, EDACerton said:

Actually, no.

Using md5 would not provide privacy like crc32 does. Here's why:

The Unraid flash GUID is 96 bits. md5 provides a 128-bit hash -- so reverse engineering that back to the original GUID would be trivial (since it'll provide a unique hash per GUID).

crc32, however, provides 32 bits of data. That means that, for every 32-bit clientID, there are 2^64 = 18,446,744,073,709,551,616 possible flash GUIDs that it could have come from -- and no way to figure out which one it was.

However, let's be even more particular, since technically the first 32 bits of the flash GUID aren't completely random (they're the USB vendor and device IDs from the flash drive). That leaves us with 2^32 (the total number of flash drive models in existence). For the sake of argument, then, let's go with an absurdly low number and assume that there are only 10 flash drive models in the world. That leaves us with 2^32 * 10 = 42,949,672,960 possible GUIDs. (And in reality, that 42-billion number is actually much, much larger.)

And finally, if we're going to make comparisons to browser cookies, a more accurate analogy would be the User-Agent string that your browser sends with every request, to every web site, which provides the running browser/version and OS of the device.

the thing isnt about restoring the original guid, its that the hash is always static(unless your usb stick dies). You can see which hash has which of your plugins installed and subsequently you have the ability to track that particular hash and their interactions with your plugins. Not saying that youre doing it, its just a feasible possibilty and thats where my nitpick about being anonymous comes from as its lacking any kind of entropy.

5 minutes ago, Mainfrezzer said:

the thing isnt about restoring the original guid, its that the hash is always static(unless your usb stick dies). You can see which hash has which of your plugins installed and subsequently you have the ability to track that particular hash and their interactions with your plugins. Not saying that youre doing it, its just a feasible possibilty and thats where my nitpick about being anonymous comes from as its lacking any kind of entropy.

[random, unidentifiable value] installed multiple plugins. There's no privacy implication to that. It doesn't make it less anonymous.

Edited May 25, 20251 yr by EDACerton

Thanks @EDACerton for forking these plugins when they were removed, and I believe you have some enhancements planned too, which is cool.

Thanks for going ahead and removing the telemetry, this is something we were aware of but didn't have good policies for. Although I think you were doing it well and with user privacy in mind, I expect we'll work on a policy for that and ultimately provide a more global solution for optionally reporting telemetry from plugins.

Getting file activity logged on pool.

Also got some logging of things happening on the domain share (that is cache/pool only and SSD)

I only want things happening on the array (HDD) logged. Nothing else.

tempdata is pool device (HDD). tempdrive is the share.


Latest EDACerton version.

Edited June 2, 20251 yr by Niklas

i was about to report the plugin for some reason mark as unknown to CA and I find the whole thread with tons of answers and more 🤷‍♂️

2025.06.08 has been released, which includes various improvements to the backend processing, and also a new and improved display.

@Niklas , I haven't forgotten about you, the backend improvements in this release are the first phase of improving how disks are detected/handled. :)