To answer the question "why should my escrow see that" - the difficulty here is we are trying to prove whether the BTC seller has received the promised USD in his account or not. That can only be resolved by seeing a list of transactions for the given date.
You could show only the details of the relevant transaction. At least every internet banking I've used so far do display a "confirmation page" after a transaction is finished, and this confirmation page contains all relevant data for the escrow (source and target accounts, amount, date, description).
The only "inconvenience" is that the plugin wouldn't be able to automatically recognize the confirmation page - well, it could learn if it's a really fancy software with AI and all, but let's keep it simple please
-, meaning that the user should manually indicate that "this is the good page to save". That's why I mentioned a printscreen-like button. And as long as the internet banking displays the details of past transactions, the escrow could always instruct his clients on how to obtain proof of transfer in case of a dispute, meaning that in 'everything goes well' use cases, people wouldn't even need to bother with installing the plugin.
Yes I think you understand the basic situation. The problems are technical, and I see two:
1. If we want a "proof of sending", we have to record all sessions, whether there's a dispute or not. Then we have to know how to parse the output in every case. Ideally this would be automatic, and we would have to build parsers for every possible bank, which would be an unfeasible amount of work imo.
By only running the "recording" process for audit cases (cases of dispute), we can fall back on "manual parsing" (i.e. the escrow agent or other expert just reading the decrypted output and interpreting it). This is not as bad as it sounds, because tools like Fiddler which I've been using today will allow you to view the decrypted output in text, hex or html (obviously easiest!). In theory you get to see the web pages exactly as the user saw them.
Now the reason this is a problem is that the auditing version means looking at the *output* of the wire transfer, not the input, which means looking at a record of the BTC seller (and USD buyer's) transactions. I guess we could (and perhaps should) look at the USD seller/BTC buyer's transaction record too. But anyway in this model (audit only) just looking at the "wire transfer sent confirmation page" can't happen.
2. The other problem is the technical problem of "recording" only *part* of the SSL session, so as not to expose the most sensitive data. I don't think the user could first login to internet banking, and then switch on a proxy to start rerouting traffic via the escrow's machine (who would then dump all decrypted SSL output). That's what we want, but it sounds somewhere between tricky and impossible. There needs to be a solution to this.
Dan's fallback of changing your password after the audit is a great idea for a last resort (or for the sensibly paranoid), but it can't be the main idea there.