New Vector Ltd

Modular Matrix Hosting

Modular provides self-sovereign, secure alternatives to WhatsApp or Slack for end-to-end encrypted collaboration within Government and enterprise. Built on the Matrix.org open standard for secure interoperable communication, users can communicate as widely as they like while still having total control over their data for regulatory and privacy purposes.

Features

  • Instant messaging
  • Audited end-to-end encryption
  • VoIP and video conferencing
  • Team collaboration
  • Self-sovereignty
  • Built entirely on open standards
  • Regulatory compliance (FOI etc)
  • Encrypted file transfer
  • Encryption-aware antivirus
  • Enterprise key management

Benefits

  • Communicate securely using government-grade audited end-to-end encryption
  • Communicate seamlessly with users on other Matrix deployments (e.g. France)
  • Communicate seamlessly with users on other platforms (e.g. Slack, PSTN)
  • Synchronised communication across Web, iOS, Android, Desktop
  • Communicate via instant messaging, file-transfer, voice/video calls and conferences
  • Communicate efficiently via read receipts, typing notifications, presence info
  • Access the open Matrix ecosystem of bots, bridges and apps
  • Embed webapps into your chatrooms for dashboarding, collaboration, etc
  • Host conversations in the UK, administered by a UK company
  • Comply with communication regulatory requirements (e.g. FOI) without sacrificing security

Pricing

£1.50 to £15.00 per person per month

Service documents

Framework

G-Cloud 11

Service ID

2 8 3 7 4 0 6 4 4 5 0 3 4 7 9

Contact

New Vector Ltd

Amandine Le Pape

07715212960

amandine@vector.im

Service scope

Software add-on or extension
No
Cloud deployment model
  • Public cloud
  • Private cloud
  • Community cloud
  • Hybrid cloud
Service constraints
Modular has no specific constraints. It is typically provided as a self-service public cloud hosted offering, but is often deployed in private, hybrid and community clouds too. Modular is built on the open source implementations of the Matrix protocol, which support a very wide range of platforms and configurations.
System requirements
  • No specific system requirements by default.
  • When self-hosted requires Linux (Debian, RHEL, SUSe) and PostgreSQL

User support

Email or online ticketing support
Yes, at extra cost
Support response times
For critical severity (service unavailable), 30 minute response & 2h time to resolution
For major security (feature unavailable), 2h response and 8h time to resolution
For general support, within 1 working day.
User can manage status and priority of support tickets
No
Phone support
No
Web chat support
Yes, at an extra cost
Web chat support availability
24 hours, 7 days a week
Web chat support accessibility standard
WCAG 2.1 AA or EN 301 549
Web chat accessibility testing
We use Modular itself for web chat support, which in turn is built on components from the Matrix open source project for secure communication. Web chat is provided by the open source Riot/Web client, which has several long-term contributing developers who are partially-sighted and test, use and improve the webapp via screenreaders (JAWS, NVDA, Orca and macOS VoiceOver). We are currently working on reviewing all screenreader accessibility as part of a proposal to deploy Matrix for Mozilla.
Onsite support
Yes, at extra cost
Support levels
Support for the public-cloud hosted Modular service is typically Level 1 (e.g. helping users with password resets, generally using the app) and Level 2 (e.g. investigating reports of features which are not working). We are currently finalising pricing, but the expectation is for L1/L2 support availability to be charged on a per-monthly-active-user-basis at around £2/user/month.

Support for private-cloud hosted Modular deployments also includes L3 support, to provide SLA'd resolution to Matrix-specific issues on the service (e.g. high CPU, resource starvation, handling traffic anomalous traffic etc). This is charged depending on the complexity of the deployment and the required SLA, but is typically an additional £2/user/month.

Private/Hybrid/Community-cloud deployments include a technical account manager.
Support available to third parties
Yes

Onboarding and offboarding

Getting started
Modular comes with built-in tutorials and user documentation, which act as a form of online training and onboarding for new users provided by a chatbot. The bot shares videos, images, tips and hits, and answers questions from users. These questions may be routed through to a human support operator.

We can also provide onsite training for additional cost.
Service documentation
Yes
Documentation formats
HTML
End-of-contract data extraction
Modular is built on Matrix, an open standard for decentralised communication. Data portability and self-sovereignty is an inherent feature of the service. Users have many options to extract their data by 1) automatically migrating to an alternative Matrix provider via tools such as https://modular.im/tools/account-migration 2) manually migrating to an alternative Matrix provider by adding the new account to their conversations 3) Using Matrix's GDPR data-takeout APIs to extract their data 4) In future, multihoming their account to a new server so that their data seamlessly replicates between the old & new provider.
End-of-contract process
There are no specific end-of-contract features or costs.

Using the service

Web browser interface
Yes
Supported browsers
  • Microsoft Edge
  • Firefox
  • Chrome
  • Safari 9+
  • Opera
