DOI websites (e.g. DOI.gov) may use third-party embedded code, provided that certain procedures are followed:
- Embedded code must be evaluated by IT security to ensure it does not introduce vulnerabilities into any DOI site. Consult with IT security officials in your bureau before embedding code on your site.
- DOI or bureau websites employing embedded code must disclaim endorsement for the code and/or the code’s provider, or the suitability of the code for any other use. The site must also disclaim that any non-Federal external site linked to the code is outside of DOI or bureau control. Neither DOI, nor the bureau, take responsibility for the external site’s compliance, or lack thereof, with any law, regulation, or DOI or bureau policy. Terms of Service (TOS): DOI must have approved Terms of Service with the provider. Generally, TOS negotiation occurs at the DOI/OCO level, so the revised/amended TOS may apply to all DOI bureaus and offices. Bureaus and offices should not conduct their own TOS negotiations for such services without permission of OCO, to avoid replication of efforts.
- Privacy Impact Assessment (PIA): DOI requires a preliminary PIA for all systems. The preliminary PIA determines if the system contains PII, and is kept as a record by the Department. The PIA documents the assessment of how government actions may affect citizens, providing both a paper trail and an opportunity for multiple parties to offer thoughts, criticism and approval or disapproval. Contact your privacy officer for further information on Privacy Impact Assessments.
- System of Records Notice (SORN): Any DOI action which creates a System of Records may only create it within the auspices of a System of Records Notice.
- Failure to comply: Failure to comply with the above may result in disciplinary action. Creation of a System of Records without a proper SORN may result in fines ranging from $1000 to $5000.
- With rare exceptions, we do not approve of embedded code which provides identity data of our website users to third parties. For example, social media buttons and embeddable feeds of various forms can typically transmit identity information and plant cookies. Such buttons and feeds should not be used.
According to DOI’s PIA, any IP address passed from our users to the analytics provider will have its final octet masked to allow limited geolocation-based reporting but will both prevent the IP address from being considered PII and deal with certain privacy concerns.
NOTE: OS No longer uses AddThis. Our replacement code “NCShare” (No Cookie Share) is available on GitHub (https://github.com/usinterior/ncshare).
DOI has approved the AddThis social media "share" button service. This does not imply any endorsement of AddThis, merely that TOS and PIA have been completed for this service.
When creating an AddThis “share” button, you may activate analytics. AddThis analytics do not provide DOI with PII.- No other "share" buttons have been approved.
- Note: Certain popular SocMed “share” tools have been noted in the popular press for their data-gathering technology.
- The DOI Digital Strategy team is particularly wary of placing externally sourced code on .gov websites (and any other sites that we might have authority over) that runs a risk of degrading user privacy.
DOI has approved limited YouTube embedding, under certain conditions. Please see our Services section for details.
DOI has approved SlideShare embedding, under certain conditions. Please see our Services section for details.
A widget is a portable piece of computer code that can be executed within a Web page to allow content from one site to be presented dynamically within another. Widgets often take the form of on-screen tools (clocks, event countdowns, auction tickers, stock market tickers, flight arrival information, daily weather, etc).
At present, limited “widget” code has been approved for use. Please see the individual entries for various services in this Guidebook, as well as Requirements F (above).
QR codes don’t really fit our definition of website-embedded services; but they’re close, and we get plenty of requests for advice about them, so here is our current advice:
- If you’ve never used a QR code, please don’t implement a QR code.
- QR codes and their destination URLs are intended for mobile devices (mostly smartphones). If the intended location of the QR code and the website aren’t both mobile-device friendly, please don’t implement the QR code.
- QR codes are pretty much impossible to interpret by human sight. This means that an online entity could easily pose as a free provider of QR codes and instead provide surreptitious user-tracking, person-in-the-middle attacks, or worse -- and we might not find out about it until the doom has already struck. Please don’t fall for such scams. One Interior office put externally-sourced QR codes on their site, in their email sig-blocks, and in printed documents.
- QR codes are vulnerable to editing and replacement by sneaky folks. A permanent sign with a QR code is an invitation to mischief.
If you’re still considering using a QR code, even after the warnings above, please watch this YouTube video. Please notice that we provided a traditional hyperlink to the video, and not a QR code.
