{
    "version" : "https://jsonfeed.org/version/1",
    "content" : "news",
    "type" : "single",
    "title" : "Secure Central Hosting for the Digital Analytics Program |Digital.gov",
    "description": "Secure Central Hosting for the Digital Analytics Program",
    "home_page_url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/","feed_url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/2015/08/14/secure-central-hosting-for-the-digital-analytics-program/index.json","item" : [
    {"title" :"Secure Central Hosting for the Digital Analytics Program","summary" : "The U.S. government’s Digital Analytics Program (DAP) collects Web traffic and analytics data from across the federal government.","date" : "2015-08-14T13:00:48-04:00","date_modified" : "2025-01-27T19:42:55-05:00","authors" : {"eric-mill" : "Eric Mill"},"topics" : {
        
            "analytics" : "Analytics",
            "security" : "Security"
            },"branch" : "bc-archive-content-3",
      "filename" :"2015-08-14-secure-central-hosting-for-the-digital-analytics-program.md",
      
      "filepath" :"news/2015/08/2015-08-14-secure-central-hosting-for-the-digital-analytics-program.md",
      "filepathURL" :"https://github.com/GSA/digitalgov.gov/blob/bc-archive-content-3/content/news/2015/08/2015-08-14-secure-central-hosting-for-the-digital-analytics-program.md",
      "editpathURL" :"https://github.com/GSA/digitalgov.gov/edit/bc-archive-content-3/content/news/2015/08/2015-08-14-secure-central-hosting-for-the-digital-analytics-program.md","slug" : "secure-central-hosting-for-the-digital-analytics-program","url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/2015/08/14/secure-central-hosting-for-the-digital-analytics-program/","content" :"\u003cp\u003eThe U.S. government’s \u003ca href=\"/preview/gsa/digitalgov.gov/bc-archive-content-3/guides/dap/\"\u003eDigital Analytics Program\u003c/a\u003e (DAP) collects Web traffic and analytics data from across the federal government. That data flows into a very large central account, and some of that data is automatically made public in real time at \u003ca href=\"https://analytics.usa.gov/\"\u003eanalytics.usa.gov\u003c/a\u003e.\u003c/p\u003e\n\u003cdiv class=\"image\"\u003e\n  \u003cimg\n    src=\"https://s3.amazonaws.com/digitalgov/_legacy-img/2015/08/600-x-330-Analytics-USA-gov-08-14-2015.jpg\"\n    alt=\"A screencapture of the anaylytics.usa.gov dashboard on August 14, 2015\"/\u003e\u003c/div\u003e\n\n\n\u003cp\u003eTo accomplish this feat, participating federal websites need to add a [CODE] reference to a \u003ca href=\"https://github.com/digital-analytics-program/gov-wide-code/blob/master/Universal-Federated-Analytics.js\"\u003estandard bit of JavaScript code\u003c/a\u003e. Until now, the only option agencies have had is to host this JavaScript file themselves, like this:\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e\u0026lt;script src=\u0026#34;/js/federated-analytics.js\u0026#34; id=\u0026#34;_fed_an_ua_tag\u0026#34;\u0026gt;\u0026lt;/script\u0026gt;\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eWhile this approach allows agencies more control, it makes it seriously challenging for DAP to ensure that security improvements and other bug fixes are quickly distributed to participating websites.\u003c/p\u003e\n\u003cp\u003eTo address this, DAP has set up a centrally hosted URL at dap.digitalgov.gov containing the most current DAP collection code, which agencies can reference like this:\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e\u0026lt;script src=\u0026#34;https://dap.digitalgov.gov/Universal-Federated-Analytics-Min.js\u0026#34; id=\u0026#34;_fed_an_ua_tag\u0026#34;\u0026gt;\u0026lt;/script\u0026gt;\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eBy adding this tag and following \u003ca href=\"https://s3.amazonaws.com/digitalgov/_legacy-img/2015/02/GSA-DAP-UA-Code-Quick-Guide-15-01-30-v1-02_mvf.pdf\"\u003eDAP’s guidance\u003c/a\u003e (PDF, 273 KB, 7 pages, February 2015) to add parameters identifying your agency, a federal website will begin reporting its Web analytics to DAP and will be guaranteed to always be using the latest, greatest, most secure DAP code.\u003c/p\u003e\n\u003ch2 id=\"securing-visits-to-federal-websites\"\u003eSecuring Visits to Federal Websites\u003c/h2\u003e\n\u003cdiv class=\"image\"\u003e\n  \u003cimg\n    src=\"https://s3.amazonaws.com/digitalgov/_legacy-img/2015/03/600-x-360-Https-secure-KeremYucel-iStock-Thinkstock-ThinkstockPhotos-181290353.jpg\"\n    alt=\"The beginning of a secure https URL shown in an web browser\u0026#39;s address bar; the s on https and padlock are red.\"/\u003e\u003c/div\u003e\n\n\n\u003cp\u003eHosting a widely-referenced piece of JavaScript introduces its own security concerns, because any change to that JavaScript will immediately affect all federal websites that reference it. It’s extremely important that the JavaScript on dap.digitalgov.gov not be modified by an attacker.\u003c/p\u003e\n\u003cp\u003eThis isn’t a theoretical concern: in March of 2015, \u003ca href=\"http://www.vox.com/2015/3/30/8315281/github-chinese-ddos-attacks\"\u003ea large Chinese network took advantage of a centrally hosted analytics JavaScript file\u003c/a\u003e that was served over an insecure connection to rewrite its contents and turn visitors’ browsers into attack bots. Any network, from a coffee shop to a global ISP, can easily attack insecure connections in this way.\u003c/p\u003e\n\u003cp\u003eOn the web, the way to prevent this kind of attack is to use \u003ca href=\"https://https.cio.gov/\"\u003eHTTPS\u003c/a\u003e, which encrypts and secures the connection between a visitor and the JavaScript code.\u003c/p\u003e\n\u003cp\u003edap.digitalgov.gov \u003ca href=\"https://www.ssllabs.com/ssltest/analyze.html?d=dap.digitalgov.gov\u0026amp;s=23.203.230.91\u0026amp;latest\"\u003euses strong HTTPS\u003c/a\u003e as well as \u003ca href=\"https://https.cio.gov/hsts/\"\u003eHTTP Strict Transport Security\u003c/a\u003e (HSTS), which adds some additional protections.\u003c/p\u003e\n\u003cp\u003eThe \u003ca href=\"https://https.cio.gov/\"\u003erecent federal government policy on HTTPS\u003c/a\u003e requires HTTPS and HSTS for all new federal websites and services. (For agencies: DigitalGov University recently produced educational videos on an \u003ca href=\"https://www.youtube.com/watch?v=d2GmcPYWm5k\"\u003eIntroduction to HTTPS\u003c/a\u003e and \u003ca href=\"https://www.youtube.com/watch?v=rnM2qAfEG-M\"\u003eImplementing HTTPS\u003c/a\u003e.)\u003c/p\u003e\n\u003ch2 id=\"breaking-the-protocol-relative-url\"\u003eBreaking the Protocol-Relative URL\u003c/h2\u003e\n\u003cp\u003eMany people on the Web are accustomed to using \u003ca href=\"http://www.paulirish.com/2010/the-protocol-relative-url/\"\u003eprotocol-relative URLs\u003c/a\u003e, which have long been promoted as a best practice. They look like this:\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e\u0026lt;img src=\u0026#34;//domain.com/img/logo.png\u0026#34; alt=\u0026#34;\u0026#34; /\u0026gt;\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eThis means that the URL will inherit the protocol of the containing page. If the embedding website uses HTTPS, then the image will be fetched over HTTPS, and likewise for HTTP. When HTTPS was considered optional for many sites, this made some sense. However, in 2015, \u003ca href=\"http://www.paulirish.com/2010/the-protocol-relative-url/\"\u003eprotocol-relative URLs are considered an anti-pattern\u003c/a\u003e and are discouraged.\u003c/p\u003e\n\u003cp\u003eBecause dap.digitalgov.gov is a potential high-value target, the Digital Analytics Program did not want to support plain HTTP connections at all—even for a redirect. Though HTTP redirects are helpful, they are still an opportunity for attack. \u003ca href=\"https://https.cio.gov/hsts/\"\u003eHSTS\u003c/a\u003e is designed to help with this, but an even more secure solution is to simply disable HTTP altogether.\u003c/p\u003e\n\u003cp\u003eThis generally isn’t a viable solution for websites, because users type bare domains like “whitehouse.gov” into browser location bars, and browsers generally have to assume plain HTTP as a first try in these situations. But because dap.digitalgov.gov is a brand new subdomain used only as a third party service, DAP can set a higher standard by \u003cstrong\u003ebreaking the protocol-relative URL\u003c/strong\u003e when used on a plain HTTP site.\u003c/p\u003e\n\u003cp\u003eThe simplest solution is to refuse \u003ccode\u003ehttp://\u003c/code\u003e connections entirely by closing port 80 and not allowing browsers to connect at all, but this was not a viable option for DAP’s hosting provider. However, returning an error code instead of a redirect for plain HTTP connections would not be in compliance with federal HTTPS policy.\u003c/p\u003e\n\u003cp\u003eWe solved the issue by \u003cstrong\u003ecombining\u003c/strong\u003e a redirect with an error code. Any HTTP requests to a file on \u003ca href=\"http://dap.digitalgov.gov\"\u003ehttp://dap.digitalgov.gov\u003c/a\u003e will redirect the user to \u003ca href=\"https://dap.digitalgov.gov/403\"\u003ehttps://dap.digitalgov.gov/403\u003c/a\u003e, which then returns a 403 error code.\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e$ curl --head http://dap.digitalgov.gov/Universal-Federated-Analytics-Min.js\nHTTP/1.1 301 Moved Permanently\nLocation: https://dap.digitalgov.gov/403\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eThis ensures that data can \u003cem\u003eonly\u003c/em\u003e be collected over HTTPS, and \u003cem\u003ebreaks\u003c/em\u003e any HTTP or protocol-relative URLs participating agencies might accidentally use when integrating their websites into the Digital Analytics Program.\u003c/p\u003e\n\u003cp\u003eWhile DAP’s solution ended up being straightforward, this approach is surprisingly novel—most common third party services today don’t even require HTTPS.\u003c/p\u003e\n\u003cp\u003eBut on today’s Internet, they should, and the Digital Analytics Program is leading by example.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eEric Mill is an 18F team member.\u003c/em\u003e\u003c/p\u003e\n"}
  ]
}