bangaladore

Imo Cursor did had the first mover advantage by making the first well known AI coding agent IDE. But I can't help but think they have no realistic path forward.

As someone who is a huge IDE fan, I vastly prefer the experience from Codex CLI compared to having that built into my IDE, which I customize for my general purposes. The fact it's a fork of VSCode (or whatever) will make me never use it. I wonder if they bet wrong.

But that's just usability and preference. When the SOTA model makers give out tokens for substantially less than public API cost, how in the world is Cursor going to stay competitive? The moat just isn't there (in fact I would argue its non-existent)

Interesting. I agree with the other commenter about the post should've included how an account takeover was possible.

You mention one method being a cookie sent to an attacker-controlled domain, but that in itself is a vulnerability given it being incorrectly scoped (missing HTTPOnly & SameSite atleast).

> the auth token is stored in local storage

Has anyone reported this (rhetorical question)? What in the world could be the justification for this?

In my opinion, any full account takeovers due to XSS is a vulnerability, even ignoring XSS. Changing email/password/phone should require verification back to one of those methods. Or at least input of the previous password.

Yeah, this one must be socially engineered-- but a (fake) login page when accessing a docs site would fool most people.

Thankfully the browser prevents sending the cookies cross origin or else this is just a single click exploit.

Edit: I gave too much credit to Discord here. They aren't protecting their tokens correctly.

Do any of the supported backends work in practice though?

My understanding is pretty much all of them are extremely immature and not a drop in replacement.

Transpiling to C means you get all architectures gcc supports.

Building a backend for LLVM to a single architecture, well, only provides access to that architecture.

A SAFETY comment is supposed to justify why the unsafe code is sound. Here it justified the wrong thing. Ownership was not the problem, concurrent mutation was. That is exactly the kind of gap a SAFETY comment can hide by giving a false sense that the hard parts were already considered.

The fact that this survived review is the worrying part. Unsafe blocks are intentionally small and localized in Rust precisely so the safety argument can be checked. If the stated safety argument is incomplete and still passes review, that suggests reviewers are relying on the comment as the proof, rather than rederiving the invariants themselves. Unless of course the wrong people are reviewing these changes. Why rewrite in Rust if we don't apply extreme scrutiny to the tiny subset (presumably) that should be scrutinized.

To be clear, I think this is a failure of process, not Rust of course.

I think part of the problem is people start thinking that unsafe code with a SAFETY comment nearby is probably safe.

Then the safety comment can easily bias the reader into believing that the author has fully understood the problem and all edge cases.

Correct me if I'm wrong, but this comment is atleast partially incorrect right?

> Since it was in an unsafe block, the error for sure was way easier to find within the codebase than in C. Everything that's not unsafe can be ruled out as a reason for race conditions and the usual memory handling mistakes - that's already a huge win.

The benefit of Rust is you can isolate the possible code that causes an XYZ to an unsafe block*. But that doesn't necessarily mean the error shown is directly related to the unsafe block. Like C++, triggering undefined behavior can in theory cause the program to do anything, including fail spectacularly within seemingly unrelated safe code.

* Excluding cases where safe things are actually possibly unsafe (like some incorrectly marked FFI)

Given I need to read the instructions to understand how to use this, It's a no go for me. I clicked it and I thought there was a bug because I could only place on the element I clicked.

Yes, both in the case of them and I.

For an online business in a dubious (but legal) domain, my co-owner spent a few hundred bucks registering a business in New Mexico with a registered agent to get an EV cert.

So, a barrier to entry, but not much of one.

If you think there are competitors, you are clearly mistaken of what exactly O365 is.

Nobody offers what Microsoft bundles here. From editors, to storage, to communication to identity to management.

And I say this as someone who hates dealing with Microsoft and their products.

That makes absolutely zero sense, and you know it. I understand you are here to essentially shill bitcoin given you have a company that exists because of it but at least argue in good faith.

I believe there was an implication of the commenter I responded to that the risk of a savings account is somewhat similar to the risk of crypto. So, I asked said commenter to quantify or describe the risk. A comment simply with the text "A normal savings account does not have zero risk." is useless to a productive conversation.

I think most people would accept inflation as less of a risk then 20+% swings of the crypto market on a fairly common basis.

Gold has a use case in the real world. We can't manufacture it, so every time it is used to plate a printed circuit board, or XYZ other real application someone needs to purchase it from someone else. Some amount gets recycled, but certainly some not.

Crypto has zero fundamental use case in the real world.

What risk are you taking on with a normal savings account?

If you are saying the global collapse of the financial system, crypto will be the first to fall in that case. Crypto like BTC is pretty much a more volatile market tracker.

