[existencebox]

Some perspective, since I've been on the other side of exactly this issue, but for another bigco:

While there may well be a backend issue, in many cases, the HAR file contains tons of useful details (in my product's case) for things like "what were responses from other service calls, was anything failing locally, was any state in a weird... state" that can then let me better understand what's going on in the backend, or even know where to be looking in the backend. These large services are _so complex_ nowadays that looking at a slice of backend logs without the frontend to dovetail can often be a very partial view of the world, or be a needle-in-a-haystack scenario.

I'm giving them the benefit of the doubt here that it's similar to my project, clearly, they could maybe just be running a script (since we similarly request a HAR for all reports, since 99% of the time in practice it _is_ very useful), and you won't be harming anyone from trying to get a clear answer as to if the PG/triage group actually needs it to move forward and pushing back if they don't.

I also imagine that, if they're anything like us, you could request explicit deletion of all your support data from that case after the case is done, and they'd have to comply per GDPR/etc (We certainly would) and they likely already have to silo the information in ways that explicitly makes sure that sort of PII doesn't end up in buckets it shouldn't. I don't know if this moves the needle for you, CC #s are still touchy, but just thinking out loud.

Anyway, I hope this doesn't come across as apologetic for lax security practices, just wanted to give this perspective as I just remember the feeling of frustration of the customer refusing to send logs with a similar justification and my going "but it's going to be _much_ harder/impossible to diagnose your issue without that, and I have 0 doubts in my team's ability to properly handle and dispose of secure data as professionals, we are literally legally obligated to."

[sgrytoyr]

Appreciate the perspective. I do realise that HAR files are very useful, if for nothing else than being able to rule out any client-side issues. However, I don’t agree with their decision to make it impossible to get something looked at without HAR files - especially when there is a legitimate consern that they may contain highly sensitive data (even after their tool’s automated cleaning) and for something that is almost certainly a backend issue.

Also, it’s not so much that I don’t trust Google to handle the files responsibly, I just think it’s principally wrong to ask customers to send highly technical files (that most people won’t understand the implications of) in this day and age, when everywhere else we are all trying our best to educate people how NOT to get tricked into sharing security credentials and credit card info.

How easy wouldn’t it be to call someone you know are having a payment card issue, claim you are from Google Support, and then ask them to follow the procedure to record a HAR file while they are trying to add a new card, and then send it to some Google-like email? Even though many now have learned that they shouldn’t give out their password to anyone or click random links in emails, I suspect that a huge percentage of people would have no idea of what they just emailed to some stranger in this scenario.

Do we really want the major players to teach their customers that it’s perfectly fine to share whatever with someone claiming to be a support rep? Shouldn’t we be moving in the other direction instead?

[existencebox]

There's definitely a line to walk there re: consumer education, but I'll give the analogy that if you walk into a bank to obtain a loan, you'll hand over _far_ more sensitive information than is in a HAR file. Typically this is fine though, because we're confident we're talking to a party that actually needs this and is whom they say they are, both to lend legitimacy and potentially follow back if something goes wrong. (The fact that we initiated the interaction as well would seem to lend some legitimacy to otherwise "escalatory" requests) I personally see a similar relationship when I reach out to some service provider/utility with an issue, e.g. I'll tell them my SSN but if someone on the street walks up and says "I'm from the water company tell me your birthdate" I'd... make a very confused face.

Both as such, and to be clear, I am sensitive to the making it impossible part, and stand by my earlier statement that ideally you should be able to push back enough to get a cogent answer from the PG as to why they need it, or get an exception if not. (We should absolutely teach people to have informed reservations. Ideally we'd also have better mechanisms for easily verifying identity and securely sharing and ring-fencing information, but if wishes were nickels etc.)

(To wrap this ramble up, I will grant you a scary addendum though: A slight variation to the phishing attack you described even broaches the "We initiated the communication" trust-exercise, as a more sophisticated phisher may be able to by side channel identify that you're having a certain issue and may have reached out for assistance, and can try to intercede in that by extending help pretending to be the intended respondent. The mitigation to this one is typically "never trust someone who reaches out to you, call the trusted verifiable root-of-identity yourself each time." but it illustrates the balance one has to strike in keeping ahead of the escalating cat and mouse game while still being able to securely exchange information when necessary.)