Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update official government banner text #3524

Merged
merged 3 commits into from
Jul 8, 2020

Conversation

thisisdano
Copy link
Member

@thisisdano thisisdano commented Jun 25, 2020

The USWDS banner has a few key responsibilities:

  • Introduce consistency and continuity across federal government websites
  • Help the public easily identify U.S. government organizations on the internet
  • Educate the public on how to interpret the info in the browser bar

This pull request incorporates feedback we've received on the banner over the last year or so, along with a review of the language by GSA subject matter experts. This change hopes to convey a few key enhancements:

Default (Preview)

Official websites use .gov Secure .gov websites use HTTPS
A website ending in .gov indicates it is an official U.S. government organization. A lock (🔒) or https:// before the website name indicates information you get or provide is transmitted securely.

Spanish (Preview)

Los sitios web oficiales usan .gov Los sitios web .gov seguros usan HTTPS
Un sitio web cuyo URL termina en .gov indica que es un sitio oficial del Gobierno de Estados Unidos. Un candado (🔒) o https:// antes del nombre del sitio web indica que la información que usted provee o recibe se transmite en forma segura.

.mil (Preview)

Official websites use .mil Secure .mil websites use HTTPS
A website ending in .mil indicates it is an official U.S. government organization. A lock (🔒) or https:// before the website name indicates information you get or provide is transmitted securely.

We also recognize that this text and guidance may change over time (perhaps the lock may go away as well), and that this makes it even more important that we improve how we're able to communicate these changes to downstream users. So we'll be working to promote this change through notifications, direct outreach, public meetings, and social media. Future versions of the design system might make it even easier to stay up to date.

This change will also require a guidance update to uswds-site.

@thisisdano
Copy link
Member Author

Looping in @h-m-f-t, @konklone, and @wslack from the issues and PRs referenced above for any feedback you may have on this!

@konklone
Copy link
Contributor

konklone commented Jun 26, 2020

Thanks for taking the time to revise this text, and for tagging me on it!

Overall, I really like the simplification of the text, and I think this improves the banner. Some thoughts and suggestions below:

  • The grammar here is a little odd: "A website ending in .gov indicates it is an official U.S. government organization." The website isn't the organization itself, and "indicates" is a little wonky as a word choice. I'd suggest something a bit more straightforward, like "A website ending in .gov belongs to an official U.S. government organization." Same for the .mil text.

  • Just on wording clarity: "indicates" and "you get or provide" both strike me as wonky or hard to parse for laypeople, in "A lock (🔒) or https:// before the website name indicates information you get or provide is transmitted securely." I think "before the website name" can be left implied, and is also a bit more futureproof. (I'll suggest a reword synthesizing some more thoughts below.)

  • I hate having to say this, but unfortunately, being at an HTTPS website doesn't mean that any information you submit is sent securely. HTTPS websites can still embed HTTP forms, and often do - and there is no indicator shown to the user that the form target is insecure when it's embedded on an HTTPS page. I don't know how big of an issue this remains in the USG, but it is a security gap on the web which we should start closing. I'm proud to say that my team at Chrome is beginning to tackle this, but it's early days and I don't know what other browsers are doing. I am torn on whether the language needs to hedge on this point, since 1) the existing text also says the same thing, so this isn't making it worse, and 2) the failure case should be very rare in the USG, and we should be trying to make users feel safe submitting information to the government over HTTPS. And yet, all it takes is someone finding a counter-example to make this text seem irresponsible. Since the existing text has this issue, I lean towards "accepting the risk" and emphasizing it's safe to submit information, but I'm curious @h-m-f-t's take. (Side note: detecting insecure form targets would be an excellent Spotlight candidate - though to be worthwhile it'd need to be checking more than root homepages of websites. cc @gbinal )

  • When we previously discussed the Krebs on Security piece, I pretty strongly disagreed with their take that "you are connecting to the official website" in the HTTPS part is wrong. This new version drops that point, which leaves its description of HTTPS incomplete. This new text describes the confidentiality and integrity aspects of HTTPS, but not authenticity. The authenticity part is basically why site owners are required to get their certificate from a trusted authority that is supposed to verify that the requester actually owns the domain name, since it's otherwise trivial for a website owner to "self-sign" a certificate and encrypt traffic with it. It's very similar to verifying to Google Webmaster Tools that you actually own the website you're trying to see data for, by adding a DNS record or uploading a text file or the like. That said, I'm not arguing to add text back in for its own sake, I recognize this is trying to simplify the copy and focus on the highest-value things. Perhaps this can be addressed implicitly by better communicating the combined value of .gov + HTTPS, which I think is the best way to respond to the point that Krebs on Security raised.

  • So, synthesizing all that together, a suggested reword: "A lock (🔒) or https:// means you've safely connected to the .gov website, and any information you submit is sent privately." This hits both safety and privacy, while connecting HTTPS to the use of the .gov name. And since it's next to the .gov text to its left, "the .gov website" makes sense in context.

  • And if we did want to hedge on HTTPS submission, one possible rewording idea that is at least more technically bulletproof: "A lock (🔒) or https:// means you've safely connected to the .gov website. You should only share sensitive information over a secure connection."

@konklone
Copy link
Contributor

Just noting for those reading only over email, that I merged a subsequent comment into my larger one above, and made a bunch of edits to it. :)