> There are DDR4 interposers you can buy for 50$.

Indeed, you can buy a piece of fiberglass shaped correctly for 50$. That's not the hard part. Just the probe you are supposed to connect to such a PCB is > 1k USD per pin you need to sample. The oscilloscope / logic analyzer to sample it is likely 6-7 figures.

> Or you can use an FPGA to interpose the RAM and intercept the network traffic for a couple hundred bucks.

What FPGA solution do you have for a couple hundred bucks could interpose DDR4 RAM at any frequency? This number seems completely made up to me.

Latency and size. Otherwise pretty much useless.

Bedrock is a lot more than just a standard endpoint. Also, the security guarantees.

Yeah- given all top AI models are more and more generalists, as time goes on there is less and less reason to use one over another.

> I have been loading and using the WinIO driver on windows all the way up to the latest version to read and write any memory I want. I also have a few drivers that are lesser known that are not even flagged by most anti-cheats

I can assure you that you will get banned from a game with a modern anti-cheat using that or you won't even be able to launch the game. Also 'flagged by most anti-cheats' means very little. Most good anti-cheats will delay bans or correlate multiple factors prior to a ban.

> You are going to have to decrypt the memory eventually. Even TEE.fail can get around AMD SEV and Intel's TEE.

You don't have to decrypt it on the RAM wire bus. And the reasons TEE.fail is successful is because they screwed up the crypto as far as I can tell.

> Once you can intercept network traffic and decrypt its game over!

Not sure why you are so hung up on this. You still need to access the memory first. That's what they will detect and prevent. They obviously can't prevent or detect network sniffing if the key is known.

> You do not need an ASIC to interpose DDR5 and steal all the traffic, there are FPGAs that are powerful enough. Once PCIE DMA cards go the way of the dino with IOMMU people will just switch to memory interposers with FPGAs

I've made FPGA designs previously, including custom PCIE DMA cards back in ~2018. It would surprise me if you could find an FPGA capable of reliably sniffing DDDR5 6000+ MT/S without crashing the host system. FPGAs are not nearly as fast as CPUs. Maybe you could somehow hack a FPGA DDR memory interface. But finding one fast enough for DDR5 is probably impossible (or terribly expensive). Maybe https://www.amd.com/en/products/adaptive-socs-and-fpgas/vers... is theoretically possible. But you are looking at a 10k+ chip, if not 20k$+. Such a chip is not going to be easily embeddable and likely requires 10s if not 100s of amps of power delivery.

> Assuming that your operating system doesn't allow any bad drivers (Windows does NOT do this)

Windows eventually tends to revoke the certificate of vulnerable drivers. And prior to that, anti-cheats will flag the signature and prevent booting or outright ban for egregious ones.

> Something like TEE.fail can be used to read encryption keys for network traffic

So, encrypt the memory well then? Also, that attack slows down RAM to 3200 MT/S and is infeasible for game cheating. Maybe if you could make a custom ram stick with an ASIC on it, which would cost millions on millions of dollars to keep up with DDR5, you could capture encrypted bits and crash your system pretty often.

I don't consider it an arms race if you can prevent cheating to 10s of people in a million-player game. That's noise at best.

Obvious when rereading. Sorry :)

> Doing everything server side does prevent cheating.

No. Server side only protects against some types of cheats, such as telling the server that your bullet in an FPS is actually a grenade.

It cannot prevent snapping your aim to a target on screen.

> Kernel anticheat is not really effective because it can be circumvented on the hardware level, for example using direct memory access with a second computer and screen to show the hidden game state.

Incorrect. DMA (direct memory access) is and can be prevented [1] and detected [2].

[1] https://www.faceit.com/en/news/faceit-rollout-of-tpm-secure-...

[2] https://community.osr.com/t/detecting-pcie-dma-based-cheatin...

Imo, WSL2 is almost indistinguishable from a true Ubuntu VM. If you haven't tried it since WSL1, I'd give it a shot.

Of course this comes down to whether you care or not about the integrations with Windows.

I love that the JS loads so slow on first load that it just says "The magic number: 0 /tflops"

I haven't look into it much, but, Source 2 supports all major desktop platforms and even all mobile platforms. Dotnet supports all those platforms as well.

So I'm not certain why S&box is Windows only, but my guess is that's just temporary.

> Does this mean you need Source 2 to develop with S&box?

Maybe I'm wrong, but S&box is essentially a game developed with Source 2, thats purpose is to expose internal APIs and wrap them for users to build their own games with. So you develop your thing in S&box that happens to be made with Source 2, but you don't care about that. Basically Roblox.