gov banner text on websites and HTTPS is inaccurate

konklone commented 7 years ago

Description

This text contains some inaccuracies (screenshot from https://tech.gsa.gov) -

The two big issues are -

Not every government websites ends in .gov or .mil. Besides .fed.us also being a valid "official" suffix, there are government websites that use .com and .org. For example, here's a list DHS keeps of theirs, and here's a (stale) dataset of other URLs kept by GSA. While OMB wants people to use .gov and .mil only, we can't tell users that all government websites use them.
The HTTPS certificate information says that the US government signed the certificate, which is not true. Commercial certificate authorities do that, and this will differ per-agency. In the case of tech.gsa.gov, Let's Encrypt signed the certificate. In addition, SSL is an outdated marketing term and not an accurate description of the certificate or protocol in use. I am also not sure what the reference to browsing history is for. I would like to rewrite this language entirely and refocus it.

Steps to reproduce the issue

Visit a site with the full banner.
Click the Here's how you know link in the banner.

Additional information [optional]

The relevant places with text seem to be:

shawnbot commented 7 years ago

Thank you for this, @konklone! For me this signals a need to refactor our header code and promote the banner as a discrete component. See #1596 for more info.

juliaelman commented 7 years ago

@konklone thanks for opening this issue! While @shawnbot works on the header refactor, let's schedule some time to pair and talk about how we can update the language.

juliaelman commented 7 years ago

Talked with the team and @konklone today about this. We will be removing the copy in the banner until we can come up with a more general solution for this guidance.

shawnbot commented 7 years ago

Thanks again to @konklone for pointing out that this copy is both wrong and (mostly) unnecessary because it describes properties of sites that users are already viewing. From here, my suggestion is to do the following:

Remove the button and expandable content from the headers (and remove a whole bunch of attendant CSS and JavaScript! 🎉)
Promote the banner to "component" status
Move the banner out of the header component and update our page templates accordingly
Move our guidance for promoting trust on government web sites (using HTTPS and, whenever possible, using .gov and .mil domains) to the new component page

juliaelman commented 7 years ago

Fixed in #1749 and will be part of the next release ✌️

carodew commented 7 years ago

Adding some context here – adding this detail text came from the FFD discovery research that indicated that folks don't know how to distinguish a government site from a spammer site, which is a big problem in some contexts. For example, private scammers who charge people for filling out the FAFSA, the free application for federal student aid. This text is intended to help folks understand how to recognize official, secure government sites. The banner text is also intended to help push agencies to use best practices (.gov domains, https). I'm sad to see you're moving away from supporting an identified and researched user need.

carodew commented 7 years ago

" (mostly) unnecessary because it describes properties of sites that users are already viewing."

Follow up – this is a bad assumption. People who know DO look for the dot gov and https to see if they can trust the site, the effort here is to help more people know to look for that.

Text tweaks could fix the problem with the minor inaccuracies.

jpyuda commented 7 years ago

Do not - I repeat, do not - remove this. If it's removed, put it back.

shawnbot commented 7 years ago

The current state of things is that we've removed this content, but that change has not been released to the public yet. It's easy to bring it back, but before we do I think we need to get a couple of things straight:

I understand that some people simply don't know how to verify the authenticity of government sites, but did we validate that this particular implementation taught them to do so? Because I'm skeptical that folks are clicking that link and reading all of that text, then retaining that information next time they go looking for government web services.

If so, I'm certainly open to bringing this back and fixing the language, in which case we have several distinct issues to address:

There are quite a few government sites that are not on .gov or .mil domains, so that text is misleading. Maybe it makes sense to say that "all .gov and .mil sites are [official blah blah blah]", rather than suggesting the inverse (that .com, .org, or .fed.us sites are not)?
The HTTPS text is misleading. First of all, there's nothing stopping somebody from putting this banner on a site served over HTTP. In fact, according to Pulse, 25% of government-owned domains do not use HTTPS.
The mention of "SSL" as opposed to HTTPS is wrong.

Given the difficulty in communicating the domain and security criteria both simply and accurately, I think it makes a lot more sense to have the "Here's how you know" button replaced with a link to an official URL where we can explain all of this stuff with more authority and nuance. What we've got now is an accumulating content debt situation in which we're embedding static content on hundreds of sites with no plan—or mechanism, besides expecting our users to copy and paste—to keep it up-to-date.

mariamarrero commented 7 years ago

Additional comments on text tweaks for the expandable link can be seen in ticket: https://github.com/18F/web-design-standards/issues/1748. We (folks at USAGov) will be trying to make updates to this text and keep it. Some data: Crazy Egg reports already show users interested in this link in USA.gov and GobiernoUSA.gov.

jpyuda commented 7 years ago

I'll put my comments over in #1748.

That said, I do think it's important, when requests like this come up, that we step back and make sure that we're serving user needs over agency desires. And by "users", I mean the general public. (More on this in the other thread as well.)

konklone commented 7 years ago

I'd like to re-open this, and now feel more strongly that this banner should just be removed from the USWDS ecosystem. Obviously, if individual sites like usa.gov want to continue using such a banner, they are free to, but I think it's proving unsustainable for the USWDS ecosystem to maintain and update accurate text about a key issue.

As of this comment, https://standards.usa.gov is still using the inaccurate text, and people are (quite reasonably) assuming that the version on https://standards.usa.gov is correct and copying it into new designs, further distributing the inaccurate text -- 7 months after I first raised the issue and we worked out more accurate text.

So I'll again ask that the team consider removing this text from the USWDS components altogether, as I think it is proving more harm than good.

jpyuda commented 7 years ago

I understand the concern here, and clearly the team needs to work on how they handle prioritization, but removal of this element would be a major concern to me.

This is one of the only (if not the only) user-driven addition to the standards in some time (we have clear research that points to why it's there), and if the Standards are going to be responsive only to stakeholder concerns and not address user needs, then I question why we continue the project at all.

konklone commented 7 years ago

I understand, but let's try to distinguish between what users want from government websites, and what the US Web Design Standards project can reasonably be asked to deliver with the quality users expect.

To be clear, I'm not trying to say it's a bad idea for a government website to show this text, or that downstream users like www.usa.gov should take down the accurate text that they are showing.

I'm saying that the USWDS project may not be set up in such a way (and it may not be reasonable to ask it to be set up in such a way) that it can satisfy this need as part of the Standards. It's one thing if the USWDS team can't rapidly get improvements in responsiveness or aesthetics out to its community in a consistent manner. Prominent inaccurate text like this could plausibly be made an issue by an agency's legal counsel or congressional oversight committee, which is the sort of thing that could really damage the USWDS project's reputation in the federal community.

There are other factors to weigh over what users say they need -- for example, even if federal developers asked for a central CDN to host USWDS assets for them (which was also suggested to potentially fix this text problem), the security and privacy ramifications would make it unlikely for it to be a responsible thing for the program to do. The team would have to change how it works and make a significant investment in a new and highly disciplined workflow to ensure that the security and privacy ramifications of that central hosting were worth the risks.

If the team makes a concerted effort, I'm sure they could go and get most/all of the downstream users of the USWDS to update their text to be accurate. But I think the fact that the inaccuracies made it out so far before relevant subject matter expertise was consulted, and the fact that it's been so challenging for so long to get it fixed, suggests that the project (in its current state, anyway) would find it easier to not be responsible for this kind of process going forward.

shawnbot commented 7 years ago

Obviously I don't have any say in this since I'm no longer on the team or in the federal government at all, but I feel like I need to say something here.

I'm 100% with @konklone on this one. I don't think that the Standards (or 18F) should be in the business of telling other agencies what content they can or should put on their sites. They can suggest everything from visual and functional patterns to voice, tone, and even specific language. But to say that the banner is this specific thing that federal sites need, with prescriptive (and inaccurate!) content, seems to me to overstep the responsibilities and boundaries of this project.

This is one of the only (if not the only) user-driven addition to the standards in some time (we have clear research that points to why it's there), and if the Standards are going to be responsive only to stakeholder concerns and not address user needs, then I question why we continue the project at all.

I'd appreciate being able to have a conversation about the language and purpose of a UI component without diving into hyperbole like this. But maybe it's a fair point: If the project can't withstand a reasonable challenge to "its only user-driven addition," then I'd say that's a pretty big problem. How the banner came to be is not, IMO, a good enough reason to saddle every USWDS user with its issues; and even removing it entirely (which is not what I would suggest) should not be the end of this project.

I'd suggest offering the banner as a customizable component with suggested language, and allow agencies to customize it to their needs. Some may choose to use it without the expandable content; others may opt for content that better suits their needs. You could even remove a bunch of JS and CSS by refactoring it to use native <details> element and the graphic list/media block styles.

donjo commented 7 years ago

FWIW the point @shawnbot brings up is basically the conclusion we came to when looking at how/if we should present the Password Reset Form. Instead of going down the rabbit hole of ever-changing best practices for password creation, the Standards are better suited to provide the styles for where the guidance/validation in the component should go but not pretend to be the authority for what they currently are or should be for your agency. In future versions of the documentation the text will be more clearly placeholder and we'll link to the appropriate places you can go to learn what your password reset guidance should actually look like.

maya commented 6 years ago

This issue is fixed here on the live site and fractal instance: https://standards.usa.gov/components/headers/ and https://federalist-proxy.app.cloud.gov/preview/18f/web-design-standards/develop/components/detail/banner.html. Since the issue around notifying folks with the inaccurate text is in #2093, closing this issue.

konklone commented 6 years ago

Thank you, @maya.

@donjo, did you want to continue discussing the maintenance topic here, or another thread, or to not continue?

uswds / uswds