| ▲ | Groxx an hour ago |
| >We take a trace produced by a frontier model, replay it into a weaker sibling, jailbreak the weaker model, ... Ha! I've been wondering if replaying across models would work, ever since https://blog.cryptographyengineering.com/2026/05/29/fooling-... I'm honestly rather curious if this was intentionally allowed, it's the sort of validation that's easy to miss (particularly if you're wading into the vibe waters). Seems like something that'd be absolutely riddled with possibilities for shenanigans. |
|
| ▲ | sandeepkd 3 minutes ago | parent | next [-] |
| I believe its a result of chasing the speed and happy path. The intent was to make the data available for reuse on the backend side for the same user session, it kind of makes sense. Making it available across the models is most likely by design. The flaw is that the data is not strictly tied to user session, making the session data hijacking a lot easier. 1. Its a security issue. 2. Publicly available sessions make it much worse |
|
| ▲ | yojo an hour ago | parent | prev [-] |
| If you didn’t allow it, you wouldn’t be able to change models in the same conversation, as key parts of the context would be lost. Wouldn’t surprise me if the providers just remove that ability and lock the model once the conversation starts. |
| |
| ▲ | myworkaccount2 22 minutes ago | parent | next [-] | | There seems to be an obvious choice to make here, should you give the users to decrypt and use the COT that they did not generate themselves? This is only required if you want users to be able to share things with everyone and you are going for the simplest implementation. If not you could try to keep a record of keys associated with a user, then when a new request comes in look through to see if the user has a valid key to decrypt the COT. For explicit shares, just add the key used in that one conversation to the users valid keys. For global shares use the global keys. But that's adding more complexity to the system. | |
| ▲ | aix1 8 minutes ago | parent | prev | next [-] | | I really don't understand why server-side storage of the trace isn't a viable approach here, with only a unique key flowing to the client and back. Does it have something to do with how backend load-balancing works? | |
| ▲ | Groxx 35 minutes ago | parent | prev | next [-] | | Fair (I haven't been using the encrypted-reasoning systems, though this is common in open ones - I'm kinda surprised it's an option in encrypted ones too), though what they're doing here is cross-user replays in addition to cross-model. | |
| ▲ | Der_Einzige 31 minutes ago | parent | prev [-] | | 100% guaranteed that this research just forced this to happen now. Sucks. |
|
