Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.mac.advocacy > #142999 > unrolled thread
| Started by | Octothorpe Obelus <one2threeMainstreet@anytown.org> |
|---|---|
| First post | 2026-03-03 19:16 -0500 |
| Last post | 2026-03-08 09:00 +0000 |
| Articles | 20 on this page of 118 — 17 participants |
Back to article view | Back to comp.sys.mac.advocacy
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: How To Protect Your Mac From Being Bricked Octothorpe Obelus <one2threeMainstreet@anytown.org> - 2026-03-03 19:16 -0500
Re: How To Protect Your Mac From Being Bricked Gremlin <nobody@haph.org> - 2026-03-07 05:57 +0000
Re: How To Protect Your Mac From Being Bricked super70s <super70s@super70s.invalid> - 2026-03-07 01:59 -0600
Re: How To Protect Your Mac From Being Bricked pothead <pothead@snakebite.com> - 2026-03-07 23:06 +0000
Re: How To Protect Your Mac From Being Bricked % <pursent100@gmail.com> - 2026-03-07 20:26 -0700
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-08 05:32 +0000
Re: How To Protect Your Mac From Being Bricked Bobby The Shitstain <hotmailsss@hotmail.edu> - 2026-03-08 08:55 +0000
Re: How To Protect Your Mac From Being Bricked Ubiquitous <webermark@polaris.net> - 2026-03-08 09:03 +0000
Re: How To Protect Your Mac From Being Bricked Gremlin <nobody@haph.org> - 2026-03-08 04:28 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-08 04:42 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-08 04:48 +0000
Re: How To Protect Your Mac From Being Bricked Gremlin <nobody@haph.org> - 2026-03-08 04:28 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-07 08:24 +0000
Re: How To Protect Your Mac From Being Bricked Gremlin <nobody@haph.org> - 2026-03-08 04:28 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-08 20:04 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-08 23:56 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-09 18:32 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-09 18:38 +0000
Re: How To Protect Your Mac From Being Bricked Kelly Phillips <KFile@podcasts.org.invalid> - 2026-03-09 18:32 -0500
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-10 00:11 +0000
Re: How To Protect Your Mac From Being Bricked Alan <nuh-uh@nope.com> - 2026-03-09 17:16 -0700
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-10 00:38 +0000
Re: How To Protect Your Mac From Being Bricked "Lionel Tiberius Jackson Jr." <lTjjr@localmail.net> - 2026-03-09 20:56 -0400
Re: How To Protect Your Mac From Being Bricked % <pursent100@gmail.com> - 2026-03-09 20:40 -0700
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-11 11:08 +0000
Re: How To Protect Your Mac From Being Bricked % <pursent100@gmail.com> - 2026-03-09 17:58 -0700
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-10 16:38 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-10 21:35 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-11 01:40 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-11 09:27 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-11 14:03 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-11 14:32 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-12 01:43 +0000
Re: How To Protect Your Mac From Being Bricked "Lionel Tiberius Jackson Jr." <lTjjr@localmail.net> - 2026-03-11 21:55 -0400
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-12 11:22 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-12 14:14 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-12 15:16 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-12 15:54 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-12 16:49 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-12 17:40 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-12 22:05 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-12 22:19 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-12 23:27 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-13 00:09 +0000
Re: How To Protect Your Mac From Being Bricked % <pursent100@gmail.com> - 2026-03-12 18:37 -0700
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-13 18:19 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-13 09:55 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <Brock.McNuggets@gmail.com> - 2026-03-13 13:46 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-13 22:41 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-13 23:43 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-14 00:10 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-14 01:10 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-14 08:03 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <Brock.McNuggets@gmail.com> - 2026-03-14 09:26 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-14 14:25 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-14 15:44 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-14 15:56 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-14 18:07 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-16 10:53 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <Brock.McNuggets@gmail.com> - 2026-03-16 13:46 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <Brock.McNuggets@gmail.com> - 2026-03-14 15:52 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-14 16:13 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-14 18:08 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-16 10:38 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-14 20:22 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-16 10:40 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-16 14:07 +0000
Re: How To Protect Your Mac From Being Bricked Kelly Phillips <KFile@podcasts.org.invalid> - 2026-03-16 13:23 -0500
Re: How To Protect Your Mac From Being Bricked "Nobody" <nobodyspecial@kinkos.net> - 2026-03-14 18:48 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-14 19:58 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-16 10:43 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-16 14:06 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-16 23:39 +0000
Re: How To Protect Your Mac From Being Bricked Glock <glock@localhost.com> - 2026-03-14 21:15 +0000
Re: How To Protect Your Mac From Being Bricked % <pursent100@gmail.com> - 2026-03-14 14:30 -0700
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-15 01:25 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-15 01:26 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-08 05:23 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-08 13:11 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-08 17:51 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-08 20:28 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-08 21:36 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-08 22:21 +0000
Re: How To Protect Your Mac From Being Bricked Alan <nuh-uh@nope.com> - 2026-03-08 16:21 -0700
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-08 23:36 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-09 00:26 +0000
Re: How To Protect Your Mac From Being Bricked Alan <nuh-uh@nope.com> - 2026-03-08 17:50 -0700
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-09 18:22 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-09 18:39 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-09 00:27 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-09 20:01 +0000
Re: How To Protect Your Mac From Being Bricked % <pursent100@gmail.com> - 2026-03-09 14:37 -0700
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-09 22:06 +0000
Re: How To Protect Your Mac From Being Bricked % <pursent100@gmail.com> - 2026-03-09 15:13 -0700
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-09 23:42 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-09 00:02 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-09 18:48 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-09 19:00 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-10 22:04 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-11 01:38 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-13 19:58 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-13 22:00 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-13 23:36 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-14 00:16 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-14 01:04 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-13 18:39 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-13 18:52 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-13 20:22 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-08 04:45 +0000
Re: How To Protect Your Mac From Being Bricked Creon <creon@creon.earth> - 2026-03-11 11:25 +0000
Re: How To Protect Your Mac From Being Bricked Brock McNuggets <brock.mcnuggets@gmail.com> - 2026-03-11 14:01 +0000
Re: How To Protect Your Mac From Being Bricked % <pursent100@gmail.com> - 2026-03-11 10:04 -0700
Re: How To Protect Your Mac From Being Bricked Creon <creon@creon.earth> - 2026-03-11 09:37 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-11 09:43 +0000
Re: How To Protect Your Mac From Being Bricked Creon <creon@creon.earth> - 2026-03-11 11:11 +0000
Re: How To Protect Your Mac From Being Bricked "David B." <David@hotmail.co.uk> - 2026-03-11 23:26 +0000
Re: How To Protect Your Mac From Being Bricked Gremlin <nobody@haph.org> - 2026-03-22 06:18 +0000
Re: How To Protect Your Mac From Being Bricked c186282 <c186282@nnada.ne> - 2026-03-08 09:00 +0000
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | "David B." <David@hotmail.co.uk> |
|---|---|
| Date | 2026-03-12 22:05 +0000 |
| Message-ID | <n1grlhFeoa7U1@mid.individual.net> |
| In reply to | #143326 |
On 12/03/2026 17:40, Brock McNuggets wrote: > On Mar 12, 2026 at 9:49:38 AM MST, ""David B."" wrote > <n1g953FbuilU1@mid.individual.net>: <BIG SNIP> >> I prefer to verify. > > No. You are not verifying anything. You are obsessing and attacking. Please > stop. Brock, You are leaning heavily on the "harassment" label to avoid addressing the underlying security architecture. Let’s look at the technical facts: 1. The Root of Trust (Developer ID and Gatekeeper) You claim that because EtreCheck isn't in the App Store, the developer's standing there is irrelevant. This is technically incorrect. Apple’s security model for both Notarization and the App Store relies on the same Developer ID certificate. When a user launches an app, Gatekeeper performs a series of checks. It doesn't just look for a signature; it checks the Notarization ticket and queries Apple's OCSP (Online Certificate Status Protocol) servers to see if the developer's certificate is still valid. If a developer is caught engaging in malicious activity or violates Apple's trust in a way that leads to a certificate revocation, it doesn't just affect one app. The moment that certificate is revoked, Gatekeeper will block every piece of standalone software they’ve released—including EtreCheck. They are intrinsically linked by the same cryptographic root of trust. Monitoring a developer's standing across the ecosystem is a logical way to gauge the reliability of their software. 2. Functional Access vs. Intent You admitted that an app with permissions can do "all sorts of things." We agree there. Where we differ is that you trust the developer's intent, while I am looking at the functional capability. If a program has the "run" and "network" entitlements, the technical "access" exists. Pointing out this potential attack surface isn't an "attack" on the author; it’s a basic risk assessment of the code and the "Hardened Runtime" it operates within. 3. The Purpose of a Workshop A technical newsgroup is exactly the place to analyze how software interacts with our systems. If questioning a commercial product's "phoning-home" behaviour and its security lifecycle is "harmful" to you, then you are valuing personal sentiment over technical transparency. The developer is an active commercial entity on the ASC forums; his products are not immune to critique. I have no interest in his personal choices regarding who he speaks to. I am interested in the code running on my iMac. I will continue to "audit" and "verify" any software I choose to use, as should anyone who values system integrity. -- David
[toc] | [prev] | [next] | [standalone]
| From | Brock McNuggets <brock.mcnuggets@gmail.com> |
|---|---|
| Date | 2026-03-12 22:19 +0000 |
| Message-ID | <69b33bfe$1$18$882e4bbb@reader.netnews.com> |
| In reply to | #143332 |
On Mar 12, 2026 at 3:05:37 PM MST, ""David B."" wrote <n1grlhFeoa7U1@mid.individual.net>: > On 12/03/2026 17:40, Brock McNuggets wrote: >> On Mar 12, 2026 at 9:49:38 AM MST, ""David B."" wrote >> <n1g953FbuilU1@mid.individual.net>: > > <BIG SNIP> >>> I prefer to verify. >> >> No. You are not verifying anything. You are obsessing and attacking. Please >> stop. > > Brock, > > You are leaning heavily on the "harassment" label to avoid addressing > the underlying security architecture. No, I am noting harassment is wrong. You have spent years "investigating" and found -- NOTHING. The only thing you ever find is your obsession with him and his product, and your need to make a bunch of negative insinuations. It is wrong of you. > Let’s look at the technical facts: > > 1. The Root of Trust (Developer ID and Gatekeeper) > You claim that because EtreCheck isn't in the App Store, the developer's > standing there is irrelevant. No. If he was found to be doing wrong there it would matter. But him being there is not a signhe was doing wrong until he was there. > This is technically incorrect. Apple’s > security model for both Notarization and the App Store relies on the > same Developer ID certificate. This is not in question. You AI is not understanding things any better than you are. > > When a user launches an app, Gatekeeper performs a series of checks. It > doesn't just look for a signature; it checks the Notarization ticket and > queries Apple's OCSP (Online Certificate Status Protocol) servers to see > if the developer's certificate is still valid. If a developer is caught > engaging in malicious activity or violates Apple's trust in a way that > leads to a certificate revocation, it doesn't just affect one app. The > moment that certificate is revoked, Gatekeeper will block every piece of > standalone software they’ve released—including EtreCheck. They are > intrinsically linked by the same cryptographic root of trust. Monitoring > a developer's standing across the ecosystem is a logical way to gauge > the reliability of their software. This is true for software that is NOT on the store, too. Again, you keep staring things you do not understand. Your "investigation" is not investigating anything. It is your own obsession with this innocent man and your need to attack him. Please stop. > > 2. Functional Access vs. Intent > You admitted that an app with permissions can do "all sorts of things." You say "admit" as if this is in question. Seriously, you are not understanding any of what you "investigate". You are merely making of fool of yourself and seeking to harm an innocent man. > We agree there. Where we differ is that you trust the developer's > intent, while I am looking at the functional capability. You are not looking at "functional capacity" -- you are targeting a specific person with unfounded attacks. > If a program > has the "run" and "network" entitlements, the technical "access" exists. > Pointing out this potential attack surface isn't an "attack" on the > author; it’s a basic risk assessment of the code and the "Hardened > Runtime" it operates within. Again: you are singling out one person based on your own challenges. It has nothing to do with Etrecheck or its developer but your own obsession. PLEASE STOP! > > 3. The Purpose of a Workshop > A technical newsgroup is exactly the place to analyze how software > interacts with our systems. If questioning a commercial product's > "phoning-home" behaviour and its security lifecycle is "harmful" to you, > then you are valuing personal sentiment over technical transparency. This again shows you (and you AI) cannot understand what you are reading. I never said your harassment of him was a direct harm to me. Why do you think he refuses to speak to you? Why do you think everyone you encounter on your one-man crusade, friend or foe, tells you how misguided you are? > The developer is an active commercial entity on the ASC forums; his > products are not immune to critique. Nobody said they were... but harassment is WRONG. Please stop! > I have no interest in his personal > choices regarding who he speaks to. I am interested in the code running > on my iMac. I will continue to "audit" and "verify" any software I > choose to use, as should anyone who values system integrity. You are not auditing anything. You are not verifying anything. You do not even understand the basics here. You simply target and harass an innocent man. It is wrong, David. I say this as a friend. I do not think you mean to cause harm -- I do not think you understand how much your focus on this software, or ClamXAV, is utter nonsense -- but it is. Even if something shows up in the future where it is found he is doing wrong, YOU will not be the one to find it. You are not helping anyone here. You are harming him and making a fool of yourself. Period. -- It's impossible for someone who is at war with themselves to be at peace with you.
[toc] | [prev] | [next] | [standalone]
| From | "David B." <David@hotmail.co.uk> |
|---|---|
| Date | 2026-03-12 23:27 +0000 |
| Message-ID | <n1h0eeFfgrrU1@mid.individual.net> |
| In reply to | #143333 |
On 12/03/2026 22:19, Brock McNuggets wrote: <BIG SNIP AGAIN> > It is wrong, David. I say this as a friend. I do not think you mean to cause > harm -- I do not think you understand how much your focus on this software, or > ClamXAV, is utter nonsense -- but it is. Even if something shows up in the > future where it is found he is doing wrong, YOU will not be the one to find > it. You are not helping anyone here. You are harming him and making a fool of > yourself. Period. Brock, You’ve made it clear that you prefer to focus on the person rather than the protocol. My "investigation" has yielded exactly what I sought: a clear understanding of the cryptographic dependencies between a developer's standing with Apple and the viability of their software. Whether you label that "obsession" or "due diligence" doesn't change the technical reality of how Gatekeeper and OCSP function. If you think technical scrutiny of a commercial product is "nonsense," we simply have different standards for system security. I’m happy to leave the moralizing to you; I’ll stick to the technicals. Rest easy — my "obsession" is with my own system's integrity, not the developer's personal feelings. David
[toc] | [prev] | [next] | [standalone]
| From | Brock McNuggets <brock.mcnuggets@gmail.com> |
|---|---|
| Date | 2026-03-13 00:09 +0000 |
| Message-ID | <69b355a1$3$26$882e4bbb@reader.netnews.com> |
| In reply to | #143336 |
On Mar 12, 2026 at 4:27:09 PM MST, ""David B."" wrote <n1h0eeFfgrrU1@mid.individual.net>: > On 12/03/2026 22:19, Brock McNuggets wrote: > > <BIG SNIP AGAIN> > >> It is wrong, David. I say this as a friend. I do not think you mean to cause >> harm -- I do not think you understand how much your focus on this software, or >> ClamXAV, is utter nonsense -- but it is. Even if something shows up in the >> future where it is found he is doing wrong, YOU will not be the one to find >> it. You are not helping anyone here. You are harming him and making a fool of >> yourself. Period. > > Brock, > > You’ve made it clear that you prefer to focus on the person rather than > the protocol. No. You and your AI are just flat out wrong. I am asking you to please leave him alone. STOP HARASSING HIM! You are in the wrong. But, and this is sad and hard to say, you don't care. You do not care if you harm him. Your own false sense of security -- and it is false -- is more important to you than if you harm someone. This is what Carroll does with me. Granted, you are not as extreme. You ask absurd questions and make absurd insinuations but you do not create socks to pretend there is more support, you do not lie about his driving record, you do not make up stories about legal issues. So you are not as bad. Not nearly. But you are still wrong. > > My "investigation" has yielded exactly what I sought: a clear > understanding of the cryptographic dependencies between a developer's > standing with Apple and the viability of their software. No. It has not. You continually make claims like how EtreCheck is somehow safer to use because the developer again has an app on the App Store. You say things like how the developer has access to your machine because the software does, as if the developer is doing something wrong. No evidence. No support. Just wrong insinuation. > Whether you > label that "obsession" or "due diligence" doesn't change the technical > reality of how Gatekeeper and OCSP function. It is obsession and it is not "due diligence" at all. Due diligence would not target one developer and his software. Nor two if you count your past focus on ClamXAV. This is a nasty and personal vendetta on your part. And it is wrong. > > If you think technical scrutiny of a commercial product is "nonsense," I said nothing of the sort. You make things up to try to defend your harm. > we simply have different standards for system security. I’m happy to > leave the moralizing to you; I’ll stick to the technicals. The fact you refuse to is a part of the problem. > > Rest easy — my "obsession" is with my own system's integrity, not the > developer's personal feelings. You do not care what harm you do nor his feelings about the harm you do. THAT is an issue. David, stop using AI, stop this nonsense vendetta against him, and stop pretending it has anything to do with security concerns. If it did it would be broader in scope. It is targeted -- laser focused on one person. > > David -- It's impossible for someone who is at war with themselves to be at peace with you.
[toc] | [prev] | [next] | [standalone]
| From | % <pursent100@gmail.com> |
|---|---|
| Date | 2026-03-12 18:37 -0700 |
| Message-ID | <-HCdnexEN_Tt9y70nZ2dnZfqnPqdnZ2d@giganews.com> |
| In reply to | #143337 |
Brock McNuggets wrote: > On Mar 12, 2026 at 4:27:09 PM MST, ""David B."" wrote > <n1h0eeFfgrrU1@mid.individual.net>: > >> On 12/03/2026 22:19, Brock McNuggets wrote: >> >> <BIG SNIP AGAIN> >> >>> It is wrong, David. I say this as a friend. I do not think you mean to cause >>> harm -- I do not think you understand how much your focus on this software, or >>> ClamXAV, is utter nonsense -- but it is. Even if something shows up in the >>> future where it is found he is doing wrong, YOU will not be the one to find >>> it. You are not helping anyone here. You are harming him and making a fool of >>> yourself. Period. >> >> Brock, >> >> You’ve made it clear that you prefer to focus on the person rather than >> the protocol. > > No. You and your AI are just flat out wrong. I am asking you to please leave > him alone. STOP HARASSING HIM! You are in the wrong. > > But, and this is sad and hard to say, you don't care. You do not care if you > harm him. Your own false sense of security -- and it is false -- is more > important to you than if you harm someone. > > This is what Carroll does with me. Granted, you are not as extreme. You ask > absurd questions and make absurd insinuations but you do not create socks to > pretend there is more support, you do not lie about his driving record, you do > not make up stories about legal issues. So you are not as bad. Not nearly. But > you are still wrong. >> >> My "investigation" has yielded exactly what I sought: a clear >> understanding of the cryptographic dependencies between a developer's >> standing with Apple and the viability of their software. > > No. It has not. You continually make claims like how EtreCheck is somehow > safer to use because the developer again has an app on the App Store. You say > things like how the developer has access to your machine because the software > does, as if the developer is doing something wrong. No evidence. No support. > Just wrong insinuation. > >> Whether you >> label that "obsession" or "due diligence" doesn't change the technical >> reality of how Gatekeeper and OCSP function. > > It is obsession and it is not "due diligence" at all. Due diligence would not > target one developer and his software. Nor two if you count your past focus on > ClamXAV. This is a nasty and personal vendetta on your part. And it is wrong. >> >> If you think technical scrutiny of a commercial product is "nonsense," > > I said nothing of the sort. You make things up to try to defend your harm. > >> we simply have different standards for system security. I’m happy to >> leave the moralizing to you; I’ll stick to the technicals. > > The fact you refuse to is a part of the problem. >> >> Rest easy — my "obsession" is with my own system's integrity, not the >> developer's personal feelings. > > You do not care what harm you do nor his feelings about the harm you do. THAT > is an issue. > > David, stop using AI, stop this nonsense vendetta against him, and stop > pretending it has anything to do with security concerns. If it did it would be > broader in scope. It is targeted -- laser focused on one person. >> >> David > > go david go , wreck everything
[toc] | [prev] | [next] | [standalone]
| From | Brock McNuggets <brock.mcnuggets@gmail.com> |
|---|---|
| Date | 2026-03-13 18:19 +0000 |
| Message-ID | <69b4552e$0$19$882e4bbb@reader.netnews.com> |
| In reply to | #143339 |
On Mar 12, 2026 at 6:37:46 PM MST, "%" wrote <-HCdnexEN_Tt9y70nZ2dnZfqnPqdnZ2d@giganews.com>: > Brock McNuggets wrote: >> On Mar 12, 2026 at 4:27:09 PM MST, ""David B."" wrote >> <n1h0eeFfgrrU1@mid.individual.net>: >> >>> On 12/03/2026 22:19, Brock McNuggets wrote: >>> >>> <BIG SNIP AGAIN> >>> >>>> It is wrong, David. I say this as a friend. I do not think you mean to cause >>>> harm -- I do not think you understand how much your focus on this software, or >>>> ClamXAV, is utter nonsense -- but it is. Even if something shows up in the >>>> future where it is found he is doing wrong, YOU will not be the one to find >>>> it. You are not helping anyone here. You are harming him and making a fool of >>>> yourself. Period. >>> >>> Brock, >>> >>> You’ve made it clear that you prefer to focus on the person rather than >>> the protocol. >> >> No. You and your AI are just flat out wrong. I am asking you to please leave >> him alone. STOP HARASSING HIM! You are in the wrong. >> >> But, and this is sad and hard to say, you don't care. You do not care if you >> harm him. Your own false sense of security -- and it is false -- is more >> important to you than if you harm someone. >> >> This is what Carroll does with me. Granted, you are not as extreme. You ask >> absurd questions and make absurd insinuations but you do not create socks to >> pretend there is more support, you do not lie about his driving record, you do >> not make up stories about legal issues. So you are not as bad. Not nearly. But >> you are still wrong. >>> >>> My "investigation" has yielded exactly what I sought: a clear >>> understanding of the cryptographic dependencies between a developer's >>> standing with Apple and the viability of their software. >> >> No. It has not. You continually make claims like how EtreCheck is somehow >> safer to use because the developer again has an app on the App Store. You say >> things like how the developer has access to your machine because the software >> does, as if the developer is doing something wrong. No evidence. No support. >> Just wrong insinuation. >> >>> Whether you >>> label that "obsession" or "due diligence" doesn't change the technical >>> reality of how Gatekeeper and OCSP function. >> >> It is obsession and it is not "due diligence" at all. Due diligence would not >> target one developer and his software. Nor two if you count your past focus on >> ClamXAV. This is a nasty and personal vendetta on your part. And it is wrong. >>> >>> If you think technical scrutiny of a commercial product is "nonsense," >> >> I said nothing of the sort. You make things up to try to defend your harm. >> >>> we simply have different standards for system security. I’m happy to >>> leave the moralizing to you; I’ll stick to the technicals. >> >> The fact you refuse to is a part of the problem. >>> >>> Rest easy — my "obsession" is with my own system's integrity, not the >>> developer's personal feelings. >> >> You do not care what harm you do nor his feelings about the harm you do. THAT >> is an issue. >> >> David, stop using AI, stop this nonsense vendetta against him, and stop >> pretending it has anything to do with security concerns. If it did it would be >> broader in scope. It is targeted -- laser focused on one person. >>> >>> David >> >> > go david go , wreck everything LOL! I know I am wasting my virtual breath... but I do respect David. I am hoping he will listen and stop with these vendettas against imagined enemies. -- It's impossible for someone who is at war with themselves to be at peace with you.
[toc] | [prev] | [next] | [standalone]
| From | "David B." <David@hotmail.co.uk> |
|---|---|
| Date | 2026-03-13 09:55 +0000 |
| Message-ID | <n1i58aFktauU1@mid.individual.net> |
| In reply to | #143337 |
On 13/03/2026 00:09, Brock McNuggets wrote: [....] > David, stop using AI, stop this nonsense vendetta against him, and stop > pretending it has anything to do with security concerns. If it did it would be > broader in scope. It is targeted -- laser focused on one person. Brock, It's interesting that you’ve pivoted from a technical discussion to an emotional intervention. Telling me to "stop using AI" is a strange way to concede that the technical points—specifically the OCSP and Developer ID links—are indeed accurate and irrefutable. You keep using the word "harassment." In a technical workshop, auditing the behavior of a commercial product (and the standing of the entity behind it) isn't harassment—it's consumer transparency. If a software product "phones home" and relies on a specific cryptographic chain of trust, those are legitimate topics for debate. Since you mentioned ClamXAV, it's a perfect example of why this "due diligence" matters. When a user pays a subscription to a company like Canimaan Software Ltd, they aren't just buying code; they are buying the stability and reliability of that company. As someone with a background in financial advising, I tend to look at the "Hardened Runtime" of the business as well as the software. If a company operates as a Micro-Entity in Edinburgh while handling global security data, or if the directors are heavily utilizing Director’s Loans from company coffers, that is a valid data point for a user's risk assessment. It’s not a "vendetta"; it’s an audit. I’m happy to stick to the technicals and the financials. If you find the reality of macOS security or corporate filings "absurd," then we simply have a different understanding of what "verifying" actually means. I'll leave the moralizing to you. I have some financial ledgers to finish reviewing! -- Kind regards, David
[toc] | [prev] | [next] | [standalone]
| From | Brock McNuggets <Brock.McNuggets@gmail.com> |
|---|---|
| Date | 2026-03-13 13:46 +0000 |
| Message-ID | <69b41524$0$54857$882e4bbb@reader.netnews.com> |
| In reply to | #143349 |
David B. <David@hotmail.co.uk> wrote: > On 13/03/2026 00:09, Brock McNuggets wrote: > [....] >> David, stop using AI, stop this nonsense vendetta against him, and stop >> pretending it has anything to do with security concerns. If it did it would be >> broader in scope. It is targeted -- laser focused on one person. > > Brock, > > It's interesting that you’ve pivoted from a technical discussion to an > emotional intervention. Telling me to "stop using AI" is a strange way > to concede that the technical points—specifically the OCSP and Developer > ID links—are indeed accurate and irrefutable. > > You keep using the word "harassment." In a technical workshop, auditing > the behavior of a commercial product (and the standing of the entity > behind it) isn't harassment—it's consumer transparency. If a software > product "phones home" and relies on a specific cryptographic chain of > trust, those are legitimate topics for debate. > > Since you mentioned ClamXAV, it's a perfect example of why this "due > diligence" matters. When a user pays a subscription to a company like > Canimaan Software Ltd, they aren't just buying code; they are buying the > stability and reliability of that company. > > As someone with a background in financial advising, I tend to look at > the "Hardened Runtime" of the business as well as the software. If a > company operates as a Micro-Entity in Edinburgh while handling global > security data, or if the directors are heavily utilizing Director’s > Loans from company coffers, that is a valid data point for a user's risk > assessment. It’s not a "vendetta"; it’s an audit. > > I’m happy to stick to the technicals and the financials. If you find the > reality of macOS security or corporate filings "absurd," then we simply > have a different understanding of what "verifying" actually means. > > I'll leave the moralizing to you. I have some financial ledgers to > finish reviewing! > > David, You’re not being asked to “stop using AI” because the points are irrefutable. You’re being asked to stop using it because it’s clearly generating confident-sounding explanations about topics you don’t actually understand. That’s not verification — it’s cargo-cult technical analysis. Let’s untangle a few things. First, OCSP and Developer ID aren’t discoveries. They’re fundamental parts of the macOS security model created by Apple. Every properly signed macOS application participates in that chain of trust. Mentioning those terms doesn’t reveal anything unusual about a specific utility — it simply shows the software is behaving exactly the way the platform is designed to behave. Second, EtreCheck isn’t “phoning home” in the conspiratorial sense you’re implying. The developer, Etresoft (Etresoft), has been extremely transparent for years about what the app does: it collects system diagnostic data locally and can optionally share anonymized data for troubleshooting. That’s normal for diagnostic utilities and has been publicly documented many times. Third, bringing up UK corporate filings and director’s loans for the company behind ClamXAV — Canimaan Software Ltd — isn’t “auditing the hardened runtime of the business.” It’s just dragging unrelated financial trivia into a technical discussion. UK small-company filings routinely include director loans; they’re common, legal, and not remotely indicative of security risk. So no, the issue isn’t that the “technical points are irrefutable.” The issue is that the points being presented don’t actually support the conclusions you’re drawing from them. Calling that “harassment” isn’t moralizing — it’s pointing out that repeatedly targeting a small independent developer with speculative accusations based on misunderstood infrastructure isn’t productive or fair. If you want to discuss macOS security, great. There are lots of interesting details in the notarization and Developer ID systems. But right now you’re treating ordinary platform behavior as if it were a discovery, and treating public company filings as if they were a vulnerability report. That’s not an audit. It’s just noise. -- Personal attacks from those who troll show their own insecurity. They cannot use reason to show the message to be wrong so they try to feel somehow superior by attacking the messenger. They cling to their attacks and ignore the message time and time again.
[toc] | [prev] | [next] | [standalone]
| From | "David B." <David@hotmail.co.uk> |
|---|---|
| Date | 2026-03-13 22:41 +0000 |
| Message-ID | <n1ji5dFrnn7U1@mid.individual.net> |
| In reply to | #143355 |
On 13/03/2026 13:46, Brock McNuggets wrote: [....] > David, > > You’re not being asked to “stop using AI” because the points are > irrefutable. You’re being asked to stop using it because it’s clearly > generating confident-sounding explanations about topics you don’t actually > understand. That’s not verification — it’s cargo-cult technical analysis. > > Let’s untangle a few things. > > First, OCSP and Developer ID aren’t discoveries. They’re fundamental parts > of the macOS security model created by Apple. Every properly signed macOS > application participates in that chain of trust. Mentioning those terms > doesn’t reveal anything unusual about a specific utility — it simply shows > the software is behaving exactly the way the platform is designed to > behave. Of course. > Second, EtreCheck isn’t “phoning home” in the conspiratorial sense you’re > implying. The developer, Etresoft (Etresoft), has been extremely > transparent for years about what the app does: it collects system > diagnostic data locally and can optionally share anonymized data for > troubleshooting. That’s normal for diagnostic utilities and has been > publicly documented many times. That's correct. It DOES have a connection to my computer when I run it. > Third, bringing up UK corporate filings and director’s loans for the > company behind ClamXAV — Canimaan Software Ltd — isn’t “auditing the > hardened runtime of the business.” It’s just dragging unrelated financial > trivia into a technical discussion. UK small-company filings routinely > include director loans; they’re common, legal, and not remotely indicative > of security risk. It's an indication of possible criminal activity. > So no, the issue isn’t that the “technical points are irrefutable.” The > issue is that the points being presented don’t actually support the > conclusions you’re drawing from them. That's just *your* opinion. Most folk do not trust what you say. :-( > Calling that “harassment” isn’t moralizing — it’s pointing out that > repeatedly targeting a small independent developer with speculative > accusations based on misunderstood infrastructure isn’t productive or fair. I haven't misunderstood anything! > If you want to discuss macOS security, great. There are lots of interesting > details in the notarization and Developer ID systems. But right now you’re > treating ordinary platform behavior as if it were a discovery, and treating > public company filings as if they were a vulnerability report. > > That’s not an audit. > > It’s just noise. No, it's not. You have taken no interest in matters which have concerned me. I even feel guilty for having recommended that you use Usenapp. That's another suspect software from someone who hides in the shadows! You've never shown any interest in a product which could be logging every key which you press on your keyboard! You simply don't care, do you? -- Kind regards, David
[toc] | [prev] | [next] | [standalone]
| From | Brock McNuggets <brock.mcnuggets@gmail.com> |
|---|---|
| Date | 2026-03-13 23:43 +0000 |
| Message-ID | <69b4a123$0$27$882e4bbb@reader.netnews.com> |
| In reply to | #143381 |
On Mar 13, 2026 at 3:41:49 PM MST, ""David B."" wrote <n1ji5dFrnn7U1@mid.individual.net>: > On 13/03/2026 13:46, Brock McNuggets wrote: > [....] >> David, >> >> You’re not being asked to “stop using AI” because the points are >> irrefutable. You’re being asked to stop using it because it’s clearly >> generating confident-sounding explanations about topics you don’t actually >> understand. That’s not verification — it’s cargo-cult technical analysis. >> >> Let’s untangle a few things. >> >> First, OCSP and Developer ID aren’t discoveries. They’re fundamental parts >> of the macOS security model created by Apple. Every properly signed macOS >> application participates in that chain of trust. Mentioning those terms >> doesn’t reveal anything unusual about a specific utility — it simply shows >> the software is behaving exactly the way the platform is designed to >> behave. > > Of course. > >> Second, EtreCheck isn’t “phoning home” in the conspiratorial sense you’re >> implying. The developer, Etresoft (Etresoft), has been extremely >> transparent for years about what the app does: it collects system >> diagnostic data locally and can optionally share anonymized data for >> troubleshooting. That’s normal for diagnostic utilities and has been >> publicly documented many times. > > That's correct. It DOES have a connection to my computer when I run it. What "it"? The software running on your system? How could it NOT have a "connection" to your system? What would that even mean? > >> Third, bringing up UK corporate filings and director’s loans for the >> company behind ClamXAV — Canimaan Software Ltd — isn’t “auditing the >> hardened runtime of the business.” It’s just dragging unrelated financial >> trivia into a technical discussion. UK small-company filings routinely >> include director loans; they’re common, legal, and not remotely indicative >> of security risk. > > It's an indication of possible criminal activity. Your harassment of these people is possible criminal activity. > >> So no, the issue isn’t that the “technical points are irrefutable.” The >> issue is that the points being presented don’t actually support the >> conclusions you’re drawing from them. > > That's just *your* opinion. Most folk do not trust what you say. :-( You have no counter... and immediately drop your argument and move to ad hominem. That is a sign even you know you really have no point to make. > >> Calling that “harassment” isn’t moralizing — it’s pointing out that >> repeatedly targeting a small independent developer with speculative >> accusations based on misunderstood infrastructure isn’t productive or fair. > > I haven't misunderstood anything! You absolutely have. And have been called out. Repeatedly. > >> If you want to discuss macOS security, great. There are lots of interesting >> details in the notarization and Developer ID systems. But right now you’re >> treating ordinary platform behavior as if it were a discovery, and treating >> public company filings as if they were a vulnerability report. >> >> That’s not an audit. >> >> It’s just noise. > > No, it's not. You have taken no interest in matters which have > concerned me. I have no interest in harassing ANYONE. > I even feel guilty for having recommended that you use Usenapp. > That's another suspect software from someone who hides in the shadows! > You've never shown any interest in a product which could be logging > every key which you press on your keyboard! You simply don't care, do you? I am not paranoid and filled with fear over every app. No. Nor should I be. It would be absurd to be so. And to use such a personal issue as an excuse to harass others would be wrong -- and perhaps illegal. -- It's impossible for someone who is at war with themselves to be at peace with you.
[toc] | [prev] | [next] | [standalone]
| From | "David B." <David@hotmail.co.uk> |
|---|---|
| Date | 2026-03-14 00:10 +0000 |
| Message-ID | <n1jnboFsgmpU1@mid.individual.net> |
| In reply to | #143385 |
On 13/03/2026 23:43, Brock McNuggets wrote: > On Mar 13, 2026 at 3:41:49 PM MST, ""David B."" wrote > <n1ji5dFrnn7U1@mid.individual.net>: > >> On 13/03/2026 13:46, Brock McNuggets wrote: >> [....] >>> David, >>> >>> You’re not being asked to “stop using AI” because the points are >>> irrefutable. You’re being asked to stop using it because it’s clearly >>> generating confident-sounding explanations about topics you don’t actually >>> understand. That’s not verification — it’s cargo-cult technical analysis. >>> >>> Let’s untangle a few things.<SNIP> Brock/Michael, Since you've moved this from a technical discussion to a personal intervention, let's be clear: we’ve been friends on Facebook for a long time, and I stood by you during your divorce. You know better than anyone that I don't act out of malice or a "vendetta." However, in a technical workshop, friendship is not a substitute for verification. You dismiss corporate filings as "trivia," but as an IFA, I see them differently. Canimaan Software Ltd is a "Micro-Entity" in Edinburgh. When such a small firm—handling global security subscriptions—shows significant Director’s Loans on its balance sheet while relying on "long-term workarounds" for kernel panics (as documented in their own version history), that is a professional red flag. It isn't "harassment" to point out that a company’s financial liquidity and technical architecture are linked. You tell me to "stop using AI," yet you haven't refuted the technical reality of OCSP or Developer ID revocation. You’ve simply labeled the facts "noise" because they don't fit your narrative of "protecting" an innocent developer. I’m not "paranoid," Michael. I’m an auditor. I separate the person from the product. If you find technical and financial transparency "absurd," then we simply have a fundamental disagreement on what constitutes system security. I’m going to get some rest now. I'll leave the moralizing to you; I’ll stick to the ledgers. David
[toc] | [prev] | [next] | [standalone]
| From | Brock McNuggets <brock.mcnuggets@gmail.com> |
|---|---|
| Date | 2026-03-14 01:10 +0000 |
| Message-ID | <69b4b599$0$24$882e4bbb@reader.netnews.com> |
| In reply to | #143386 |
On Mar 13, 2026 at 5:10:31 PM MST, ""David B."" wrote <n1jnboFsgmpU1@mid.individual.net>: > On 13/03/2026 23:43, Brock McNuggets wrote: >> On Mar 13, 2026 at 3:41:49 PM MST, ""David B."" wrote >> <n1ji5dFrnn7U1@mid.individual.net>: >> >>> On 13/03/2026 13:46, Brock McNuggets wrote: >>> [....] >>>> David, >>>> >>>> You’re not being asked to “stop using AI” because the points are >>>> irrefutable. You’re being asked to stop using it because it’s clearly >>>> generating confident-sounding explanations about topics you don’t actually >>>> understand. That’s not verification — it’s cargo-cult technical analysis. >>>> >>>> Let’s untangle a few things.<SNIP> > > Brock/Michael, > > Since you've moved this from a technical discussion to a personal > intervention, This was never a technical discussion. > let's be clear: we’ve been friends on Facebook for a long > time, and I stood by you during your divorce. You know better than > anyone that I don't act out of malice or a "vendetta." I do not think you mean to cause harm -- but you are causing harm. > > However, in a technical workshop, friendship is not a substitute for > verification. > > You dismiss corporate filings as "trivia," but as an IFA, I see them > differently. Canimaan Software Ltd is a "Micro-Entity" in Edinburgh. > When such a small firm—handling global security subscriptions—shows > significant Director’s Loans on its balance sheet while relying on > "long-term workarounds" for kernel panics (as documented in their own > version history), that is a professional red flag. It isn't "harassment" > to point out that a company’s financial liquidity and technical > architecture are linked. What has come of this? > > You tell me to "stop using AI," yet you haven't refuted the technical > reality of OCSP or Developer ID revocation. What makes you think it has been in contention? As far as not using AI, I do not mean at all -- but as a substitute for understanding. > You’ve simply labeled the > facts "noise" because they don't fit your narrative of "protecting" an > innocent developer. No. You are not understanding. > > I’m not "paranoid," Michael. Your focus on EtreCheck is not rational. > I’m an auditor. No you are not. > I separate the person from > the product. No, you do not. > If you find technical and financial transparency "absurd," > then we simply have a fundamental disagreement on what constitutes > system security. I find an irrational focus on one or two developers and personal attacks and harassment to be wrong. > > I’m going to get some rest now. I'll leave the moralizing to you; I’ll > stick to the ledgers. > > David -- It's impossible for someone who is at war with themselves to be at peace with you.
[toc] | [prev] | [next] | [standalone]
| From | "David B." <David@hotmail.co.uk> |
|---|---|
| Date | 2026-03-14 08:03 +0000 |
| Message-ID | <n1kj2eF21npU1@mid.individual.net> |
| In reply to | #143389 |
On 14/03/2026 01:10, Brock McNuggets wrote: > On Mar 13, 2026 at 5:10:31 PM MST, ""David B."" wrote > <n1jnboFsgmpU1@mid.individual.net>: > >> On 13/03/2026 23:43, Brock McNuggets wrote: >>> On Mar 13, 2026 at 3:41:49 PM MST, ""David B."" wrote >>> <n1ji5dFrnn7U1@mid.individual.net>: >>> >>>> On 13/03/2026 13:46, Brock McNuggets wrote: >>>> [....] >>>>> David, >>>>> >>>>> You’re not being asked to “stop using AI” because the points are >>>>> irrefutable. You’re being asked to stop using it because it’s clearly >>>>> generating confident-sounding explanations about topics you don’t actually >>>>> understand. That’s not verification — it’s cargo-cult technical analysis. >>>>> >>>>> Let’s untangle a few things.<SNIP> >> >> Brock/Michael, >> >> Since you've moved this from a technical discussion to a personal >> intervention, > > This was never a technical discussion. > >> let's be clear: we’ve been friends on Facebook for a long >> time, and I stood by you during your divorce. You know better than >> anyone that I don't act out of malice or a "vendetta." > > I do not think you mean to cause harm -- but you are causing harm. >> >> However, in a technical workshop, friendship is not a substitute for >> verification. >> >> You dismiss corporate filings as "trivia," but as an IFA, I see them >> differently. Canimaan Software Ltd is a "Micro-Entity" in Edinburgh. >> When such a small firm—handling global security subscriptions—shows >> significant Director’s Loans on its balance sheet while relying on >> "long-term workarounds" for kernel panics (as documented in their own >> version history), that is a professional red flag. It isn't "harassment" >> to point out that a company’s financial liquidity and technical >> architecture are linked. > > What has come of this? [SNIP] Michael, You asked, "What has come of this?" What has come of it is a formal recognition that the financial and technical health of a security provider are inseparable. As an IFA, I don’t ignore a "Micro-Entity" balance sheet dominated by five-figure Director's Loans while the product itself relies on documented "workarounds" for system-level stability issues. I have taken the appropriate professional steps to ensure that the financial side of this operation is reviewed by the relevant authorities. If there is no wrongdoing, then there is no issue. But "the truth will out," and users have a right to know if the company they trust with their system's "Root" access is as stable as its marketing suggests. You call this "irrational focus." I call it professional accountability. While you focus on protecting the "man," I will continue to focus on protecting the "system." Do you actually know what an IFA does in real life? Here's a clue:- An independent financial adviser or IFA can advise you on all financial products that they think meet your needs. They are independent and whole-of-market: Independent means they aren't acting on behalf of any particular product, provider or other body.Whole-of-market means they can consider various financial products from multiple lenders.They act on behalf of you, the client, which means *the advice they give you must be impartial*. https://www.money.co.uk/guides/5-steps-to-finding-an-ifa-you-can-trust HTH. 😅 -- Kind regards, David
[toc] | [prev] | [next] | [standalone]
| From | Brock McNuggets <Brock.McNuggets@gmail.com> |
|---|---|
| Date | 2026-03-14 09:26 +0000 |
| Message-ID | <69b529e2$0$21$882e4bbb@reader.netnews.com> |
| In reply to | #143394 |
David B. <David@hotmail.co.uk> wrote: > On 14/03/2026 01:10, Brock McNuggets wrote: >> On Mar 13, 2026 at 5:10:31 PM MST, ""David B."" wrote >> <n1jnboFsgmpU1@mid.individual.net>: >> >>> On 13/03/2026 23:43, Brock McNuggets wrote: >>>> On Mar 13, 2026 at 3:41:49 PM MST, ""David B."" wrote >>>> <n1ji5dFrnn7U1@mid.individual.net>: >>>> >>>>> On 13/03/2026 13:46, Brock McNuggets wrote: >>>>> [....] >>>>>> David, >>>>>> >>>>>> You’re not being asked to “stop using AI” because the points are >>>>>> irrefutable. You’re being asked to stop using it because it’s clearly >>>>>> generating confident-sounding explanations about topics you don’t actually >>>>>> understand. That’s not verification — it’s cargo-cult technical analysis. >>>>>> >>>>>> Let’s untangle a few things.<SNIP> >>> >>> Brock/Michael, >>> >>> Since you've moved this from a technical discussion to a personal >>> intervention, >> >> This was never a technical discussion. >> >>> let's be clear: we’ve been friends on Facebook for a long >>> time, and I stood by you during your divorce. You know better than >>> anyone that I don't act out of malice or a "vendetta." >> >> I do not think you mean to cause harm -- but you are causing harm. >>> >>> However, in a technical workshop, friendship is not a substitute for >>> verification. >>> >>> You dismiss corporate filings as "trivia," but as an IFA, I see them >>> differently. Canimaan Software Ltd is a "Micro-Entity" in Edinburgh. >>> When such a small firm—handling global security subscriptions—shows >>> significant Director’s Loans on its balance sheet while relying on >>> "long-term workarounds" for kernel panics (as documented in their own >>> version history), that is a professional red flag. It isn't "harassment" >>> to point out that a company’s financial liquidity and technical >>> architecture are linked. >> >> What has come of this? > [SNIP] > > Michael, > > You asked, "What has come of this?" > > What has come of it is a formal recognition that the financial and > technical health of a security provider are inseparable. As an IFA, I > don’t ignore a "Micro-Entity" balance sheet dominated by five-figure > Director's Loans while the product itself relies on documented > "workarounds" for system-level stability issues. > > I have taken the appropriate professional steps to ensure that the > financial side of this operation is reviewed by the relevant > authorities. If there is no wrongdoing, then there is no issue. But "the > truth will out," and users have a right to know if the company they > trust with their system's "Root" access is as stable as its marketing > suggests. > > You call this "irrational focus." I call it professional accountability. > While you focus on protecting the "man," I will continue to focus on > protecting the "system." > > Do you actually know what an IFA does in real life? > > Here's a clue:- > > An independent financial adviser or IFA can advise you on all financial > products that they think meet your needs. They are independent and > whole-of-market: > Independent means they aren't acting on behalf of any particular product, > provider or other body.Whole-of-market means they can consider various > financial products from > multiple lenders.They act on behalf of you, the client, which means *the > advice they give you must be impartial*. > > https://www.money.co.uk/guides/5-steps-to-finding-an-ifa-you-can-trust > > HTH. 😅 The post sounds confident, but it mostly substitutes implication and credentials for actual evidence. The author claims the “financial and technical health” of a security product are inseparable, then points to a micro-entity balance sheet and director’s loans as if that somehow proves a security risk. That’s a pretty big leap. Small independent software developers commonly have simple accounts and director loans—it’s normal and not evidence of instability or wrongdoing. Likewise, mentioning “workarounds” or “root access” without explaining a specific technical flaw doesn’t demonstrate a real security problem. The repeated emphasis on being an “IFA” doesn’t really help the argument either. Independent financial advisers typically advise clients on investments, pensions, and insurance; they don’t audit software architecture or evaluate macOS security tooling. Invoking regulators and explaining what an IFA does reads more like credential-waving and escalation than a substantive critique. If there’s a real technical issue, the productive path would be to show the actual vulnerability or flawed behavior rather than relying on insinuation about company finances. -- Personal attacks from those who troll show their own insecurity. They cannot use reason to show the message to be wrong so they try to feel somehow superior by attacking the messenger. They cling to their attacks and ignore the message time and time again.
[toc] | [prev] | [next] | [standalone]
| From | "David B." <David@hotmail.co.uk> |
|---|---|
| Date | 2026-03-14 14:25 +0000 |
| Message-ID | <n1l9e2F5esfU1@mid.individual.net> |
| In reply to | #143395 |
On 14/03/2026 09:26, Brock McNuggets posted an AI answer! > The post sounds confident, but it mostly substitutes implication and > credentials for actual evidence. The author claims the “financial and > technical health” of a security product are inseparable, then points to a > micro-entity balance sheet and director’s loans as if that somehow proves a > security risk. That’s a pretty big leap. Small independent software > developers commonly have simple accounts and director loans—it’s normal and > not evidence of instability or wrongdoing. Likewise, mentioning > “workarounds” or “root access” without explaining a specific technical flaw > doesn’t demonstrate a real security problem. > > The repeated emphasis on being an “IFA” doesn’t really help the argument > either. Independent financial advisers typically advise clients on > investments, pensions, and insurance; they don’t audit software > architecture or evaluate macOS security tooling. Invoking regulators and > explaining what an IFA does reads more like credential-waving and > escalation than a substantive critique. If there’s a real technical issue, > the productive path would be to show the actual vulnerability or flawed > behavior rather than relying on insinuation about company finances. = Michael, You dismiss my concerns as "insinuation" and "credential-waving," yet you continue to ignore the hard data. Let’s move past the labels and look at the "substantive critique" you claim is missing. 1. The "Root Access" Fact: CVE-2024-24245 You say I haven't explained a specific technical flaw. Here is the documentation: CVE-2024-24245. For nearly four years (Nov 2020 to April 2024), ClamXAV versions 3.1.2 through 3.6.1 contained a Local Privilege Escalation vulnerability in the Privileged Helper Tool. This wasn't a "theoretical" risk; it was a flaw that allowed low-level processes to gain System/Root privileges. If you think a 41-month window to patch a Root-level exploit is "normal," then we have vastly different definitions of security. 2. The Financial Logic You claim Director's Loans are just "normal trivia." As an IFA, I see a conflict of interest. While the developer was leaving that Root-level vulnerability unpatched for years, the company filings show tens of thousands of pounds being moved into Director's Loans. In any other industry, extracting capital while failing to fix a critical safety flaw in a "security" product would be a scandal. 3. The "Workaround" Reality I don’t need to be a kernel engineer to read the developer’s own notes: "Long-term workaround for Apple's kernel panic issue" (v3.5.1). You defend the "man," but the code tells the story of a Micro-Entity taking shortcuts because a full architectural rewrite to Apple's modern Endpoint Security Framework was likely too expensive. I’m an auditor, Michael. I look at the balance sheet and the CVE record. You look at a Facebook profile. The "truth will out," and currently, the truth is written in the National Vulnerability Database and the Companies House records. -- Kind regards, David
[toc] | [prev] | [next] | [standalone]
| From | Brock McNuggets <brock.mcnuggets@gmail.com> |
|---|---|
| Date | 2026-03-14 15:44 +0000 |
| Message-ID | <69b5827a$4$24$882e4bbb@reader.netnews.com> |
| In reply to | #143399 |
On Mar 14, 2026 at 7:25:06 AM MST, ""David B."" wrote
<n1l9e2F5esfU1@mid.individual.net>:
> On 14/03/2026 09:26, Brock McNuggets posted an AI answer!
>
>> The post sounds confident, but it mostly substitutes implication and
>> credentials for actual evidence. The author claims the “financial and
>> technical health” of a security product are inseparable, then points to a
>> micro-entity balance sheet and director’s loans as if that somehow proves a
>> security risk. That’s a pretty big leap. Small independent software
>> developers commonly have simple accounts and director loans—it’s normal and
>> not evidence of instability or wrongdoing. Likewise, mentioning
>> “workarounds” or “root access” without explaining a specific technical flaw
>> doesn’t demonstrate a real security problem.
>>
>> The repeated emphasis on being an “IFA” doesn’t really help the argument
>> either. Independent financial advisers typically advise clients on
>> investments, pensions, and insurance; they don’t audit software
>> architecture or evaluate macOS security tooling. Invoking regulators and
>> explaining what an IFA does reads more like credential-waving and
>> escalation than a substantive critique. If there’s a real technical issue,
>> the productive path would be to show the actual vulnerability or flawed
>> behavior rather than relying on insinuation about company finances.
>
> =
>
> Michael,
>
> You dismiss my concerns as "insinuation" and "credential-waving," yet
> you continue to ignore the hard data. Let’s move past the labels and
> look at the "substantive critique" you claim is missing.
>
> 1. The "Root Access" Fact: CVE-2024-24245
> You say I haven't explained a specific technical flaw. Here is the
> documentation: CVE-2024-24245.
> For nearly four years (Nov 2020 to April 2024), ClamXAV versions 3.1.2
> through 3.6.1 contained a Local Privilege Escalation vulnerability in
> the Privileged Helper Tool. This wasn't a "theoretical" risk; it was a
> flaw that allowed low-level processes to gain System/Root privileges. If
> you think a 41-month window to patch a Root-level exploit is "normal,"
> then we have vastly different definitions of security.
>
> 2. The Financial Logic
> You claim Director's Loans are just "normal trivia." As an IFA, I see a
> conflict of interest. While the developer was leaving that Root-level
> vulnerability unpatched for years, the company filings show tens of
> thousands of pounds being moved into Director's Loans. In any other
> industry, extracting capital while failing to fix a critical safety flaw
> in a "security" product would be a scandal.
>
> 3. The "Workaround" Reality
> I don’t need to be a kernel engineer to read the developer’s own notes:
> "Long-term workaround for Apple's kernel panic issue" (v3.5.1). You
> defend the "man," but the code tells the story of a Micro-Entity taking
> shortcuts because a full architectural rewrite to Apple's modern
> Endpoint Security Framework was likely too expensive.
>
> I’m an auditor, Michael. I look at the balance sheet and the CVE record.
> You look at a Facebook profile. The "truth will out," and currently, the
> truth is written in the National Vulnerability Database and the
> Companies House records.
This reply reads rhetorically strong but analytically weak. It mixes a real
technical point with speculation and a credibility attack. Breaking it down:
⸻
1. The CVE claim (partly factual, partly overstated)
He cites CVE-2024-24245 involving ClamXAV.
A few important points:
What he gets right
• The vulnerability existed.
• It involved the privileged helper tool, which runs with elevated
privileges.
• Local privilege escalation bugs are considered serious.
Where the argument becomes misleading
1. “41-month window” framing
CVE timelines usually reflect when the bug existed in released versions, not
when the developer knew about it.
In most cases:
• vulnerability exists silently
• researcher discovers it
• coordinated disclosure
• patch released
Unless he can show the developer knew about it for four years, the “41 months
to patch” claim is unsupported.
2. Local privilege escalation ≠ remote exploit
LPE vulnerabilities require an attacker to already have code execution on the
system.
That’s still a flaw, but it’s not equivalent to malware being able to remotely
root your Mac.
3. No proof the patch delay was abnormal
Many CVEs remain undiscovered for years across all software ecosystems.
So the CVE is a legitimate point, but his interpretation exaggerates what it
proves.
⸻
2. The financial argument is mostly irrelevant
He tries to link:
• Director loans in company filings
• an unpatched vulnerability
• developer negligence
This is a logical leap.
Director loans are common in small UK companies and simply mean:
• a director lends money to the company, or
• the company lends money to the director.
They do not indicate resources were diverted from development.
He also provides no evidence that:
• fixing the vulnerability required major funding
• the loan transactions affected security work
• the developer even knew about the flaw during that period
So the financial argument is essentially innuendo.
⸻
3. The “workaround” claim misunderstands macOS security APIs
He refers to:
“Long-term workaround for Apple’s kernel panic issue”
and claims this proves the developer avoided rewriting to the Endpoint
Security Framework.
Problems with this claim:
1. Kernel panic workarounds are normal in security software.
2. Many macOS security tools used kernel extensions historically before
Apple transitioned to Endpoint Security.
3. The presence of a workaround does not prove architectural shortcuts.
Without code analysis, this is speculation.
⸻
4. Tone and debate tactics
The post uses several classic Usenet debate tactics:
Credential inflation
• “I’m an auditor”
• “I’m an IFA”
These credentials are not relevant to vulnerability analysis.
False dichotomy
“I look at the balance sheet and CVE record. You look at Facebook.”
That reframes the debate rather than addressing the critique.
Moral framing
He tries to turn a technical issue into an ethical scandal narrative.
⸻
5. Likely intent
Based on the pattern:
• heavy rhetorical tone
• mixing technical facts with financial insinuation
• escalation language (“scandal”, “truth will out”)
This reads less like a technical discussion and more like reputation damage
framing.
Notably, he never shows:
• exploit code
• technical analysis
• reproduction steps
• severity scoring
All of which would normally appear in a serious security critique.
⸻
Short Usenet-style summary reply
If you wanted a concise response:
Citing CVE-2024-24245 is legitimate, but the conclusions drawn from it are
exaggerated. The CVE describes a local privilege escalation bug in ClamXAV’s
privileged helper tool. However, CVE timelines reflect how long a bug existed
in released versions, not how long the developer knew about it. Without
evidence the flaw was known for years, the “41-month delay” claim is
unsupported.
The financial argument is also a non-sequitur. Director loans in UK
micro-entities are routine accounting entries and don’t demonstrate that
security work was neglected. Linking them to a vulnerability without evidence
is speculation.
In short: one real CVE, followed by several unsupported conclusions.
⸻
If you want, I can also explain what the ClamXAV CVE actually allowed
technically, because the details are much less dramatic than the post implies.
--
It's impossible for someone who is at war with themselves to be at peace with you.
[toc] | [prev] | [next] | [standalone]
| From | "David B." <David@hotmail.co.uk> |
|---|---|
| Date | 2026-03-14 15:56 +0000 |
| Message-ID | <n1lepqF683eU1@mid.individual.net> |
| In reply to | #143422 |
On 14/03/2026 15:44, Brock McNuggets copied and pasted a response! Michael, It’s clear you’re now relying on an AI to provide a "concise summary" of why you shouldn't be concerned. However, your AI’s defense of "normalcy" fails when held up against professional auditing standards. 1. On the "41-Month Window" Your AI claims that unless the developer "knew" about the bug, the 41-month exposure is irrelevant. As an auditor, I disagree. In security, undiscovered vulnerabilities are a liability of competence. If a "Security" company allows a Root-level exploit (CVE-2024-24245) to sit in their "Privileged Helper Tool" for nearly four years without catching it themselves, that is a failure of their internal security audit process. Exposure time is the metric of risk, not the developer’s "awareness." 2. On Financial "Innuendo" You (or your AI) claim that Director's Loans are just "routine accounting." This is where my IFA background actually matters. In a UK Micro-Entity, capital is finite. When a company is diverting significant funds into Director's Loans (which are essentially interest-free personal capital), that money is not being spent on third-party security audits or hiring the high-level engineers needed to move from legacy "workarounds" to the Apple Endpoint Security Framework. In professional risk assessment, we look at Resource Allocation. If the money is going to the Director's pocket instead of fixing "long-term kernel panics" and finding Root exploits, that is a substantive critique of the business's priorities. 3. On "Reputation Damage" You call this reputation damage; I call it Consumer Transparency. A company that sells security on a subscription basis is making a promise of superior vigilance. The "Truth" revealed by the CVE and the Companies House filings is that the vigilance was absent for 41 months while the profits were being extracted as loans. Michael, you can have your AI generate all the "analytical" summaries it wants. It doesn't change the fact that while you were defending the "man," his software was providing a Root-level door for attackers and his balance sheet was showing a preference for personal loans over technical excellence. I’m happy to let the "silent observers" decide whose standards for Mac security — and corporate transparency — they prefer. -- Kind regards, David
[toc] | [prev] | [next] | [standalone]
| From | Brock McNuggets <brock.mcnuggets@gmail.com> |
|---|---|
| Date | 2026-03-14 18:07 +0000 |
| Message-ID | <69b5a3d8$0$27$882e4bbb@reader.netnews.com> |
| In reply to | #143448 |
On Mar 14, 2026 at 8:56:42 AM MST, ""David B."" wrote <n1lepqF683eU1@mid.individual.net>: > On 14/03/2026 15:44, Brock McNuggets copied and pasted a response! > > > Michael, > > It’s clear you’re now relying on an AI to provide a "concise summary" of > why you shouldn't be concerned. However, your AI’s defense of "normalcy" > fails when held up against professional auditing standards. > > 1. On the "41-Month Window" > Your AI claims that unless the developer "knew" about the bug, the > 41-month exposure is irrelevant. As an auditor, I disagree. In security, > undiscovered vulnerabilities are a liability of competence. If a > "Security" company allows a Root-level exploit (CVE-2024-24245) to sit > in their "Privileged Helper Tool" for nearly four years without catching > it themselves, that is a failure of their internal security audit > process. Exposure time is the metric of risk, not the developer’s > "awareness." Exposure time ≠ known vulnerability window. CVE timelines typically reflect how long a bug existed in released versions, not how long the developer knew about it. Many mature projects have vulnerabilities that existed for years before discovery. Examples include flaws found in software maintained by the Apache Software Foundation, Google, and Apple. Long-lived bugs unfortunately occur across the entire industry. The meaningful metric for judging a developer is response time once a vulnerability is discovered, not the historical lifespan of the bug. Treating the version window as proof that the developer "ignored" the issue for four years assumes facts not in evidence. To the contrary, you spreading this false claim is harmful to him. Do you wish to understand or cause harm? > > 2. On Financial "Innuendo" > You (or your AI) claim that Director's Loans are just "routine > accounting." This is where my IFA background actually matters. In a UK > Micro-Entity, capital is finite. As opposed to? Infinite capital? What are you even talking about here? LOL! > When a company is diverting significant > funds into Director's Loans (which are essentially interest-free > personal capital), that money is not being spent on third-party security > audits or hiring the high-level engineers needed to move from legacy > "workarounds" to the Apple Endpoint Security Framework. Do you even have evidence of which way the money was loaned? And the idea that without a loan they would have found a bug? None of your comments are holding up here. > > In professional risk assessment, we look at Resource Allocation. If the > money is going to the Director's pocket instead of fixing "long-term > kernel panics" and finding Root exploits, that is a substantive critique > of the business's priorities. How much resources did the put toward the bug fixes? Please be specific. How much is this compared to similar companies? You simply make innuendo with the intent to harm... but without the evidence to back it. > 3. On "Reputation Damage" > You call this reputation damage; I call it Consumer Transparency. It does not matter what you call your inappropriate harm -- it is wrong. > A > company that sells security on a subscription basis is making a promise > of superior vigilance. How do they compare to other similar companies here? > The "Truth" revealed by the CVE and the Companies > House filings is that the vigilance was absent for 41 months while the > profits were being extracted as loans. No, that is not supported by your evidence. > > Michael, you can have your AI generate all the "analytical" summaries it > wants. It doesn't change the fact that while you were defending the > "man," I am not. I am denouncing your vendetta against him. > his software was providing a Root-level door for attackers and > his balance sheet was showing a preference for personal loans over > technical excellence. Again: this is not true based on the evidence you have shown. You are not backing your derogatory claims. Facts matter. > > I’m happy to let the "silent observers" decide whose standards for Mac > security — and corporate transparency — they prefer. You are using AI and it is leading you astray. Please, David, try to understand you are not helping your case here. -- It's impossible for someone who is at war with themselves to be at peace with you.
[toc] | [prev] | [next] | [standalone]
| From | "David B." <David@hotmail.co.uk> |
|---|---|
| Date | 2026-03-16 10:53 +0000 |
| Message-ID | <n1q5ojFsokbU1@mid.individual.net> |
| In reply to | #143460 |
On 14/03/2026 18:07, Brock McNuggets wrote: [....] > You are using AI and it is leading you astray. Please, David, try to > understand you are not helping your case here. Michael, You keep reaching for "industry normalcy" to defend a specific, documented failure. Let’s address the "substantive evidence" that you claim is missing, using the global standards for security auditing. 1. The "41-Month Window" & CVSS 7.8 (High) You compare ClamXAV to Google and Apple. That is a false equivalence. When a security provider allows a High-Severity vulnerability (CVSS 7.8) to sit in its "Privileged Helper Tool" for 41 months (Nov 2020 to April 2024), it is not a "silent industry quirk." It is a failure of internal audit and technical competence. A 7.8 score means the risk to Confidentiality and Integrity is high. If you think a three-and-a-half-year window for a Root exploit is "normal," your standards are not industry-compliant. 2. A 12-Year Record of "Workarounds" This isn't a new "vendetta." I invite you to read the PCMag review of ClamXAV and look for my comments dating back to October 2013: https://uk.pcmag.com/antivirus/4669/clamxav-for-mac For over a decade, I’ve been calling out the same architectural shortcuts—like the "Sentry" disconnect—that have now culminated in this CVE. When a developer relies on "long-term workarounds" (v3.5.1) instead of migrating to Apple’s Endpoint Security Framework, they are accumulating technical debt that puts users at risk. 3. The Financial Reality (Companies House) As an IFA, I look at Resource Allocation. The public filings for Canimaan Software Ltd show a Micro-Entity where significant capital is moved into Director's Loans. In a business of this size, money taken as personal loans is money not spent on the high-level engineering required to find Root exploits or fix kernel panics. Michael, you are defending a "man." I am auditing a Subscription Security Provider. The numbers in the National Vulnerability Database and the Companies House ledgers don't care about friendship. They show a high-risk product with a history of deferred maintenance. I’ll leave the "silent observers" to decide which professional standard they trust. -- Kind regards, David
[toc] | [prev] | [next] | [standalone]
| From | Brock McNuggets <Brock.McNuggets@gmail.com> |
|---|---|
| Date | 2026-03-16 13:46 +0000 |
| Message-ID | <69b809c4$0$21$882e4bbb@reader.netnews.com> |
| In reply to | #143513 |
David B. <David@hotmail.co.uk> wrote: > On 14/03/2026 18:07, Brock McNuggets wrote: > [....] >> You are using AI and it is leading you astray. Please, David, try to >> understand you are not helping your case here. > > Michael, David. Give your own thoughts and not the hallucinations of AI. Please. -- Personal attacks from those who troll show their own insecurity. They cannot use reason to show the message to be wrong so they try to feel somehow superior by attacking the messenger. They cling to their attacks and ignore the message time and time again.
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.sys.mac.advocacy
csiph-web