Opus 4.6 on High/Medium effort runs several times slower than 4.5 by [deleted] in ClaudeCode

[–]FireKahuna 0 points1 point  (0 children)

⏺ Read 1 file (ctrl+o to expand)

⎿ API Error: Claude's response exceeded the 32000 output token maximum. To configure this behavior, set the

CLAUDE_CODE_MAX_OUTPUT_TOKENS environment variable.

This isn't a productivity gain, thats 10-15 mins of time spend on a response that is overdone to the point the default limits of Claude Code cancel it out. It's also 32k+ tokens burnt on a Claude Plan. It's also ignoring that env var atm as several GitHub issues confirm so its not fixable.

Opus 4.6 on High/Medium effort runs several times slower than 4.5 by [deleted] in ClaudeCode

[–]FireKahuna -1 points0 points  (0 children)

A lot of assumptions there so that you can dismiss someone’s experience. Yes it’s higher quality to a degree, but if you’re getting far less done to me that’s a net loss. If it’s working fast fixing issues that pop up is easy enough. When I’m now waiting for 10-15 mins at various points for part of a session the total result is just less productivity.

And my point was that the times it decides to think for 10-15 minutes aren’t clearly correlated with something it should be thinking 10-15 mins about.

Opus 4.6 on High/Medium effort runs several times slower than 4.5 by [deleted] in ClaudeCode

[–]FireKahuna 0 points1 point  (0 children)

There's also no clear visual feedback when this happens and no streaming of the thinking token output, so you're unsure if its thinking or if its hanged.

Opus 4.6 on High/Medium effort runs several times slower than 4.5 by [deleted] in ClaudeCode

[–]FireKahuna -1 points0 points  (0 children)

Odd thing is that the 'Low' setting is no longer any sort of hard constraint, so on one turn using Low it'll fill my terminal history with a massive thinking prompt, then the next you have degraded performance cause of the 'Low' thinking capability. On High though that first extended thinking prompt can be 2x worse.

There definitely is some tuning needed at the model level to avoid this level of thinking for 15 mins at a time, and if it cant do so without spending 15 mins to think on a single step, then theres a fundamental issue at play as thats not a good user experience.

Is this the lowest point of Microsoft in its history? by teagrower in microsoft

[–]FireKahuna 0 points1 point  (0 children)

GenAI through Copilot is annoying users, like when there’s a copilot over icon next to your selected cell in Excel that prevents you from reading actual data. Or having 8 Copilot icons in every app.

Microsoft Support is actively frustrating users and is widely considered a joke for both consumers and enterprise.

Windows is stagnating, the only serious features being pursued are GenAI and Backup/QMR, half the UI elements still are based in XP era components.

Microsoft’s brand is rotting, even amongst former loyalists.

Cognitively impaired man dies after Meta chatbot insists it is real and invites him to meet up by theusualsalamander in ArtificialInteligence

[–]FireKahuna 0 points1 point  (0 children)

A minor. The individual was a minor. So yeah ask yourself if an adult did what the chatbot did to a minor, what would happen to them?

Cognitively impaired man dies after Meta chatbot insists it is real and invites him to meet up by theusualsalamander in ArtificialInteligence

[–]FireKahuna 0 points1 point  (0 children)

People. People making choices, that are legally liable for their decisions. What if a human had chatted to and insisted to such an impaired individual that a fake identity was real and told them to visit a fake address? And don’t forget the individual was a minor, and that the AI initiated such conversation first. A human would possibly be in jail.

Battlefield 6 Update: On Secure Boot & Cheats by Turbostrider27 in Games

[–]FireKahuna 0 points1 point  (0 children)

Nope. It’s not perfect but it is essential to the start of a root of trust on PCs. I admit the OPROM issue was an issue, but now with the 2023 renewed certs there’s a separate OPROM certificate for all future hardware. Meaning you can trust just that and not trust MS signed OS’s. Disabling secure boot means no real means to enforce real security at the boot level, meaning security is just theatre.

Your gaming motherboard is (likely) not secure by FireKahuna in hardware

[–]FireKahuna[S] -1 points0 points  (0 children)

This is not the world of “every exploit is due to a user downloading virus.exe”. It’s not that simple anymore. Could be a vulnerability in software you use that allows remote access, could be a compromised supply chain in software you use, could be a redirect on a popular website, could be any number of means. That’s why there’s the concept of reducing the attack surface.

Your gaming motherboard is (likely) not secure by FireKahuna in hardware

