Again, it's purely anecdotal, but I've had more than one topic go without any reply, and one result in a Microsoft employee asking me to email logs. One of which was over 600MB in size, just from loading VS and after sending the email, I never heard back. I eventually gave up on that particular issue and took the only remaining option which was reimaging my machine. (A Microsoft produced and supported VS addon was causing errors in the .NET runtime that were uncaught and untraceable. Reinstallation of VS, SP1, and all installed version of the .NET runtime were futile).
(funny, the parent reply was posted, my post was downvoted and shriphani's post were resurrected all within 30 seconds. Can't we just have a conversation about this without it being personal or political? I know you both work or have for Microsoft)
You wrote "The only venue that Microsoft provides to give feedback and bug reports is their connect website." That was simply, overtly, directly, incontrovertably false.
Now, because you are a message board geek, instead of saying "oh, interesting, I didn't know that, thanks for letting me know", you've given me 6 grafs of random stuff about security people, black-and-white, you-didn't-even-read-the-report, 0-day-not-crash-whatever. I don't care. You were wrong, that wasn't the way to report a security issue. It's either a security issue --- which your original argument depends on it being --- or it's not. If it's a security issue, posting it on a public bug tracking server was the wrong call.
Glad to clear that up for you. Feel free to the last word.
Which is of course a terrible idea when you're trying to report a problem that has or could have security relevance. I'm definitely not going to pay for support just so I can report security bugs to Microsoft.
I was talking about the last post, sorry if that wasn't clear. My point was, if other people have the same problem and find the thread, they will not read 19 pages and rather go to the last one to see where's the issue at. And there they will find nothing that answers their question. Lenovo staff could have at least have said "it is a known issue" / "it is a driver issue" / "We have an agreement with Microsoft"... Whatever the reason is.
The big problem, outside of questionable conduct from MS, is the lack of stability surrounding the userspace plumbing. The DEs and their friends lower in the stack can't stop CADTing the APIs etc, and that scares away third parties.
Although of course an even better solution is to complain and get MS to fix their shit. This was almost certainly someone not realizing they should feature test instead of checking a UA.
On Microsoft's forums these stupid suggestions are the official answers ("trouble shooting"). Have literally any issue? Why don't you reboot, reinstall, switch your hardware piece by piece and bake me a cake?
No diagnosis. Just 3 weeks of work for the reporter before they'll even look at the problem.
"I was very interested in that question. And one of the places that I focused on was the MSRC, which is short for Microsoft Security Response Center. This center is like a clearing house for reports of security bugs, and it was Harris' very first stop when he began warning colleagues of the flaw that he discovered. But the issue is that the center itself was understaffed and underresourced. And one employee who used to work there told me that staff is trained to think of cases in terms of how can I get to won't fix. So this center also clashed with the product teams."
I used to work for the MSRC. He's right that it was understaffed and underresourced. It's one of the reasons I quit, same for many of my ex-colleagues. But I disagree with his characterization of us trying to find any way to get cases to Won't Fix. The fact is, we got many, many reports that were genuinely not vulns, and therefore shouldn't be prioritized for fixing from a security standpoint. Yes, occasionally reports may be incorrectly analyzed but that's not because we were trying to get them to Won't Fix. It's just people making mistakes now and then.
"And, you know, another big issue there is that they're clashing with the product teams that they need to fix the actual issues. So they would bring a security vulnerability to a product group. They'd say, you need to fix this flaw. But those groups were often unmotivated to act fast, if at all, because compensation is tied to the release of new products and features."
That's true in part, but it varies wildly between product teams. Some were incredibly responsive and knowledgeable, some were clueless about security, some just didn't prioritize it.
Sometimes the fix was insufficient. When I was there, MSRC wouldn't check if the fix did what it was supposed to do, except in occasional cases where we were explicitly asked to check or if it was a particularly risky case that needed the extra scrutiny. But like he says, we were understaffed and underresourced, we simply didn't have the time to do this for every case.
MS dev here. Thanks for calling this out. I contacted the GH@MS admins to look into this and to consider adding some safeguards to the tooling so this doesn't happen in the future.
reply