[thayne]

It seems to me like the browser should not include cookies in HAR files by default. Sure, have a way to enable including cookies, but it should be behind a scary warning informing the user that the cookies likely contain sensitive data.

[usrbinbash]

How about: People shouldn't send around HAR files that contain sensitive information, or at least make sure the information contained is no longer sensitive (eg. by flushing active sessions)?

HAR files are a debug tool. If I have to debug a problem with a webservice, I require them to contain all the information that was sent/received by the browser. The browser arbitrarily deciding to delete part of that information, would make it worthless to me as a debug tool.

[usrusr]

Reminds me of that banner Facebook writes to the browser console to warn people of pasting stuff that will hand over their session to third parties. Handing over a HAR is just as bad if there is any form of session involved.

Browsers could add even more nag screens between the user and the tools, but those have zero effect once the assumption "I'm talking to a person from the hoster" is established. It's the old "put on a safety vest and a hardhat and you can walk anywhere" hack that only training can protect you from. And even with the best training, you'll never reach 100%. That's why you need many tiers of your operation is as sensitive as selling a trust store.

It's well possible that 1Password are still far from being breached thanks to tiers, but it's interesting to see even people working full-time on the conflict between authentication and convenience struggle with that balancing act.

[thayne]

There have been several times when I was working on triaging a customer reported bug where I wanted to ask for a HAR file (through customer support), but didn't, because I didn't want them sending me (or the support intermediary) their session cookies. And having the cookies wouldn't have helped me debug it.

[usrbinbash]

> And having the cookies wouldn't have helped me debug it.

But having that cookie, or any other data from my dev environment, after I manage to recreate the reported bug internally, has often helped me debug problems.

The point here is, debug tools that delete information are less useful. Worst case, they are useless.

Yes, such tools can be problematic. With great power comes great responsability. But I rather have powerful tools with a big 'ol warning sign, than useless tools.

[hunter2_]

This sounds to me like the correct way to plug this leak. It will benefit additional use cases involving the HAR export beyond individual support portals sanitizing it before storage.

The "Copy as cURL" feature has the same issue. As does highlighting and copying request/response headers to the clipboard.

However, less sensitive data should ideally remain easily transferred, without much effort on the part of the user.