Re: [w3ctag/design-reviews] ads.txt (#201)

Up to date list of concerns, referencing the 1.0.1 version of the doc:

* This spec defines a well known, hard coded URL.  There is now a standard for placing these paths within a `.well-known` prefix, see https://tools.ietf.org/html/rfc5785
* The spec does not define the format using a formal syntax grammar, eg. ABNF, making it very hard to understand what would be valid examples of this format.  For example, there is no specification for which whitespace characters are acceptable as separators.  For examples of good grammar specifications, see https://www.w3.org/TR/tabular-data-model/
* The spec requires that the ads.txt file is published on a 'root domain'.  There is no technical definition of 'root domain' in web architecture, and sites with authority and control over an origin may reasonably not have control over the parent origin.
* The document specifies that ads.txt should be available on "HTTP and/or HTTPS".  This is enormously concerning, especially since some sites are moving away from listening for HTTP traffic at all, and suggesting the use of HTTP for any web specification should be considered contrary to the very principles of good web architecture and detrimental to the future development of the web.  See the TAG finding on [securing the web](https://www.w3.org/2001/tag/doc/web-https)
* The document contains a normative reference to w3schools regarding URL encoding, which is a site generally regarded as a poor source of information about the web, and certainly not a primary source on any subject.  On this point, https://tools.ietf.org/html/rfc3986 would be the correct normative reference.
* The doc indicates that crawlers should follow redirects within the same CNAME entry (although the language is woolly regarding "root domain"); e.g. it allows redirects between https://example.com and http://example.com, enabling downgrade of connection security.
* There appear to be additions for "SUBDOMAIN" which is a redirect type. It does not appear to be well-specified and it's unclear why redirects with an eTLD+1 policy aren't being used instead.
* Google has a system called [App links](https://support.google.com/webmasters/answer/6212023) and we are wondering why a mechanism like that is not appropriate for this use case.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/201#issuecomment-362284668