Application to install
Yes
Compatible operating systems
  • Android
  • IOS
  • Linux or Unix
  • MacOS
  • Windows
Designed for use on mobile devices
Yes
Differences between the mobile and desktop service
Modular users install an (optionally) rebranded version of the Riot messaging app (https://riot.im) to communicate. Riot has excellent native application support for iOS, Android, Web and Desktop. Each platform is its own app, but feature parity is aggressively maintained across all four platforms.
Service interface
Yes
Description of service interface
Modular provides two service interfaces: one for system administrators to configure their deployment (at https://modular.im for the public cloud offering) and one for users, chatroom moderators and chatroom administrators to use & configure the service.

The system administrator interface is a responsive progressive webapp as seen on https://modular.im. The main user/mod interface is as per https://riot.im (albeit a dedicated version of the app for the specific Modular deployment).
Accessibility standards
WCAG 2.1 AA or EN 301 549
Accessibility testing
We have several long-term active contributors in the Matrix community who are partially sighted and use both Riot and Modular via screenreaders (JAWS, NVDA, Orca and macOS Voiceover). Our own SDLC process includes testing on screenreaders and running through accessibility checks as a matter of course.
API
Yes
What users can and can't do using the API
All of Modular is built on the Matrix open standard for decentralised communication, and as such every single feature in the platform is available as an open standard open API as specified at https://matrix.org/docs/spec and formalised via OpenAPI (Swagger 2) at https://github.com/matrix-org/matrix-doc/tree/master/api. This includes provisioning users, sending messages, and every other aspect of the service.
API documentation
Yes
API documentation formats
  • Open API (also known as Swagger)
  • HTML
API sandbox or test environment
Yes
Customisation available
Yes
Description of customisation
The public cloud instance of Modular.im allows customisation of:

* Service URL

* Service name

* Service branding (logo, wallpaper)

* Service Terms & Conditions.

* Provisioned integrations (e.g. bridges to Slack and other systems; Single Sign On integrations) for additional cost.

* Custom integrations configured manually by New Vector (e.g. custom antivirus, content filtering).

Branded versions of the mobile and desktop app are also possible at additional cost.

Private/hybrid/community cloud deployments of Modular allow full customisation of all aspects of the services (e.g. custom integrations and features).

Users also have rich control over customising the service; creating and configuring their own collaboration environments, using either existing group access controls or defining their own, and branding and customising rooms and communities of rooms as they require.

Scaling

Independence of resources
All deployments of Modular are entirely operationally isolated and independent, running on dedicated VMs per customer. There are currently no shared resources.

Analytics

Service usage metrics
Yes
Metrics types
Modular provides two levels of service metrics: for the public cloud offering, a basic real-time dashboard is available to gauge the utilisation of the service (CPU/Memory usage, Storage capacity, user directory, room directory etc). For the private/hybrid/community cloud offering, a highly granular metrics API is available for OSS purposes via Prometheus and Grafana APIs as per https://github.com/matrix-org/synapse/blob/master/docs/metrics-howto.rst and https://raw.githubusercontent.com/matrix-org/synapse/master/contrib/grafana/synapse.json. This API can also be exposed on the public cloud offering as required.
Reporting types
  • API access
  • Real-time dashboards

Resellers

Supplier type
Not a reseller

Staff security

Staff security clearance
Staff screening not performed
Government security clearance
Up to Developed Vetting (DV)

Asset protection

Knowledge of data storage and processing locations
Yes
Data storage and processing locations
  • United Kingdom
  • European Economic Area (EEA)
User control over data storage and processing locations
Yes
Datacentre security standards
Managed by a third party
Penetration testing frequency
At least every 6 months
Penetration testing approach
In-house
Protecting data at rest
Encryption of all physical media
Data sanitisation process
Yes
Data sanitisation type
Explicit overwriting of storage before reallocation
Equipment disposal approach
In-house destruction process

Data importing and exporting

Data export approach
Users may export their conversations by: migrating to an alternative Matrix server using a tool such as https://modular.im/tools/account-migration, or using a tool to export their data such as https://gitlab.com/argit/matrix-recorder. Conversation data is also automatically replicated across all the Matrix servers participating in a conversation, so data may be exported by simply communicating with a user on a different server (e.g. a new account). Matrix clients may also provide export as HTML, PDF, etc.
Data export formats
  • CSV
  • Other
Other data export formats
  • Matrix event archives (https://matrix.org/docs/spec/#events)
  • HTML
  • Raw synapse SQL database dump
Data import formats
Other
Other data import formats
Matrix events (https://matrix.org/docs/spec/#events)

Data-in-transit protection

Data protection between buyer and supplier networks
  • TLS (version 1.2 or above)
  • Other
Other protection between networks
We can also deploy IPsec or TLS VPNs or provide private/public sector network connectivity as required.
Data protection within supplier network
  • TLS (version 1.2 or above)
  • IPsec or TLS VPN gateway

Availability and resilience

Guaranteed availability
We provide 99.8% SLA on our public & private cloud deployment. For any outage exceeding this threshold in a given month, users are compensated with credit worth 20x the duration of the outage exceeding the threshold.
Approach to resilience
Modular may be deployed in an active/backup high-availability architecture, with application servers and databases replicated between separate physical servers, optionally in different datacenters or zones. We rely on short-lived DNS TTLs to move DNS when promoting the backup deployment to be primary. Within a given deployment, many services are also deployed active/active, and may be distributed across multiple VMs (optionally across datacenters) to provide resilience to outage.
Outage reporting
We provide a public dashboard powered by https://cachethq.io/, which can also expose an API if required.

Identity and authentication

User authentication needed
Yes
User authentication
  • 2-factor authentication
  • Identity federation with existing provider (for example Google Apps)
  • Username or password
Access restrictions in management interfaces and support channels
Access in Matrix is typically restricted based on 'power levels' - a number which defines the amount of power a user has in a given setting. Different roles and permissions can be assigned to a given level of power, rather than supporting free-form role definition. This provides a well-defined hierarchy of power in any context. Groups of users may also be defined by external services (e.g. Active Directory; LDAP groups) for ACL purposes.
Access restriction testing frequency
At least every 6 months
Management access authentication
  • 2-factor authentication
  • Username or password

Audit information for users

Access to user activity audit information
Users have access to real-time audit information
How long user audit data is stored for
User-defined
Access to supplier activity audit information
Users have access to real-time audit information
How long supplier audit data is stored for
User-defined
How long system logs are stored for
User-defined

Standards and certifications

ISO/IEC 27001 certification
No
ISO 28000:2007 certification
No
CSA STAR certification
No
PCI certification
No
Other security certifications
No

Security governance

Named board-level person responsible for service security
Yes
Security governance certified
No
Security governance approach
We apply a pragmatic subset of ISO27001 security governance processes in running our services, and have been successfully audited by ANSSI (the French Government's information security agency) as providing sufficient security for the purposes of their cross-ministerial public sector deployment (16 ministries, ~50 servers, 5.5M users)
Information security policies and processes
We provide training on information security to all employees, and have defined playbooks for security-related operations (e.g. access to production infrastructure, access and handling of PII data, employee onboarding/offboarding). Employees with access to secure systems report to the Head of Engineering, who in turn reports to the CTO. The named security point of responsibility is the CTO.

Operational security

Configuration and change management standard
Supplier-defined controls
Configuration and change management approach
All changes to production are tracked via a combination of Github, Gitlab, and Ansible configuration management and AWX (Ansible Tower) automation. Deployment to production is restricted to deploying well defined tagged artefacts and configuration from Git via Ansible. All configuration and code without exception is versioned in Git, and requires code review by a peer or manager via Github pull requests or Gitlab merge requests to be merged, tagged and deployed. Code review covers both bugs and potential security impact, with sensitive areas requiring additional review.
Vulnerability management type
Supplier-defined controls
Vulnerability management approach
We assess potential threats via regular internal pentesting and vulnerability scans. Security patches are deployed on a daily basis. Potential threats come from CERT and Debian security mailing lists.

For vulnerabilities in our own software, please see https://matrix.org/security-disclosure-policy/
Protective monitoring type
Supplier-defined controls
Protective monitoring approach
We maintain active intrusion detection systems for network and filesystem level intrusion, as well as extensively leveraging configuration management to detect abuse.

When discovering a potential compromise, we follow our internal incident response playbook, which includes appointing an incident response manager, internal & external communication coordinator, incident response team, and then initial forensics, mitigation, user and ICO notification if required, in-depth forensics and remediations using external independent parties as required.

We respond to detected security incidents within 30 minutes, 24x7x365.
Incident management type
Supplier-defined controls
Incident management approach
When handling a security incident, we follow our internal incident response playbook, which includes pre-defined processes for common events (e.g. lost device, compromised password). We appoint an incident response manager, internal & external communication coordinator, incident response team, and then initial forensics, mitigation, user and ICO notification if required, in-depth forensics and remediations using external independent parties as required.

Users report incidents to security@vector.im, or via the Matrix.org security disclosure policy (https://matrix.org/security-disclosure-policy/).

We provide incident reports in realtime at the appropriate level of transparency (e.g. public reports for public-facing incidents), with full post-mortem within 4 weeks of the incident.

Secure development

Approach to secure software development best practice
Supplier-defined process

Public sector networks

Connection to public sector networks
Yes
Connected networks
Other
Other public sector networks
Connection with NATO in progress via our French+US government deployments

Pricing

Price
£1.50 to £15.00 per person per month
Discount for educational organisations
Yes
Free trial available
Yes
Description of free trial
All services can be trialled for free via https://riot.im or https://sandbox.riot.im. This does not include access to the management console however, and is on a shared public server, and does not include any deployment-specific integrations. There is no time limit.
Link to free trial
https://modular.im

Service documents

Return to top ↑