Seek to detect and prevent misuse, and poor use, of the service

[RichardTaylor]

See more specific tickets

• Detect personal correspondence and deter misuse of services to send such correspondence Detect personal correspondence and deter misuse of services to send such correspondence #6001
• Warn user when their new request is too wordy Warn user when their new request is too wordy #4987

There may be more we can do eg.

• Detect correspondence which asks for an opinion / view rather than the release of information
• Require admin authorisation for very long requests.

Perhaps there are key phrases which should never be in FOI requests?

Lots of site administration time and effort on WhatDoTheyKnow relates to poor quality requests, many bordering on misuse of the service and of FOI. The more we can do to deter and prevent such requests the better.

[RichardTaylor]

The presence of the text "my 999 call" for example could prompt a strong warning not to make subject access requests in public.

[RichardTaylor]

See WDTK request 898484. I'm not linking to it or mentioning its subject to avoid drawing attention to less than ideal use of the service.

We have an issue with multiple people making the essentially same request to the same body.

This is particularly an issue in this case as they appear to be using FOI to investigate some misinformation / non-mainstream theory which might mean WDTK is getting traffic related to that subject.

Ultimately the requests result in a useful explanation of the situation from the public body, so in that respect this is a great use of FOI and WDTK.

Already the other previous requests will come up under "Possible related requests" on the request submission form, but users proceed to make their own.

What more can be done to deter people making their own requests on this subject, and point them to one of the many existing responses? A note on the body page may be counterproductive, and give undue prominence to this issue.

If we had a generic version of

• Detect personal correspondence and deter misuse of services to send such correspondence #6001

we could trigger a special warning / advice note based on the presence of a keyword/phrase.

[garethrees]

we could trigger a special warning / advice note based on the presence of a keyword/phrase

We now have Notes, which are pretty generic and can operate by tag. I think we could re-use these during the request → preview flow. The workflow would go like:

• Submit request for preview
• Check a hash of terms and apply any associated tags
• Render the preview page, with a new section containing notes based on the applied tags

The code would go something like:

# Controller
def preview
  detect_taggable_terms
  # … 
end

def detect_taggable_terms
  InfoRequest.taggable_terms.each_pair do |term, tag|
    # Or ideally apply the tag to the message if we can handle that
    @info_request.apply_tag(tag) if @outgoing_message.body =~ Regexp.new(term)
  end
end

# Configurable attribute somewhere (could be on the model, or could 
# extract InfoRequest::PreviewController and add the accessor to that).
# Not sure I like "taggable_terms" as a name but can think about that
# later.
class InfoRequest
    cattr_accessor :taggable_terms, default: {}
end

# Customise your terms & tags in theme
# term => tag
InfoRequest.taggable_terms = {
  'Some foo term' => 'preview_warning:foo',
  'I want bar' => 'preview_warning:bar',
}

[garethrees]

We now have Notes…

Here's a quick proof of concept.

First, some quick code tweaks. This just applies the trains tag if the message body contains the word "train", and renders notes on the preview page:

diff --git a/app/controllers/request_controller.rb b/app/controllers/request_controller.rb
index fdfb7866d..8bf46fb73 100644
--- a/app/controllers/request_controller.rb
+++ b/app/controllers/request_controller.rb
@@ -252,6 +252,10 @@ def new
       return
     end

+    if @outgoing_message.body =~ /train/
+      @info_request.add_tag_if_not_already_present('trains')
+    end
+
     # Show preview page, if it is a preview
     return render_new_preview if params[:preview].to_i == 1

diff --git a/app/views/request/preview.html.erb b/app/views/request/preview.html.erb
index 3f8ea1df4..9c6a3960c 100644
--- a/app/views/request/preview.html.erb
+++ b/app/views/request/preview.html.erb
@@ -10,6 +10,8 @@

   <div class="message-preview">
     <div class="preview-advice">
+      <%= render_notes(@info_request.all_notes) %>
+
       <div class="advice-panel">
         <ul>
           <li><%= _('Check you haven\'t included any <strong>personal information</strong>.') %></li>

Then, create a Note that applies to the trains tag:

When the request is submitted, we identify the content in the message body, apply the tag, and then render the appropriate note. Tada 🎉.

Of course, it's never that easy. Currently we display any tags applied to a to-be-created request to the user, which doesn't feel appropriate in this situation.

Some issues we'd want to consider alongside this:

