justinsteven

> They say user data remains in the Secure Enclave at all times

No they don't. They say that the Secure Enclave participates in the secure boot chain, and in generating non-exportable keys used for secured transport. It reads to me as though user devices will encrypt requests to the keys held in the Secure Enclave of a subset of PCC nodes. A PCC node that receives the encrypted request will use the Secure Enclave to decrypt the payload. At that point, the general-purpose Application Processor in the PCC node has a cleartext copy of the user request for doing the needful inference, which _could_ be done on an NVidia GPU, but appears to be done on general-purpose Apple Silicon.

There is no suggestion that the user request is processed entirely within the Secure Enclave. The Secure Enclave is a cryptographic coprocessor. It almost certainly doesn't have the grunt to do inference.

No, `hmac(key=key, message=input) == hmac(key=key, message=secret)` where key is either a static secret key for comparison purposes, or random for each comparison.

I tested with SameSite being Lax and Strict. Neither block the attack in Chrome. My reading of the SameSite spec indicates that it doesn't take cookie path into account.

It would not. It would stop the cookie from being sent to things outside of the path specified, but the Same Origin Policy is about, among other things, gaining read-access to the responses of fetch/XMLHttpRequest/AJAX requests.

If there is a cookie set for the path '/secret' and I can host content at '/attacker', then some of my JavaScript under /attacker could do a fetch request to /secret/something. This fetch request would carry the cookie for /secret, and the response would be readable by my JavaScript (due to Same Origin Policy). I could read the response, extract sensitive content, or even extract CSRF tokens to allow me to do state-changing CSRF-protected things under /secret