From c08900e15d0abb78c72a5292cd04d70dd58cf955 Mon Sep 17 00:00:00 2001 From: Jorrit Nutma Date: Tue, 4 Nov 2025 15:28:54 +0100 Subject: [PATCH 1/3] Remove GA tracker because the cookieless solution did not work --- website/docusaurus.config.ts | 8 -------- website/static/js/load_tag.js | 23 ----------------------- 2 files changed, 31 deletions(-) delete mode 100644 website/static/js/load_tag.js diff --git a/website/docusaurus.config.ts b/website/docusaurus.config.ts index 4f500b0..c29bd7c 100644 --- a/website/docusaurus.config.ts +++ b/website/docusaurus.config.ts @@ -130,14 +130,6 @@ const config: Config = { } satisfies Preset.ThemeConfig, scripts: [ - { - src: "https://www.googletagmanager.com/gtag/js?id=G-1T0FLTHM3C", - async: true - }, - { - src: '/js/load_tag.js', - async: true - }, ], }; diff --git a/website/static/js/load_tag.js b/website/static/js/load_tag.js deleted file mode 100644 index f062435..0000000 --- a/website/static/js/load_tag.js +++ /dev/null @@ -1,23 +0,0 @@ -window.dataLayer = window.dataLayer || []; -function gtag(){dataLayer.push(arguments);} -gtag('js', new Date()); - -gtag('config', 'G-1T0FLTHM3C', { - 'storage': 'none', - 'client_storage': 'none', - 'cookie_flags': 'max-age=0;secure;samesite=none', - 'anonymize_ip': true - }); - -// var _paq = window._paq = window._paq || []; -// /* tracker methods like "setCustomDimension" should be called before "trackPageView" */ -// _paq.push(['disableCookies']); -// _paq.push(['trackPageView']); -// _paq.push(['enableLinkTracking']); -// (function() { -// var u="https://docs-s2standard.matomo.cloud/"; -// _paq.push(['setTrackerUrl', u+'matomo.php']); -// _paq.push(['setSiteId', '1']); -// var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0]; -// g.async=true; g.src='https://cdn.matomo.cloud/docs-s2standard.matomo.cloud/matomo.js'; s.parentNode.insertBefore(g,s); -// })(); \ No newline at end of file From 4fadc0e7634671c00410870d3d000ec41aadf896 Mon Sep 17 00:00:00 2001 From: Jorrit Nutma Date: Tue, 4 Nov 2025 15:58:58 +0100 Subject: [PATCH 2/3] Add brute-force protection note to security considerations --- website/docs/communication-layer/security-considerations.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/website/docs/communication-layer/security-considerations.md b/website/docs/communication-layer/security-considerations.md index 3592b5c..c0cdba0 100644 --- a/website/docs/communication-layer/security-considerations.md +++ b/website/docs/communication-layer/security-considerations.md @@ -160,7 +160,7 @@ SelfSignedCA --> LocalServerCertificate -### Trusting aself signed root certificate +### Trusting a self-signed root certificate The self signed root certificate is by default not trusted. However during the pairing phase, the server with the self signed root certificate will share part of the root's certificate fingerprint as part of the pairing token, via a second channel. This will enable the client to verify the self signed root certificate, and create trust. From this moment on, the client will store the complete fingerprint of the self signed root certificate, and use it to verify the server certificate for all future connections. @@ -172,6 +172,9 @@ A server can update its certificate. When a cloud server updates it's certificat If the server is in local-local mode, and uses a self-signed CA certificate, the CA certificate **SHOULD** be created with a validity period which is long enough for the expected lifetime of the server. If the used crypto for the the CA certificate is broken, or the lifetime of the server is longer than the validity of the certificate, the server **MUST** create a new self-signed CA certificate and all clients need to be paired again. Like cloud servers, a local server **SHOULD** update its server certificate at least once every 6 months. +## Brute-force protection +To prevent brute-force pairing request, the server MUST implement rate limiting on the requestPairing endpoint. It is up to the server implementation to define the type of rate limiting. + ## How are the requirements met? In the follow section, reasoning for each security requirement will be given. From 194ab51ff9106e6b89355f2c055b12f783e1e3c4 Mon Sep 17 00:00:00 2001 From: Jorrit Nutma Date: Tue, 4 Nov 2025 15:59:54 +0100 Subject: [PATCH 3/3] Fix link to cem-rm mapping to client-server node --- .../communication-layer/discovery-pairing-authentication.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/website/docs/communication-layer/discovery-pairing-authentication.md b/website/docs/communication-layer/discovery-pairing-authentication.md index 2d60d02..91dbbfb 100644 --- a/website/docs/communication-layer/discovery-pairing-authentication.md +++ b/website/docs/communication-layer/discovery-pairing-authentication.md @@ -101,7 +101,7 @@ This is used to denote the endpoint of both the REST API client and the WebSocke A person or entity that manages S2 nodes. For the purpose of this specification it is assumed that there is already a trust relationship in place between this person and the S2 nodes. The means that the way the trust relationship has been established is out of scope for this specification. -# Mapping the CEM and RM to S2 Server and Client Nodes +## Mapping CEM and RM to S2 Server and Client Nodes The CEM and RM roles defined by the S2 protocol are distinct from the Server and Client roles of the S2 pairing process. The following rules apply to determine whether the RM or CEM acts as a Client or Server in the pairing process. @@ -144,7 +144,7 @@ A LAN scenario where both RM and CEM are running on the same local network. Disc ## The pairing process -The pairing process is based on the trust relation that the end user has with both the CEM and the RM. That trust relation is out of scope for this specification and is up to CEM and RM providers to implement. Given the deployment scenario, it [follows](# Mapping the CEM and RM to S2 Server and Client Nodes) which of the RM and the CEM is server and which is the client in the pairing process. +The pairing process is based on the trust relation that the end user has with both the CEM and the RM. That trust relation is out of scope for this specification and is up to CEM and RM providers to implement. Given the deployment scenario, it [follows](#mapping-cem-and-rm-to-s2-server-and-client-nodes) which of the RM and the CEM is server and which is the client in the pairing process. The pairing process can either be initiated from the client or from the server.