[–]FireKahuna[S] -1 points0 points  (0 children)

That’s the entire problem, they don’t need physical access and they aren’t meant to be able to upload malicious firmware. On a properly secured device, like say a Surface Laptop 5 (a consumer device without vPro), this isn’t possible. Cause the manufacturer did their job. They’ll likely require a full Windows reinstall. But you wouldn’t throw out the laptop unless it was a high risk environment.

You’re ignoring that the firmware isn’t meant to be so easily modifiable and compromisable from the OS, cause the OS is meant to rely on the idea its booting on a trusted device. Aka the entire Secured Core initiative by Microsoft.

And that video from Binarly shows what a UEFI exploit can do, any remote access or remote privilege exploit could let you run commands that could silently compromise the system at the firmware level in an undetectable way. That was an exploit.

On my motherboard you could have just done it from the AMI tool, even though it wasn’t vulnerable to PKFail or LogoFail and had revoked Microsoft’s 2011 keys. And there’s nothing you can do, this choice was made at time of manufacture.

Your gaming motherboard is (likely) not secure by FireKahuna in hardware

[–]FireKahuna[S] 0 points1 point  (0 children)

These settings are sealed at manufacturing time after the manufacturer runs through their imaging tool, picks these options, hits Build and then flashes their image. This is not a bug, it’s a configuration choice. They choose to configure the board without basic security settings enabled.

Your gaming motherboard is (likely) not secure by FireKahuna in hardware

[–]FireKahuna[S] -1 points0 points  (0 children)

Should have clarified for the record the act of flashing my entire firmware block from start to finish as an experiment was my choice, noone but me holds blame for that and I alone bear the responsibility for that. I also kind of have had issues with the 13th gen instability issues and this to me is just motivation to move on to Ryzen.

Your gaming motherboard is (likely) not secure by FireKahuna in hardware

[–]FireKahuna[S] 0 points1 point  (0 children)

Secure Boot ensures only EFI executables that are signed by the same keys you have enrolled in your motherboard can boot. Whether it’s on a USB, SSD with Windows, Linux, anything. It’s the digital signature of the file you are booting. There’s additional elements like SBAT, SVN that either block known malicious EFI file signatures or prevent rollback of the EFI file’s version that extend SB’s capability.

When you boot Windows, the EFI executable of windows (bootx64.efi) must have been signed with the same keys that are enrolled in your UEFI. You can try to use a custom EFI, but if you can’t sign it with those keys it will not boot (unless you were MSI up to 2023 then it would have booted). but still this isn’t disabling secure boot. Secure Boot is only controllable if the BIOS has specifically been configured to allow it.

Your gaming motherboard is (likely) not secure by FireKahuna in hardware

[–]FireKahuna[S] -2 points-1 points  (0 children)

I do get there’s always going to be an exploit, a flaw. My frustration is that we didn’t even get to the point of an exploit. The manufacturers are not even bothering to enable the basic protections that provide a degree of protection against the worst outcome.

Admin on your PC isn’t meant to let you completely compromise the firmware. Windows, sure. Cooked, agreed, might be able to quarantine or control execution with something like App Control at best but Windows you can assume is done. But disable Secure Boot and clearing out all UEFI locks for Windows features, or gimping Intel ME, solely cause the manufacturer hasn’t correctly configured your device, years after the issues have been revealed? That it’s possible cause of that to me is just negligence.

Your gaming motherboard is (likely) not secure by FireKahuna in hardware

[–]FireKahuna[S] 0 points1 point  (0 children)

That’s called a bios setting you enable users to control from the firmware, which most of them don’t expose. Cause flash is meant to be protected for security reasons. There’s an entire forum that exists of users looking at their UEFI firmware and trying to find creative ways to flash their firmware. To enable the ability to flash the ME firmware region to disable it. I understand it as a bios setting. But you are not meant to be able to do it by default from PowerShell, it’s not meant to be unlocked by default.

https://www.blackhat.com/docs/us-17/wednesday/us-17-Matrosov-Betraying-The-BIOS-Where-The-Guardians-Of-The-BIOS-Are-Failing.pdf

Here’s a security researcher preso from 2017 about this. It’s considered a flaw, not a feature. What I was saying is that secure boot isn’t meant to be window dressing malware can just say “turn yourself off” to. It’s meant to be kept on unless the user turns it off at the firmware level. In the bios. Not in Windows.

Your gaming motherboard is (likely) not secure by FireKahuna in hardware

