> Microsoft Process Explorer has the same functionality so they don't have standing to block competitors then go and include the exact same features in their own software.
> Microsoft has been secretly adding more powerful features than Process Hacker via their SAC product – SAC has no security whatsoever by design – they're clearly targeting the project not because of any actual technical issues but rather because we're more popular than their products, so they're using the same (illegal and anti-competitive) tactics they used against Netscape Navigator to eliminate competition but also labeling the project malicious in an attempt to mislead the competition regulators.
Yet another example of a trillion dollar tech company stifling competition and innovation with anti-competitive tactics.
Both Microsoft and Apple require developers to sign software in order for their apps to run on Windows or macOS. Developers must pay to buy and renew their certificates regularly and must remain in good standing with either company if they want their apps to run on either OS. At any time, and for any reason, Microsoft or Apple can revoke your certificates and prevent Windows or macOS from running your apps at all.
The control over what apps can run on Windows or macOS is all about securing profits for either company, first and foremost. Actual security is just an afterthought.
Both companies take it one step further and are locking developers out of kernel space. Apple stills signs a few third-party .kexts, like macFUSE, but everyone else is out of luck. Microsoft needs to sign kernel-mode drivers or situations like the one in the OP will occur.
This is certainly different than, but reminiscent of, the situation with AppGet and Microsoft's clone, Winget[1].
Console manufacturers have often lost their case whenever game studios took them to caught over this though. Hence EA and Codemasters not using standard Megadrive / Genesis carts. So there is at least some hope that there is precedence in favour of independent publishers.
Microsoft owns github, it could be said that they no longer depend / compete with the open source community, since they operate it from the shadows. It is reasonable to think that game development is too complex to be privatised (for now, at least)
For unsigned drivers users have to enable test mode and I can't imagine secure boot works unless the drivers are signed. In the case of unsigned applications it's correct that it's just a warning.
The highlighted comment has been marked as off-topic and requires logging in to view, which I'm disinclined to do from mobile. Is there a summary elsewhere?
DavidXanatos
on 16 Aug
Interesting driver,
is the process termination feature of PH the only thing MSFT has a problem with?
I mean if its the only thing they don't like, may be its worth moving that feature into a separate tool or a plugin with an own unsigned driver?
Also changing the name would be an option, if than all the problems can be avoided.
@dmex
dmex
on 16 Aug
Maintainer
the only thing MSFT has a problem with
MS refused to discuss anything and have ignored every email so who knows what their problem is.
if its the only thing they don't like
It's not the only thing.... There are recent changes to APIs that block and limit features when the caller isn't taskmgr.exe.
Either way this discussion is offtopic from the KPH updates.
> Microsoft has been secretly adding more powerful features than Process Hacker via their SAC product – SAC has no security whatsoever by design – they're clearly targeting the project not because of any actual technical issues but rather because we're more popular than their products, so they're using the same (illegal and anti-competitive) tactics they used against Netscape Navigator to eliminate competition but also labeling the project malicious in an attempt to mislead the competition regulators.
Yet another example of a trillion dollar tech company stifling competition and innovation with anti-competitive tactics.
Both Microsoft and Apple require developers to sign software in order for their apps to run on Windows or macOS. Developers must pay to buy and renew their certificates regularly and must remain in good standing with either company if they want their apps to run on either OS. At any time, and for any reason, Microsoft or Apple can revoke your certificates and prevent Windows or macOS from running your apps at all.
The control over what apps can run on Windows or macOS is all about securing profits for either company, first and foremost. Actual security is just an afterthought.
Both companies take it one step further and are locking developers out of kernel space. Apple stills signs a few third-party .kexts, like macFUSE, but everyone else is out of luck. Microsoft needs to sign kernel-mode drivers or situations like the one in the OP will occur.
This is certainly different than, but reminiscent of, the situation with AppGet and Microsoft's clone, Winget[1].
[1] https://keivan.io/the-day-appget-died/