Du kan inte välja fler än 25 ämnen Ämnen måste starta med en bokstav eller siffra, kan innehålla bindestreck ('-') och vara max 35 tecken långa.

consent_tracking.md 7.2 KiB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197
  1. Support in Synapse for tracking agreement to server terms and conditions
  2. ========================================================================
  3. Synapse 0.30 introduces support for tracking whether users have agreed to the
  4. terms and conditions set by the administrator of a server - and blocking access
  5. to the server until they have.
  6. There are several parts to this functionality; each requires some specific
  7. configuration in `homeserver.yaml` to be enabled.
  8. Note that various parts of the configuration and this document refer to the
  9. "privacy policy": agreement with a privacy policy is one particular use of this
  10. feature, but of course administrators can specify other terms and conditions
  11. unrelated to "privacy" per se.
  12. Collecting policy agreement from a user
  13. ---------------------------------------
  14. Synapse can be configured to serve the user a simple policy form with an
  15. "accept" button. Clicking "Accept" records the user's acceptance in the
  16. database and shows a success page.
  17. To enable this, first create templates for the policy and success pages.
  18. These should be stored on the local filesystem.
  19. These templates use the [Jinja2](http://jinja.pocoo.org) templating language,
  20. and [docs/privacy_policy_templates](https://github.com/matrix-org/synapse/tree/develop/docs/privacy_policy_templates/)
  21. gives examples of the sort of thing that can be done.
  22. Note that the templates must be stored under a name giving the language of the
  23. template - currently this must always be `en` (for "English");
  24. internationalisation support is intended for the future.
  25. The template for the policy itself should be versioned and named according to
  26. the version: for example `1.0.html`. The version of the policy which the user
  27. has agreed to is stored in the database.
  28. Once the templates are in place, make the following changes to `homeserver.yaml`:
  29. 1. Add a `user_consent` section, which should look like:
  30. ```yaml
  31. user_consent:
  32. template_dir: privacy_policy_templates
  33. version: 1.0
  34. ```
  35. `template_dir` points to the directory containing the policy
  36. templates. `version` defines the version of the policy which will be served
  37. to the user. In the example above, Synapse will serve
  38. `privacy_policy_templates/en/1.0.html`.
  39. 2. Add a `form_secret` setting at the top level:
  40. ```yaml
  41. form_secret: "<unique secret>"
  42. ```
  43. This should be set to an arbitrary secret string (try `pwgen -y 30` to
  44. generate suitable secrets).
  45. More on what this is used for below.
  46. 3. Add `consent` wherever the `client` resource is currently enabled in the
  47. `listeners` configuration. For example:
  48. ```yaml
  49. listeners:
  50. - port: 8008
  51. resources:
  52. - names:
  53. - client
  54. - consent
  55. ```
  56. Finally, ensure that `jinja2` is installed. If you are using a virtualenv, this
  57. should be a matter of `pip install Jinja2`. On debian, try `apt-get install
  58. python-jinja2`.
  59. Once this is complete, and the server has been restarted, try visiting
  60. `https://<server>/_matrix/consent`. If correctly configured, this should give
  61. an error "Missing string query parameter 'u'". It is now possible to manually
  62. construct URIs where users can give their consent.
  63. ### Enabling consent tracking at registration
  64. 1. Add the following to your configuration:
  65. ```yaml
  66. user_consent:
  67. require_at_registration: true
  68. policy_name: "Privacy Policy" # or whatever you'd like to call the policy
  69. ```
  70. 2. In your consent templates, make use of the `public_version` variable to
  71. see if an unauthenticated user is viewing the page. This is typically
  72. wrapped around the form that would be used to actually agree to the document:
  73. ```html
  74. {% if not public_version %}
  75. <!-- The variables used here are only provided when the 'u' param is given to the homeserver -->
  76. <form method="post" action="consent">
  77. <input type="hidden" name="v" value="{{version}}"/>
  78. <input type="hidden" name="u" value="{{user}}"/>
  79. <input type="hidden" name="h" value="{{userhmac}}"/>
  80. <input type="submit" value="Sure thing!"/>
  81. </form>
  82. {% endif %}
  83. ```
  84. 3. Restart Synapse to apply the changes.
  85. Visiting `https://<server>/_matrix/consent` should now give you a view of the privacy
  86. document. This is what users will be able to see when registering for accounts.
  87. ### Constructing the consent URI
  88. It may be useful to manually construct the "consent URI" for a given user - for
  89. instance, in order to send them an email asking them to consent. To do this,
  90. take the base `https://<server>/_matrix/consent` URL and add the following
  91. query parameters:
  92. * `u`: the user id of the user. This can either be a full MXID
  93. (`@user:server.com`) or just the localpart (`user`).
  94. * `h`: hex-encoded HMAC-SHA256 of `u` using the `form_secret` as a key. It is
  95. possible to calculate this on the commandline with something like:
  96. ```bash
  97. echo -n '<user>' | openssl sha256 -hmac '<form_secret>'
  98. ```
  99. This should result in a URI which looks something like:
  100. `https://<server>/_matrix/consent?u=<user>&h=68a152465a4d...`.
  101. Note that not providing a `u` parameter will be interpreted as wanting to view
  102. the document from an unauthenticated perspective, such as prior to registration.
  103. Therefore, the `h` parameter is not required in this scenario. To enable this
  104. behaviour, set `require_at_registration` to `true` in your `user_consent` config.
  105. Sending users a server notice asking them to agree to the policy
  106. ----------------------------------------------------------------
  107. It is possible to configure Synapse to send a [server
  108. notice](server_notices.md) to anybody who has not yet agreed to the current
  109. version of the policy. To do so:
  110. * ensure that the consent resource is configured, as in the previous section
  111. * ensure that server notices are configured, as in [the server notice documentation](server_notices.md).
  112. * Add `server_notice_content` under `user_consent` in `homeserver.yaml`. For
  113. example:
  114. ```yaml
  115. user_consent:
  116. server_notice_content:
  117. msgtype: m.text
  118. body: >-
  119. Please give your consent to the privacy policy at %(consent_uri)s.
  120. ```
  121. Synapse automatically replaces the placeholder `%(consent_uri)s` with the
  122. consent uri for that user.
  123. * ensure that `public_baseurl` is set in `homeserver.yaml`, and gives the base
  124. URI that clients use to connect to the server. (It is used to construct
  125. `consent_uri` in the server notice.)
  126. Blocking users from using the server until they agree to the policy
  127. -------------------------------------------------------------------
  128. Synapse can be configured to block any attempts to join rooms or send messages
  129. until the user has given their agreement to the policy. (Joining the server
  130. notices room is exempted from this).
  131. To enable this, add `block_events_error` under `user_consent`. For example:
  132. ```yaml
  133. user_consent:
  134. block_events_error: >-
  135. You can't send any messages until you consent to the privacy policy at
  136. %(consent_uri)s.
  137. ```
  138. Synapse automatically replaces the placeholder `%(consent_uri)s` with the
  139. consent uri for that user.
  140. ensure that `public_baseurl` is set in `homeserver.yaml`, and gives the base
  141. URI that clients use to connect to the server. (It is used to construct
  142. `consent_uri` in the error.)