@h-m-f-t
Copy link

h-m-f-t commented Jun 29, 2020

Thanks for the tag, @thisisdano.

I agree with @konklone on the awkwardness of "A website ending in .gov indicates it is an official U.S. government organization." I'm concerned with it for an additional reason. Recognizing your field of interest (and remit) is "federal government websites", I'm concerned the text perpetuates the common but incomplete notion that .gov is for "U.S. government organization(s)", which I suspect most people will read as "U.S. *G*overnment organization(s)". This misread leaves people with a substantially limited view of what .gov is, since 80% of .gov domains are registered by non-USG US-based city, county, Native American, territorial, or state governments.

For me, this connotation leads to negative outcomes in and outside the USG.

  • Inside, and especially among cybersecurity teams, .gov is treated as solely a USG responsibility, and ".gov" gets used as shorthand for "the sum of networks and systems under our control" – or, worse, the network/system under our control. Reduced down to a single thing, folks (who should know better) oversimplify the complexity involved and dream up threat models that don't account for reality.
  • Outside, you see this incorrect notion reflected in e.g., a number of news clips covering last week's .gov preloading announcement, where the announcement is treated as mostly local to "federal websites", which is incorrect (FCW, Cyberscoop).

On mixed content (where HTTP resources are embedded in HTTPS content), I agree that this language doesn't make it worse. I think there's value in making the text resilient to mixed content cases, but I think this is headed that way since users will see something other than a standalone 🔒 or https:// in their browser. (FWIW, I saw at least 3 mixed content warnings on federal .gov sites last week. We have work to do!)

I like @konklone's suggested reword, but I would also be happy to see both elements continue to stand alone as long as it's clear both elements together constitute "how you know" something is official.

@buckaroogeek
Copy link

buckaroogeek commented Jun 29, 2020

Good morning from Oregon. - Eric, Cameron - good to see your names again from the security listserve. I retired last December. A couple of thoughts on the 'Here is how you know' drop down.

It seems to me that someone reading this text is doing so in the context of a specific web site (e.g. www.fs.usda.gov - my former agency). The banner text is phrased to target federal (or .gov) web sits more generally. Perhaps it would be beneficial to have templated text that the agency web master would modify for their use for that agency.

For example the template might be: title "The xxxx.gov means it's official". supporting text: "All XXXX [department | agency | bureau] web sites end in [.gov | .mil]. Before sharing sensitive information with this agency, make sure you are on an [department } agency | bureau] site."

And the agency web site might display: "The fs.usda.gov means it's offical.", and " All US Forest Service web sites end in fs.usda.gov. Before sharing information with the agency, make sure you are on an agency site."

Some slight modification to the https/lock banner could be made to reference the specific agency or site.

Brad Smith

@thisisdano
Copy link
Member Author

thisisdano commented Jun 29, 2020

Hi everyone (and also good morning [EDIT: afternoon!] from Oregon!). This is all very useful feedback. Thank you for your continued commitment to this issue.

@konklone You make good points about HTTPS, and I think your edits are clear improvements to correctness, completeness, and syntax.

@h-m-f-t Do you think that these changes worsen confusion over the scope of .gov? (That is, is this language more confusing than the existing language?) While we've developed this banner for federal sites (which I read in your comment as capital-G Government sites), the information should still be broadly accurate. Is there anything we might say in a component like this that would help?

@buckaroogeek I appreciate the sentiment here, but I am concerned about opening up the language to interpretation and customization. While I think that specificity could help clarify in individual specific situations, it's important that this banner give a consistent message from usage to usage, across sites and agencies — that the pedagogic role of the banner is best supported by consistent, universal usage and language.


Does this feel like an appropriate synthesis of your comments?

Official websites use .gov Secure .gov websites use HTTPS
A website ending in .gov belongs to an official U.S. government organization. A lock (:lock:) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.

