Skip to content
This repository has been archived by the owner on Jun 10, 2020. It is now read-only.

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

Open
tdlowden opened this issue May 4, 2017 · 8 comments
Open

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

tdlowden opened this issue May 4, 2017 · 8 comments
Labels

Comments

@tdlowden
Copy link
Contributor

tdlowden commented May 4, 2017

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
Copy link
Contributor

konklone commented May 7, 2017

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
Copy link
Contributor Author

tdlowden commented May 7, 2017

@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
Copy link
Contributor

konklone commented May 8, 2017

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
Copy link
Contributor Author

tdlowden commented May 8, 2017

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
Copy link
Contributor

konklone commented May 8, 2017

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
Copy link
Contributor Author

tdlowden commented May 8, 2017

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
Copy link
Contributor

konklone commented May 8, 2017

@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
Copy link
Contributor Author

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

@konklone konklone added the bug label Apr 23, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants