[jpgoldberg]

The browser would have to hold on to the shared key long term. Where does it put this?

Encrypting with a key that is available to attackers (who have the same set a privileges needed to run localhost sniffing) is not encryption. It is obfuscation.

[ikeboy]

I thought the point of the arxiv paper was that a non privileged app could effectively "sniff" by pretending to be the other app.

If I'm understanding correctly, that means that encrypting with a shared key helps. Am I missing something?

[roustem]

1Password verifies the code signature of the apps connecting to the WebSockets server using SecCodeCheckValidity.

That would prevent connection from the apps that do not have their code signature whitelisted.

[ikeboy]

From the paper:

>WebSocket. WebSocket servers are typically built over a few popular opensource frameworks, such as CocoaHTTPServer [3] and QtWebKit [14]. All of them provide a receiver method for getting messages from browser extensions, which is used by Xavus to fingerprint this channel, and a response method for replying to the extensions. The invocations of these two methods are identified as the claim and the use of the channel, respectively. Between them, the server is supposed to access the HTTP header Origin that includes extension IDs attached by the browser and check the signature of the browser through the API SecCodeCheckValidity. If these operations are not found, the app is considered vulnerable to the threat from a malicious extension or app. On the other hand, the attack from a malicious server against an extension cannot be detected through any existing APIs.

This sounds to me like the app validates the extension, but the extension can't validate the app. In that case, using a shared key helps.