Hello again, folks! Efya
There has been some discussion across recent threads about standard
macOS uninstallation behaviour rCo specifically whether dragging an application bundle ('App') to the Bin is sufficient for all software.
For most applications, it is. Self-contained, sandboxed apps leave
nothing behind that matters, and dragging to the Bin is perfectly
adequate. However, a distinct technical exception applies to utilities
that require elevated privileges to scan system hardware, read
restricted logs, or monitor storage health.
EtreCheck is a prime example of this class of software.
To perform its deep system analysis, EtreCheck installs a *Privileged
Helper Tool* rCo an elevated background daemon that requires admin authorisation on first run. This is entirely legitimate behaviour, but
it has a practical consequence for uninstallation.
*The problem with "drag to Bin" for this category of software*:-
1. *The App Bundle* rCo Dragging the `.app` to the Bin removes the user- facing interface, as expected.
2. *The Lingering Daemon* rCo macOS does not automatically unregister or remove privileged helpers when their parent app is trashed.
3. *The Binary* rCo The helper executable persists in the root-level directory `/Library/PrivilegedHelperTools/`.
4. *The Property Lists* rCo Associated configuration files remain in the system launch directories.
For ordinary apps that only write to `~/Library/Application Support/` or `~/Library/Caches/`, this isn't a concern rCo those files are dormant and easily ignored or removed. But when a utility has installed a persistent background daemon that survives deletion of the main app bundle, a
dedicated uninstaller (or at minimum an inline **Uninstall** menu
option) is not just courteous rCo it's the correct design choice. Without one, users are left manually navigating root-level directories to remove components most wouldn't know to look for.
Hopefully this clarifies things for anyone tracking file-system
behaviour or managing utility software on their Macs.
You own me an apology for your nonsense. And EtreCheck's developer.
Brock McNuggets <brock.mcnuggets@gmail.com> news:6a16ffde$0$47728$882e4bbb@reader.netnews.com Wed, 27 May 2026
14:29:50 GMT in alt.computer.workshop, wrote:
You own me an apology for your nonsense. And EtreCheck's developer.
He owes several people apologies for his nonsense.
As do you with your--
nonsensical bullshit lies. The two of you are like peas in a pod. It's hilarious watching the two of you call each other out and essentially repeat what the majority of us already know about both. One dishonest dumbass leading
a completely dishonest moron is what we are witnessing here. It's funny as fuck!
On May 27, 2026 at 7:03:48rC>AM MST, ""David B."" wrote <n7obu5F9snuU1@mid.individual.net>:
Hello again, folks! Efya
There has been some discussion across recent threads about standard
macOS uninstallation behaviour rCo specifically whether dragging an
application bundle ('App') to the Bin is sufficient for all software.
For most applications, it is. Self-contained, sandboxed apps leave
nothing behind that matters, and dragging to the Bin is perfectly
adequate. However, a distinct technical exception applies to utilities
that require elevated privileges to scan system hardware, read
restricted logs, or monitor storage health.
EtreCheck is a prime example of this class of software.
To perform its deep system analysis, EtreCheck installs a *Privileged
Helper Tool* rCo an elevated background daemon that requires admin
authorisation on first run. This is entirely legitimate behaviour, but
it has a practical consequence for uninstallation.
*The problem with "drag to Bin" for this category of software*:-
1. *The App Bundle* rCo Dragging the `.app` to the Bin removes the user-
facing interface, as expected.
2. *The Lingering Daemon* rCo macOS does not automatically unregister or
remove privileged helpers when their parent app is trashed.
3. *The Binary* rCo The helper executable persists in the root-level
directory `/Library/PrivilegedHelperTools/`.
4. *The Property Lists* rCo Associated configuration files remain in the
system launch directories.
For ordinary apps that only write to `~/Library/Application Support/` or
`~/Library/Caches/`, this isn't a concern rCo those files are dormant and
easily ignored or removed. But when a utility has installed a persistent
background daemon that survives deletion of the main app bundle, a
dedicated uninstaller (or at minimum an inline **Uninstall** menu
option) is not just courteous rCo it's the correct design choice. Without
one, users are left manually navigating root-level directories to remove
components most wouldn't know to look for.
Hopefully this clarifies things for anyone tracking file-system
behaviour or managing utility software on their Macs.
This is a decent description of Privileged Helper Tools in general rCo unfortunately it describes a problem that the evidence refuses to cooperate with.
https://shottr.cc/s/PDfQ/SCR-20260527-b1c
This is screensho showing AppCleaner's complete findings for EtreCheckPro. AppCleaner specifically scans /Library/PrivilegedHelperTools/ and /Library/LaunchDaemons/ rCo hunting down exactly these kinds of remnants is rather the whole point of the application. The result? Seven items, every single one sitting in perfectly ordinary user ~/Library/ locations. No daemon.
No privileged helper. Nothing that survives a reboot, let alone plots against you in the background.
You can verify this in about eight seconds. Open Terminal and type:
ls /Library/PrivilegedHelperTools/
If there's no com.etresoft.* entry, the centrepiece of your argument evaporates rCo and what AppCleaner found is exactly what I've been saying all along: standard, dormant, utterly unremarkable Library files that every Mac app leaves behind.
Which brings us to the .plist. A .plist is a small XML file that remembers things like your window position and preferred settings. It does not run. It does not phone home. It does not lurk. It just sits there, taking up 4 KB, waiting for an app that may never come back. Every application on your Mac left one behind rCo including whatever you used to compose this post. Raising the alarm about a .plist file is the digital equivalent of reporting a restaurant to the health inspector because they wrote your name on a notepad.
You own me an apology for your nonsense. And EtreCheck's developer.
On 27/05/2026 15:29, Brock McNuggets wrote:
On May 27, 2026 at 7:03:48rC>AM MST, ""David B."" wrote
<n7obu5F9snuU1@mid.individual.net>:
Hello again, folks! Efya
There has been some discussion across recent threads about standard
macOS uninstallation behaviour rCo specifically whether dragging an
application bundle ('App') to the Bin is sufficient for all software.
For most applications, it is. Self-contained, sandboxed apps leave
nothing behind that matters, and dragging to the Bin is perfectly
adequate. However, a distinct technical exception applies to utilities
that require elevated privileges to scan system hardware, read
restricted logs, or monitor storage health.
EtreCheck is a prime example of this class of software.
To perform its deep system analysis, EtreCheck installs a *Privileged
Helper Tool* rCo an elevated background daemon that requires admin
authorisation on first run. This is entirely legitimate behaviour, but
it has a practical consequence for uninstallation.
*The problem with "drag to Bin" for this category of software*:-
1. *The App Bundle* rCo Dragging the `.app` to the Bin removes the user- >>> facing interface, as expected.
2. *The Lingering Daemon* rCo macOS does not automatically unregister or >>> remove privileged helpers when their parent app is trashed.
3. *The Binary* rCo The helper executable persists in the root-level
directory `/Library/PrivilegedHelperTools/`.
4. *The Property Lists* rCo Associated configuration files remain in the >>> system launch directories.
For ordinary apps that only write to `~/Library/Application Support/` or >>> `~/Library/Caches/`, this isn't a concern rCo those files are dormant and >>> easily ignored or removed. But when a utility has installed a persistent >>> background daemon that survives deletion of the main app bundle, a
dedicated uninstaller (or at minimum an inline **Uninstall** menu
option) is not just courteous rCo it's the correct design choice. Without >>> one, users are left manually navigating root-level directories to remove >>> components most wouldn't know to look for.
Hopefully this clarifies things for anyone tracking file-system
behaviour or managing utility software on their Macs.
This is a decent description of Privileged Helper Tools in general rCo
unfortunately it describes a problem that the evidence refuses to cooperate >> with.
https://shottr.cc/s/PDfQ/SCR-20260527-b1c
This is screensho showing AppCleaner's complete findings for EtreCheckPro. >> AppCleaner specifically scans /Library/PrivilegedHelperTools/ and
/Library/LaunchDaemons/ rCo hunting down exactly these kinds of remnants is >> rather the whole point of the application. The result? Seven items, every
single one sitting in perfectly ordinary user ~/Library/ locations. No daemon.
No privileged helper. Nothing that survives a reboot, let alone plots against
you in the background.
You can verify this in about eight seconds. Open Terminal and type:
ls /Library/PrivilegedHelperTools/
If there's no com.etresoft.* entry, the centrepiece of your argument
evaporates rCo and what AppCleaner found is exactly what I've been saying all
along: standard, dormant, utterly unremarkable Library files that every Mac >> app leaves behind.
Which brings us to the .plist. A .plist is a small XML file that remembers >> things like your window position and preferred settings. It does not run. It >> does not phone home. It does not lurk. It just sits there, taking up 4 KB, >> waiting for an app that may never come back. Every application on your Mac >> left one behind rCo including whatever you used to compose this post. Raising
the alarm about a .plist file is the digital equivalent of reporting a
restaurant to the health inspector because they wrote your name on a notepad.
You own me an apology for your nonsense. And EtreCheck's developer.
There is no need for an apology, Brock, because you are looking at a
clean room
and concluding the house was never built.
Earlier today in the "Screenshot!" thread, you explicitly stated: "I
believe I
deleted them since the last time we discussed this." Running a third-
party uninstallation utility after you have already deleted the software
and its components is not a benchmark for what the software installs
during live operation.
For the benefit of the group, here is how EtreCheck's architecture
actually functions:
The main application bundle runs in standard user space. However, when a
user initiates
tasks that require root privilegesrCosuch as reading restricted system
logs, running advanced storage diagnostics, or granting "Full Disk
Access" for deeper malware scansrCoEtreCheck explicitly prompts the user
for an administrator password.
It is at that specific moment of authorization that macOS copies and registers the
privileged helper tool into:/Library/PrivilegedHelperTools/com.etresoft.EtreCheckHelper
If a user runs EtreCheck in a limited, surface-level capacity without
ever triggering
or granting those elevated administrative tasks, the helper tool is not deployed. But for users utilizing the full diagnostic suite, that binary
is explicitly installedrCoand dragging the .app bundle to the Bin
afterwards does not trigger macOS to remove it.
My technical note stands exactly as written. The persistence of
privileged helper
tools is a well-documented behavioral trait of macOS, and understanding
when and how they are installed is key to managing a clean file system.-- David
Hello again, folks! Efya
There has been some discussion across recent threads about standard
macOS uninstallation behaviour rCo specifically whether dragging an application bundle ('App') to the Bin is sufficient for all software.
For most applications, it is. Self-contained, sandboxed apps leave
nothing behind that matters, and dragging to the Bin is perfectly
adequate. However, a distinct technical exception applies to utilities
that require elevated privileges to scan system hardware, read
restricted logs, or monitor storage health.
EtreCheck is a prime example of this class of software.
To perform its deep system analysis, EtreCheck installs a *Privileged
Helper Tool* rCo an elevated background daemon that requires admin authorisation on first run. This is entirely legitimate behaviour, but
it has a practical consequence for uninstallation.
*The problem with "drag to Bin" for this category of software*:-
1. *The App Bundle* rCo Dragging the `.app` to the Bin removes the user- facing interface, as expected.
2. *The Lingering Daemon* rCo macOS does not automatically unregister or remove privileged helpers when their parent app is trashed.
3. *The Binary* rCo The helper executable persists in the root-level directory `/Library/PrivilegedHelperTools/`.
4. *The Property Lists* rCo Associated configuration files remain in the system launch directories.
For ordinary apps that only write to `~/Library/Application Support/` or `~/Library/Caches/`, this isn't a concern rCo those files are dormant and easily ignored or removed. But when a utility has installed a persistent background daemon that survives deletion of the main app bundle, a
dedicated uninstaller (or at minimum an inline **Uninstall** menu
option) is not just courteous rCo it's the correct design choice. Without one, users are left manually navigating root-level directories to remove components most wouldn't know to look for.
Hopefully this clarifies things for anyone tracking file-system
behaviour or managing utility software on their Macs.
On May 27, 2026 at 10:34:51rC>AM MST, ""David B."" wrote <n7oo9rFbpdcU1@mid.individual.net>:<ANOTHER BIG SIGH>!
On 27/05/2026 15:29, Brock McNuggets wrote:
On May 27, 2026 at 7:03:48rC>AM MST, ""David B."" wrote
<n7obu5F9snuU1@mid.individual.net>:
Hello again, folks! Efya
There has been some discussion across recent threads about standard
macOS uninstallation behaviour rCo specifically whether dragging an
application bundle ('App') to the Bin is sufficient for all software.
For most applications, it is. Self-contained, sandboxed apps leave
nothing behind that matters, and dragging to the Bin is perfectly
adequate. However, a distinct technical exception applies to utilities >>>> that require elevated privileges to scan system hardware, read
restricted logs, or monitor storage health.
EtreCheck is a prime example of this class of software.
To perform its deep system analysis, EtreCheck installs a *Privileged
Helper Tool* rCo an elevated background daemon that requires admin
authorisation on first run. This is entirely legitimate behaviour, but >>>> it has a practical consequence for uninstallation.
*The problem with "drag to Bin" for this category of software*:-
1. *The App Bundle* rCo Dragging the `.app` to the Bin removes the user- >>>> facing interface, as expected.
2. *The Lingering Daemon* rCo macOS does not automatically unregister or >>>> remove privileged helpers when their parent app is trashed.
3. *The Binary* rCo The helper executable persists in the root-level
directory `/Library/PrivilegedHelperTools/`.
4. *The Property Lists* rCo Associated configuration files remain in the >>>> system launch directories.
For ordinary apps that only write to `~/Library/Application Support/` or >>>> `~/Library/Caches/`, this isn't a concern rCo those files are dormant and >>>> easily ignored or removed. But when a utility has installed a persistent >>>> background daemon that survives deletion of the main app bundle, a
dedicated uninstaller (or at minimum an inline **Uninstall** menu
option) is not just courteous rCo it's the correct design choice. Without >>>> one, users are left manually navigating root-level directories to remove >>>> components most wouldn't know to look for.
Hopefully this clarifies things for anyone tracking file-system
behaviour or managing utility software on their Macs.
This is a decent description of Privileged Helper Tools in general rCo
unfortunately it describes a problem that the evidence refuses to cooperate >>> with.
https://shottr.cc/s/PDfQ/SCR-20260527-b1c
This is screensho showing AppCleaner's complete findings for EtreCheckPro. >>> AppCleaner specifically scans /Library/PrivilegedHelperTools/ and
/Library/LaunchDaemons/ rCo hunting down exactly these kinds of remnants is >>> rather the whole point of the application. The result? Seven items, every >>> single one sitting in perfectly ordinary user ~/Library/ locations. No daemon.
No privileged helper. Nothing that survives a reboot, let alone plots against
you in the background.
You can verify this in about eight seconds. Open Terminal and type:
ls /Library/PrivilegedHelperTools/
If there's no com.etresoft.* entry, the centrepiece of your argument
evaporates rCo and what AppCleaner found is exactly what I've been saying all
along: standard, dormant, utterly unremarkable Library files that every Mac >>> app leaves behind.
Which brings us to the .plist. A .plist is a small XML file that remembers >>> things like your window position and preferred settings. It does not run. It
does not phone home. It does not lurk. It just sits there, taking up 4 KB, >>> waiting for an app that may never come back. Every application on your Mac >>> left one behind rCo including whatever you used to compose this post. Raising
the alarm about a .plist file is the digital equivalent of reporting a
restaurant to the health inspector because they wrote your name on a notepad.
You own me an apology for your nonsense. And EtreCheck's developer.
There is no need for an apology, Brock, because you are looking at a
clean room
and concluding the house was never built.
Earlier today in the "Screenshot!" thread, you explicitly stated: "I
believe I
deleted them since the last time we discussed this." Running a third-
party uninstallation utility after you have already deleted the software
and its components is not a benchmark for what the software installs
during live operation.
For the benefit of the group, here is how EtreCheck's architecture
actually functions:
The main application bundle runs in standard user space. However, when a
user initiates
tasks that require root privilegesrCosuch as reading restricted system
logs, running advanced storage diagnostics, or granting "Full Disk
Access" for deeper malware scansrCoEtreCheck explicitly prompts the user
for an administrator password.
It is at that specific moment of authorization that macOS copies and
registers the
privileged helper tool
into:/Library/PrivilegedHelperTools/com.etresoft.EtreCheckHelper
If a user runs EtreCheck in a limited, surface-level capacity without
ever triggering
or granting those elevated administrative tasks, the helper tool is not
deployed. But for users utilizing the full diagnostic suite, that binary
is explicitly installedrCoand dragging the .app bundle to the Bin
afterwards does not trigger macOS to remove it.
My technical note stands exactly as written. The persistence of
privileged helper
tools is a well-documented behavioral trait of macOS, and understanding
when and how they are installed is key to managing a clean file system.--
David
I just ran it. Full scan. Nothing where you say in /Library/PrivilegedHelperTools/
Even if there was, you would need to show it ran without EtreCheck running -- even when deleted.
You have not. Not will you because you are in over your head and have no clue what you are talking about.
David, PLEASE stop making a complete idiot of yourself. And I have allowed you
to waste my time on software I do not care about... all to help you learn (something you seem immune to on this issue) and to help defend software and a
developer you keep attacking with your paranoia and ignorance.
On May 27, 2026 at 7:03:48rC>AM MST, ""David B."" wrote <n7obu5F9snuU1@mid.individual.net>:
Hello again, folks! Efya
There has been some discussion across recent threads about standard
macOS uninstallation behaviour rCo specifically whether dragging an
application bundle ('App') to the Bin is sufficient for all software.
For most applications, it is. Self-contained, sandboxed apps leave
nothing behind that matters, and dragging to the Bin is perfectly
adequate. However, a distinct technical exception applies to utilities
that require elevated privileges to scan system hardware, read
restricted logs, or monitor storage health.
EtreCheck is a prime example of this class of software.
To perform its deep system analysis, EtreCheck installs a *Privileged
Helper Tool* rCo an elevated background daemon that requires admin
authorisation on first run. This is entirely legitimate behaviour, but
it has a practical consequence for uninstallation.
*The problem with "drag to Bin" for this category of software*:-
1. *The App Bundle* rCo Dragging the `.app` to the Bin removes the user-
facing interface, as expected.
2. *The Lingering Daemon* rCo macOS does not automatically unregister or
remove privileged helpers when their parent app is trashed.
3. *The Binary* rCo The helper executable persists in the root-level
directory `/Library/PrivilegedHelperTools/`.
4. *The Property Lists* rCo Associated configuration files remain in the
system launch directories.
For ordinary apps that only write to `~/Library/Application Support/` or
`~/Library/Caches/`, this isn't a concern rCo those files are dormant and
easily ignored or removed. But when a utility has installed a persistent
background daemon that survives deletion of the main app bundle, a
dedicated uninstaller (or at minimum an inline **Uninstall** menu
option) is not just courteous rCo it's the correct design choice. Without
one, users are left manually navigating root-level directories to remove
components most wouldn't know to look for.
Hopefully this clarifies things for anyone tracking file-system
behaviour or managing utility software on their Macs.
OK, did more work FOR you. To help you.
There is no evidence EtreCheck does as you say and puts something in
/Library/LaunchDaemons/
/Library/PrivilegedHelperTools/
Or any other place where an uninstaller might be more useful. I even did a check in /Library/ for "EtreCheck" and found one item, and it was in:
/Library/Logs/DiagnosticReports/
No issue with that.
But guess what, even if it did have stuff there, that would not mean an uninstaller would be absolutely needed. Here:
https://www.telestream.net/telestream-support/screen-flow/help/Install.11.6.html
No uninstaller -- you have to manually go to:
/System/Library/Extensions/TelestreamAudio.kext
And delete it.
How about Windscribe?
https://windscribe.com/knowledge-base/articles/how-do-i-reinstall-the-windscribe-mac-app
This page talks about uninstalling it (even if the focus is on installing). Drag to trash and delete. But guess what... unlike EtreCheck it DOES leave things in the /Library folder.
/Library/LaunchDaemons/com.windscribe.helper.macos.plist
Can you find anyone with a shred of concern about this? I would say ideally they should have a simple way to do this -- apps like Zoom and TeamViewer do have ways in the app itself.
But you are not only wrong -- there is no such cruft left behind in /Library/ -- but even if there was you would STILL be making a mountain out of a molehill... whining about things you do not understand in the slightest.
David, I keep asking: stop these insane paranoid attacks against EtreCheck and
its developer. You are making a complete and utter fool of yourself and doing so in thread after thread and across multiple newsgroups.
On 27/05/2026 21:00, Brock McNuggets wrote:
On May 27, 2026 at 10:34:51rC>AM MST, ""David B."" wrote<ANOTHER BIG SIGH>!
<n7oo9rFbpdcU1@mid.individual.net>:
On 27/05/2026 15:29, Brock McNuggets wrote:
On May 27, 2026 at 7:03:48rC>AM MST, ""David B."" wrote
<n7obu5F9snuU1@mid.individual.net>:
Hello again, folks! Efya
There has been some discussion across recent threads about standard
macOS uninstallation behaviour rCo specifically whether dragging an
application bundle ('App') to the Bin is sufficient for all software. >>>>>
For most applications, it is. Self-contained, sandboxed apps leave
nothing behind that matters, and dragging to the Bin is perfectly
adequate. However, a distinct technical exception applies to utilities >>>>> that require elevated privileges to scan system hardware, read
restricted logs, or monitor storage health.
EtreCheck is a prime example of this class of software.
To perform its deep system analysis, EtreCheck installs a *Privileged >>>>> Helper Tool* rCo an elevated background daemon that requires admin
authorisation on first run. This is entirely legitimate behaviour, but >>>>> it has a practical consequence for uninstallation.
*The problem with "drag to Bin" for this category of software*:-
1. *The App Bundle* rCo Dragging the `.app` to the Bin removes the user- >>>>> facing interface, as expected.
2. *The Lingering Daemon* rCo macOS does not automatically unregister or >>>>> remove privileged helpers when their parent app is trashed.
3. *The Binary* rCo The helper executable persists in the root-level >>>>> directory `/Library/PrivilegedHelperTools/`.
4. *The Property Lists* rCo Associated configuration files remain in the >>>>> system launch directories.
For ordinary apps that only write to `~/Library/Application Support/` or >>>>> `~/Library/Caches/`, this isn't a concern rCo those files are dormant and >>>>> easily ignored or removed. But when a utility has installed a persistent >>>>> background daemon that survives deletion of the main app bundle, a
dedicated uninstaller (or at minimum an inline **Uninstall** menu
option) is not just courteous rCo it's the correct design choice. Without >>>>> one, users are left manually navigating root-level directories to remove >>>>> components most wouldn't know to look for.
Hopefully this clarifies things for anyone tracking file-system
behaviour or managing utility software on their Macs.
This is a decent description of Privileged Helper Tools in general rCo >>>> unfortunately it describes a problem that the evidence refuses to cooperate
with.
https://shottr.cc/s/PDfQ/SCR-20260527-b1c
This is screensho showing AppCleaner's complete findings for EtreCheckPro. >>>> AppCleaner specifically scans /Library/PrivilegedHelperTools/ and
/Library/LaunchDaemons/ rCo hunting down exactly these kinds of remnants is
rather the whole point of the application. The result? Seven items, every >>>> single one sitting in perfectly ordinary user ~/Library/ locations. No daemon.
No privileged helper. Nothing that survives a reboot, let alone plots against
you in the background.
You can verify this in about eight seconds. Open Terminal and type:
ls /Library/PrivilegedHelperTools/
If there's no com.etresoft.* entry, the centrepiece of your argument
evaporates rCo and what AppCleaner found is exactly what I've been saying all
along: standard, dormant, utterly unremarkable Library files that every Mac
app leaves behind.
Which brings us to the .plist. A .plist is a small XML file that remembers >>>> things like your window position and preferred settings. It does not run. It
does not phone home. It does not lurk. It just sits there, taking up 4 KB, >>>> waiting for an app that may never come back. Every application on your Mac >>>> left one behind rCo including whatever you used to compose this post. Raising
the alarm about a .plist file is the digital equivalent of reporting a >>>> restaurant to the health inspector because they wrote your name on a notepad.
You own me an apology for your nonsense. And EtreCheck's developer.
There is no need for an apology, Brock, because you are looking at a
clean room
and concluding the house was never built.
Earlier today in the "Screenshot!" thread, you explicitly stated: "I
believe I
deleted them since the last time we discussed this." Running a third-
party uninstallation utility after you have already deleted the software >>> and its components is not a benchmark for what the software installs
during live operation.
For the benefit of the group, here is how EtreCheck's architecture
actually functions:
The main application bundle runs in standard user space. However, when a >>> user initiates
tasks that require root privilegesrCosuch as reading restricted system
logs, running advanced storage diagnostics, or granting "Full Disk
Access" for deeper malware scansrCoEtreCheck explicitly prompts the user >>> for an administrator password.
It is at that specific moment of authorization that macOS copies and
registers the
privileged helper tool
into:/Library/PrivilegedHelperTools/com.etresoft.EtreCheckHelper
If a user runs EtreCheck in a limited, surface-level capacity without
ever triggering
or granting those elevated administrative tasks, the helper tool is not
deployed. But for users utilizing the full diagnostic suite, that binary >>> is explicitly installedrCoand dragging the .app bundle to the Bin
afterwards does not trigger macOS to remove it.
My technical note stands exactly as written. The persistence of
privileged helper
tools is a well-documented behavioral trait of macOS, and understanding
when and how they are installed is key to managing a clean file system.-- >>> David
I just ran it. Full scan. Nothing where you say in
/Library/PrivilegedHelperTools/
Even if there was, you would need to show it ran without EtreCheck running --
even when deleted.
You have not. Not will you because you are in over your head and have no clue
what you are talking about.
David, PLEASE stop making a complete idiot of yourself. And I have allowed you
to waste my time on software I do not care about... all to help you learn
(something you seem immune to on this issue) and to help defend software and a
developer you keep attacking with your paranoia and ignorance.
A standard "Full Scan" in EtreCheck does not automatically drop the
helper tool, Brock. That is entirely by design. The developer built the
core scanning engine to operate safely within regular user space so that
an everyday user doesn't have to input an admin password just to
generate a basic text report.
The privileged helper tool is explicitly gated behind specific, advanced operations within the apprCosuch as running low-level storage benchmarks
or choosing to execute root-level tasks that trigger a standard macOS
admin password prompt.
Until a user actively invokes a feature that requires that elevation,
macOS does not write the binary to the root directory.
However, the architecture to do so is permanently embedded in the application. Anyone can verify this in seconds without even running the app:
Right-click the EtreCheck application bundle and select Show Package Contents.
Navigate to /Contents/Library/LaunchServices/. Inside, you will find the dormant binary executable: com.etresoft.EtreCheckHelper.
Open the app's main Info.plist file. You will see the security key SMPrivilegedExecutables, which explicitly registers com.etresoft.EtreCheckHelper with macOS for system-level escalation.
As for your second point: I have never claimed the helper runs
continuously in the background after the main application is deleted. It
is managed by launchd as a launch-on-demand service.
The issue being discussed is file system persistence, not active CPU cycles.
The technical reality remains exactly as stated in the opening note:
once a user triggers a feature that requires administrative
authorization, macOS copies that helper binary to /Library/PrivilegedHelperTools/. When the user later drags the main .app bundle to the Bin, macOS leaves that root-level binary behind as a
permanent orphan.
Understanding the conditional nature of how and when these tools are
deployed is fundamental to understanding macOS file structure.
--
David
On 27/05/2026 21:31, Brock McNuggets wrote:
On May 27, 2026 at 7:03:48rC>AM MST, ""David B."" wrote
<n7obu5F9snuU1@mid.individual.net>:
Hello again, folks! Efya
There has been some discussion across recent threads about standard
macOS uninstallation behaviour rCo specifically whether dragging an
application bundle ('App') to the Bin is sufficient for all software.
For most applications, it is. Self-contained, sandboxed apps leave
nothing behind that matters, and dragging to the Bin is perfectly
adequate. However, a distinct technical exception applies to utilities
that require elevated privileges to scan system hardware, read
restricted logs, or monitor storage health.
EtreCheck is a prime example of this class of software.
To perform its deep system analysis, EtreCheck installs a *Privileged
Helper Tool* rCo an elevated background daemon that requires admin
authorisation on first run. This is entirely legitimate behaviour, but
it has a practical consequence for uninstallation.
*The problem with "drag to Bin" for this category of software*:-
1. *The App Bundle* rCo Dragging the `.app` to the Bin removes the user- >>> facing interface, as expected.
2. *The Lingering Daemon* rCo macOS does not automatically unregister or >>> remove privileged helpers when their parent app is trashed.
3. *The Binary* rCo The helper executable persists in the root-level
directory `/Library/PrivilegedHelperTools/`.
4. *The Property Lists* rCo Associated configuration files remain in the >>> system launch directories.
For ordinary apps that only write to `~/Library/Application Support/` or >>> `~/Library/Caches/`, this isn't a concern rCo those files are dormant and >>> easily ignored or removed. But when a utility has installed a persistent >>> background daemon that survives deletion of the main app bundle, a
dedicated uninstaller (or at minimum an inline **Uninstall** menu
option) is not just courteous rCo it's the correct design choice. Without >>> one, users are left manually navigating root-level directories to remove >>> components most wouldn't know to look for.
Hopefully this clarifies things for anyone tracking file-system
behaviour or managing utility software on their Macs.
OK, did more work FOR you. To help you.
There is no evidence EtreCheck does as you say and puts something in
/Library/LaunchDaemons/
/Library/PrivilegedHelperTools/
Or any other place where an uninstaller might be more useful. I even did a >> check in /Library/ for "EtreCheck" and found one item, and it was in:
/Library/Logs/DiagnosticReports/
No issue with that.
But guess what, even if it did have stuff there, that would not mean an
uninstaller would be absolutely needed. Here:
https://www.telestream.net/telestream-support/screen-flow/help/Install.11.6.html
No uninstaller -- you have to manually go to:
/System/Library/Extensions/TelestreamAudio.kext
And delete it.
How about Windscribe?
https://windscribe.com/knowledge-base/articles/how-do-i-reinstall-the-windscribe-mac-app
This page talks about uninstalling it (even if the focus is on installing). >> Drag to trash and delete. But guess what... unlike EtreCheck it DOES leave >> things in the /Library folder.
/Library/LaunchDaemons/com.windscribe.helper.macos.plist
Can you find anyone with a shred of concern about this? I would say ideally >> they should have a simple way to do this -- apps like Zoom and TeamViewer do >> have ways in the app itself.
But you are not only wrong -- there is no such cruft left behind in /Library/
-- but even if there was you would STILL be making a mountain out of a
molehill... whining about things you do not understand in the slightest.
David, I keep asking: stop these insane paranoid attacks against EtreCheck and
its developer. You are making a complete and utter fool of yourself and doing
so in thread after thread and across multiple newsgroups.
Thank you, Brock. You have just perfectly illustrated the exact
technical point of this entire thread.
By bringing up Windscribe's leftover background daemon plist, you are explicitly confirming my premise: when software utilizes root-level privileges, dropping the application bundle into the Bin leaves
persistent background configuration files or binaries behind in the
system directories.
As you quite rightly noted yourself, apps like Zoom and TeamViewer
provide an explicit, built-in mechanism to handle this cleanup because
they use these elevated privileges. That is precisely the design
standard I am highlighting.
Regarding your inability to find EtreCheck's privileged helper binary
during your basic scan: as explained in my concurrent post, the helper
is entirely conditional. The core scanning engine runs inside standard
user space. The helper tool (com.etresoft.EtreCheckHelper) is only
unpacked, registered, and written to /Library/PrivilegedHelperTools/
when a user executes specific, advanced tasks that trigger a standard
macOS administrative password prompt (such as the low-level drive
performance benchmark).
If you haven't triggered that admin elevation, the file won't be in your
root directory yet. However, the blueprint is permanently baked into the software. Anyone can verify this by right-clicking the EtreCheck app
bundle, selecting Show Package Contents, and looking inside /Contents/Library/LaunchServices/, or inspecting the
SMPrivilegedExecutables array in its main Info.plist.
There is no "paranoia" or "attack" here. Pointing out the architectural reality of how macOS manages privileged helper tools, how specific
software utilizes them, and why a standard "drag to Bin" leaves them
behind is a matter of basic system administration.
----
Kind regards,
David
On 27/05/2026 15:29, Brock McNuggets wrote:
[
https://shottr.cc/s/PDfQ/SCR-20260527-b1c
This is screensho showing AppCleaner's complete findings for
EtreCheckPro.
AppCleaner specifically scans /Library/PrivilegedHelperTools/ and
/Library/LaunchDaemons/ rCo hunting down exactly these kinds of remnants is >> rather the whole point of the application. The result? Seven items, every
single one sitting in perfectly ordinary user ~/Library/ locations. No
daemon.
No privileged helper. Nothing that survives a reboot, let alone plots
against
you in the background.
Please explain why MY finding has 9 entries, whilst your has only 7.
https://i.ibb.co/ZzFxjY5r/Screenshot-2026-05-28-at-12-26-44.png
Perhaps it's because I have paid for a full licence some weeks ago?
I did tell you! ;-)
MID <6a178095$0$26$882e4bbb@reader.netnews.com>
On May 27, 2026, Brock McNuggets posted:-
https://shottr.cc/s/Pv0B/SCR-20260527-o33
"Nope. Not there. Another place where you simply are trusting AI and not checking for yourself."
=
You are looking at the basic, free App Store version or an un-activated bundle, Brock.
The developer explicitly splits the architecture between the basic
user-space scanner and the advanced diagnostic features.
The privileged helper tool functionality is tied directly to the
EtreCheckPro activation and its advanced storage benchmark tools.
If you want to actually see the mechanics in action instead of looking
at a surface-level folder, try this exact test:
Open EtreCheckPro.Select the Storage
or Performance testing sections
that require low-level disk access.Watch for the standard macOS security dialogue box asking for your administrator password to allow the tool to measure raw drive performance.
The moment you authenticate that prompt, open your Terminal and run:ls
-la /Library/PrivilegedHelperTools/
You will see com.etresoft.EtreCheckHelper appear right there.
The mechanism isn't a hallucination; it is the standard SMJobBless API architecture that macOS uses to safely escalate privileges for specific diagnostic tools.
As we already established with your Windscribe example, the core issue
is that once a user grants that admin permission, dragging the main app
to the Trash leaves that privileged helper binary behind in the root
system folder.
No amount of looking at basic, un-triggered app bundles changes how the underlying operating system manages authorized helper tools.
"David B." <"David B."@invalid.org> news:n7ug66F8n7lU1@mid.individual.net Fri, 29 May 2026 21:53:10 GMT in alt.computer.workshop, wrote:
On 29/05/2026 22:19, pothead wrote:
If you are interested in bits and bytes left around after a removal of
a program you will have a field day with Windows and the registry.
Happy hunting.
That's all behind me now. I cut my teeth on Windows 3.1 and have used
nearly all the Microsoft operating systems up to Windows 10.
Yet you remain for all intents and purposes, a tech n00b. In all that time, you have less technical working knowledge of how the machine in front of you works than Snit.
That is NOT something you should be proud of. You have done as poorly with tech as you did flying. It's a shame you can't be forced to turn your computers in like you did your pilots wings. You had to turn those in for gross incompetence, too. You were deemed a danger to yourself, your own people and your own gear. The enemy would have nothing to fear from you.
It's a shame you can't be forced to turn your computers in like
you did your pilots wings. You had to turn those in for gross
incompetence, too.
On May 28, 2026 at 12:48:27rC>AM MST, ""David B."" wrote <n7qaabFj4hqU1@mid.individual.net>:
MID <6a178095$0$26$882e4bbb@reader.netnews.com>
On May 27, 2026, Brock McNuggets posted:-
https://shottr.cc/s/Pv0B/SCR-20260527-o33
"Nope. Not there. Another place where you simply are trusting AI and not
checking for yourself."
=
You are looking at the basic, free App Store version or an un-activated
bundle, Brock.
I am not going to pay for EtreCheck. Nope. Not gonna happen.
The developer explicitly splits the architecture between the basic
user-space scanner and the advanced diagnostic features.
The privileged helper tool functionality is tied directly to the
EtreCheckPro activation and its advanced storage benchmark tools.
If you want to actually see the mechanics in action instead of looking
at a surface-level folder, try this exact test:
Open EtreCheckPro.Select the Storage
https://shottr.cc/s/P4Mf/SCR-20260528-8gt
or Performance testing sections
that require low-level disk access.Watch for the standard macOS security
dialogue box asking for your administrator password to allow the tool to
measure raw drive performance.
The moment you authenticate that prompt, open your Terminal and run:ls
-la /Library/PrivilegedHelperTools/
David
-----
If you haven't triggered that admin elevation, the file won't
be in your root directory yet. However, the blueprint is
permanently baked into the software. Anyone can verify this
by right-clicking the EtreCheck app bundle, selecting Show
Package Contents, and looking inside
/Contents/Library/LaunchServices/
-----
https://shottr.cc/s/Pv0B/SCR-20260527-o33
You will see com.etresoft.EtreCheckHelper appear right there.
The mechanism isn't a hallucination; it is the standard SMJobBless API
architecture that macOS uses to safely escalate privileges for specific
diagnostic tools.
As we already established with your Windscribe example, the core issue
is that once a user grants that admin permission, dragging the main app
to the Trash leaves that privileged helper binary behind in the root
system folder.
This is not in contention.
No amount of looking at basic, un-triggered app bundles changes how the
underlying operating system manages authorized helper tools.
No evidence of you being correct, and even if you are about it having some helper in very specific situations, no evidence of it causing any harm.
On 28 May 2026 at 13:26:58 BST, "Brock McNuggets" <brock.mcnuggets@gmail.com> wrote:
On May 28, 2026 at 12:48:27rC>AM MST, ""David B."" wrote
<n7qaabFj4hqU1@mid.individual.net>:
MID <6a178095$0$26$882e4bbb@reader.netnews.com>
On May 27, 2026, Brock McNuggets posted:-
https://shottr.cc/s/Pv0B/SCR-20260527-o33
"Nope. Not there. Another place where you simply are trusting AI and not >>> checking for yourself."
=
You are looking at the basic, free App Store version or an un-activated
bundle, Brock.
I am not going to pay for EtreCheck. Nope. Not gonna happen.
It's a small price to pay for LOTS of information about one's computer! ;-)
The developer explicitly splits the architecture between the basic
user-space scanner and the advanced diagnostic features.
The privileged helper tool functionality is tied directly to the
EtreCheckPro activation and its advanced storage benchmark tools.
If you want to actually see the mechanics in action instead of looking
at a surface-level folder, try this exact test:
Open EtreCheckPro.Select the Storage
https://shottr.cc/s/P4Mf/SCR-20260528-8gt
Thank you for that!
or Performance testing sections
that require low-level disk access.Watch for the standard macOS security >>> dialogue box asking for your administrator password to allow the tool to >>> measure raw drive performance.
The moment you authenticate that prompt, open your Terminal and run:ls
-la /Library/PrivilegedHelperTools/
David
-----
If you haven't triggered that admin elevation, the file won't
be in your root directory yet. However, the blueprint is
permanently baked into the software. Anyone can verify this
by right-clicking the EtreCheck app bundle, selecting Show
Package Contents, and looking inside
/Contents/Library/LaunchServices/
-----
https://shottr.cc/s/Pv0B/SCR-20260527-o33
You will see com.etresoft.EtreCheckHelper appear right there.
The mechanism isn't a hallucination; it is the standard SMJobBless API
architecture that macOS uses to safely escalate privileges for specific
diagnostic tools.
As we already established with your Windscribe example, the core issue
is that once a user grants that admin permission, dragging the main app
to the Trash leaves that privileged helper binary behind in the root
system folder.
This is not in contention.
No amount of looking at basic, un-triggered app bundles changes how the
underlying operating system manages authorized helper tools.
No evidence of you being correct, and even if you are about it having some >> helper in very specific situations, no evidence of it causing any harm.
Another Usenet poster said this to me in an email message .....
"RE: the 'leaving things behind' argument, from my POV it's not malware (though, I acknowledge it's not completely impossible for that to happen)"
THAT is my only concern - that it might be possibe for malware to be stored surreptitiously in such hidden places.
It would be difficult to spot!
On 02/06/2026 04:37, Gremlin wrote:
"David B." <"David B."@invalid.org> news:n7ug66F8n7lU1@mid.individual.net
Fri, 29 May 2026 21:53:10 GMT in alt.computer.workshop, wrote:
On 29/05/2026 22:19, pothead wrote:
If you are interested in bits and bytes left around after a removal of >>>> a program you will have a field day with Windows and the registry.
Happy hunting.
That's all behind me now. I cut my teeth on Windows 3.1 and have used
nearly all the Microsoft operating systems up to Windows 10.
Yet you remain for all intents and purposes, a tech n00b. In all that time, >> you have less technical working knowledge of how the machine in front of you >> works than Snit.
That is NOT something you should be proud of. You have done as poorly with >> tech as you did flying. It's a shame you can't be forced to turn your
computers in like you did your pilots wings. You had to turn those in for
gross incompetence, too. You were deemed a danger to yourself, your own
people and your own gear. The enemy would have nothing to fear from you.
"Gremlin" <nobody@haph.org> wrote:
It's a shame you can't be forced to turn your computers in like
you did your pilots wings. You had to turn those in for gross
incompetence, too.
Your imagination is running wild again, Dustin.
My 1969 naval flying logbook records the standard, administrative
"Suspended from Flying Training. Flying Badge Removed" stamp from the
Naval Aircrew Advisory Board. It was standard service practice, not a dramatic court-martial for "gross incompetence."
Here's another copy, to save you 'digging back':-
https://i.ibb.co/3mkhnC3Q/Flying-Log-Book.jpg
I went on to serve in the Royal Navy for over 20 years, specialised in
air traffic control, was promoted to Lieutenant Commander, and chose
early retirement in 1983. (Under the 1981 Defence Review)
As for your "tech n00b" lectures, I managed to handle advanced naval
radar systems back when you were likely still in short trousers.
Feel free to keep screaming at the clouds, but do try to stick to facts
next time!
If you want to understand malware, you first need to understand how a system behaves when it's not infected.
It's like a doctor trying to diagnose an illness without knowing normal human anatomy. If they don't know what a healthy body looks like, every unusual finding looks suspicious.
On Jun 2, 2026 at 1:59:32rC>AM MST, ""David B."" wrote <n87kbkFm6lrU1@mid.individual.net>:
On 02/06/2026 04:37, Gremlin wrote:
"David B." <"David B."@invalid.org> news:n7ug66F8n7lU1@mid.individual.net >>> Fri, 29 May 2026 21:53:10 GMT in alt.computer.workshop, wrote:
On 29/05/2026 22:19, pothead wrote:
If you are interested in bits and bytes left around after a removal of >>>>> a program you will have a field day with Windows and the registry.
Happy hunting.
That's all behind me now. I cut my teeth on Windows 3.1 and have used
nearly all the Microsoft operating systems up to Windows 10.
Yet you remain for all intents and purposes, a tech n00b. In all that time, >>> you have less technical working knowledge of how the machine in front of you
works than Snit.
That is NOT something you should be proud of. You have done as poorly with >>> tech as you did flying. It's a shame you can't be forced to turn your
computers in like you did your pilots wings. You had to turn those in for >>> gross incompetence, too. You were deemed a danger to yourself, your own
people and your own gear. The enemy would have nothing to fear from you.
"Gremlin" <nobody@haph.org> wrote:
It's a shame you can't be forced to turn your computers in like
you did your pilots wings. You had to turn those in for gross
incompetence, too.
Your imagination is running wild again, Dustin.
My 1969 naval flying logbook records the standard, administrative
"Suspended from Flying Training. Flying Badge Removed" stamp from the
Naval Aircrew Advisory Board. It was standard service practice, not a
dramatic court-martial for "gross incompetence."
Here's another copy, to save you 'digging back':-
https://i.ibb.co/3mkhnC3Q/Flying-Log-Book.jpg
I went on to serve in the Royal Navy for over 20 years, specialised in
air traffic control, was promoted to Lieutenant Commander, and chose
early retirement in 1983. (Under the 1981 Defence Review)
As for your "tech n00b" lectures, I managed to handle advanced naval
radar systems back when you were likely still in short trousers.
Feel free to keep screaming at the clouds, but do try to stick to facts
next time!
Gremlin feels the need to make up stories about others -- putting them down, and about himself -- propping himself up. He tells the most amazing whoppers to try to make himself look better to others, but more importantly to himself.
On 02/06/2026 17:14, Brock McNuggets wrote:
On Jun 2, 2026 at 1:59:32rC>AM MST, ""David B."" wrote
<n87kbkFm6lrU1@mid.individual.net>:
On 02/06/2026 04:37, Gremlin wrote:
"David B." <"David B."@invalid.org> news:n7ug66F8n7lU1@mid.individual.net >>>> Fri, 29 May 2026 21:53:10 GMT in alt.computer.workshop, wrote:"Gremlin" <nobody@haph.org> wrote:
On 29/05/2026 22:19, pothead wrote:
If you are interested in bits and bytes left around after a removal of >>>>>> a program you will have a field day with Windows and the registry. >>>>>> Happy hunting.
That's all behind me now. I cut my teeth on Windows 3.1 and have used >>>>> nearly all the Microsoft operating systems up to Windows 10.
Yet you remain for all intents and purposes, a tech n00b. In all that time,
you have less technical working knowledge of how the machine in front of you
works than Snit.
That is NOT something you should be proud of. You have done as poorly with >>>> tech as you did flying. It's a shame you can't be forced to turn your
computers in like you did your pilots wings. You had to turn those in for >>>> gross incompetence, too. You were deemed a danger to yourself, your own >>>> people and your own gear. The enemy would have nothing to fear from you. >>>
It's a shame you can't be forced to turn your computers in like
you did your pilots wings. You had to turn those in for gross
incompetence, too.
Your imagination is running wild again, Dustin.
My 1969 naval flying logbook records the standard, administrative
"Suspended from Flying Training. Flying Badge Removed" stamp from the
Naval Aircrew Advisory Board. It was standard service practice, not a
dramatic court-martial for "gross incompetence."
Here's another copy, to save you 'digging back':-
https://i.ibb.co/3mkhnC3Q/Flying-Log-Book.jpg
I went on to serve in the Royal Navy for over 20 years, specialised in
air traffic control, was promoted to Lieutenant Commander, and chose
early retirement in 1983. (Under the 1981 Defence Review)
As for your "tech n00b" lectures, I managed to handle advanced naval
radar systems back when you were likely still in short trousers.
Feel free to keep screaming at the clouds, but do try to stick to facts
next time!
Gremlin feels the need to make up stories about others -- putting them down, >> and about himself -- propping himself up. He tells the most amazing whoppers >> to try to make himself look better to others, but more importantly to himself.
Nowadays, tradesmen are "the salt of the earth".
He should be proud of all he has achieved.
On Jun 2, 2026 at 1:58:41rC>PM MST, ""David B."" wrote <n88ug1FsjfjU1@mid.individual.net>:
On 02/06/2026 17:13, Brock McNuggets wrote:
[....]
On Jun 2, 2026, Brock McNuggets wrote:
If you want to understand malware, you first need to understand how a system
behaves when it's not infected.
It's like a doctor trying to diagnose an illness without knowing normal human
anatomy. If they don't know what a healthy body looks like, every unusual >>> finding looks suspicious.
I completely agree with your medical analogy, Brock. Establishing a
known-good baseline is fundamental to system triage.
However, you are misinterpreting my concern as a novice's confusion over
normal anatomy. Having actively investigated malware and system
anomalies since 2005, I am well aware of what a healthy macOS baseline
looks like, and I fully understand that legitimate applications utilize
background services, LaunchDaemons, and privileged helpers for low-level
tasks.
Evidence shows you are not familiar with this. You repeatedy ask about the user Library being hidden, about files in the ~/Library folder, etc. You get confused when you find that deleting an app does not delete these files.
You are not familiar with normal operations and still seek to find abnormal.
My concern is not with the existence of these tools; it is with poor
digital hygiene and "orphaned" persistence.
These files are left behind by design. It is then norm. Until you understand the norm, you cannot move forward.
When a developer uses the SMJobBless API to install a helper tool with
root privileges, but provides no mechanism to clean it up when the user
drags the main application to the Trash, they leave a persistent,
root-owned binary sitting silently in a system directory.
What is this even relevant to?
In the security world, we look at attack surfaces. An orphaned helper
tool left behind by a deleted application is an unnecessary liability.
Again: relevance?
If that helper tool has any undiscovered vulnerabilities or loose
permissions, it can be subverted by local malware for privilege
escalation. Furthermore, hidden, un-monitored system folders are the
exact real estate malware authors look for to achieve stealth persistence. >>
The issue isn't that legitimate software is malicious. The issue is that
lazy uninstallation methods leave the door unlatched, making the
system's "normal anatomy" harder to defend.
What are you referring to?
These files are left behind by design. It is then norm. Until you understand the norm, you cannot move forward.
What is this even relevant to?
Again: relevance?
What are you referring to?
On 2 Jun 2026 at 22:03:11 BST, "Brock McNuggets" <brock.mcnuggets@gmail.com> wrote:
On Jun 2, 2026 at 1:58:41rC>PM MST, ""David B."" wrote
<n88ug1FsjfjU1@mid.individual.net>:
On 02/06/2026 17:13, Brock McNuggets wrote:
[....]
On Jun 2, 2026, Brock McNuggets wrote:
If you want to understand malware, you first need to understand how a system
behaves when it's not infected.
It's like a doctor trying to diagnose an illness without knowing normal human
anatomy. If they don't know what a healthy body looks like, every unusual >>>> finding looks suspicious.
I completely agree with your medical analogy, Brock. Establishing a
known-good baseline is fundamental to system triage.
However, you are misinterpreting my concern as a novice's confusion over >>> normal anatomy. Having actively investigated malware and system
anomalies since 2005, I am well aware of what a healthy macOS baseline
looks like, and I fully understand that legitimate applications utilize
background services, LaunchDaemons, and privileged helpers for low-level >>> tasks.
Evidence shows you are not familiar with this. You repeatedy ask about the >> user Library being hidden, about files in the ~/Library folder, etc. You get >> confused when you find that deleting an app does not delete these files.
You are not familiar with normal operations and still seek to find abnormal. >>>
My concern is not with the existence of these tools; it is with poor
digital hygiene and "orphaned" persistence.
These files are left behind by design. It is then norm. Until you understand >> the norm, you cannot move forward.
When a developer uses the SMJobBless API to install a helper tool with
root privileges, but provides no mechanism to clean it up when the user
drags the main application to the Trash, they leave a persistent,
root-owned binary sitting silently in a system directory.
What is this even relevant to?
In the security world, we look at attack surfaces. An orphaned helper
tool left behind by a deleted application is an unnecessary liability.
Again: relevance?
If that helper tool has any undiscovered vulnerabilities or loose
permissions, it can be subverted by local malware for privilege
escalation. Furthermore, hidden, un-monitored system folders are the
exact real estate malware authors look for to achieve stealth persistence. >>>
The issue isn't that legitimate software is malicious. The issue is that >>> lazy uninstallation methods leave the door unlatched, making the
system's "normal anatomy" harder to defend.
What are you referring to?
<BIG SIGH>
On Jun 2, 2026, Brock McNuggets wrote:
These files are left behind by design. It is then norm. Until you understand >> the norm, you cannot move forward.
You are confusing a "common bad habit" with intentional operating system design, Michael.
Apple did not design macOS with the explicit goal of permanently cluttering up
the root /Library with orphaned, high-privilege binaries.
Apple actually
provides developers with the tools to handle uninstallation properly. If a developer uses SMJobBless to escalate privileges, they can just as easily use SMJobRemove to clean up that root-level helper when the user requests an uninstall or when the companion app is deleted.
The fact that many developers choose to leave their root tools lying around is
a result of lazy software hygiene, not Apple's architectural intent.
What is this even relevant to?
Again: relevance?
What are you referring to?
It is relevant to the exact topic of this thread: "Privileged Helpers, dragging to Trash, and EtreCheck."
Shouting "relevance" at basic cybersecurity concepts doesn't make them disappear. If an app is dragged to the Trash, and a root-owned helper is left behind in /Library/PrivilegedHelperTools/, that tool is entirely decoupled from the user's view.
If that orphaned tool has zero vulnerabilities, it is merely clutter. But if it possesses an unpatched flaw or loose permissions, it represents an attack surface. Local malware routinely exploits unmonitored, legacy privileged helpers left behind by legitimate software to achieve privilege escalation (moving from standard user to root).'
Instead of deflecting to irrelevant claims about my past threads, perhaps you could explain why you believe a permanent, unmonitored, root-privileged binary
left behind in a system folder is a textbook example of "good security design"?
On 02/06/2026 17:14, Brock McNuggets wrote:
On Jun 2, 2026 at 1:59:32rC>AM MST, ""David B."" wrote
<n87kbkFm6lrU1@mid.individual.net>:
On 02/06/2026 04:37, Gremlin wrote:
"David B." <"David B."@invalid.org> news:n7ug66F8n7lU1@mid.individual.net >>>> Fri, 29 May 2026 21:53:10 GMT in alt.computer.workshop, wrote:"Gremlin" <nobody@haph.org> wrote:
On 29/05/2026 22:19, pothead wrote:
If you are interested in bits and bytes left around after a removal of >>>>>> a program you will have a field day with Windows and the registry. >>>>>> Happy hunting.
That's all behind me now. I cut my teeth on Windows 3.1 and have used >>>>> nearly all the Microsoft operating systems up to Windows 10.
Yet you remain for all intents and purposes, a tech n00b. In all that time,
you have less technical working knowledge of how the machine in front of you
works than Snit.
That is NOT something you should be proud of. You have done as poorly with >>>> tech as you did flying. It's a shame you can't be forced to turn your
computers in like you did your pilots wings. You had to turn those in for >>>> gross incompetence, too. You were deemed a danger to yourself, your own >>>> people and your own gear. The enemy would have nothing to fear from you. >>>
It's a shame you can't be forced to turn your computers in like
you did your pilots wings. You had to turn those in for gross
incompetence, too.
Your imagination is running wild again, Dustin.
My 1969 naval flying logbook records the standard, administrative
"Suspended from Flying Training. Flying Badge Removed" stamp from the
Naval Aircrew Advisory Board. It was standard service practice, not a
dramatic court-martial for "gross incompetence."
Here's another copy, to save you 'digging back':-
https://i.ibb.co/3mkhnC3Q/Flying-Log-Book.jpg
I went on to serve in the Royal Navy for over 20 years, specialised in
air traffic control, was promoted to Lieutenant Commander, and chose
early retirement in 1983. (Under the 1981 Defence Review)
As for your "tech n00b" lectures, I managed to handle advanced naval
radar systems back when you were likely still in short trousers.
Feel free to keep screaming at the clouds, but do try to stick to facts
next time!
Gremlin feels the need to make up stories about others -- putting them down, >> and about himself -- propping himself up. He tells the most amazing whoppers >> to try to make himself look better to others, but more importantly to himself.
Nowadays, tradesmen are "the salt of the earth".
He should be proud of all he has achieved.
On 2 Jun 2026 at 22:46:26 BST, "Brock McNuggets" <brock.mcnuggets@gmail.com> wrote:
On Jun 2, 2026 at 2:21:49rC>PM MST, "David B." wrote
<6a1f496d$0$20$882e4bbb@reader.netnews.com>:
On 2 Jun 2026 at 22:03:11 BST, "Brock McNuggets" <brock.mcnuggets@gmail.com>
wrote:
On Jun 2, 2026 at 1:58:41rC>PM MST, ""David B."" wrote
<n88ug1FsjfjU1@mid.individual.net>:
On 02/06/2026 17:13, Brock McNuggets wrote:
[....]
On Jun 2, 2026, Brock McNuggets wrote:
If you want to understand malware, you first need to understand how a system
behaves when it's not infected.
It's like a doctor trying to diagnose an illness without knowing normal human
anatomy. If they don't know what a healthy body looks like, every unusual
finding looks suspicious.
I completely agree with your medical analogy, Brock. Establishing a
known-good baseline is fundamental to system triage.
However, you are misinterpreting my concern as a novice's confusion over >>>>> normal anatomy. Having actively investigated malware and system
anomalies since 2005, I am well aware of what a healthy macOS baseline >>>>> looks like, and I fully understand that legitimate applications utilize >>>>> background services, LaunchDaemons, and privileged helpers for low-level >>>>> tasks.
Evidence shows you are not familiar with this. You repeatedy ask about the >>>> user Library being hidden, about files in the ~/Library folder, etc. You get
confused when you find that deleting an app does not delete these files. >>>>
You are not familiar with normal operations and still seek to find abnormal.
My concern is not with the existence of these tools; it is with poor >>>>> digital hygiene and "orphaned" persistence.
These files are left behind by design. It is then norm. Until you understand
the norm, you cannot move forward.
When a developer uses the SMJobBless API to install a helper tool with >>>>> root privileges, but provides no mechanism to clean it up when the user >>>>> drags the main application to the Trash, they leave a persistent,
root-owned binary sitting silently in a system directory.
What is this even relevant to?
Again: relevance?
In the security world, we look at attack surfaces. An orphaned helper >>>>> tool left behind by a deleted application is an unnecessary liability. >>>>
If that helper tool has any undiscovered vulnerabilities or loose
permissions, it can be subverted by local malware for privilege
escalation. Furthermore, hidden, un-monitored system folders are the >>>>> exact real estate malware authors look for to achieve stealth persistence.
The issue isn't that legitimate software is malicious. The issue is that >>>>> lazy uninstallation methods leave the door unlatched, making the
system's "normal anatomy" harder to defend.
What are you referring to?
<BIG SIGH>
On Jun 2, 2026, Brock McNuggets wrote:
These files are left behind by design. It is then norm. Until you understand
the norm, you cannot move forward.
You are confusing a "common bad habit" with intentional operating system >>> design, Michael.
Apple did not design macOS with the explicit goal of permanently cluttering up
the root /Library with orphaned, high-privilege binaries.
What binaries are you talking about?
Apple actually
provides developers with the tools to handle uninstallation properly. If a >>> developer uses SMJobBless to escalate privileges, they can just as easily use
SMJobRemove to clean up that root-level helper when the user requests an >>> uninstall or when the companion app is deleted.
The fact that many developers choose to leave their root tools lying around is
a result of lazy software hygiene, not Apple's architectural intent.
What "root tools" are you referring to?
What is this even relevant to?
Again: relevance?
What are you referring to?
It is relevant to the exact topic of this thread: "Privileged Helpers,
dragging to Trash, and EtreCheck."
EtreCheck does not leave such. We already discussed this.
Again: you do not understand the norm, so you assume it doing what is normal >> is somehow bad.
Shouting "relevance" at basic cybersecurity concepts doesn't make them
disappear. If an app is dragged to the Trash, and a root-owned helper is left
behind in /Library/PrivilegedHelperTools/, that tool is entirely decoupled >>> from the user's view.
Remember you already acknowledged it does not do this. So you are talking
about... what?
If that orphaned tool has zero vulnerabilities, it is merely clutter. But if
it possesses an unpatched flaw or loose permissions, it represents an attack
surface. Local malware routinely exploits unmonitored, legacy privileged >>> helpers left behind by legitimate software to achieve privilege escalation >>> (moving from standard user to root).'
What tool are you talking about?
Instead of deflecting to irrelevant claims about my past threads, perhaps you
could explain why you believe a permanent, unmonitored, root-privileged binary
left behind in a system folder is a textbook example of "good security
design"?
I am just asking what tool you even mean. And sadly you do not know. You are >> going with AI, forgetting you went around and around with this before YOUR >> image showed your claim was not accurate.
You are insisting EtreCheck is doing something -- without being specific on >> what file -- that you already admitted it does not do.
On Jun 2, 2026, Brock McNuggets wrote:
What binaries are you talking about?
What "root tools" are you referring to?
What tool are you talking about? I am just asking what tool you even mean.
I am talking about com.etresoft.EtreCheckHelper.
Lest you forget your own participation in this thread, let's look at the timeline. I explained that EtreCheckPro contains a privileged helper blueprint
inside its bundle (/Contents/Library/LaunchServices/) used to execute low-level storage testing via the SMJobBless API.
I explicitly noted that if a user triggers that admin elevation, the root-owned binary is dropped into /Library/PrivilegedHelperTools/. I then explicitly stated that dragging the main app to the Trash leaves that privileged helper binary behind in the root folder.
Your exact response to that mechanical reality was, and I quote: "This is not in contention."
You explicitly admitted it was not in contention, Michael. Yet now, you are frantically typing "What tool?" and pretending the file doesn't exist, simply because you realized you cannot defend your subsequent claim that leaving orphaned root-privileged binaries behind is "by design."
The mechanics remain unchanged: com.etresoft.EtreCheckHelper uses SMJobBless. If triggered, it leaves a persistent binary behind upon a standard drag-to-trash uninstallation because it lacks an SMJobRemove routine. That is poor software hygiene, it creates an unnecessary attack surface, and no amount
of feigned ignorance changes the code.
I don't want to fight you over this, but I really do want you to understand.
On 2026-06-02, David B. <"David B."@invalid.org> wrote:
On 02/06/2026 17:14, Brock McNuggets wrote:
On Jun 2, 2026 at 1:59:32rC>AM MST, ""David B."" wrote
<n87kbkFm6lrU1@mid.individual.net>:
On 02/06/2026 04:37, Gremlin wrote:
"David B." <"David B."@invalid.org> news:n7ug66F8n7lU1@mid.individual.net >>>>> Fri, 29 May 2026 21:53:10 GMT in alt.computer.workshop, wrote:"Gremlin" <nobody@haph.org> wrote:
On 29/05/2026 22:19, pothead wrote:
If you are interested in bits and bytes left around after a removal of >>>>>>> a program you will have a field day with Windows and the registry. >>>>>>> Happy hunting.
That's all behind me now. I cut my teeth on Windows 3.1 and have used >>>>>> nearly all the Microsoft operating systems up to Windows 10.
Yet you remain for all intents and purposes, a tech n00b. In all that time,
you have less technical working knowledge of how the machine in front of you
works than Snit.
That is NOT something you should be proud of. You have done as poorly with
tech as you did flying. It's a shame you can't be forced to turn your >>>>> computers in like you did your pilots wings. You had to turn those in for >>>>> gross incompetence, too. You were deemed a danger to yourself, your own >>>>> people and your own gear. The enemy would have nothing to fear from you. >>>>
It's a shame you can't be forced to turn your computers in like
you did your pilots wings. You had to turn those in for gross
incompetence, too.
Your imagination is running wild again, Dustin.
My 1969 naval flying logbook records the standard, administrative
"Suspended from Flying Training. Flying Badge Removed" stamp from the
Naval Aircrew Advisory Board. It was standard service practice, not a
dramatic court-martial for "gross incompetence."
Here's another copy, to save you 'digging back':-
https://i.ibb.co/3mkhnC3Q/Flying-Log-Book.jpg
I went on to serve in the Royal Navy for over 20 years, specialised in >>>> air traffic control, was promoted to Lieutenant Commander, and chose
early retirement in 1983. (Under the 1981 Defence Review)
As for your "tech n00b" lectures, I managed to handle advanced naval
radar systems back when you were likely still in short trousers.
Feel free to keep screaming at the clouds, but do try to stick to facts >>>> next time!
Gremlin feels the need to make up stories about others -- putting them down,
and about himself -- propping himself up. He tells the most amazing whoppers
to try to make himself look better to others, but more importantly to himself.
Nowadays, tradesmen are "the salt of the earth".
He should be proud of all he has achieved.
Indeed.
A Harvard degree in gender studies is 100% useless and the $100k or more
that the student is left in debt, in the USA, makes it even worse.
Study something you have to physically touch.
The tech installing a major network in a large company is worth a heck of
a lot more than the network architect designing the system and who probably resides in some 3rd world country.
And AI will replace that person soon.
The trades are extremely lucrative especially now that the boomer generation is aging and needs help doing things that maybe they were able to do in the past.
I also applaud the current administration for digging into welfare/public assistance fraud both at the "factory level" and down to the individuals claiming checks each month who do not deserve them.
Those people are leeches, parasites, milking the system and when taken
as a whole, scam the taxpayers for a massive amount of money that could
go to help pay for those who truly deserve the government help as many do.
In the USA waste is extreme and needs to be stopped even if it is
one parasite at a time.
Yes. And then you realized you were in error and apologized.
A claim you have not shown and previously admitted was in error.
On 2026-06-02, David B. <"David B."@invalid.org> wrote:
On 02/06/2026 17:14, Brock McNuggets wrote:
On Jun 2, 2026 at 1:59:32rC>AM MST, ""David B."" wrote
<n87kbkFm6lrU1@mid.individual.net>:
On 02/06/2026 04:37, Gremlin wrote:
"David B." <"David B."@invalid.org> news:n7ug66F8n7lU1@mid.individual.net >>>>> Fri, 29 May 2026 21:53:10 GMT in alt.computer.workshop, wrote:"Gremlin" <nobody@haph.org> wrote:
On 29/05/2026 22:19, pothead wrote:
If you are interested in bits and bytes left around after a removal of >>>>>>> a program you will have a field day with Windows and the registry. >>>>>>> Happy hunting.
That's all behind me now. I cut my teeth on Windows 3.1 and have used >>>>>> nearly all the Microsoft operating systems up to Windows 10.
Yet you remain for all intents and purposes, a tech n00b. In all that time,
you have less technical working knowledge of how the machine in front of you
works than Snit.
That is NOT something you should be proud of. You have done as poorly with
tech as you did flying. It's a shame you can't be forced to turn your >>>>> computers in like you did your pilots wings. You had to turn those in for >>>>> gross incompetence, too. You were deemed a danger to yourself, your own >>>>> people and your own gear. The enemy would have nothing to fear from you. >>>>
It's a shame you can't be forced to turn your computers in like
you did your pilots wings. You had to turn those in for gross
incompetence, too.
Your imagination is running wild again, Dustin.
My 1969 naval flying logbook records the standard, administrative
"Suspended from Flying Training. Flying Badge Removed" stamp from the
Naval Aircrew Advisory Board. It was standard service practice, not a
dramatic court-martial for "gross incompetence."
Here's another copy, to save you 'digging back':-
https://i.ibb.co/3mkhnC3Q/Flying-Log-Book.jpg
I went on to serve in the Royal Navy for over 20 years, specialised in >>>> air traffic control, was promoted to Lieutenant Commander, and chose
early retirement in 1983. (Under the 1981 Defence Review)
As for your "tech n00b" lectures, I managed to handle advanced naval
radar systems back when you were likely still in short trousers.
Feel free to keep screaming at the clouds, but do try to stick to facts >>>> next time!
Gremlin feels the need to make up stories about others -- putting them down,
and about himself -- propping himself up. He tells the most amazing whoppers
to try to make himself look better to others, but more importantly to himself.
Nowadays, tradesmen are "the salt of the earth".
He should be proud of all he has achieved.
Indeed.
A Harvard degree in gender studies is 100% useless and the $100k or more
that the student is left in debt, in the USA, makes it even worse.
Study something you have to physically touch.
The tech installing a major network in a large company is worth a heck of
a lot more than the network architect designing the system and who probably resides in some 3rd world country.
And AI will replace that person soon.
The trades are extremely lucrative especially now that the boomer generation is aging and needs help doing things that maybe they were able to do in the past.
I also applaud the current administration for digging into welfare/public assistance fraud both at the "factory level" and down to the individuals claiming checks each month who do not deserve them.
Those people are leeches, parasites, milking the system and when taken
as a whole, scam the taxpayers for a massive amount of money that could
go to help pay for those who truly deserve the government help as many do.
In the USA waste is extreme and needs to be stopped even if it is
one parasite at a time.
On 02/06/2026 23:23, pothead wrote:
On 2026-06-02, David B. <"David B."@invalid.org> wrote:
On 02/06/2026 17:14, Brock McNuggets wrote:
On Jun 2, 2026 at 1:59:32rC>AM MST, ""David B."" wrote
<n87kbkFm6lrU1@mid.individual.net>:
On 02/06/2026 04:37, Gremlin wrote:
"David B." <"David B."@invalid.org> news:n7ug66F8n7lU1@mid.individual.net"Gremlin" <nobody@haph.org> wrote:
Fri, 29 May 2026 21:53:10 GMT in alt.computer.workshop, wrote:
On 29/05/2026 22:19, pothead wrote:
If you are interested in bits and bytes left around after a removal of >>>>>>>> a program you will have a field day with Windows and the registry. >>>>>>>> Happy hunting.
That's all behind me now. I cut my teeth on Windows 3.1 and have used >>>>>>> nearly all the Microsoft operating systems up to Windows 10.
Yet you remain for all intents and purposes, a tech n00b. In all that time,
you have less technical working knowledge of how the machine in front of you
works than Snit.
That is NOT something you should be proud of. You have done as poorly with
tech as you did flying. It's a shame you can't be forced to turn your >>>>>> computers in like you did your pilots wings. You had to turn those in for
gross incompetence, too. You were deemed a danger to yourself, your own >>>>>> people and your own gear. The enemy would have nothing to fear from you. >>>>>
It's a shame you can't be forced to turn your computers in like
you did your pilots wings. You had to turn those in for gross
incompetence, too.
Your imagination is running wild again, Dustin.
My 1969 naval flying logbook records the standard, administrative
"Suspended from Flying Training. Flying Badge Removed" stamp from the >>>>> Naval Aircrew Advisory Board. It was standard service practice, not a >>>>> dramatic court-martial for "gross incompetence."
Here's another copy, to save you 'digging back':-
https://i.ibb.co/3mkhnC3Q/Flying-Log-Book.jpg
I went on to serve in the Royal Navy for over 20 years, specialised in >>>>> air traffic control, was promoted to Lieutenant Commander, and chose >>>>> early retirement in 1983. (Under the 1981 Defence Review)
As for your "tech n00b" lectures, I managed to handle advanced naval >>>>> radar systems back when you were likely still in short trousers.
Feel free to keep screaming at the clouds, but do try to stick to facts >>>>> next time!
Gremlin feels the need to make up stories about others -- putting them down,
and about himself -- propping himself up. He tells the most amazing whoppers
to try to make himself look better to others, but more importantly to himself.
Nowadays, tradesmen are "the salt of the earth".
He should be proud of all he has achieved.
Indeed.
A Harvard degree in gender studies is 100% useless and the $100k or more
that the student is left in debt, in the USA, makes it even worse.
Study something you have to physically touch.
The tech installing a major network in a large company is worth a heck of
a lot more than the network architect designing the system and who probably >> resides in some 3rd world country.
And AI will replace that person soon.
The trades are extremely lucrative especially now that the boomer generation >> is aging and needs help doing things that maybe they were able to do in the past.
I also applaud the current administration for digging into welfare/public
assistance fraud both at the "factory level" and down to the individuals
claiming checks each month who do not deserve them.
Those people are leeches, parasites, milking the system and when taken
as a whole, scam the taxpayers for a massive amount of money that could
go to help pay for those who truly deserve the government help as many do. >>
In the USA waste is extreme and needs to be stopped even if it is
one parasite at a time.
I support all you have said above.
It's exactly the same in the UK.
On Jun 3, 2026, Brock McNuggets wrote:
Yes. And then you realized you were in error and apologized.
A claim you have not shown and previously admitted was in error.
You are confusing a precise technical clarification about timing with an admission of error, Michael.
Clarifying that the binary is written to /Library/PrivilegedHelperTools/ only *after* a user triggers the advanced drive benchmark - rather than sitting there on a fresh, un-triggered install - is called precision. It does not change the core mechanical fact that the tool is there, it runs as root, and a
standard drag-to-trash leaves it behind.
The architectural facts remain entirely unchanged, and anyone reading this can
verify them in thirty seconds:
1. Download EtreCheckPro.
2. Right-click the app bundle -> Show Package Contents.
3. Navigate to /Contents/Library/LaunchServices/
4. There sits the blueprint: com.etresoft.EtreCheckHelper.
Apple's development documentation explicitly states that binaries listed in that directory are designed to be installed via the SMJobBless API into the root system folder to execute tasks with root privileges.
Since you continue to claim this file isn't a security concern,
let's move
past the semantic games and test your actual technical knowledge of macOS security architecture.
If leaving an orphaned, root-privileged binary like com.etresoft.EtreCheckHelper sitting silently in a system directory after a drag-to-trash uninstall is perfectly acceptable "design," answer this:
How does a standard security scanner or built-in OS mechanism reliably detect a privilege escalation exploit if a local threat vector hijacks an orphaned, legitimate tool running via SMJobBless - especially if that tool lacks an SMJobRemove routine to cleanly de-authorize it?
If this lazy cleanup is a perfectly safe "norm," you should easily be able to provide the newsgroup with a technical breakdown of how the system defends against that specific attack surface. I await your explanation.
David B. <boaterdave@hotmail.co.uk> wrote:
On Jun 3, 2026, Brock McNuggets wrote:
Yes. And then you realized you were in error and apologized.
A claim you have not shown and previously admitted was in error.
You are confusing a precise technical clarification about timing with an
admission of error, Michael.
Clarifying that the binary is written to /Library/PrivilegedHelperTools/ only
*after* a user triggers the advanced drive benchmark - rather than sitting >> there on a fresh, un-triggered install - is called precision. It does not
change the core mechanical fact that the tool is there, it runs as root, and a
standard drag-to-trash leaves it behind.
The architectural facts remain entirely unchanged, and anyone reading this can
verify them in thirty seconds:
1. Download EtreCheckPro.
2. Right-click the app bundle -> Show Package Contents.
3. Navigate to /Contents/Library/LaunchServices/
4. There sits the blueprint: com.etresoft.EtreCheckHelper.
Show a screenshot.
Apple's development documentation explicitly states that binaries listed in >> that directory are designed to be installed via the SMJobBless API into the >> root system folder to execute tasks with root privileges.
Since you continue to claim this file isn't a security concern,
Files that donrCOt exist are not concerns.
[....]
Show a screenshot.
Files that donrCOt exist are not concerns.
On 3 Jun 2026 at 15:02:38 BST, "Brock McNuggets" <Brock.McNuggets@gmail.com> wrote:
David B. <boaterdave@hotmail.co.uk> wrote:
On Jun 3, 2026, Brock McNuggets wrote:
Yes. And then you realized you were in error and apologized.
A claim you have not shown and previously admitted was in error.
You are confusing a precise technical clarification about timing with an >>> admission of error, Michael.
Clarifying that the binary is written to /Library/PrivilegedHelperTools/ only
*after* a user triggers the advanced drive benchmark - rather than sitting >>> there on a fresh, un-triggered install - is called precision. It does not >>> change the core mechanical fact that the tool is there, it runs as root, and a
standard drag-to-trash leaves it behind.
The architectural facts remain entirely unchanged, and anyone reading this can
verify them in thirty seconds:
1. Download EtreCheckPro.
2. Right-click the app bundle -> Show Package Contents.
3. Navigate to /Contents/Library/LaunchServices/
4. There sits the blueprint: com.etresoft.EtreCheckHelper.
Show a screenshot.
Apple's development documentation explicitly states that binaries listed in >>> that directory are designed to be installed via the SMJobBless API into the >>> root system folder to execute tasks with root privileges.
Since you continue to claim this file isn't a security concern,
Files that donrCOt exist are not concerns.
[....]
On Jun 3, 2026, Brock McNuggets wrote:
Show a screenshot.
Files that donrCOt exist are not concerns.
They certainly are a concern when they do exist, Michael.
If you right-click EtreCheckPro and look at the actual package contents, you don't even have to dig deep. Right there in the main Contents folder sits a dedicated directory explicitly named "Helpers". Inside it is the binary:
EtreCheckPro.app/Contents/Helpers/storageHelper
In fact, I just executed it directly from the bundle. Here is the exact output
on my machine:
Last login: Sat May 30 15:09:52 on ttys000 /Applications/EtreCheckPro.app/Contents/Helpers/storageHelper ; exit;
davidbrooks@Davids-iMac ~ % /Applications/EtreCheckPro.app/Contents/Helpers/storageHelper ; exit;
Saving session...
...copying shared history...
The binary exists, it is baked into the software by the developer, and it executes exactly like a headless background helper is designed to do. Denying its presence inside the bundle is flatly incorrect.
I notice you completely omitted any attempt to answer the security architecture question. Let's try it again:
How does a standard security scanner or built-in OS mechanism reliably protect
against local privilege escalation if a local threat vector hijacks an unmonitored, privileged companion tool like storageHelper - especially when a standard drag-to-trash uninstall leaves the elevated system artifacts behind with no built-in cleanup routine?
The file exists, the root execution model exists, and your silence on the threat modeling speaks volumes. I still await your technical explanation.
On Jun 3, 2026, Brock McNuggets wrote:
Yes. And then you realized you were in error and apologized.
A claim you have not shown and previously admitted was in error.
You are confusing a precise technical clarification about timing with an admission of error, Michael.
Clarifying that the binary is written to /Library/PrivilegedHelperTools/
On Jun 3, 2026 at 12:46:12rC>AM MST, "David B." wrote <6a1fdbc4$1$55442$882e4bbb@reader.netnews.com>:
On Jun 3, 2026, Brock McNuggets wrote:
Yes. And then you realized you were in error and apologized.
A claim you have not shown and previously admitted was in error.
You are confusing a precise technical clarification about timing with an
admission of error, Michael.
Clarifying that the binary is written to /Library/PrivilegedHelperTools/
Please show a screenshot backing this.
You have yet to give any actual concern with that file or show ascreenshot of
it being in the System folder. If you drag the Bundle to the trash it is deleted.
On Jun 3, 2026 at 7:54:39rC>AM MST, "David B." wrote <6a20402f$2$18$882e4bbb@reader.netnews.com>:
On 3 Jun 2026 at 15:02:38 BST, "Brock McNuggets" <Brock.McNuggets@gmail.com> >> wrote:
David B. <boaterdave@hotmail.co.uk> wrote:
On Jun 3, 2026, Brock McNuggets wrote:
Yes. And then you realized you were in error and apologized.
A claim you have not shown and previously admitted was in error.
You are confusing a precise technical clarification about timing with an >>>> admission of error, Michael.
Clarifying that the binary is written to /Library/PrivilegedHelperTools/ only
*after* a user triggers the advanced drive benchmark - rather than sitting >>>> there on a fresh, un-triggered install - is called precision. It does not >>>> change the core mechanical fact that the tool is there, it runs as root, and a
standard drag-to-trash leaves it behind.
The architectural facts remain entirely unchanged, and anyone reading this can
verify them in thirty seconds:
1. Download EtreCheckPro.
2. Right-click the app bundle -> Show Package Contents.
3. Navigate to /Contents/Library/LaunchServices/
4. There sits the blueprint: com.etresoft.EtreCheckHelper.
Show a screenshot.
Apple's development documentation explicitly states that binaries listed in
that directory are designed to be installed via the SMJobBless API into the
root system folder to execute tasks with root privileges.
Since you continue to claim this file isn't a security concern,
Files that donrCOt exist are not concerns.
[....]
On Jun 3, 2026, Brock McNuggets wrote:
Show a screenshot.
Files that donrCOt exist are not concerns.
They certainly are a concern when they do exist, Michael.
If you right-click EtreCheckPro and look at the actual package contents, you >> don't even have to dig deep. Right there in the main Contents folder sits a >> dedicated directory explicitly named "Helpers". Inside it is the binary:
EtreCheckPro.app/Contents/Helpers/storageHelper
In fact, I just executed it directly from the bundle. Here is the exact output
on my machine:
Last login: Sat May 30 15:09:52 on ttys000
/Applications/EtreCheckPro.app/Contents/Helpers/storageHelper ; exit;
davidbrooks@Davids-iMac ~ %
/Applications/EtreCheckPro.app/Contents/Helpers/storageHelper ; exit;
Saving session...
...copying shared history...
The binary exists, it is baked into the software by the developer, and it
executes exactly like a headless background helper is designed to do. Denying
its presence inside the bundle is flatly incorrect.
I notice you completely omitted any attempt to answer the security
architecture question. Let's try it again:
How does a standard security scanner or built-in OS mechanism reliably protect
against local privilege escalation if a local threat vector hijacks an
unmonitored, privileged companion tool like storageHelper - especially when a
standard drag-to-trash uninstall leaves the elevated system artifacts behind >> with no built-in cleanup routine?
The file exists, the root execution model exists, and your silence on the
threat modeling speaks volumes. I still await your technical explanation.
You have yet to give any actual concern with that file or show a screenshot of
it being in the System folder. If you drag the Bundle to the trash it is deleted.
Please show a screenshot backing this.
You have yet to give any actual concern with that file or show a screenshot of
it being in the System folder. If you drag the Bundle to the trash it is deleted.
On 03/06/2026 16:45, Brock McNuggets wrote:
On Jun 3, 2026 at 12:46:12rC>AM MST, "David B." wrote
<6a1fdbc4$1$55442$882e4bbb@reader.netnews.com>:
On Jun 3, 2026, Brock McNuggets wrote:
Yes. And then you realized you were in error and apologized.
A claim you have not shown and previously admitted was in error.
You are confusing a precise technical clarification about timing with an >>> admission of error, Michael.
Clarifying that the binary is written to /Library/PrivilegedHelperTools/
Please show a screenshot backing this.
On Jun 3, 2026, Brock McNuggets wrote:
You have yet to give any actual concern with that file or show ascreenshot of
it being in the System folder. If you drag the Bundle to the trash it is
deleted.
Moving the goalposts won't save your argument, Michael. First you
claimed the file didn't exist at all. Now that IrCOve proven it exists and executed it, you claim dragging the bundle to the Trash deletes everything.
That is fundamentally, text-book wrong.
Dragging an application bundle from /Applications/ to the Trash deletes
ONLY the bundle itself. It does NOTrCoand inherently cannotrCoclean up files that have been escalated to the root system folder (/Library/PrivilegedHelperTools/).
A standard user space action like dragging an icon to the Trash does not possess the root-level privileges required to modify or delete files
inside protected root system directories. Apple specifically designed
the Finder to prevent standard user actions from altering the root
directory.
As we already established earlier in this thread, the storageHelper
inside the bundle is the blueprint. The moment a user runs the advanced
drive benchmark and authenticates the administrator prompt, macOS uses
the system APIs to install a persistent copy into:
/Library/PrivilegedHelperTools/
If you drag EtreCheckPro to the Trash after that, the root-owned system binary remains left behind silently in the root folder. That is the
literal definition of an "orphaned privileged helper."
Since you claim dragging the bundle deletes it all, please explain the
magic mechanism by which the user-space Finder deletes a root-owned
binary inside a protected system directory without asking the user for
an administrator password. IrCOll wait.
On 3 Jun 2026 at 16:43:33 BST, "Brock McNuggets" <brock.mcnuggets@gmail.com> wrote:
On Jun 3, 2026 at 7:54:39rC>AM MST, "David B." wrote
<6a20402f$2$18$882e4bbb@reader.netnews.com>:
On 3 Jun 2026 at 15:02:38 BST, "Brock McNuggets" <Brock.McNuggets@gmail.com>You have yet to give any actual concern with that file or show a screenshot of
wrote:
David B. <boaterdave@hotmail.co.uk> wrote:
On Jun 3, 2026, Brock McNuggets wrote:
Yes. And then you realized you were in error and apologized.
A claim you have not shown and previously admitted was in error.
You are confusing a precise technical clarification about timing with an >>>>> admission of error, Michael.
Clarifying that the binary is written to /Library/PrivilegedHelperTools/ only
*after* a user triggers the advanced drive benchmark - rather than sitting
there on a fresh, un-triggered install - is called precision. It does not >>>>> change the core mechanical fact that the tool is there, it runs as root, and a
standard drag-to-trash leaves it behind.
The architectural facts remain entirely unchanged, and anyone reading this can
verify them in thirty seconds:
1. Download EtreCheckPro.
2. Right-click the app bundle -> Show Package Contents.
3. Navigate to /Contents/Library/LaunchServices/
4. There sits the blueprint: com.etresoft.EtreCheckHelper.
Show a screenshot.
Apple's development documentation explicitly states that binaries listed in
that directory are designed to be installed via the SMJobBless API into the
root system folder to execute tasks with root privileges.
Since you continue to claim this file isn't a security concern,
Files that donrCOt exist are not concerns.
[....]
On Jun 3, 2026, Brock McNuggets wrote:
Show a screenshot.
Files that donrCOt exist are not concerns.
They certainly are a concern when they do exist, Michael.
If you right-click EtreCheckPro and look at the actual package contents, you
don't even have to dig deep. Right there in the main Contents folder sits a >>> dedicated directory explicitly named "Helpers". Inside it is the binary: >>>
EtreCheckPro.app/Contents/Helpers/storageHelper
In fact, I just executed it directly from the bundle. Here is the exact output
on my machine:
Last login: Sat May 30 15:09:52 on ttys000
/Applications/EtreCheckPro.app/Contents/Helpers/storageHelper ; exit;
davidbrooks@Davids-iMac ~ %
/Applications/EtreCheckPro.app/Contents/Helpers/storageHelper ; exit;
Saving session...
...copying shared history...
The binary exists, it is baked into the software by the developer, and it >>> executes exactly like a headless background helper is designed to do. Denying
its presence inside the bundle is flatly incorrect.
I notice you completely omitted any attempt to answer the security
architecture question. Let's try it again:
How does a standard security scanner or built-in OS mechanism reliably protect
against local privilege escalation if a local threat vector hijacks an
unmonitored, privileged companion tool like storageHelper - especially when a
standard drag-to-trash uninstall leaves the elevated system artifacts behind
with no built-in cleanup routine?
The file exists, the root execution model exists, and your silence on the >>> threat modeling speaks volumes. I still await your technical explanation. >>
it being in the System folder. If you drag the Bundle to the trash it is
deleted.
On Jun 3, 2026, Brock McNuggets wrote:
Please show a screenshot backing this.
You have yet to give any actual concern with that file or show a screenshot of
it being in the System folder. If you drag the Bundle to the trash it is
deleted.
Moving the goalposts twice in five minutes won't save your argument, Michael. First you claimed the file didn't exist at all. Now that IrCOve proven it exists
and executed it, you claim dragging the bundle to the Trash magically deletes everything.
That is fundamentally, text-book wrong.
Dragging an application bundle from /Applications/ to the Trash deletes ONLY the bundle itself. It does NOTrCoand inherently cannotrCoclean up files that have
been escalated to the root system folder (/Library/PrivilegedHelperTools/).
A standard user space action like dragging an icon to the Trash does not possess the root-level privileges required to modify or delete files inside protected root system directories. Apple specifically designed the Finder to prevent standard user actions from altering the root directory without an explicit administrator password prompt.
As for your obsession with a screenshot of the system folder: the entire point
of the SMJobBless threat modelrCowhich you are struggling to grasprCois timing.
The "storageHelper" inside the application bundle is the blueprint. The moment
a user runs the advanced drive benchmark and authenticates the administrator prompt, macOS uses the system APIs to dynamically install that helper into:
/Library/PrivilegedHelperTools/
If you drag EtreCheckPro to the Trash *after* running that benchmark, the main
bundle is deleted, but the root-owned system binary remains left behind silently in the root folder. That is the literal definition of an "orphaned privileged helper."
Since you claim dragging the bundle deletes it all, please explain the magic mechanism by which the user-space Finder deletes a root-owned binary inside a protected system directory without asking the user for an administrator password. IrCOll wait.
You have yet to give any actual concern with that file or show a screenshot of
it being in the System folder. If you drag the Bundle to the trash it is deleted.
You have yet to show a screenshot of the file you are concerned with.
Hint: last time you went through this you eventually admitted it did not exist.
On 3 Jun 2026 at 20:06:00 BST, "Brock McNuggets" <brock.mcnuggets@gmail.com> wrote
You have yet to show a screenshot of the file you are concerned with.
Hint: last time you went through this you eventually admitted it did not
exist.
Nice try with the gaslighting, Michael, but revisionist history won't save your collapsed argument.
I have never admitted the helper binary "did not exist." What we actually clarified earlier was the *timing*rCothat the companion tool is actively dropped
into the root folder *after* the advanced storage benchmark is explicitly triggered, rather than sitting there from a basic, un-triggered installation.
The binary itself exists, it is right inside the application package contents under Contents/Helpers/storageHelper, and I literally just posted the raw Terminal log proving I executed it on my machine. Denying its existence at this stage is public comedy.
I notice you have completely failedrCofor the third timerCoto answer the core technical question:
By what magic mechanism does a user-space Finder "Trash" drag delete a root-owned binary inside /Library/PrivilegedHelperTools/ without asking the user for an administrator password?
You can't answer it because standard UNIX permissions prevent it. You got caught flat-out wrong on basic macOS architecture, and hiding behind a fictional "hint" doesn't change the file math.
Go back to your holiday. WerCOre done here! :-D
On Jun 3, 2026, Brock McNuggets wrote:
You have yet to give any actual concern with that file or show a screenshot of
it being in the System folder. If you drag the Bundle to the trash it is
deleted.
You are literally repeating yourself word-for-word now, Michael. Your script has broken down because you cannot defend your claim.
Repeating "if you drag the Bundle to the trash it is deleted" doesn't magically alter the fundamental security architecture of macOS. A user-space Finder action cannot delete a root-owned binary inside /Library/PrivilegedHelperTools/. This is standard UNIX file permissions 101.
Since you are entirely unable to explain the mechanism by which the Finder would bypass root permissions to clean up an elevated system file, and you have resorted to an identical copy-paste response from your holiday, we are done here.
The facts remain exactly as I stated them: the companion binary exists inside the bundle, it elevates to root when triggered, and standard uninstallation leaves an orphaned root asset behind. Anyone with a Mac and a basic understanding of terminal permissions can see you are completely out of your depth.
Enjoy the rest of your holiday.
You have yet to give any actual concern with that file or show a screenshot of
it being in the System folder. If you drag the Bundle to the trash all of its contents are deleted. If you want to discuss a file OUTSIDE of that bundle, show a screenshot of the file. Good day!
On 02/06/2026 04:37, Gremlin wrote:
"David B." <"David B."@invalid.org>
news:n7ug66F8n7lU1@mid.individual.net Fri, 29 May 2026 21:53:10 GMT in
alt.computer.workshop, wrote:
On 29/05/2026 22:19, pothead wrote:
If you are interested in bits and bytes left around after a removal
of a program you will have a field day with Windows and the registry.
Happy hunting.
That's all behind me now. I cut my teeth on Windows 3.1 and have used
nearly all the Microsoft operating systems up to Windows 10.
Yet you remain for all intents and purposes, a tech n00b. In all that
time, you have less technical working knowledge of how the machine in
front of you works than Snit.
That is NOT something you should be proud of. You have done as poorly
with tech as you did flying. It's a shame you can't be forced to turn
your computers in like you did your pilots wings. You had to turn those
in for gross incompetence, too. You were deemed a danger to yourself,
your own people and your own gear. The enemy would have nothing to fear
from you.
"Gremlin" <nobody@haph.org> wrote:
It's a shame you can't be forced to turn your computers in like
you did your pilots wings. You had to turn those in for gross
incompetence, too.
Your imagination is running wild again, Dustin.
My 1969 naval flying logbook records the standard, administrative
"Suspended from Flying Training. Flying Badge Removed" stamp from the
Naval Aircrew Advisory Board. It was standard service practice, not a dramatic court-martial for "gross incompetence."
Here's another copy, to save you 'digging back':-
https://i.ibb.co/3mkhnC3Q/Flying-Log-Book.jpg
I went on to serve in the Royal Navy for over 20 years, specialised in
air traffic control, was promoted to Lieutenant Commander, and chose
early retirement in 1983. (Under the 1981 Defence Review)
~BD~ <~BD~@nomail.afraid.org> wrote in
news:lmtcrb$ind$2...@dont-email.me:
SeaNymph wrote:
On 6/6/2014 3:48 PM, ~BD~ wrote:
Dustin wrote:
david brooks was released from the military for being
declared a danger to himself and others.
That is completely untrue, Dustin.
In fact, *a lie*!
You really _should_ have paid more attention!
Well then, why don't you tell us the truth. Wasn't it something
about being kicked out of the aviation program for being a danger
to others?
As published on Annexcafe in 2006:
=
Stopped when the "powers that be"
thought I might kill someone 'other than the enemy' (myself and/or
my crew!).
No shit. Wanna call me a liar again? You were kicked out for being a
danger to yourself and/or your crew, just like I said. You'd already
told us this before.. So how was I lieing about it?
As for your "tech n00b" lectures, I managed to handle advanced naval
radar systems back when you were likely still in short trousers.
Feel free to keep screaming at the clouds, but do try to stick to facts
next time!
Gremlin feels the need to make up stories about others -- putting them
down, and about himself -- propping himself up. He tells the most
amazing whoppers to try to make himself look better to others, but more importantly to himself.
Now you go and find some old source code you don't understand and ask
for Snits advice concerning it? The idiot didn't even realize what
you were asking about and provided you no answer.
~BD~ <~BD~@nomail.afraid.org> wrote in
news:lmtcrb$ind$2...@dont-email.me:
SeaNymph wrote:
On 6/6/2014 3:48 PM, ~BD~ wrote:
Dustin wrote:
david brooks was released from the military for being
declared a danger to himself and others.
That is completely untrue, Dustin.
In fact, *a lie*!
You really _should_ have paid more attention!
Well then, why don't you tell us the truth. Wasn't it something
about being kicked out of the aviation program for being a danger
to others?
As published on Annexcafe in 2006:
=
Stopped when the "powers that be"
thought I might kill someone 'other than the enemy' (myself and/or
my crew!).
No shit. Wanna call me a liar again? You were kicked out for being a
danger to yourself and/or your crew, just like I said. You'd already
told us this before.. So how was I lieing about it?
Brock McNuggets <brock.mcnuggets@gmail.com> news:6a1f015e$0$20$882e4bbb@reader.netnews.com Tue, 02 Jun 2026 16:14:22
GMT in alt.computer.workshop, wrote:
Gremlin feels the need to make up stories about others -- putting them
down, and about himself -- propping himself up. He tells the most
amazing whoppers to try to make himself look better to others, but more
importantly to himself.
Stop projecting, Snit. I'm not you.
You're the one who does what you described:
MID: <hhk7lhFue2dU2@mid.individual.net>
From: Snit <usenet@gallopinginsanity.com>
Newsgroups: alt.computer.workshop
Subject: Re: Please note.
Date: Thu, 7 May 2020 22:05:53 -0700
Lines: 112
Message-ID: <hhk7lhFue2dU2@mid.individual.net>
References: <o2fsG.77364$fk3.33122@fx26.ams1>
<hheifoFogdjU1@mid.individual.net>
<XnsABB76B32E964HT1@8P1PQ2e52.7r7wsG43c>
In-Reply-To: <XnsABB76B32E964HT1@8P1PQ2e52.7r7wsG43c>
On 5/7/20 9:36 PM, Diesel wrote:
....
Now you go and find some old source code you don't understand and ask
for Snits advice concerning it? The idiot didn't even realize what
you were asking about and provided you no answer.
Ah, more trolling of me by you. So more reminding you of your past
nonsense.
----------------------------------------------------------------------
Diesel <XnsAB6D6F1BFA61HT1@3dOIZISX3.IwU6R1OH8iz29MMTN26bF08TPFtT157gyFB5>:
-----
Snit, if you're running the bot you have an easy way out
that won't cost you any respect, face, or anything else.
Just stop. That's it. Simple right?
-----
The last time the bot had posted was more than three hours before.
Diesel made it clear he could find the IP of the person running the bot.
And he made it clear it would be easy for him to make a Sandman-like
time table of posting, but showing Carroll and the bot and myself.
Was he lying when he said that? Maybe. But I do not think so. And if he
was merely lying he would not have access to the program itself, which
he makes VERY clear he did.
Diesel and Carroll were trolling together. The bot goes silent. Diesel
then says if the bot is just turned off he will let it slide. Does that
sound like Diesel to you? And he also say this:
-----
It needs to be recoded anyway, it's a seriously piss poor
example of writing software.
-----
Diesel made it clear he had access not just to the output of the bot but
to the code itself. When called out on this he clarified it was merely
the compiled code he had:
<XnsAB6E44E6AFE1AHT1@ZdS859K14.7p1JRyU90Zyd>
-----
Do you think when you disassemble something that you're
provided the original source code that was
compiled/assembled by the author? You aren't, what you're
given looks nothing like the original source code, but it
still tells you *everything* about the program.
-----
So how did Diesel get a copy of the program, compiled or not? My guess:
he will NEVER say.
***
You *already wrote a hell of a whopper about me*. You continue trying to peddle bullshit about me as you have pothead and Steve Carroll. It doesn't work, Snit. ROFL. Some people already know what you are and more are
learning all about you.
You should have fact checked David, too. Dumbarse. Here's a bit of his
flying history he is denying now:
~BD~ <~BD~@nomail.afraid.org> wrote in
news:lmtcrb$ind$2...@dont-email.me:
SeaNymph wrote:
On 6/6/2014 3:48 PM, ~BD~ wrote:
Dustin wrote:
david brooks was released from the military for being
declared a danger to himself and others.
That is completely untrue, Dustin.
In fact, *a lie*!
You really _should_ have paid more attention!
Well then, why don't you tell us the truth. Wasn't it something
about being kicked out of the aviation program for being a danger
to others?
As published on Annexcafe in 2006:
=
Stopped when the "powers that be"
thought I might kill someone 'other than the enemy' (myself and/or
my crew!).
No shit. Wanna call me a liar again? You were kicked out for being a
danger to yourself and/or your crew, just like I said. You'd already
told us this before.. So how was I lieing about it?
Your spelling needs attention.
~BD~'s profile photo
~BD~
unread,
Jun 6, 2014, 5:46:27?PM
to
As published on Annexcafe in 2006:
=
More about BoaterDaveTJ:
Joined the Royal Navy as an Artificer Apprentice in 1962. Studied
Control Engineering for 5 years (when computers I worked with had
thermionic valves!). I was promoted and attended BRNC Dartmouth in 1967. Flying training as a pilot thereafter. Flew Jet Provost, twin and single
seat Hawker Hunters and a Buccaneer. Stopped when the "powers that be" thought I might kill someone 'other than the enemy' (myself and/or my
crew!). Still within the RN, retrained and served as an ATCO (Air
Traffic Control Officer). Left in 1983 under voluntary redundancy terms
with the rank of Lieutenant Commander. Thereafter, I became a qualified Independent Financial Adviser and worked for Marsh Inc here in the UK
and became a Divisional Director. Retired again! (early - 53) in 1999
with the intention of working for myself or, perhaps, a small local firm
with less stressful demands. Tragically, however, my younger son, Nick, suddenly collapsed and died in Jan 99 - no cause for his death was
found. My wife and I were totally devastated. We bought a narrowboat of
our own (we had had a share in one previously) and set out to more fully explore the English waterways; it has been highly therapeutic yet we are still coming to terms with our loss. Therafter I decided that 'work'
would be a four letter word ................. and I remain retired!
**
See the part where the powers that be deemed him a threat to his own people and himself? They kicked him out of flight school. He didn't continue flying. As I fucking wrote.
The two of you cannot save each other. You cannot rebrand each other. You're both pondscum and more people will learn that about the two of you.
You're fucked, weasel. :)
"David B." <"David B."@invalid.org> news:n87kbkFm6lrU1@mid.individual.net Tue, 02 Jun 2026 08:59:32 GMT in alt.computer.workshop, wrote:
On 02/06/2026 04:37, Gremlin wrote:
"David B." <"David B."@invalid.org>
news:n7ug66F8n7lU1@mid.individual.net Fri, 29 May 2026 21:53:10 GMT in
alt.computer.workshop, wrote:
On 29/05/2026 22:19, pothead wrote:
If you are interested in bits and bytes left around after a removal
of a program you will have a field day with Windows and the registry. >>>>> Happy hunting.
That's all behind me now. I cut my teeth on Windows 3.1 and have used
nearly all the Microsoft operating systems up to Windows 10.
Yet you remain for all intents and purposes, a tech n00b. In all that
time, you have less technical working knowledge of how the machine in
front of you works than Snit.
That is NOT something you should be proud of. You have done as poorly
with tech as you did flying. It's a shame you can't be forced to turn
your computers in like you did your pilots wings. You had to turn those
in for gross incompetence, too. You were deemed a danger to yourself,
your own people and your own gear. The enemy would have nothing to fear
from you.
"Gremlin" <nobody@haph.org> wrote:
It's a shame you can't be forced to turn your computers in like
you did your pilots wings. You had to turn those in for gross
incompetence, too.
Your imagination is running wild again, Dustin.
I was hoping you'd perform another clit clogging session. You have not let
me down with your reply.
My 1969 naval flying logbook records the standard, administrative
"Suspended from Flying Training. Flying Badge Removed" stamp from the
Naval Aircrew Advisory Board. It was standard service practice, not a
dramatic court-martial for "gross incompetence."
Here's another copy, to save you 'digging back':-
https://i.ibb.co/3mkhnC3Q/Flying-Log-Book.jpg
I went on to serve in the Royal Navy for over 20 years, specialised in
air traffic control, was promoted to Lieutenant Commander, and chose
early retirement in 1983. (Under the 1981 Defence Review)
Awe, David, you're leaving some of your past out of your reply. Let me help you fill in the missing spots:
~BD~ <~BD~@nomail.afraid.org> wrote in
news:lmtcrb$ind$2...@dont-email.me:
SeaNymph wrote:
On 6/6/2014 3:48 PM, ~BD~ wrote:
Dustin wrote:
david brooks was released from the military for being
declared a danger to himself and others.
That is completely untrue, Dustin.
In fact, *a lie*!
You really _should_ have paid more attention!
Well then, why don't you tell us the truth. Wasn't it something
about being kicked out of the aviation program for being a danger
to others?
As published on Annexcafe in 2006:
=
Stopped when the "powers that be"
thought I might kill someone 'other than the enemy' (myself and/or
my crew!).
No shit. Wanna call me a liar again? You were kicked out for being a
danger to yourself and/or your crew, just like I said. You'd already
told us this before.. So how was I lieing about it?
Your spelling needs attention.
~BD~'s profile photo
~BD~
unread,
Jun 6, 2014, 5:46:27?PM
to
As published on Annexcafe in 2006:
=
More about BoaterDaveTJ:
Joined the Royal Navy as an Artificer Apprentice in 1962. Studied
Control Engineering for 5 years (when computers I worked with had
thermionic valves!). I was promoted and attended BRNC Dartmouth in 1967. Flying training as a pilot thereafter. Flew Jet Provost, twin and single
seat Hawker Hunters and a Buccaneer. Stopped when the "powers that be" thought I might kill someone 'other than the enemy' (myself and/or my
crew!). Still within the RN, retrained and served as an ATCO (Air
Traffic Control Officer). Left in 1983 under voluntary redundancy terms
with the rank of Lieutenant Commander. Thereafter, I became a qualified Independent Financial Adviser and worked for Marsh Inc here in the UK
and became a Divisional Director. Retired again! (early - 53) in 1999
with the intention of working for myself or, perhaps, a small local firm
with less stressful demands. Tragically, however, my younger son, Nick, suddenly collapsed and died in Jan 99 - no cause for his death was
found. My wife and I were totally devastated. We bought a narrowboat of
our own (we had had a share in one previously) and set out to more fully explore the English waterways; it has been highly therapeutic yet we are still coming to terms with our loss. Therafter I decided that 'work'
would be a four letter word ................. and I remain retired!]
***
Now, what did you write about the powers that be above? :) They took you
away from the flight controls, right, David? For being a danger to yourself and others. You were no longer a pilot, correct, David? Therefore, as I fucking wrote, you were kicked out of that. It doesn't matter what you were transferred to doing, you were stilL KICKED OUT of flying.
As for your "tech n00b" lectures, I managed to handle advanced naval
radar systems back when you were likely still in short trousers.
I don't give a fuck what you handled, jerked off with, etc. Fact is, you
know fuck all about how the tech sitting in front of you actually works. You have spent years asking the same stupid fucking questions because you do not retain knowledge well, if at all. Long term effects of alcohol abuse will do that.
Feel free to keep screaming at the clouds, but do try to stick to facts
next time!
Haha. I did stick to the facts. I don't have the memory of a gnat or the attention span of a gold fish. You have demonstrated as having both. Stop drinking, dumbass!
Btw, lieing by omission is something that just doesn't really work for
usenet purposes. Usenet has a memory. Fucking idiot.
Keep doing the clit clog David! Maybe you'll get good enough to teach Snit a new move. He's pretty good, being as he's so experienced, so you might have to work for it!
On Jun 3, 2026, Brock McNuggets wrote:
You have yet to give any actual concern with that file or show a screenshot of
it being in the System folder. If you drag the Bundle to the trash all of its
contents are deleted. If you want to discuss a file OUTSIDE of that bundle, >> show a screenshot of the file. Good day!
And there it isrCothe absolute breakdown of your entire argument, Michael.
You are desperately trying to draw a line between the "file inside the bundle"
and the "file outside the bundle" because you don't understand how SMJobBless works.
They are not separate, unrelated files. The "storageHelper" inside the application bundle is the master architecture binary. When the user authenticates the administrator prompt to run low-level benchmarks, macOS explicitly copies and installs that EXACT tool OUTSIDE the bundle and into the
root system folder:
/Library/PrivilegedHelperTools/
So when you proudly state: "If you drag the Bundle to the trash all of its contents are deleted," you are proving my exact security point for me!
Yes, dragging the bundle to the Trash deletes the app and its internal folder.
But because the Finder cannot touch root directories without authentication, the persistent copy that was installed OUTSIDE the bundle inside /Library/PrivilegedHelperTools/ is left behind completely orphaned.
The main app is gone, but the root-privileged system artifact remains behind silently in the root OS folder. That is lazy cleanup, it is a persistent attack surface, and it is standard macOS security debt.
Thank you for explicitly conceding that the Trash only deletes the bundle contents
while leaving the root system directory completely untouched. You
just argued my case for me.
Good day indeed!
You have yet to show a screenshot of the file you are concerned with.
Hint: last time you went through this you eventually admitted it did not exist.
On Jun 3, 2026, Brock McNuggets wrote:
You have yet to show a screenshot of the file you are concerned with.
Hint: last time you went through this you eventually admitted it did not
exist.
I have never admitted the helper binary "did not exist," Michael. Stop trying to invent revisionist history to cover for your collapsed argument.
Since you are begging for a screenshot, look closely at the file "Screenshot 2026-06-04 at 08.40.59.jpg", which you can view directly here: https://i.ibb.co/RpKwFsy7/Screenshot-2026-06-04-at-08-40-59.png
Anyone looking at "Screenshot 2026-06-04 at 08.40.59.jpg" can see the absolute
reality of the application's internal structure. Right there in plain sight, highlighted under the "Helpers" directory, is the exact standalone UNIX executable I have been talking about:
EtreCheckPro.app/Contents/Helpers/storageHelper
When a user runs the advanced drive benchmark, the main application invokes this helper binary and prompts the user for an administrator password to elevate its execution state to root.
By your own logic: "If you drag the Bundle to the trash all of its contents are deleted."
Exactly! The binary lives entirely inside a user-writable directory (/Applications/). Because it relies on on-demand privilege escalation rather than a cryptographically bound, system-protected daemon, it creates a classic Local Privilege Escalation (LPE) threat vector.
If a local malicious actor or script modifies that helper binary inside the user-space bundle shown in "Screenshot 2026-06-04 at 08.40.59.jpg", the next time the administrator authenticates the benchmark prompt, they are unknowingly handing root execution rights to a compromised asset.
Relying on the user-space Finder Trash to clean up an executable that regularly requests root-level privileges is exactly what is meant by structural security debt.
You have now copy-pasted the exact same response three times because you cannot address the basic threat modeling of local privilege escalation.
Enjoy the rest of your holiday! :-D
On 04/06/2026 00:45, Brock McNuggets needs to know this:-
=
The US Navy's system is legendary for its unforgiving nature,
particularly because it culminates in carrier landings. The Navy divides
its students into pipelines (Strike, Rotary, Maritime, Tilt-rotor), with "Strike" being the fast-jet track (F/A-18 Super Hornets and F-35C
Lightning IIs).
According to recent US Navy flight data and training research:
The Overall Attrition: Flight school as a whole carries an overall
attrition rate of roughly 17% to 25% across all phases.
The Pure Flight Failures: Even after beating the odds to get selected
for the Strike pipeline, the pressure doesn't let up. Historical data
from Training Air Wing One shows that the combined attrition rate specifically within the Intermediate and Advanced Strike phases (flying
the T-45 Goshawk) sits at around 8% to 12%.
According to a recent 10-year US Navy study on training data, over 50%
of late-stage dropouts in the jet pipeline are explicitly due to flight performance issues (hitting a wall with advanced tactics, tactical
formation flying, or Field Carrier Landing Practice). The rest are due
to medical issues or "DOR" (Drop on RequestrCovoluntary withdrawal when
the stress or physical toll becomes too high).
The Safety Valve: "Re-Streaming"
Just like in the Royal Navy, washing out of a fast-jet syllabus in the
US military doesn't always mean your military career is over.
The US Navy notes that roughly 55% to 60% of student pilots who fail to complete the high-stress Strike syllabus are actually successfully
re-routed into multi-engine maritime or helicopter pipelines. They are perfectly capable pilots, but they simply hit their human ceiling when subjected to the extreme cognitive load, speed, and spatial awareness required for high-performance tactical jets.
The Pure Mathematics
When you add up the initial screening tests, officer training dropouts,
the massive 75% filter at track selection, and the subsequent 10%
failure rate in advanced jet training, fewer than 3% to 5% of original
US military pilot applicants ever successfully "wing" as frontline
fast-jet pilots.
It costs the US Navy nearly $10 million to train a single basic
qualified fighter pilot. They do not spend that kind of money, nor do
they hand over a $100 million aircraft, to anyone who shows even a hint
of hesitation at the controls!
=
It wasn't an easy path to follow, but it *WAS* great fun! Efn-
On 03/06/2026 21:22, Gremlin wrote:
Stopped when the "powers that be"
thought I might kill someone 'other than the enemy' (myself and/or my
crew!).
Oh dear, Dustin. You've gone to all that effort to dig up a 2006 post,
and you still managed to miss the dry British military humour completely.
Anyone who has served knows that "before I kill someone other than the
enemy" is a classic, self-deprecating joke about the sheer difficulty of fast-jet training. It's how we laugh about the brutal pipeline that
washes out the vast majority of students.
There was no drama, no scandal, and no "kick out"rCojust a standard administrative transfer to Air Traffic Control, followed by a very
successful 20-year naval career and promotion to Lieutenant Commander.
IrCOm happy to let my official service record and logbook stand against
your colourful imagination!
On Jun 4, 2026 at 1:08:35rC>AM MST, "David B." wrote <6a213283$1$25$882e4bbb@reader.netnews.com>:
On Jun 3, 2026, Brock McNuggets wrote:
You have yet to show a screenshot of the file you are concerned with.
Hint: last time you went through this you eventually admitted it did not >>> exist.
I have never admitted the helper binary "did not exist," Michael. Stop trying
to invent revisionist history to cover for your collapsed argument.
Since you are begging for a screenshot, look closely at the file "Screenshot >> 2026-06-04 at 08.40.59.jpg", which you can view directly here:
https://i.ibb.co/RpKwFsy7/Screenshot-2026-06-04-at-08-40-59.png
Anyone looking at "Screenshot 2026-06-04 at 08.40.59.jpg" can see the absolute
reality of the application's internal structure. Right there in plain sight, >> highlighted under the "Helpers" directory, is the exact standalone UNIX
executable I have been talking about:
EtreCheckPro.app/Contents/Helpers/storageHelper
When a user runs the advanced drive benchmark, the main application invokes >> this helper binary and prompts the user for an administrator password to
elevate its execution state to root.
By your own logic: "If you drag the Bundle to the trash all of its contents >> are deleted."
Exactly! The binary lives entirely inside a user-writable directory
(/Applications/). Because it relies on on-demand privilege escalation rather >> than a cryptographically bound, system-protected daemon, it creates a classic
Local Privilege Escalation (LPE) threat vector.
If a local malicious actor or script modifies that helper binary inside the >> user-space bundle shown in "Screenshot 2026-06-04 at 08.40.59.jpg", the next >> time the administrator authenticates the benchmark prompt, they are
unknowingly handing root execution rights to a compromised asset.
Relying on the user-space Finder Trash to clean up an executable that
regularly requests root-level privileges is exactly what is meant by
structural security debt.
You have now copy-pasted the exact same response three times because you
cannot address the basic threat modeling of local privilege escalation.
Enjoy the rest of your holiday! :-D
Does this mean you are (again) dropping your claim that EtreCheck is copying files to your /System folder?
That has been my point. You keep insisting it does -- with no support. The fact it has executables is not in question. The fact that it needs more privileges than some other software is not in question. The idea it copies things to the /System folder is not backed.
Does this mean you are (again) dropping your claim that EtreCheck is copying files to your /System folder?
That has been my point. You keep insisting it does -- with no support. The fact it has executables is not in question. The fact that it needs more privileges than some other software is not in question. The idea it copies things to the /System folder is not backed.
On 4 Jun 2026 at 14:53:13 BST, "Brock McNuggets" <brock.mcnuggets@gmail.com> wrote:
On Jun 4, 2026 at 1:08:35rC>AM MST, "David B." wrote
<6a213283$1$25$882e4bbb@reader.netnews.com>:
On Jun 3, 2026, Brock McNuggets wrote:
You have yet to show a screenshot of the file you are concerned with.
Hint: last time you went through this you eventually admitted it did not >>>> exist.
I have never admitted the helper binary "did not exist," Michael. Stop trying
to invent revisionist history to cover for your collapsed argument.
Since you are begging for a screenshot, look closely at the file "Screenshot
2026-06-04 at 08.40.59.jpg", which you can view directly here:
https://i.ibb.co/RpKwFsy7/Screenshot-2026-06-04-at-08-40-59.png
Anyone looking at "Screenshot 2026-06-04 at 08.40.59.jpg" can see the absolute
reality of the application's internal structure. Right there in plain sight,
highlighted under the "Helpers" directory, is the exact standalone UNIX
executable I have been talking about:
EtreCheckPro.app/Contents/Helpers/storageHelper
When a user runs the advanced drive benchmark, the main application invokes >>> this helper binary and prompts the user for an administrator password to >>> elevate its execution state to root.
By your own logic: "If you drag the Bundle to the trash all of its contents >>> are deleted."
Exactly! The binary lives entirely inside a user-writable directory
(/Applications/). Because it relies on on-demand privilege escalation rather
than a cryptographically bound, system-protected daemon, it creates a classic
Local Privilege Escalation (LPE) threat vector.
If a local malicious actor or script modifies that helper binary inside the >>> user-space bundle shown in "Screenshot 2026-06-04 at 08.40.59.jpg", the next
time the administrator authenticates the benchmark prompt, they are
unknowingly handing root execution rights to a compromised asset.
Relying on the user-space Finder Trash to clean up an executable that
regularly requests root-level privileges is exactly what is meant by
structural security debt.
You have now copy-pasted the exact same response three times because you >>> cannot address the basic threat modeling of local privilege escalation.
Enjoy the rest of your holiday! :-D
Does this mean you are (again) dropping your claim that EtreCheck is copying >> files to your /System folder?
That has been my point. You keep insisting it does -- with no support. The >> fact it has executables is not in question. The fact that it needs more
privileges than some other software is not in question. The idea it copies >> things to the /System folder is not backed.
On Jun 4, 2026, Brock McNuggets wrote:
Does this mean you are (again) dropping your claim that EtreCheck is copying >> files to your /System folder?
That has been my point. You keep insisting it does -- with no support. The >> fact it has executables is not in question. The fact that it needs more
privileges than some other software is not in question. The idea it copies >> things to the /System folder is not backed.
Nice try rewriting history within the span of 24 hours, Michael.
First, nobody claimed it touched the read-only "/System" folder. The technical
discussion was about local privilege escalation and how root tools are typically handled via system architecture frameworks (like /Library/PrivilegedHelperTools/).
Second, your sudden pivot to "The fact it has executables is not in question" is pure public comedy. Just yesterday you flatly denied its existence, stating
word-for-word in this very thread: "Files that donrCOt exist are not concerns."
Now that my screenshot (https://i.ibb.co/RpKwFsy7/Screenshot-2026-06-04-at-08-40-59.png) forced you to admit the executable does, in fact, exist inside the bundle, you are frantically moving the goalposts to split hairs about directory paths.
The core threat model remains completely unaddressed by you:
EtreCheckPro relies on a standalone UNIX binary sitting inside a standard user-writable directory (/Applications/) that regularly requests full root execution privileges via on-demand escalation.
This presents a classic,
textbook Local Privilege Escalation (LPE) vector if that application bundle is
compromised by local malware or a malicious script.
No amount of desperate semantic dodging or shifting definitions will alter basic software security architecture.
Put the phone down and go enjoy your holiday. :-P
You've lost this one from every possible angle!
--
David
*YOU* are supposed to be my friend, Michael!
Please act like it.
Taking a page out of your book:do not
[Massive block of AI-generated text analyzing flight school statistics]
I agree. I celebrate your accomplishments and am proud of you, but I
see the relevance to what we have been discussing about EtreCheck putting files in the /System folder.
I meant /Library, not /System. My apologies.
But my point stands. Have you dropped that claim?
On Jun 4, 2026, Brock McNuggets wrote:
Taking a page out of your book:do not
[Massive block of AI-generated text analyzing flight school statistics]
I agree. I celebrate your accomplishments and am proud of you, but I
see the relevance to what we have been discussing about EtreCheck putting
files in the /System folder.
Did you really just copy-paste my background text into an AI model to generate a critique for you, Michael?
Talk about public embarrassment.
You can't even write your own responses any more while you're on holiday.
Let's address the reality here:
1. You chose to reply to this background branch because you are utterly paralysed by the technical response I dropped in the main architectural branch. You still haven't explained how your mythical "user-space Finder Trash" bypasses standard UNIX permissions to clean up elevated files.
2. I have never claimed that landing a jet makes me an expert on macOS internals. My knowledge of macOS internals comes from decades of
managing systems, executing binaries, and reading actual developer documentation.
3. You are the only one desperately shouting about a "/System folder."
As I already corrected you on, nobody claimed EtreCheck touches the
sealed, read-only system volume. The architectural risk is the
standalone binary (storageHelper) sitting inside the user-writable / Applications bundle that regularly requests root execution rights.
Your automated "analysis" is an entertaining smoke screen, but it
doesn't change the file maths. My screenshot (https://i.ibb.co/RpKwFsy7 Screenshot-2026-06-04-at-08-40-59.png) completely demolished your claim
that the binary didn't exist.
If you want to discuss local privilege escalation, go reply to the
actual technical message. Otherwise, let your AI wrapper enjoy the rest
of your vacation for you.
On Jun 4, 2026, Brock McNuggets wrote:
I meant /Library, not /System. My apologies.
But my point stands. Have you dropped that claim?
Apology accepted, Michael. We all make typos when we are arguing from a deck chair.
To answer your question: I clarified that architecture class days ago. As my screenshot (https://i.ibb.co/RpKwFsy7/Screenshot-2026-06-04-at-08-40-59.png) clearly proved, EtreCheckPro is using on-demand privilege escalation for "storageHelper" inside the user-writable bundle rather than dropping a persistent daemon into /Library/PrivilegedHelperTools/.
But your response to this reality being an indifferent "And?" is an incredible
take for a tech thread.
You spent days insisting that dragging the bundle to the Trash completely eliminates all security risks.
Now that you've been forced to admit the
root-escalating binary sits permanently inside a user-writable space (/Applications/), your defense is "And?"
"And?" means that any local malware, malicious script, or non-admin user can alter that binary. The next time the administrator runs a drive benchmark and types their password, they are handing full root-level execution to a compromised asset. That is the literal definition of a Local Privilege Escalation (LPE) vulnerability.
The fact that an app "needs privileges to do what it does" is fine. The fact that it designs its privilege model to run an unprotected binary out of a user-writable directory is bad security architecture.
I'm glad we finally agree that the binary exists, it elevates, and the standard Trash can't protect the system from user-space tampering.
Buy the next round of drinks when you get back and we'll call it even.
Enjoy the rest of your holiday! :-D
This is how macOS works. Any such app. So what is your point? Youdropped the
/Library claim and now are looking to have me argue other things.
On Jun 4, 2026, Brock McNuggets wrote:
This is how macOS works. Any such app. So what is your point? You dropped the
/Library claim and now are looking to have me argue other things.
My point, Michael, is that standard security architecture evolves
precisely because saying "this is how it works, so what?" is how systems
stay vulnerable.
Modern macOS apps using privilege separation explicitly avoid leaving
raw, executable helper binaries sitting inside user-writable directories (/Applications/) for exactly the Local Privilege Escalation (LPE)
reasons I just laid out. They use modern system daemons precisely
because allowing user-space assets to elevate straight to root upon
admin authentication is a known architectural hazard.
But I'll let you have your minor victory lap on the directory path
cleanup.
Yes, we established the tool relies on on-demand escalation
inside the bundle rather than a persistent drop into /Library.
The
screenshot cleared the air, which is exactly why I posted it.
I am glad to hear the holiday and business are both going well! Keep
soaking up the sun, enjoy the rest of your trip, and don't think about
UNIX file permissions for at least the next few days.
I'll hold you to that round of drinks when you're back.--
Cheers!
David
On Jun 4, 2026 at 12:07:18rC>PM MST, ""David B."" wrote <n8e0n7Fge4rU1@mid.individual.net>:
On Jun 4, 2026, Brock McNuggets wrote:
This is how macOS works. Any such app. So what is your point? You dropped the
/Library claim and now are looking to have me argue other things.
My point, Michael, is that standard security architecture evolves
precisely because saying "this is how it works, so what?" is how systems
stay vulnerable.
I am not going to change how macOS works. LOL! More than that, I think Apple does a pretty good job of improving as they go. With that said, sure, there is
a place to talk about the theory and how an OS can be made better. No issue with that. But you are not doing that. You are looking at EtreCheck and saying
it is a risk -- when you have not shown it to be any more of a risk than similar software that needs similar permissions.
You have started with a conclusion -- EtreCheck is evil -- and are looking to show it. And failing. And in doing so you are looking to see what that software does not knowing what is the norm. Without knowing the norm you cannot know if what it is doing is outside of the norm.
Below you change topics to things that are not in contention.
Modern macOS apps using privilege separation explicitly avoid leaving
raw, executable helper binaries sitting inside user-writable directories
(/Applications/) for exactly the Local Privilege Escalation (LPE)
reasons I just laid out. They use modern system daemons precisely
because allowing user-space assets to elevate straight to root upon
admin authentication is a known architectural hazard.
But I'll let you have your minor victory lap on the directory path
cleanup.
It was the one thing I was questioning you about. And you have conceded the point (again). Not sure what we are even arguing about.
Yes, we established the tool relies on on-demand escalation
inside the bundle rather than a persistent drop into /Library.
Good to see you have learned since you said this <6a1fdbc4$1$55442$882e4bbb@reader.netnews.com>:
Clarifying that the binary is written to /Library/PrivilegedHelperTools/
And I responded with:
Please show a screenshot backing this.
That was my point. I did not believe you were correct -- though even in my wording there I was open to being shown I was wrong.
The
screenshot cleared the air, which is exactly why I posted it.
The screenshot did not back your claim quoted above... and you have since given up on your claim. With that I am not even sure what we are discussing or
even more disagreeing about. You keep assuming I meant things I never said. Of
course, you are using AI and it is not getting the context and is possibly hallucinating and otherwise leading you astray. So be it. A bit amusing but also a bit sad -- I have no quarrel with you. I do disagree with your extreme focus on trying to find wrongdoing in EtreCheck. As I have said, it is harmful
to all involved. But it is not like you go to the extremes of my stalker, so not gonna get too worked up over it.
I am glad to hear the holiday and business are both going well! Keep
soaking up the sun, enjoy the rest of your trip, and don't think about
UNIX file permissions for at least the next few days.
I am working with someone with a mixed environment -- Windows and macOS. No Linux.
I'll hold you to that round of drinks when you're back.
Cheers!
David
The screenshot did not back your claim quoted above... and you have since given up on your claim. With that I am not even sure what we are discussing or
even more disagreeing about. You keep assuming I meant things I never said. Of
course, you are using AI and it is not getting the context and is possibly hallucinating and otherwise leading you astray. So be it.
...
I am working with someone with a mixed environment -- Windows and macOS. No Linux.
On 04/06/2026 20:16, Brock McNuggets wrote:
On Jun 4, 2026 at 12:07:18rC>PM MST, ""David B."" wrote
<n8e0n7Fge4rU1@mid.individual.net>:
On Jun 4, 2026, Brock McNuggets wrote:
This is how macOS works. Any such app. So what is your point? You dropped the
/Library claim and now are looking to have me argue other things.
My point, Michael, is that standard security architecture evolves
precisely because saying "this is how it works, so what?" is how systems >>> stay vulnerable.
I am not going to change how macOS works. LOL! More than that, I think Apple >> does a pretty good job of improving as they go. With that said, sure, there is
a place to talk about the theory and how an OS can be made better. No issue >> with that. But you are not doing that. You are looking at EtreCheck and saying
it is a risk -- when you have not shown it to be any more of a risk than
similar software that needs similar permissions.
You have started with a conclusion -- EtreCheck is evil -- and are looking to
show it. And failing. And in doing so you are looking to see what that
software does not knowing what is the norm. Without knowing the norm you
cannot know if what it is doing is outside of the norm.
Below you change topics to things that are not in contention.
Modern macOS apps using privilege separation explicitly avoid leaving
raw, executable helper binaries sitting inside user-writable directories >>> (/Applications/) for exactly the Local Privilege Escalation (LPE)
reasons I just laid out. They use modern system daemons precisely
because allowing user-space assets to elevate straight to root upon
admin authentication is a known architectural hazard.
But I'll let you have your minor victory lap on the directory path
cleanup.
It was the one thing I was questioning you about. And you have conceded the >> point (again). Not sure what we are even arguing about.
Yes, we established the tool relies on on-demand escalation
inside the bundle rather than a persistent drop into /Library.
Good to see you have learned since you said this
<6a1fdbc4$1$55442$882e4bbb@reader.netnews.com>:
Clarifying that the binary is written to /Library/PrivilegedHelperTools/ >>
And I responded with:
Please show a screenshot backing this.
That was my point. I did not believe you were correct -- though even in my >> wording there I was open to being shown I was wrong.
The
screenshot cleared the air, which is exactly why I posted it.
The screenshot did not back your claim quoted above... and you have since
given up on your claim. With that I am not even sure what we are discussing or
even more disagreeing about. You keep assuming I meant things I never said. Of
course, you are using AI and it is not getting the context and is possibly >> hallucinating and otherwise leading you astray. So be it. A bit amusing but >> also a bit sad -- I have no quarrel with you. I do disagree with your extreme
focus on trying to find wrongdoing in EtreCheck. As I have said, it is harmful
to all involved. But it is not like you go to the extremes of my stalker, so >> not gonna get too worked up over it.
I am glad to hear the holiday and business are both going well! Keep
soaking up the sun, enjoy the rest of your trip, and don't think about
UNIX file permissions for at least the next few days.
I am working with someone with a mixed environment -- Windows and macOS. No >> Linux.
I'll hold you to that round of drinks when you're back.
Cheers!
David
On Jun 4, 2026, Brock McNuggets wrote:
The screenshot did not back your claim quoted above... and you have since
given up on your claim. With that I am not even sure what we are discussing or
even more disagreeing about. You keep assuming I meant things I never said. Of
course, you are using AI and it is not getting the context and is possibly >> hallucinating and otherwise leading you astray. So be it.
...
I am working with someone with a mixed environment -- Windows and macOS. No >> Linux.
Oh, Michael, you just had to get the last word in from your deck chair, didn't you? Efya
Blaming "AI" for a standard local privilege escalation argument that I illustrated
with my own physical file screenshot is a wonderfully creative way to
exit a technical corner.
As for your mixed environmentrCoWindows and macOS but no Linux?
My condolences to your client! They don't know what they are missing out
on.
We've both made our points, the screenshot cleared up the mechanics for
the group,
and the thread has thoroughly run its course. Put the phone away, get
back to your business and your holiday, and I'll see you at the pub when
you get back to Blighty.
In a manner of speaking!
I am happy you are no longer insisting EtreCheck is doing somethinguntoward
or uncommon, at least that has been shown. A far as I can tell, andhave seen,
at least modern EtreCheck does not put anything in /Library/PrivilegedHelperTools/
I am happy you are no longer insisting EtreCheck is doing something untoward or uncommon, at least that has been shown. A far as I can tell, and have seen,
at least modern EtreCheck does not put anything in /Library/PrivilegedHelperTools/
On 04/06/2026 22:15, Brock McNuggets wrote:
I am happy you are no longer insisting EtreCheck is doing something untoward >> or uncommon, at least that has been shown. A far as I can tell, and have seen,
at least modern EtreCheck does not put anything in
/Library/PrivilegedHelperTools/
It's here instead:-
https://i.ibb.co/dJKVVNwR/Screenshot-2026-06-04-at-22-29-17.png
On Jun 4, 2026, Brock McNuggets wrote:
I am happy you are no longer insisting EtreCheck is doing somethinguntoward
or uncommon, at least that has been shown. A far as I can tell, andhave seen,
at least modern EtreCheck does not put anything in
/Library/PrivilegedHelperTools/
Michael, if you keep digging like this, you're going to strike oil right there in Arizona.
I haven't changed my position on the security debt by one millimetre,
but I am absolutely not missing out on a free dinner invitation by proxy.
Go eat your steak, enjoy the free meal, and let the thread rest in peace!
Cheers,
David
On Jun 4, 2026 at 2:50:06rC>PM MST, ""David B."" wrote <n8ea8eFi4nnU1@mid.individual.net>:
On 04/06/2026 22:15, Brock McNuggets wrote:
I am happy you are no longer insisting EtreCheck is doing something untoward
or uncommon, at least that has been shown. A far as I can tell, and have seen,
at least modern EtreCheck does not put anything in
/Library/PrivilegedHelperTools/
It's here instead:-
https://i.ibb.co/dJKVVNwR/Screenshot-2026-06-04-at-22-29-17.png
In the bundle. Sure.
And not to freak you out but you likely have a copy here:
~/Library/Spotlight/
On 04/06/2026 23:27, Brock McNuggets wrote:
On Jun 4, 2026 at 2:50:06rC>PM MST, ""David B."" wrote
<n8ea8eFi4nnU1@mid.individual.net>:
On 04/06/2026 22:15, Brock McNuggets wrote:
I am happy you are no longer insisting EtreCheck is doing something untoward
or uncommon, at least that has been shown. A far as I can tell, and have seen,
at least modern EtreCheck does not put anything in
/Library/PrivilegedHelperTools/
It's here instead:-
https://i.ibb.co/dJKVVNwR/Screenshot-2026-06-04-at-22-29-17.png
In the bundle. Sure.
And not to freak you out but you likely have a copy here:
~/Library/Spotlight/
No need to freak out, Michael. That's not how modern macOS bundle
indexing works.
The metadata server (mds) registers and indexes app-scoped plugins
natively right out of the application's user-space bundle (as shown in
my screenshot).
It doesn't need to write or copy a duplicate file to ~/
Library/Spotlight/ at all. You can easily verify this by checking your
own ~/Library/Spotlight/ directoryrCoitrCOs typically empty unless you've manually installed legacy, standalone third-party importers.
The files stay inside the container, exactly as documented.
Now, step away from the Usenet feed and look at the menu.
Your dinner is getting cold! Efya
Cheers,--
David
On Jun 4, 2026, Brock McNuggets wrote:
Taking a page out of your book:
[Massive block of AI-generated text analyzing flight school
statistics]
I agree. I celebrate your accomplishments and am proud of you, but Ido not
see the relevance to what we have been discussing about EtreCheck
putting files in the /System folder.
Did you really just copy-paste my background text into an AI model to generate a critique for you, Michael? Talk about public embarrassment.
You can't even write your own responses any more while you're on
holiday.
2. I have never claimed that landing a jet makes me an expert on macOS internals. My knowledge of macOS internals comes from decades of
managing systems, executing binaries, and reading actual developer documentation.
3. You are the only one desperately shouting about a "/System folder."
As I already corrected you on, nobody claimed EtreCheck touches the
sealed, read-only system volume. The architectural risk is the
standalone binary (storageHelper) sitting inside the user-writable / Applications bundle that regularly requests root execution rights.
Your automated "analysis" is an entertaining smoke screen, but it
doesn't change the file maths. My screenshot (https://i.ibb.co/RpKwFsy7 Screenshot-2026-06-04-at-08-40-59.png) completely demolished your claim
that the binary didn't exist.
If you want to discuss local privilege escalation, go reply to the
actual technical message. Otherwise, let your AI wrapper enjoy the rest
of your vacation for you.
"David B." <"David B."@invalid.org> news:n8di6tFdjflU1@mid.individual.net Thu, 04 Jun 2026 14:59:40 GMT in uk.comp.sys.mac, wrote:
On Jun 4, 2026, Brock McNuggets wrote:
Taking a page out of your book:do not
[Massive block of AI-generated text analyzing flight school
statistics]
I agree. I celebrate your accomplishments and am proud of you, but I
see the relevance to what we have been discussing about EtreCheck
putting files in the /System folder.
Did you really just copy-paste my background text into an AI model to
generate a critique for you, Michael? Talk about public embarrassment.
You can't even write your own responses any more while you're on
holiday.
Why are you taking issue with this now? You've never done so before.
2. I have never claimed that landing a jet makes me an expert on macOS
internals. My knowledge of macOS internals comes from decades of
managing systems, executing binaries, and reading actual developer
documentation.
So an end user, n00b level. As I've already described you as being. I know you don't read the developer documentation very well. You had difficulty 'installing' BugHunter. As I recall, you weren't even sure which file you should be viewing for the instructions in the first place.
David, Do you remember saying that 'you were mystified how a zip file
could be encrypted so that an unzip utility wouldn't recognize it as a zip file?" - Your knowledge from decades of time has not been time well spent. You infact, have wasted a considerable amount of time. Decades worth by
your own words, actually.
3. You are the only one desperately shouting about a "/System folder."
As I already corrected you on, nobody claimed EtreCheck touches the
sealed, read-only system volume. The architectural risk is the
standalone binary (storageHelper) sitting inside the user-writable /
Applications bundle that regularly requests root execution rights.
There is no risk with that file being orphaned and left behind if it's deployed in the first place. Snit has tried to explain this to you several times now. For the most part, you already know I consider him to be a
running joke - but, he is actually on point with regard to you due to n00b level understanding and knowledge - making a mountain out of a mole hill.
You continue to do exactly that.
Your automated "analysis" is an entertaining smoke screen, but it
doesn't change the file maths. My screenshot (https://i.ibb.co/RpKwFsy7
Screenshot-2026-06-04-at-08-40-59.png) completely demolished your claim
that the binary didn't exist.
The binary is dropped under specific conditions as you've already stated. Unless you perform very specific actions within the program, it's not
going to drop that file.
The file doesn't pose a security threat to you when/if it's left behind because you choose to remove Etrecheck again later. It's an orphaned file
at that point. Consuming a little drive space - no big deal. No threat to your machine or the contents of it.
What's actually an entertaining smoke screen is your usage of AI to write most/all of your reply as you continue to demonstrate absolutely zero
first hand knowledge or understanding of the subjects you continue to
bring up.
If you want to discuss local privilege escalation, go reply to the
actual technical message. Otherwise, let your AI wrapper enjoy the rest
of your vacation for you.
That's an entirely different subject and you have absolutely no
understanding of it yourself. Stop showing your ass here, Please!
On 02/06/2026 17:13, Brock McNuggets wrote:
[....]
On Jun 2, 2026, Brock McNuggets wrote:
If you want to understand malware, you first need to understand how a system >> behaves when it's not infected.
It's like a doctor trying to diagnose an illness without knowing normal human
anatomy. If they don't know what a healthy body looks like, every unusual
finding looks suspicious.
I completely agree with your medical analogy, Brock. Establishing a known-good baseline is fundamental to system triage.
However, you are misinterpreting my concern as a novice's confusion over normal anatomy. Having actively investigated malware and system
anomalies since 2005, I am well aware of what a healthy macOS baseline
looks like, and I fully understand that legitimate applications utilize background services, LaunchDaemons, and privileged helpers for low-level tasks.
My concern is not with the existence of these tools; it is with poor
digital hygiene and "orphaned" persistence.
When a developer uses the SMJobBless API to install a helper tool with
root privileges, but provides no mechanism to clean it up when the user
drags the main application to the Trash, they leave a persistent,
root-owned binary sitting silently in a system directory.
In the security world, we look at attack surfaces. An orphaned helper
tool left behind by a deleted application is an unnecessary liability.
If that helper tool has any undiscovered vulnerabilities or loose permissions, it can be subverted by local malware for privilege
escalation. Furthermore, hidden, un-monitored system folders are the
exact real estate malware authors look for to achieve stealth persistence.
The issue isn't that legitimate software is malicious. The issue is that
lazy uninstallation methods leave the door unlatched, making the
system's "normal anatomy" harder to defend.
On Jun 2, 2026 at 2:21:49rC>PM MST, "David B." wrote <6a1f496d$0$20$882e4bbb@reader.netnews.com>:
On 2 Jun 2026 at 22:03:11 BST, "Brock McNuggets" <brock.mcnuggets@gmail.com> >> wrote:
On Jun 2, 2026 at 1:58:41rC>PM MST, ""David B."" wrote
<n88ug1FsjfjU1@mid.individual.net>:
On 02/06/2026 17:13, Brock McNuggets wrote:
[....]
On Jun 2, 2026, Brock McNuggets wrote:
If you want to understand malware, you first need to understand how a system
behaves when it's not infected.
It's like a doctor trying to diagnose an illness without knowing normal human
anatomy. If they don't know what a healthy body looks like, every unusual >>>>> finding looks suspicious.
I completely agree with your medical analogy, Brock. Establishing a
known-good baseline is fundamental to system triage.
However, you are misinterpreting my concern as a novice's confusion over >>>> normal anatomy. Having actively investigated malware and system
anomalies since 2005, I am well aware of what a healthy macOS baseline >>>> looks like, and I fully understand that legitimate applications utilize >>>> background services, LaunchDaemons, and privileged helpers for low-level >>>> tasks.
Evidence shows you are not familiar with this. You repeatedy ask about the >>> user Library being hidden, about files in the ~/Library folder, etc. You get
confused when you find that deleting an app does not delete these files. >>>
You are not familiar with normal operations and still seek to find abnormal.
My concern is not with the existence of these tools; it is with poor
digital hygiene and "orphaned" persistence.
These files are left behind by design. It is then norm. Until you understand
the norm, you cannot move forward.
When a developer uses the SMJobBless API to install a helper tool with >>>> root privileges, but provides no mechanism to clean it up when the user >>>> drags the main application to the Trash, they leave a persistent,
root-owned binary sitting silently in a system directory.
What is this even relevant to?
In the security world, we look at attack surfaces. An orphaned helper
tool left behind by a deleted application is an unnecessary liability.
Again: relevance?
If that helper tool has any undiscovered vulnerabilities or loose
permissions, it can be subverted by local malware for privilege
escalation. Furthermore, hidden, un-monitored system folders are the
exact real estate malware authors look for to achieve stealth persistence. >>>>
The issue isn't that legitimate software is malicious. The issue is that >>>> lazy uninstallation methods leave the door unlatched, making the
system's "normal anatomy" harder to defend.
What are you referring to?
<BIG SIGH>
On Jun 2, 2026, Brock McNuggets wrote:
These files are left behind by design. It is then norm. Until you understand
the norm, you cannot move forward.
You are confusing a "common bad habit" with intentional operating system
design, Michael.
Apple did not design macOS with the explicit goal of permanently cluttering up
the root /Library with orphaned, high-privilege binaries.
What binaries are you talking about?
Apple actually
provides developers with the tools to handle uninstallation properly. If a >> developer uses SMJobBless to escalate privileges, they can just as easily use
SMJobRemove to clean up that root-level helper when the user requests an
uninstall or when the companion app is deleted.
The fact that many developers choose to leave their root tools lying around is
a result of lazy software hygiene, not Apple's architectural intent.
What "root tools" are you referring to?
What is this even relevant to?
Again: relevance?
What are you referring to?
It is relevant to the exact topic of this thread: "Privileged Helpers,
dragging to Trash, and EtreCheck."
EtreCheck does not leave such. We already discussed this.
Again: you do not understand the norm, so you assume it doing what is normal is somehow bad.
Shouting "relevance" at basic cybersecurity concepts doesn't make them
disappear. If an app is dragged to the Trash, and a root-owned helper is left
behind in /Library/PrivilegedHelperTools/, that tool is entirely decoupled >> from the user's view.
Remember you already acknowledged it does not do this. So you are talking about... what?
If that orphaned tool has zero vulnerabilities, it is merely clutter. But if >> it possesses an unpatched flaw or loose permissions, it represents an attack >> surface. Local malware routinely exploits unmonitored, legacy privileged
helpers left behind by legitimate software to achieve privilege escalation >> (moving from standard user to root).'
What tool are you talking about?
Instead of deflecting to irrelevant claims about my past threads, perhaps you
could explain why you believe a permanent, unmonitored, root-privileged binary
left behind in a system folder is a textbook example of "good security
design"?
I am just asking what tool you even mean. And sadly you do not know. You are going with AI, forgetting you went around and around with this before YOUR image showed your claim was not accurate.
You are insisting EtreCheck is doing something -- without being specific on what file -- that you already admitted it does not do.
What binaries are you talking about?
What "root tools" are you referring to?
What tool are you talking about? I am just asking what tool you even mean.
Stopped when the "powers that be"
thought I might kill someone 'other than the enemy' (myself and/or my
crew!).
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 45:27:11 |
| Calls: | 1,100 |
| Files: | 1,339 |
| Messages: | 275,372 |
