I looked at the API calls on the CrowdStrike blog post and I have been using parts of these API's for calls in PowerShell for at least the past year for tracking down issues we have had in Office 365. I can understand how frustrating it can be if your competitors seem to have "secret knowledge". However that knowledge may have been gotten by calling up the very helpful people at MS support, laying out the problem and they send you a Powershell script in return.
I couldn't agree more. Why is the API not public? Is it because some sort of top secret corporate conspiracy? Or is it that management just decided to avoid the burden of publishing and maintaining an immature or lesser used API? After reading your comment that whole article seemed a little sensationalist
> just decided to avoid the burden of publishing and maintaining an immature or lesser used API
"Burden" is an understatement. Any API Microsoft documents becomes part of their ongoing commitment to eternal backward-compatibility. (Heck, even some things they never document at all still end up forced into that commitment, like the internal registry hives in Windows 95.)
So Microsoft do everything they can to only document what they're absolutely sure they have in a good, stable, "won't regret later that we didn't fix it some more before setting it in stone" state.
While that may be true for the Win32 APIs, it is certainly not true for their cloud-based products. They’ve had some very poor APIs for Windows Live Mail (predecessor of Office 365 for education) which were also quickly deprecated and replaced.
They could just flag it “volatile”, “unstable” or something.
It’s very unlikely that Microsoft did not properly document the api internally and as you see it’s leaking out anyway.
If you'll ever develop a single simple API you'll find out that doesn't work at all. People will use unstable APIs and people will blame YOU and only you when they break.
There are a lot of reasons that it might not be public, but a conspiracy is quite low on the list.
My guess is that it's due to one of the following:
* The API isn't considered beta yet.
* This was created as somewhat of a side project and hasn't been formalized yet.
* Documenting it is on the backlog.
* It's meant for internal use in that they may be building in tools in the Security and Compliance center that will be calling it.
This is absolutely not true. I called O365 yesterday (well, they called me at my request) to investigate a potential data breach. All the guy on the phone could do was to read to me out of a technicians manual and then suggest I purchase the Azure Active Directory P2 plan at $9/user/month.
I respect that fact that CrowdStrike and others have spent the time with the api and made life a lot easier for others. As someone who has spent more time than he wanted with the Office 365 API I am a fan of people who make my life easier. That being said I am not buying the drama that these API's have been hidden.
I don't think there is a right to compel others to unlimited spending to keep you alive. Sure, pencilin is comparatively easy to grow and hopefully you live in a country with universal healthcare that covers it, but if it were some more expensive substance that can't be covered the analogy holds.
> The tide turned on Friday, June 8. Out of the blue, an email popped onto the forensics community mailing list. It contained a single link, to an Anonymous video.
All that video said was "the API you seek is called Activities". Am I missing the joke, or is the name of the API literally the only thing that they needed to get this working?
I've not delved into the code, but typically a lot of APIs when called without any parameters can return an XML page containing the schema of what it can do. So yes, it's totally plausible, that if you already knew how Office 365 APIs worked, all you needed was the name of the unknown API.
This is similar to Azure activity logs - in that they do not provide you log access to "read" actions.. only write/delete ones. However, Azure actually DOES keep those read ops logged. Though I guess, it's not similar in that: Azure still doesn't have an API to fetch them.. not even an undocumented one.
If an API is undocumented, how can you know that it doesn't exist? It might very well exist for internal debugging purposes, just not at the URL you might expect. Or maybe it's at the expected URL but returns 404 to everyone whose access token isn't flagged as an employee in the appropriate department.
As someone who relies very heavily on logs to debug issues in immature and/or fast-moving products, I would be surprised if they didn't log everything. It's sysadmin 101.
In the modern era, you should expect that the privacy policy contains the details of everything that's logged. You need to know that so you can tell your customers what is logged by your subs.
What a naive / handwavey response. It's clearly not a case of "oh, we never finished up cleaning up the API for use in production" - it's a case of "here's a secret backdoor that we're only going to share with a privileged handful of powerful corporations"
Is this about the whole Office 365 suite including all apps like Word, Excel, etc. running locally or only about Office 365 mailbox accounts? If it is the latter, could the title please reflect this?
Even if that is true not letting forensics specialists know that those logs existed when critical security events took place is very much a problem. But it gets downright shady when only a handful of companies have them while others are told they do not exist.
All this Facebook-bashing in the recent months and then m$ office is spying on everything you do. This is like a "legit" keylogger, which is activated per default, because it's a product feature. But, you have to trust it also per default, it seems. Damn.
