DotNetOpenAuth’s “call home” reporting

A few months ago I asked how people would feel if DotNetOpenAuth collected feature statistics and sent them back to the library’s authors so we get a better feel for what features are used, errors that are common.  The feedback I got was positive, so v3.4 has reporting turned on by default, but you can opt out either entirely or just omit certain details from the report by adding some simple tags to your web.config file. 

This turns it completely off:

<dotNetOpenAuth>
  <reporting enabled="false" />
</dotNetOpenAuth>

This makes the reporting pseudonymous, in that no URLs from your own web site are sent back in the report, but a random GUID is still included in your report so that we know that the origin of the report is the same across multiple reports.

<dotNetOpenAuth>
  <reporting includeLocalRequestUris="false" />
</dotNetOpenAuth>

How is the report sent?

There’s an adjustable frequency that defaults to once daily.  When certain features in DotNetOpenAuth are accessed, a quick time check is made, and if it’s time to send a report, a thread pool thread is queued to generate and HTTP POST the report to https://reports.dotnetopenauth.net/.  We use a thread pool thread to minimize the performance impact this reporting has on your web site.  In fact the entire reporting feature is finely tuned to have virtually no impact on your site’s performance.

If your site isn’t running for at least one reporting interval, a report will not be sent.  So most of your self-hosted “localhost” sites run by Personal Web Server in Visual Studio will not generate these reports.

What’s in the report?

So what all information is actually in this report anyway? Well, here’s a sample:

{be791692-2573-41b4-bd6f-6f4760cf186c}
DotNetOpenAuth, Version=3.3.4.10015, Culture=neutral, PublicKeyToken=2780ccd10d57b246 (official)
.NET Framework 2.0.50727.4927
====================================
requests.txt
http://localhost:4856/login.aspx
http://localhost:54347/User/Authenticate
====================================
cultures.txt
en-US
====================================
features.txt
OpenIdLogin
OpenIdButton
AXFetchAsSregTransform
OpenIdRelyingParty StandardRelyingPartyApplicationStore StandardRelyingPartyApplicationStore
ClaimsRequest
FetchRequest
ClaimsResponse
XrdsPublisher
====================================
event-Yadis.txt
4	XRDS referenced in HTTP header
8	XRDS referenced in HTML
1	XRDS in initial response
====================================
event-PositiveAuthenticationResponse.txt
2	https://www.myopenid.com/server
2	http://localhost:45235/provider
====================================
event-NegativeAuthenticationResponse.txt

At the top of the file is a self-identifying GUID.  It means nothing, except that the GUID is the same for all reports that come from your web site, allowing the reporting database to update the records for your web site (whether we even know the URL of your web site or not) with the latest report. 

Then we have the DotNetOpenAuth version and CLR you’re using.  It turns out that we not only use this for statistical purposes, but it allows the reporting server that receives the report to check whether the version you’re using is on a list of versions with known exploitable security holes.  Since for many web sites authentication is a feature that’s completed and never considered again, someone using an old version of an authentication library may be exposed to security holes that a newer version would correct.  So what happens if the version of DotNetOpenAuth that’s reporting in is one with known security holes?  Not much.  But if you have DotNetOpenAuth error logging (usually via log4net) enabled, an ERROR is logged with a message describing the problem and warning the web developer to upgrade.  In the meantime the library on the web site continues functioning.  I actually debated with myself whether to install a kill-switch, since perhaps disabling authentication on a web site altogether is better than leaving the site operational with a nasty security hole.  But decided against that… and I suspect most web site owners would agree that it’s not my decision to make whether to shut down your web site. :)  So I leave it at emitting a warning in your ERROR log.

The requests.txt section gives just the first few URLs on the site that either host DotNetOpenAuth’s ASP.NET controls or programmatically process OpenID/OAuth/InfoCard messages.  Currently the longest this list of URLs can get is 3, since some sites like blogs may have login controls on every one of their blog post pages and I mostly just want to get an idea of who’s using the library.  Note that these URLs have their query strings stripped off before being included in the report to try to avoid accidental private information disclosure.  You can omit this section in your reports by setting the <reporting> element’s includeLocalRequestUris=”false” attribute.

The cultures.txt section just reports what the browser that’s accessing your web site says is its primary culture.  This will help me know which languages to offer localized error messages for.  Each report is limited to only reporting 20 cultures.  You can omit this section in your reports by setting the <reporting> element’s includeCultures=”false” attribute.

The features.txt section lists which parts of the DotNetOpenAuth library have been used by your web site.  Pretty straightforward.  You can omit this section in your reports by setting the <reporting> element’s includeFeatureUsage=”false” attribute.

The event-Yadis.txt section is just some random statistics on how OpenID identifier pages are constructed.  You can omit this section in your reports by setting the <reporting> element’s includeEventStatistics=”false” attribute.

The event-*AuthenticationResponse.txt sections tell me which remote parties DotNetOpenAuth is able to successfully interop with and which ones have issues.  Note that no user information is collected or reported.  You can omit this section in your reports by setting the <reporting> element’s includeEventStatistics=”false” attribute.

Please comment with your thoughts, including any questions or concerns you may have.