I would like to work to an acceptable synthesis here, then bring it back for some additional internal review.

@h-m-f-t
Copy link

h-m-f-t commented Jun 30, 2020

Do you think that these changes worsen confusion over the scope of .gov?

If not worsen, they maintain a pattern that oversimplifies in a way that is detrimental to clarity.

On my end, the sole offending phrase is "U.S. government organization". I'm concerned that this language, even if only deployed on federal government websites, perpetuates the notion that .gov is used only in the US Government. But I think if you flipped the language around it would be more accurate and less likely to be misinterpreted, albeit slightly longer:

A website ending in .gov belongs to an official government organization in the U.S.

@wslack
Copy link

wslack commented Jun 30, 2020

Thanks for tagging.

"website ending in .gov" - this could confuse in two ways. First, web addresses often have the .gov in the middle if someone is linked to agency.gov/leadership or something. Second, the "web address" and the "website" are different. (we might have had this discussion in the past, full disclosure

I would instead say either:

  • A .gov website belongs to an official U.S. government organization.

Or

  • A web domain ending with .gov belongs to an official U.S. government organization.

@konklone
Copy link
Contributor

konklone commented Jun 30, 2020

"website ending in .gov" - this could confuse in two ways. First, web addresses often have the .gov in the middle if someone is linked to agency.gov/leadership or something. Second, the "web address" and the "website" are different. (we might have had this discussion in the past, full disclosure

I appreciate the distinction, but I think most people don't know what a "domain" is, and browsers have evolved over the last several years to emphasize the domain and de-emphasize the path so that people don't have to. I went and took some screenshots just now in some major browsers:

Firefox:
image

Edge (the new Chromium-based version):
image

Chrome:
image

I don't have Safari handy to screenshot, but they are the most restrictive and don't show the full URL at all right now. People publish guides for power users on how to enable full URL view, but most people won't do that.

Without commenting beyond what's public, I'll also link to a Chrome bug tracking some work on simplified domain display.

So, given all of that, I think it is imperfect-but-safe to say "ending in .gov", and overall the simplest way to describe it.

And on @h-m-f-t's prior comment:

On mixed content (where HTTP resources are embedded in HTTPS content), I agree that this language doesn't make it worse. I think there's value in making the text resilient to mixed content cases, but I think this is headed that way since users will see something other than a standalone 🔒 or https:// in their browser. (FWIW, I saw at least 3 mixed content warnings on federal .gov sites last week. We have work to do!)

I don't think we need to rabbit hole on it too much here, as I think the proposed language accommodates this just fine, but I wasn't referring to "mixed content" as it's currently implemented in browsers in the sense of embedded resources. I meant insecure form targets, meaning that the form was delivered securely, but submits data to the website in plaintext at submit-time. This is a security risk that (like mixed content) descends from the legacy unencrypted web, but that (unlike mixed content) I'm not aware of any browser currently surfacing to the user in any way. Hopefully that will change over time, but just wanted to clear this up for anyone reading the thread.

@konklone
Copy link
Contributor

konklone commented Jun 30, 2020

Also, to @h-m-f-t's wording suggestion:

A website ending in .gov belongs to an official government organization in the U.S.

I support this change - it is very slightly wordier but much more obviously inclusive of non-federal governments. There is a huge push to get non-federal governments to use .gov domains, particularly since federal elections are primarily administered by state and local governments and we want the public to have an easier time telling official sources from unofficial sources.

(The same change wouldn't need to be made to .mil, of course.)

@h-m-f-t
Copy link

h-m-f-t commented Jul 1, 2020

Dropping “ending in”, I could also go for:

A .gov website belongs to an official government organization in the U.S.

Thanks for taking the time to solicit feedback, @thisisdano!

@buckaroogeek
Copy link

buckaroogeek commented Jul 1, 2020 via email

@thisisdano
Copy link
Member Author

This has been a useful discussion and I'm pleased that we're making meaningful progress. Thank you all so much. I'd like to propose some new updates:

Official websites use .gov Secure .gov websites use HTTPS
A .gov website belongs to an official government organization in the United States. A lock (:lock:) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.
Official websites use .mil Secure .mil websites use HTTPS
A .mil website belongs to an official U.S. Department of Defense organization. A lock (:lock:) or https:// means you've safely connected to the .mil website. Share sensitive information only on official, secure websites.

Do you find this to be an accurate synthesis of your proposals?

@h-m-f-t
Copy link

h-m-f-t commented Jul 1, 2020

This works for me, and I like the expansion of U.S. (though that's captured in the banner if any more concessions to char count are needed).

👏 🇺🇸

@buckaroogeek
Copy link

buckaroogeek commented Jul 1, 2020 via email

@konklone
Copy link
Contributor

konklone commented Jul 2, 2020

I like these. But now I have one small quibble with the .mil text! There is in fact one non-DoD .mil website, the Coast Guard which is a component of DHS:

https://www.uscg.mil

I feel like there were a few other weird anomalies, but I no longer remember them - that's the only one I recall off the top of my head.

@konklone
Copy link
Contributor

konklone commented Jul 2, 2020

To offer a suggestion for the .mil text that is likely safe to run with:

A .mil website belongs to an official U.S. military organization.

@thisisdano
Copy link
Member Author

We were drawing our .mil guidance from this DoD guidance publication (specifically, page 6) — understanding that there are almost always some quirks. That said, I'd feel comfortable with A .mil website belongs to an official U.S. military organization.

@wslack
Copy link

wslack commented Jul 4, 2020

👍 to the updated version. FWIW, @konklone convinced me that "ending in .gov" is also ok, but unless scam sites routinely have .gov.com domains, I think the new version is good! Thank you!

@konklone
Copy link
Contributor

konklone commented Jul 4, 2020

We were drawing our .mil guidance from this DoD guidance publication (specifically, page 6) — understanding that there are almost always some quirks.

Nice find! And yeah, totally understand that nothing will be 100.0% perfect when it's aiming to be pithy and accessible to laypersons.

👍 to the updated versions either way. Thanks for leading a productive discussion and for pushing this forward!

Copy link
Contributor

@afeijoo afeijoo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@thisisdano
Copy link
Member Author

This PR commits the following banner copy. Thanks everyone for helping us improve this important component!

.gov domains

Official websites use .gov Secure .gov websites use HTTPS
A .gov website belongs to an official government organization in the United States. A lock (🔒) or https:// means you've safely connected to the .mil website. Share sensitive information only on official, secure websites.

.gov domains (Spanish)

Los sitios web oficiales usan .gov Los sitios web seguros .gov usan HTTPS
Un sitio web .gov pertenece a una organización oficial del Gobierno de Estados Unidos. A lock (🔒) or https:// significa que usted se conectó de forma segura a un sitio web .gov. Comparta información sensible sólo en sitios web oficiales y seguros.

.mil domains

Official websites use .mil Secure .mil websites use HTTPS
A .mil website belongs to an official U.S. Department of Defense organization. A lock (🔒) or https:// means you've safely connected to the .mil website. Share sensitive information only on official, secure websites.

.mil domains (Spanish)

Los sitios web oficiales usan .mil Los sitios web seguros .mil usan HTTPS
Un sitio web .mil pertenece a una organización oficial del Departamento de Defensa de EE. UU. A lock (🔒) or https:// significa que usted se conectó de forma segura a un sitio web .mil. Comparta información sensible sólo en sitios web oficiales y seguros.

@thisisdano thisisdano merged commit ecf0925 into update-banner Jul 8, 2020
@thisisdano thisisdano deleted the dw-update-banner-text branch July 8, 2020 04:37
@thisisdano
Copy link
Member Author

Note: A copy/paste error of mine resulted in the wrong text getting into the final PR. I fixed it in d54e6a3 and we will release with the proper text. Sorry for any confusion!

@wslack
Copy link

wslack commented Jul 8, 2020

<3

@miklb
Copy link

miklb commented Jul 9, 2020

Found this thread through a tweet, and was curious if for .gov it should read means you've safely connected to the .mil website.

@wslack
Copy link

wslack commented Jul 9, 2020

@miklb it's done with a variable here: d54e6a3

@konklone
Copy link
Contributor

There is a typo above in @thisisdano's comment that @miklb might have been referring to:

image

But yeah, in the actual commit, it's done through a variable and should be right.

@thisisdano
Copy link
Member Author

Yes, this has been a bit of a copy/paste nightmare, but the documented versions on https://designsystem.digital.gov/components/banner/ and in the codebase are correct. But that typo made its way into the release notes and I’ve now updated it there as well: https://github.com/uswds/uswds/releases/tag/v2.8.0

@miklb
Copy link

miklb commented Jul 10, 2020

hey y'all, indeed I was reading from the message, and checking the subsequent commit from my phone for the typo, I didn't catch that was what was fixed.

Thanks for the prompt and courteous replies. And more importantly, thank you for your service.

@wslack
Copy link

wslack commented Jul 10, 2020

@miklb It's a pleasure to serve - thank you for the note!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants