Live data from Hacker News

Microsoft no longer signs Windows drivers for Process Hacker

borncity.com

391–400 of 543 posts

Re: Microsoft no longer signs Windows drivers for Process Hacker

#391

Earlier quoted context omitted.

You are supposed to store the recovery key(s) in a secure location. Then if you lose your 2FA device, you can reset your 2FA from those recovery keys.

What secure location? My sock drawer? Or am I expected to go buy a safety deposit box? I'm really not that organized and I loose slips of paper all the time, it's a major reason I was drawn to computers growing up.

I keep mine in a file in a drawer. My threat model doesn't cover people breaking in and finding them as well as knowing my password managers master password.

Re: Microsoft no longer signs Windows drivers for Process Hacker

#392

Earlier quoted context omitted.

weren't MS slapped around during the DOJ case for undocumented APIs? and there's a mile of difference between undocumented and "can't be called by non-MS products at all"

It was disallowed for other Microsoft products to call undocumented APIs. Anything called by Office/Azure/whatever needs to be a publicly documented API, and there are automatic checks in all Microsoft codebases to confirm that no undocumented APIs are called. Windows components, of course, aren't subject to any such rules. There have always been and always will be interfaces necessary for Windows to call itself that…

I was on a Microsoft page a few days ago reading about some of the Microsoft Store APIs and they were all marked with big warnings that claimed they could only be accessed by apps with special entitlements (so, basically signed versions of winget). Seemed really icky to me.

Re: Microsoft no longer signs Windows drivers for Process Hacker

#393

Earlier quoted context omitted.

I think to do your taxes online in Japan you need an NFC card reader and software b that only works in Windows.

In Brazil, we have a Java application that works on any system with a JVM. It's pretty nice. Why exclude citizens based on their choice of operating systems?

Note also that this was not always the case. Originally, it was a DOS-only application, then a Windows-only application, then for a while we had both the Windows-only application and the Java application, and then finally the Windows-only application was retired.

I believe that the creation of the Java version of that application was due to complaints from Linux users, so this is AFAIK a case where citizens used to be excluded based on their choice of operating systems, and convinced the government to allow more choice.

Another example is online banking in Brazil; for a while, most banks required the use of an horribly invasive "security plugin" for the browser which ran only on Windows. Nowadays, there's also a Linux version of that invasive software, so users of Linux are no longer excluded from online banking on their computers (it's not perfect because it still requires that invasive software, but it's better than before).

Re: Microsoft no longer signs Windows drivers for Process Hacker

#394
post #363

Earlier quoted context omitted.

> So, basically, for some reason, Microsoft wants to make it very hard for you to see whats running on your computer... So they can run spyware. Nearly every user hostile policy or behavior can be explained by the insatiable lust for data.

They wanted feature parity with MacOS' ability to hide processes from the user.

So basically running rootkits. So MS from spyware company has evolved to malware. Keep up the good work.

Re: Microsoft no longer signs Windows drivers for Process Hacker

#395

Earlier quoted context omitted.

> What is it with MS these past few months? I was thinking the same. It's not been a good few weeks for them. They're quickly losing trust which was hard to acquire in the first place given their history. Maybe a timely reminder to mention Halloween [1] ? [1] https://en.wikipedia.org/wiki/Halloween_documents

They've always been acting as a strong monopolistic corporation with a "fuck you" attitude. Here's a summary of Microsoft attitude these part 5 years: - rebrand as open-source friendly, only open-source whatever narrow side-projects they barely care about but could be run on other systems (VSCode, Powershell); distribute official packages with spyware - monopolize the education system by offering bribes including gra…

LOL @ "narrow side-projects" such as VSCode and Powershell ?

Re: Microsoft no longer signs Windows drivers for Process Hacker

#396
post #327

Earlier quoted context omitted.

I don't know the cause, this is based on the numbers they reported to defend their decision to exclude older chips. I think it has something to do with the modern instruction sets being kinder to the kernel and the fact that on computers with recent processors certain processor features are enabled in the UEFI config by default more often, but I couldn't tell you which features that would be. My hunch is that I has t…

This is a grade A bullshit, with a strong smell of marketing spin to it. If a program crashes on an older CPU, it damn sure will crash on a modern CPU just as well.

> If a program crashes on an older CPU, it damn sure will crash on a modern CPU just as well.

Not necessarily; if the crash is caused by an instruction that's absent on older CPUs (for instance, trying to use an AVX2 instruction when the most the CPU has is SSE2), it will work on a modern CPU but crash on an older CPU.

Re: Microsoft no longer signs Windows drivers for Process Hacker

#397
post #55
post #37

Earlier quoted context omitted.

Very informative. And presumably on OSX none of this applies because it's all BSD underneath? Or is OSX different again to just running BSD out of the box?

On macOS, you have those options: - SIP off (totally, or just driver signature enforcement) - kernel driver (deprecated, Apple doesn’t issue new certs anymore it seems) - system extension (user-mode driver, explicitly intended for device compatibility)

So whilst three is different aren’t the analogues on Windows for 1) and 2)

1) Test signing - do what you want

2) Kernel driver - still possible, needs EV cert?

Re: Microsoft no longer signs Windows drivers for Process Hacker

#398

Microsoft is locking certain API's: Always-on-top, Auto-elevation, DPS statistics, Default taskmgr application preferences (Microsoft hardcoded taskmgr.exe blocking competitors), GPU statistics (deliberately broken on Win10 and Win11 recently) and the DirectUI framework are some examples of features that I want to implement and are currently implemented by Task Manager but are Microsoft-only signature restricted whil…

I'm not familiar with the rest but how is Always-on-top locked away? Its such a basic thing and a lot of programs are using it.

SetWindowPos with HWND_TOPMOST fails with Access Denied.

CreateWindowInBand also fails with Access Denied.

Re: Microsoft no longer signs Windows drivers for Process Hacker

#399
post #397
post #55

Earlier quoted context omitted.

On macOS, you have those options: - SIP off (totally, or just driver signature enforcement) - kernel driver (deprecated, Apple doesn’t issue new certs anymore it seems) - system extension (user-mode driver, explicitly intended for device compatibility)

So whilst three is different aren’t the analogues on Windows for 1) and 2) 1) Test signing - do what you want 2) Kernel driver - still possible, needs EV cert?

1) on Windows entails a significant security downgrade, as you cannot just pick custom kernel extension only, with validation by the user. That might however not be important, depending on your threat model.

For 2), it’s borderline impossible to get a driver signing cert for macOS nowadays for individuals, it’s easier on Windows.

Re: Microsoft no longer signs Windows drivers for Process Hacker

#400
post #370
post #362

Earlier quoted context omitted.

What if you repeatedly fail to anonymize the information and also collect user-entered data like command line arguments? https://github.com/dotnet/sdk/issues/6145

Well, you make my point. What you linked to is definitely not telemetry.

I disagree - they are correct because once collected, the data is fed into a blackbox, and a user has no way of knowing if the data collected is - by your definition - spyware or telemetry. The beat way to treat this Schrodinger's telemetry, is to assume it's spyware.
Post reply on HN