That's not how Google tells it, if I'm reading this right:
Cloudflare explained that they pushed a change to production that logged malformed pages that were requested, and then sent me the list of URLs to double check.
Many of the logged urls contained query strings from https requests that I don't think they intended to share.
(I'm reading that as "intended to share with Google".)
If Cloudflare accidentally leaked additional sensitive data to Tavis during the handling of this incident, and that data wasn't already compromised by the parser bug, then you should call that out in the incident report.
I don't think that's the case: from my reading of the issue I understood that the urls with query params were sent from CF to Google for clearing from the google cache.
That's not how Google tells it, if I'm reading this right:
Cloudflare explained that they pushed a change to production that logged malformed pages that were requested, and then sent me the list of URLs to double check.
Many of the logged urls contained query strings from https requests that I don't think they intended to share.
(I'm reading that as "intended to share with Google".)
Ah. I see what you mean. Apologies, kind of tired.
If Cloudflare accidentally leaked additional sensitive data to Tavis during the handling of this incident, and that data wasn't already compromised by the parser bug, then you should call that out in the incident report.
Understandably, I think. I can't imagine you've had much sleep this week.
6 replies →
I don't think that's the case: from my reading of the issue I understood that the urls with query params were sent from CF to Google for clearing from the google cache.
I read it as "sensitive query strings sent to Google by CloudFlare engineers".