Make Landing Page scan a pre-requisite for submitting directory listing?

[rocodes]

Hi all,

As we transition to v3 onion services, the idea of onion names will be more and more appealing, and we're hopefully going to get more requests for directory listings and onion names as a result (already happening in modest numbers).

In order to get instances listed more quickly and also reduce support burden (corresponding explaining landing page guidelines etc), it could be a good idea to allow (or require?) instances to try a scan before submitting a directory listing. There seems to be a lack of clarity about implementing the guidelines, or a lack of transparency that the 'guidelines' are actually requirements before being listed in the directory, and a fair amount of time is spent corresponding with instances and their web teams to get them into compliance before approving their listing.

This might require a few UI tweaks to indicate which criteria are required (e.g. CSP, HSTS, Referrer Policy) and which ones are preferred but not required.

[harrislapiroff]

Ooooh, this is an interesting idea. We'd have to think at least a little carefully about how to implement it since a scan can be quite resource consuming and we definitely don't want someone just hammering our server requesting scans, but I like it as a concept! Maybe with a rate limit and possibly a captcha, this could work?

@eloquence, what do you think?

[eloquence]

I like the idea as well. I would suggest implementing in stages:

• only on staging site
• as a standalone page linked to from the submission form
• (potentially) integrated with the submission form

@rocodes If you'd like to help move this forward, I think prioritizing the information we'd want to surface would be the next step to make this ticket more actionable.

[rocodes]

Yes, I was also wondering about the rate-limiting or other anti-abuse strategies.

Here is the matrix we currently use to evaluate instances. In addition to this, we also scan sites (e.g. using SSLLabs) to ensure up-to-date cipher suites. The items with "E" (enforce) are the ones that we require, so I would say we should absolutely surface those (if they can be handled by the scanner and aren't a manual check), and then the rest of them are optional/improvements.

(So for clarity: things to surface for sure would be HSTS / HSTS details, CSP, Referrer policy; things that would be nice to surface would be checking for 3rd-party resources and scripts, scanning for hyperlinks to securedrop.org or to onion urls).

Security Feature	Expected Result	Actual Result	Pass/Fail	Severity
HTTPS on landing page	yes			E
Loads in Tor Browser	yes			E
Landing page on subdomain	no			S
Analytics scripts on landing page	no			E
Third party resources on landing page	None			E
Onion address	no direct link			E
Links to SecureDrop	no direct link, pointer only to .onion service			E
Privacy policy	Policy similar to our sample policy			P
Cookies	none (1st-party CDN-related cookies OK)			P
HSTS	set			E
HSTS Details	set			E
Header: CSP	includes default-src 'none'			P
Header: Referrer-policy	no-referrer			E
Header: X-XSS-Protection	set to 1; mode=block			P
Header: X-Frame-Options	DENY			P
Header: X-Permitted-Cross-Domain-Policies:	master-only			P
Header: Pragma	no-cache			P
Header: Cache-control	max-age=0, no-cache, no-store, must-revalidate			P
Header: X-Content-Type-Options	nosniff			P
Header: X-Download-Options	noopen			P

---

Legend: Severity of Issues [E]nforce : we refuse to list the page on our directory unless these things are fixed [P]refer : we recommend these things be fixed, but will still list on our directory [S]pecial : case-by-case exceptions will be allowed, otherwise enforce changes

---

[eloquence]

Discussed in Web Team Office Hours today:

• @rocodes, if you've already made improvements to the scanner or scan results logic that could be turned into a PR, that would be awesome :)
• For now we agreed that we'd aim to make it easier to run the scanner against a landing page without adding a directory entry. In the spirit of quick iteration, we'll leave it up to the person doing this whether this would be via CLI invocation, or a form in /admin.
  • A next step would be to refactor the results to be more in line with the support team's pass/fail matrix.
• A newsroom-facing UI for scanning their own landing pages will be a bit harder to build, but is a candidate for medium-sized projects the team will pick up in the next quarter or two.