Tell HN: Messages from Another Azure Customer Are Appearing in My Queue
The messages contain end-user information. No data breach has been announced.
Not downplaying the possibility of a problem on Azure's end, but the most likely scenario is your credentials have leaked, possibly (as another commenter suggests) though a stack overflow post, GitHub issue, or similar. If someone has a valid key and queue name they can post to it. That's the most likely cause.
LLMs tokens are usually common word or parts of word, and it would be extremely weird for copilot to output them verbatim in generated code(I've actually tried a few times), or it would be random invalid keys since there is no real patterns in API keys
+I'd be shocked if they weren't automatically stripped from the training data
I’m sure there are edge cases, but I’ve been surprised how well it handles this.
The repo is somewhat niche, and copilot will nearly (with some help) create the entire repo, including the original repos comments.... but won't generate the same keys no matter how hard I've tried.
I'm pretty sure there was some at least some sanitization before it made its way into the model.
Their support is useless, features are whacky, with all sorts of weird edge cases, they’ve had more significant issues than I care to count. Would not be hosting my stuff with them.
You've provided virtually zero information other than one-line comments that illuminate nothing.
Stop playing 20 questions. If you want to publicly complain about what would normally be considered a catastrophic lapse of public cloud security, provide more than zero details of how your system is architected and what you've done to investigate the issue yourself!
Do you use Storage Account keys? How confident are you that some developer hasn't pasted it into your codebase and maybe leaked it?
Are your keys stored (only) in a Key Vault? How secure is that vault? Have you checked its audit logs?
Have you rotated your keys?
Have you looked at the Storage Account diagnostic logs to see what's going on?
Have you even turned the logs on!? You mention legal compliance issues. Do you have your resource auditing configured to match your legal requirements?
Etc...
You come across as someone who has screwed up and is accusing the vendor.
"We've tried nothing and we're all out of ideas".
My sense is that OP is outright lying, probably works for a competitor, and is just trying to stir the pot.
All that, for someone else's security breach?
I assume the response has been .. muted.. because it involves legal and compliance.
Don't know about Azure, but my AWS support tickets have always been answered with very helpful diagnosis.
I expect if they ever did get back to OP on this issue, they'd just say to delete the queue and make a new one.
I rarely have first contact outside of an hour or two.
---
To be fair, I find I have to contact AWS support far less often, and honestly, if you do have a request ID in hand … they're far more receptive. But boy if you don't have that ID, it doesn't matter if you're seeing 2+ minute latency from S3 within AWS just to fetch a 1 KiB blob, it isn't happening.
And the status page is lies, but lying on the status page appears to have become industry SOP.
https://chat.openai.com/share/294a3d4f-5719-4d11-9832-fdafb1...
What if your messages are landing in others’ queue, and you don’t even know it..
You should be collecting metrics on the basics of the way your service operates and in a steady state at scale even a 1/2% drop in messages should be readily noticable and likely monitored.
It is far from certain that any application has such a "steady state", most of the ones I've worked on sure don't. There are obviously ways to analyze things and correlate enqueued and dequeues, but it is far from as simple and black and white as you suggest, especially with truly distributed systems and unknown cause of the reported behavior.
Heck, we don't even know if the messages are being "dropped" or just duplicated.
Also. Screenshot everything.
> 1. Processing shall be lawful only if and to the extent that at least one of the following applies:
> (d) processing is necessary in order to protect the vital interests of the data subject or of another natural person;
GDPR might not apply in this case, but if it does, I think you're alright.
This is an information-free one-line throw away comment by someone who's probably misconfigured something.