18F / pulse

How the federal .gov domain space is doing at best practices and policies.
Other
94 stars 56 forks source link

fs.fed.us in the DAP list? #699

Open tdlowden opened 7 years ago

tdlowden commented 7 years ago

fs.fed.us is appearing in the DAP list as not implemented. It is not a second-level domain, so I'm not sure why it's there. It actually is, in fact, implemented with DAP, but I think because the report used to compare on the Pulse denominator specifies second-level domains only, it is not appearing as implemented. Can we remove it, or should I add it to the ineligible domains yml?

screen shot 2017-05-04 at 3 34 24 pm

konklone commented 7 years ago

fs.fed.us is actually a second level domain, as .fed.us is part of the Public Suffix List, which the web browser and internet community use to manage "effective" suffixes that people register domains at. (Similarly, .co.uk is a public suffix.)

So .fed.us is effectively the same as .gov, and (confusingly) the 6-7 registered .fed.us domains appear in the .gov domain list.

If it's appearing as not implemented, there might be some issue where Pulse's code isn't correctly dealing with public suffixes, or there could be some general issue that happens to impact fs.fed.us.

tdlowden commented 7 years ago

@konklone that's interesting. In that case, I am sure the reason it's not appearing as implemented is because the logic for the DAP report is literally asking for a hostname with one dot. Can we manually override Fs.fed.us to reflect their implementation?

konklone commented 7 years ago

The system we have for manual overrides for DAP is only for eligibility, not for the actual result.

Did you identify code that is literally asking for a hostname with one dot?

tdlowden commented 7 years ago

The Regex used to create https://analytics.usa.gov/data/live/second-level-domains.csv, which Pulse uses to compare against its complete list for DAP compliance, is ^[^\.]+\\.[^\.]+$, which eliminates anything with more than one dot.

Theoretically, we could use ^[^\.]+\.fed\.us$|^[^\.]+\.[^\.]+$, but that gets a bit gnarly and it'd be making a weird exception.

Is it not possible to adjust this without adding a one-off fix in our ongoing second-level-domains report?

konklone commented 7 years ago

We could allow the use of a custom regex string in the JSON that specifies each report, rather than hardcoding just one regex in the JS code.

tdlowden commented 7 years ago

I don't think I was ever entertaining changing anything in the JS. It makes sense that we could alter the JSON report query to ^[^\.]+\.fed\.us$|^[^\.]+\.[^\.]+$. Was just wondering if there were other options. cc: @jmhooper

konklone commented 7 years ago

@tdlowden Sorry, I meant back-end JS (as in the Node code of analytics-reporter), not the front-end JS snippet that DAP uses to report in data.

tdlowden commented 7 years ago

Surfacing this again. Is there a path you all want to follow here? Or, manually add fs.fed.us as implemented?