Draft: [design-document] Reporting problem content

[jayaddison]

Design Document: Reporting problem content

Objective

There are multiple reasons that users of RecipeRadar may want to report problems with search results from the service.

The goal of this document is to provide a technical design specification that caters to the known use cases and can be implemented in software.

Use cases

We have identified three situations in which problematic search results should be reportable by users:

• Owner assertions: where the owner of a recipe would prefer for the recipe not to be displayed in RecipeRadar search results, we should allow them to request removal of their recipes.

• Unsafe content: although we try to be careful only to accept recipe webpages into the search index, ownership of domain names and the servers and logic that displays results to web users can change over time. A recipe URL that was previously perfectly safe may become corrupted, and we should allow users to report instances where this occurs.

• Corrections: there may be typos, parsing errors, or unit conversion problems in the content we have indexed into the search engine. We expect that some (but not all) users may take the time to offer corrections for those mistakes.

Observations

The use cases share some similarities, but there are some notable differences between them that imply that different workflows may be required for each:

• Owner assertions may require research effort by RecipeRadar staff, in order to confirm that the report was indeed made by a responsible owner of the content, and not, for example, by one of their or our competitors. Initially it does not seem that unsafe content reports or corrections should require the same level of identity verification.

• Unlike ownership assertions and corrections, reviewing unsafe content could incur an increased psychological risk for reviewers. The web, as-designed, allows for dynamic content delivery -- so different people can and do receive differing webpages when requesting the same URL, albeit usually the differences are marginal and inconsequential to their browsing experience.

• Corrections: these are in some sense similar to bugreports; they indicate a problem that can be traced back through our crawling, parsing and indexing pipeline to identify where the problem occurred. Some data issues may originate upstream (that is, the typo/problem is found in the original recipe webpage), and some may be in our software.

Design: user interface

An additional icon and text label (en:"Report a problem") will be placed near the 'star' / 'favourite' icon for each recipe search result.

On click, this will expand to offer three menu selections:

• Link contains unsafe content
• Please exclude my recipe(s)
• Offer a correction

The order of these is intentional: unsafe content could harm many users; unintended listing of content may be a significant economic concern but presence/absence on RecipeRadar does not, we believe, imply a likelihood of noticeable economic harm at our current web traffic levels; corrections are anticipated to be minor and rarely harmful (but even so, we may want to consider an 'important' flag or similar for them).

On click, each of these should request/display some slightly varying information:

• Link contains unsafe content:

  • Minimal information; perhaps only the nature of the unsafe content.

  • A reassurance message that we will review content and remove offending hyperlinks.

• Please exclude my recipe(s):

  • Sufficient information to confirm the user's identity as owner of the content (see the 'Identity verification' section)

  • Confirmation of whether the removal request is solely for this individual recipe, or instead for all of their recipes (perhaps by typing a confirmation word).

• Offer a correction

  • What the user expected to see, and what the actual incorrect information that was displayed was.

  • A checkbox to indicate whether the correction is important/urgent.

  • An explanation that corrections may not appear immediately.

Identity verification

Some recipe websites host community recipes by multiple authors not directly employed or within the host organization. We should therefore anticipate that removal requests could be:

• From the recipe website owner, to remove all recipes related to their domain(s).
• From an individual recipe author, to remove their recipes hosted on particular website(s).

Some verification options for website owners include:

• An update to the relevant recipe webpages to add HTML noindex instructions, to affirm that the content is not to be indexed.
• Requesting the URL of a terms-and-conditions on the recipe website that explains that search engine usage (either generally, or by RecipeRadar) is prohibited.
• Receiving an authenticated (DKIM?) email from the same domain name as the recipe website with instructions to remove the content.

Some verification options for individual authors include:

• Requesting the URL of a profile page within the recipe website that explains that search engine usage (either generally, or by RecipeRadar) is prohibited.
• Receiving an authenticated (DKIM?) email that can be 1-1 linked to the author profile page on the recipe website.

Technical details

We anticipate the addition of a single POST /recipes/report endpoint to the api microservice to accept these reports.

Validation of CAPTCHA-style challenges is worth considering during implementation, but is not required for the initial rollout.

Out-of-scope

We may want to consider allowing poor quality search results to be reported by users in future, too - however, result quality is subjective and is a use case that can be catered to by the existing feedback function in the application (arguably, all of the above can; however, providing specific UI workflows may be easier for users, and may also assist us in demonstrating that our recipe search functionality is compliant with local regulations).

[jayaddison]

Alternatively: could we add a mailto: hyperlink to allow people to contact us about these problems? The initial volume of requests should be minimal, although arguably it would mean that we might be slightly less consistent about the way that we handle incoming reports (but I think that has to be expected, to some degree, anyway).

[jayaddison]

To respond to two separate items:

We may want to consider allowing poor quality search results to be reported by users in future, too - however, result quality is subjective and is a use case that can be catered to by the existing feedback function in the application (arguably, all of the above can; however, providing specific UI workflows may be easier for users, and may also assist us in demonstrating that our recipe search functionality is compliant with local regulations).

Alternatively: could we add a mailto: hyperlink to allow people to contact us about these problems? The initial volume of requests should be minimal, although arguably it would mean that we might be slightly less consistent about the way that we handle incoming reports (but I think that has to be expected, to some degree, anyway).

What's important, I think, is to implement Ofcom's recommended measures - I don't think RecipeRadar will want or have any reason to attempt to implement alternative measures; so we can instead read through the list of recommended measures and figure out which of those apply to us.

[jayaddison]

We anticipate the addition of a single POST /recipes/report endpoint to the api microservice to accept these reports.

Nitpick: we should add the recipe_id as a parameter to this URL path So I think it will be something like POST /recipes/<recipe_id/report (each report will be in relation to a specific recipe, so we can include the ID in the URL).