TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Google demands HAR files with sensitive info to look into payment issues

6 pointsby sgrytoyrover 2 years ago
My company uses Google Workspace for email, and we are happy to pay them for their services. A while back, our old payment card expired and they emailed us saying we have to add a new one. So I logged in and tried adding a new card (a VISA card that works everywhere else, even in other parts of Google), but it repeatedly failed with the error code OR-CCSEH-26 and the message “Your card’s issuer declined this request. Contact your bank or use a different payment method.” So I contacted my bank (the largest bank in Norway) and they said everything is fine and they have heard reports that Google sometimes rejects transactions for no good reason, but there’s nothing they can do about it - I have to resolve it with Google.<p>I contact Google Workspace support and after the usual introductory pleasantries they seem to understand that I have a legitimate issue that their specialist team needs to look more closely at. However, even though this appears to be strictly a backend issue (after all, they have contacted the card’s issuer), their procedures will not allow their agents to escalate this without receiving a HAR file from me by email, containing complete details about all requests pertaining to my attempt to update the payment card.<p>Importantly, such a HAR file would contain every single payload and header sent from my browser to Google’s servers, including my authentication token and full credit card details. I balk at this and explain that I am very reluctant to send such a sensitive file to anybody, using any transport, but particularly to some shared email address at Google. Oh, that’s not a problem, the agent says (but only after I resist sending them the raw HAR file), I can just use the HAR analyser in the Google Admin Toolbox to remove any sensitive information. However, it is unclear if this tool requires me to upload the file to Google first, or if it is strictly a client-side tool (on closer inspection, it looks like it may be local, which is good). It is also unclear if it completely removes stuff like credit card details, or just auth headers.<p>Regardless, there are several things that IMHO are wrong with this:<p><pre><code> - Why is it impossible to escalate a payment issue without a HAR file? - Why do customers need to upload a HAR file to debug what is in all likelihood a backend issue? - Why is Google, a champion of online security (unironically), asking customers to send files containing their login credentials and full credit card details, by email? - I am a developer and could probably figure out how to clean a HAR file manually (even though it is 7MB of JSON), but do they really expect regular users to be able to do this? </code></pre> My issue has been ongoing for several weeks, with no solution in sight, and when asked point blank, their agent confirmed that there is nothing they can do without a HAR file. The last agent I spoke to even put me on hold while she double-checked with her supervisor that this was the case.<p>This is a bit of a rant, I know, but I also felt that the big-picture aspects of this might be worth discussing on HN. Is it really Google’s policy that they will not help a customer trying their best to give them their money, without said customer sending them a highly technical file containing extremely sensitive information? And if so, what does that say about their internal security culture?

5 comments

solardevover 2 years ago
The agent is just following some script and if that calls for HAR for troubleshooting, that&#x27;s what they&#x27;re going to ask you for, no matter if it&#x27;s a security concern.<p>Can you escalate it to a manager, or just use a different credit card? Google&#x27;s not known for their customer service, and they&#x27;re probably not very trained on how to handle foreign transaction problems. It&#x27;s one of the downsides of using Workspace... good services, poor support, and mostly you&#x27;re on your own to figure things out =&#x2F;
评论 #33658968 未加载
theduder99over 2 years ago
this situation is not unique to google. support teams asking for har files is a common practice nowadays, yes even for companies processing payments. if I was you I would escalate this thing on the issuer side again. there are a variety of reasons why the issuer would send a generic &quot;customer should contact issuer&quot; response back to google.
existenceboxover 2 years ago
Some perspective, since I&#x27;ve been on the other side of exactly this issue, but for another bigco:<p>While there may well be a backend issue, in many cases, the HAR file contains tons of useful details (in my product&#x27;s case) for things like &quot;what were responses from other service calls, was anything failing locally, was any state in a weird... state&quot; that can then let me better understand what&#x27;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.<p>I&#x27;m giving them the benefit of the doubt here that it&#x27;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&#x27;t be harming anyone from trying to get a clear answer as to if the PG&#x2F;triage group actually needs it to move forward and pushing back if they don&#x27;t.<p>I also imagine that, if they&#x27;re anything like us, you could request explicit deletion of all your support data from that case after the case is done, and they&#x27;d have to comply per GDPR&#x2F;etc (We certainly would) and they likely already have to silo the information in ways that explicitly makes sure that sort of PII doesn&#x27;t end up in buckets it shouldn&#x27;t. I don&#x27;t know if this moves the needle for you, CC #s are still touchy, but just thinking out loud.<p>Anyway, I hope this doesn&#x27;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 &quot;but it&#x27;s going to be _much_ harder&#x2F;impossible to diagnose your issue without that, and I have 0 doubts in my team&#x27;s ability to properly handle and dispose of secure data as professionals, we are literally legally obligated to.&quot;
评论 #33690292 未加载
animitronixover 2 years ago
Oh boy would you hate what one can see with session replay tools like LogRocket
评论 #33690411 未加载
评论 #33667546 未加载
barelysapientover 2 years ago
Use a different card or draw from a bank account.