[thekeyper]

Actually, Session-Lock does offer some protection against some MITM attacks in the form of a timeout that would be triggered with most MITM attacks, but its purpose (and that of Chrome's DBSC proposal) is to protect against cookie stealer malware, not MITM. This is malware that steals session tokens from the device's filesystem. Take a look here to understand the threat: https://blog.google/threat-analysis-group/phishing-campaign-...

The premise of Session-Lock and DBSC is that even if the token gets stolen, it would not be useful to the attacker because the server would reject it if it doesn't have the correct signature that's generated using a private key that should only exist on the legitimate device. This private key has to be difficult or borderline impossible for the attacker to exfiltrate, unlike the session token.

[_andrei_]

If the user has malware can't that steal the private key as well? Why is it hard to exfil if the attacker has full access?

[kevlened]

In an ideal world, the private key should be stored in an HSM, preventing exfiltration. However, even assuming an HSM, the current scheme doesn't protect against malicious actors pre-signing requests on the client and exfiltrating those requests.

This library adds more defense-in-depth, making it harder to attack sessions, but not impossible.