• Add prominence to tags #7954 Prominencable Tags #8224 – perhaps we could apply a requester_only tag for these warning notes, and only render normal tags if they've been created through the URL params
• Add prominence to Note #7564 – or we could stick with public tags, exclude any "warning" ones from the rendered list on the preview page, and then show a requester only note so that the note doesn't get shown after the creation of the request (as the tag will be persisted on creation). Alternatively, we could remove any warning tags on creation.
• Add Note#style #7771 – the blue notes look too informative; in this case I'd want to use red or yellow.

[garethrees]

I had a brainwave! We can apply the tags to the OutgoingMessage rather than the InfoRequest and therefore avoid the issue with showing the (mis)user the tag we're using.

Here's a similar diff:

diff --git a/app/controllers/request_controller.rb b/app/controllers/request_controller.rb
index fdfb7866d..fd5904998 100644
--- a/app/controllers/request_controller.rb
+++ b/app/controllers/request_controller.rb
@@ -252,6 +252,10 @@ def new
       return
     end
 
+    if @outgoing_message.body =~ /train/
+      @outgoing_message.add_tag_if_not_already_present('trains')
+    end
+
     # Show preview page, if it is a preview
     return render_new_preview if params[:preview].to_i == 1
 
diff --git a/app/models/outgoing_message.rb b/app/models/outgoing_message.rb
index 80a489226..674ee6fe3 100644
--- a/app/models/outgoing_message.rb
+++ b/app/models/outgoing_message.rb
@@ -29,6 +29,7 @@ class OutgoingMessage < ApplicationRecord
   include MessageProminence
   include Rails.application.routes.url_helpers
   include LinkToHelper
+  include Notable
   include Taggable
 
   STATUS_TYPES = %w(ready sent failed).freeze
diff --git a/app/views/request/preview.html.erb b/app/views/request/preview.html.erb
index 3f8ea1df4..2d789b4cb 100644
--- a/app/views/request/preview.html.erb
+++ b/app/views/request/preview.html.erb
@@ -10,6 +10,8 @@
 
   <div class="message-preview">
     <div class="preview-advice">
+      <%= render_notes(@outgoing_message.all_notes) %>
+
       <div class="advice-panel">
         <ul>
           <li><%= _('Check you haven\'t included any <strong>personal information</strong>.') %></li>

This has the same effect now that we've tweaked which notes get rendered:

Even better, the tag is persisted when the request gets created, so we could use this to get some insight into which outgoing messages the tag was applied (and therefore notes shown) and sent anyway.

Obviously the above diff just covers a single example case. I think we could make a generic system pretty easily:

# Core
module TaggableTerms
  extend ActiveSupport::Concern

  included do
    # TODO: could use a method to validate data structure format
    attr_accessor :taggable_terms,
                  instance_reader: true,
                  instance_writer: false,
                  instance_accessor: false,
                  default: {}

    # https://github.com/ronna-s/on_change
    # Set a callback up update the taggable terms when a configured
    # attribute changes
    taggable_terms.each do |attr, _|
      on_change attr, :update_taggable_terms
    end
  end

  def update_taggable_terms(attr, _old_value, _new_value)
    taggable_terms(attr).each do |tag, term|
      if read_attribute(attr) =~ Regexp.new(term)
        add_tag_if_not_already_present(tag)
      else
        remove_tag(tag)
      end
    end
  end
end

class OutgoingMessage
  include TaggableTerms
end

# Theme
OutgoingMessage.taggable_terms = {
  body: {
    foo: 'bar',
    abc: /abc/i
  }
}

[garethrees]

# TODO: could use a method to validate data structure format

e.g:

class SomeRecord
  # Allow each attribute to be configured with specific taggable terms
  taggable_terms :title, {
    foo: 'bar' 
  }

  taggable_terms :body, {
    foo: 'bar',
    abc: /abc/i
  }

  # Allow multiple attributes if you want the same terms for all
  taggable_terms [:title, :body], {
    foo: 'bar',
    abc: /abc/i
  }
end

[garethrees]

Linking to #7302 – we'd want to think about whether using this mechanism to render warnings and then also presenting that warning in public would be what we always wanted.

[garethrees]

Linking to some themes that we could use to test this out.

[garethrees]

Linking to #7302 – we'd want to think about whether using this mechanism to render warnings and then also presenting that warning in public would be what we always wanted.

Would be possible after #8224.

[garethrees]

This is desirable, but unlikely to be worked on in the next 12 months so closing for now.