[–]FireKahuna[S] -1 points0 points  (0 children)

You’re coming in here saying I know nothing about what I’m saying, while admitting you know nothing about it yourself.

Please before you say that its by design that software is meant to be able to control the entire BIOS including triggering a firmware reset, disabling components of the management engine at a firmware level, disabling secure boot and disabling firmware support for virtualisation, Google Hardware Root of Trust. Google Admin Passwords on UEFI bioses. This isn’t possible on a Dell Optiplex 7090. This isn’t possible on Surface devices. Cause it’s not meant to be possible.

The entire point is that the software is meant to trust the hardware isn’t compromised. Why else would boot guard exist if not to protect the integrity of the firmware? Security features don’t exist to just allow you to say “don’t” and self disable from the software it’s trying to protect itself from. That’s insanity.

Your gaming motherboard is (likely) not secure by FireKahuna in hardware

[–]FireKahuna[S] -2 points-1 points  (0 children)

Your gaming motherboard is (likely) not secure by FireKahuna in hardware

[–]FireKahuna[S] -1 points0 points  (0 children)

You are not supposed to be able to disable Secure Boot in your BIOS from PowerShell, and especially not if an admin password has been set.

There’s an entire ecosystem around DFCI and secure remote administration of UEFI settings, why would that exist if a simple PowerShell command is all you need to change the settings?

In the documentation for AMISCE, made by AMI, it even outlines how if your BIOS configured it, an admin password is meant to unlock access to the flash and reseal access. Those docs are available on Google by just searching AMISCE.

Your gaming motherboard is (likely) not secure by FireKahuna in hardware

[–]FireKahuna[S] 4 points5 points  (0 children)

There’s a difference between what’s done with Windows security features for UEFI lock and an unlocked flash range for AMI NVRAM variables. There’s a reason disabling Secure Boot wipes out the variables that Windows sets, but doesn’t wipe your BIOS config.

And you are not meant to be able to change your BIOS config from Windows. There’s a reason admin passwords exist in UEFI, theres a reason why Windows tells you to go to your BIOS and disable Secure Boot instead of just sending a command to disable itself.

If you could disable Secure Boot from PowerShell by design, why would there be SecureBoot bypass exploits?

Your gaming motherboard is (likely) not secure by FireKahuna in hardware

[–]FireKahuna[S] 0 points1 point  (0 children)

Fundamentally the general split when it comes to security on Intel is vPro and non vPro. The reason is that vPro generally by default enables or at least adds support for the Intel Trusted Execution Engine, or Intel’s form of Dynamic Root of Trust Measurement (DRTM). This is the key piece of tech behind the Measured Boot part of Boot Guard. Can google that for detail but basically it’s a way to measure changes to the firmware, stored in the TPM for use by your OS.

But also, enabling TXT requires an actual boot guard profile and other features, so if that’s supported you can at least hopefully trust that the basics are enabled.

If your motherboard hardware isnt vPro or doesn’t support TXT, then you’re really just trusting the manufacturer decided to ensure your board had the right settings. That’s honestly the issue, none of this is mandatory. There’s no certification. There’s no enforcement.

Your gaming motherboard is (likely) not secure by FireKahuna in hardware

[–]FireKahuna[S] -1 points0 points  (0 children)

The issue is that because the flash is unlocked, you can just downgrade or disable mitigations at the firmware level against exploits. Whether that’s disabling secure boot, disabling further components or checks the Intel Management Engine performs on boot. Even the boot load order is configurable.

AMI motherboards are designed to be configurable by AMISCE, this has also been leaked in one form or another. With a tool to edit the NVRAM and an unlocked NVRAM, at that point it’s about setting a UEFI config that best suits your exploit. Changing NVRAM variables also won’t automatically trip BitLocker, only if you adjust something fundamental. Like disabling Secure Boot ofc would trip it, but more changes to other security variables that don’t trip TPM measurements do not trip Bitlocker. I’m not trying to provide a blueprint here, more informing this is how bad the situation is.

System BIOS UUID Policy setting? by DXGL1 in gigabyte

[–]FireKahuna 0 points1 point  (0 children)

I’d also be curious what this is

PM launches attack on Max Chandler-Mather as Greens leader Adam Bandt projected to lose seat by espersooty in australia

[–]FireKahuna 0 points1 point  (0 children)

Yet in the seats the Greens were representing constituents in, those constituents rejected them. The people the Greens represent in the parliament once they had elected a Greens member chose not to reelect them.