globe showing Americas Diese Seite auf Deutsch anzeigen

Service description

Description

A chat system allows electronic communication by means of written text in real time.

We offer a chat server based on the matrix protocol with the possibility to communicate privately or in public forums with text, images and video.

In addition, if the user wishes, communication can be encrypted.

Customer Benefit

With the chat system you can communicate confidentially in real time in pairs or in groups.

Users can also create public chat rooms to cooperate with a wider audience (e.g. within a practice group).

Customer Groups / Cost / Order

This IT service is provided free of charge to all persons with a relationship to ETH Zurich (employees, students and lecturers).

The service can be used via the web client https://chat.ethz.ch. For other clients, ETH employees can use https://staffchat.ethz.ch as server configuration.

ETH students use https://studentchat.ethz.ch as server configuration.

How does it work

Matrix is an open standard for interoperable, decentralised, real-time communication over IP. It can be used to power Instant Messaging, VoIP / WebRTC signalling, Internet of Things communication - or anywhere you need a standard HTTP API for publishing and subscribing to data whilst tracking the conversation history. Matrix defines the standard, and provides open source reference implementations of Matrix-compatible Servers, Client SDKs and Application Services to help you create new communication solutions or extend the capabilities and reach of existing ones.  Want to know who is behind it and why they create such a useful project for the public for free? Read on in the offical matrix.org FAQ.

The webclient chat.ethz.ch is configured to use the Jitsi server of SWITCH for video conferences. Attention: we currently only guarantee that the webclient chat.ethz.ch is using SWITCH, any other clients may use a third party provider of a Jisti installation.

Get started

Connection 

The procedure for all clients is the same:

  1. Select Sign-In 
  2. Configure https://staffchat.ethz.ch as the server (except chat.ethz.ch → already preconfigured)
  3. Login with your ETH credentials
Web Browser

Mobile App


warning  please make sure to also enter https://


Desktop App

End-to-end Encryption

Element offers true end-to-end encrypted (E2EE) communication, meaning no-one else can eavesdrop on your conversations, not even server admins. Element uses the best end-to-end encryption available today. Encryption is kept friendly with features like secure key backup, which allow you to recover your encrypted data even if you lose or break a device. Advanced features like verification highlight if a user's account may be compromised.


 What is Key Backup?

When key backup is enabled, your device will maintain a secure copy of its keys on our server. To ensure those keys can only ever be accessed by you, they are encrypted on your device, with a key that you either store yourself, or secure with a passphrase and upload to our server. It is important to understand that to protect your privacy your keys will never touch our systems unencrypted.


What is a 'device'?

For historical reasons, when we say 'device' we don't mean your phone or your laptop - you actually create a new 'device' each time you log in on Matrix (and destroy it again when you log out).


What does it mean to verify or trust a device in Element?

Element uses trust to represent an additional layer of security within the app, over and above username and password authentication.

If somebody is sending messages as Alice, we know that they have access to Alice's account - either they've logged in with Alice's username and password, or they're using a logged in session, perhaps on Alice's phone. Usually, that somebody is going to be Alice. Unfortunately, in the real world, passwords can be guessed or sniffed and phones can be stolen. Element's trust mechanism is designed to mitigate this. In Element, you can see every device that has joined an encrypted conversation. If a new and unexpected device joins, you can use device verification to check that it's really Alice. And if you suspect that a trusted device has fallen into the wrong hands, you can revoke that trust and remove its access to the ongoing encrypted conversation.


Cross-signing

With the rollout of Element (Web, Desktop) version 1.6.0+, the verification procedure has been massively improved. Instead of verifying and trusting all devices of your conversation partners, you just have to verify and trust other persons (accounts). On the other hand, each person verifies and trusts their own devices.

With the update, new direct messages will be encrypted by default. Element will also suggest to enable encryption if you create a new private room. If you do not want that, just unselect Enable end-to-end encryption on the Create a private room dialog to turn off encryption. If the room to be created is intended to be a public room, then do not use encryption. End-to-end encryption can never be disabled once it is enabled.


Key Storage and Recovery Passphrase

End-to-end encryption in Element has to manage many encryption keys. All these keys are stored securely on our server. In order to do that, an additional password is required to encrypt the key storage. The two passwords for Element are named as follows:

  • Account password: This is your ETH ldap password
  • Recovery passphrase: Another secure password

There is an additional safety net called the 'recovery key', which you can use to restore access to your encrypted messages if you forget your recovery passphrase. We recommend to keep a copy of it somewhere secure, like a password manager or even a safe.

Important note: Should you forget your 'recovery passphrase' and lose your 'recovery key', your encrypted conversations could be lost! Not even server admins can help you in that case. 


Setting up Encryption

After you sign in to Element for the first time, you are asked to set up your encryption. The first step is to set your 'recovery passphrase':


After confirming the password, it will show your recovery key:

Copy it and store the key in a safe place as mentioned above or as suggested on the next screen:


Upgrade Encryption

If you have used an earlier Element version (<= 1.5.x), you will be asked to upgrade your encryption after the update to the new Element version 1.6.x (Web, Desktop):

If you login to a new session, you will be prompted to do that right after the login. The steps for the upgrade may look different depending on your previous configuration. If you have not set up the Key storage (see below) so far, see Set up encryption (above). Otherwise you will asked to enter your Account password now:

After that you will asked to enter your Recovery passphrase:

This will upgrade your encryption keys and verify the session.


Self-Verification

Should you have used Element on other devices without logging out, you will be asked to verify these sessions:

You can try that right now or just click Later (recommended).

You may also review and cleanup your existing sessions in Settings > Security & Privacy > Sessions. The example below will delete old sessions, that are no longer needed. If this session is still in use on another device, it will be logged out immediately.

To verify your other sessions, select a Room > Members > Yourname:

Security

Element is similar to email regarding security precautions you should take (see Use email with care). Anyone on the Internet can contact you, send you spam and viruses or try a phishing attack. However, Element has advanced features to confirm your correspondent's identity, which makes it much more secure than email.

Identity

The 'displayname' is an arbitrary name that users can set as they wish. This is the name you will see in Element's message history. The 'MXID' (Matrix ID) is better suited to confirm an identity. It has the following format:

@localpart:domain

You can check it by hovering over the avatar (picture) next to the name in the message history. Click on the avatar, which will open the right sidebar with additional information about that user:


Encryption

Our server uses latest Transport Layer Security (TLS) standards. This encrypts all traffic from your client to the server. You may still see Send a message (unencrypted).... This means that the message you send will not be using end-to-end encryption (e2ee). If e2ee is enabled (the default, starting from Element version 1.6.0), your messages and files are encrypted before they leave your device, and stay encrypted until they reach the other participants' devices. End-to-end encrypted messages can only be read by the participants in the conversation.

Federation (where is my data stored?)

See how federation works. Rooms are decentralized and could be synced to other Matrix homeservers. As long as all participants in a room are on our server (domainpart of MXID = staffchat.ethz.ch), the message history is on our server only. If ETH external participants (or from other domains) join the room, the message history will be synced with the homeservers that holds their account. You can control that by setting the room to invite only and carefully choose who may join.

data classification

in case you need to discuss sensitive information we prepared this guideline. When following these, the chat service can be used to discuss data classification up to "confidential" (but not: "strictly confidential"!)


  • Be sure to read the "Weisung informationssiherheit"
  • Please verify that the following settings for your chatroom are active:
    • encryption:
      • Encryption Settings of a Chatroom:
        verify that Encryption is enabled and
        "Never send encrypted messages to unverified sessions" is active
    • Access:
      • Ensure your room is invite only:
    • History:
      (highly recommendet by ETH ITS). The situation that somebody in the future is invited to a room and has access to the chat history from years ago is VERY hard to keep track and opens up huge risk for potential data leak
  • We also recommend to use "disposable" rooms on a "per project" basis and not "one confidential room with incremental history forever". With this setup, when a research project is finished, everybody can leave the room, delete their access tokens and the access to the room it is lost
  • another important point to be aware of is the local client device: be aware its not allowed to use private devices (especially smartphones) when handling data classified as confidential. Since the chatservice is also used as a messenger, be aware that members of confidential chatrooms are not allowed to do so on their private smartphones!
     
  • When inviting external researchers (not from ETHZ) be aware that federation of matrix chats opens up a whole new set of questions like
    • Where are data sent to? (USA? EU?)
    • How does the foederation server store the data? What protection/encryption does it have? How can we verify this (obvisouly we can't)?
    • whats the security level of the external chatpartners endpoint device?

      Due to these huge unknown factors we do not recommend using chatservice with external partners outside ETHZ in case you use it for data classified as internal and/or confidential.
       
  • also make sure that your customers/coworkers do not store attachments/screenshots/chatlogs etc in improper locations (like: unencrypted USB Sticks/external Harddrives, Cloud Services etcetcetc)
    • Extensions: if you plan to use widgets, be aware that they are fully hosted externally and are not part of ETH ITS services!

Room Moderation

Please refer to our Element page to learn the basics about room permissions and moderators.


Moderating unwanted content or spam

If you are the administrator of a large room or if your room is public, you have some tools to remove unwanted content or block spammers. Element provides an interface for some basics, like kicking or banning users. Please refer to the official documentation about room moderation for more information. It includes an example on how to use server ACLs to block malicious servers from interacting with a room (just be careful not to lock yourself out). To learn more about ACLs or blocking other servers, refer to:


Locking down a public room

This will make a room accessible from the Staffchat homeserver only. Servers which were already participating in that room over federation will not receive any new events.

Warning: The steps below cannot be undone. Be careful when deploying server ACLs. It is very well possible to completely lock a room. It would be lost forever.

We will now use the developer tools in Element (Web/Desktop) to send a custom state event to the room. Open the developer tools by entering the following command in Element:



/devtools



Now select Send Custom Event:


  • Click on the red Event button in the lower-right corner to switch to State Event mode
  • As Event Type set: m.room.server_acl
  • Add the following Event Content:



{ "allow": [ "staffchat.ethz.ch" ], "allow_ip_literals": false, "deny": [ "*" ] }


Finally click Send

You should now get a confirmation message that the event was sent.


You can later review the settings. Just open the devtools again and select Explore Room State > m.room.server_acl:


Invite unregistered person(s) to chatroom (PDF document)

Terminology

  • Homeserver: Each account in the Matrix federation is associated with a single homeserver. The software running at this server stores the history and account information for that user. Homeservers synchronise message history with other homeservers.
  • Federation: Federation means that separate instances of a service communicate - the best example of this is email servers, in which it’s possible to send mail between difference service providers. For Matrix, this means that data about rooms and message history is shared between matrix servers of participating users.
  • Riot/Element: Element, previously known as "Riot" is a popular matrix client developed by the core matrix.org team. It is also accessable via https://chat.ethz.ch. 
  • MXID: Matrix user IDs (MXID) are unique user IDs. They are in the format @username:staffchat.ethz.ch.
  • Sigil: Sigils refer the symbols uses at the beginning of many matrix identifiers. For example @ is used for users, # for rooms, and + for communities.
  • Community: Communities (groups) are collections of rooms.
  • Room: A room is a fundamental building bock of the matrix architecture: events are typically sent in the context of a room. A room is a conceptual place where users can send and receive events. Events are sent to a room, and all participants in that room with sufficient access will receive the event.
  • Jitsi: A service used for video conferencing. 


Homeserver Synapse

We host a Synapse Matrix Homeserver for the domain staffchat.ethz.ch. It holds user account data, message history, media uploads, room aliases, communities and participates in the Matrix federation network.

Clients

To connect to the Matrix server, you will need to use a client. As as member of ETH, we recommend using Element. Other Matrix clients that are availalbe as of today can be found here. To get started using Matrix, see get started. Clients allow you to connect to a homeserver to send/receive messages. Your homeserver stores a copy of the message history of every room you participate in. Homeservers connect to other homeservers on the internet and synchronize the message history of federated rooms.

Federation

Federation is the process by which users on different servers can participate in the same room. As soon as a Matrix user from another homeserver joins your room (either via an invitation to a private room or by joining a public room), the corresponding homeservers will start to sync the message history of that room. If one of the participating homeservers is offline, the users on other homeservers can continue talking in that room. This is called decentralization. 

Users

Each client is associated with a user account, which is identified in Matrix using a unique user ID. This ID is namespaced to the homeserver which allocated the account and has the form:
@localpart:domain

Events

All data exchanged over Matrix is expressed as an event. Typically each client action (e.g. sending a message) correlates with exactly one event. Each event has a type which is used to differentiate different kinds of data. The special top-level namespace m. is reserved for events defined in the Matrix specification - for instance m.room.message is the event type for instant messages. Events are usually sent in the context of a Room.

Room

A room is a conceptual place where users can send and receive events. Events are sent to a room, and all participants in that room with sufficient access will receive the event.
Rooms are uniquely identified internally via Room IDs, which have the form: 

!unique_id:domain

There is exactly one room ID for each room. Whilst the room ID does contain a domain, it is simply for globally namespacing room IDs. The room does NOT reside on the domain specified.

Room Alias

Each room can also have multiple Room Aliases, which look like: 

#room_alias:domain

A room alias “points” to a room ID and is the human-readable label by which rooms are publicised and discovered.

Room Version

Rooms are central to how Matrix operates, and have strict rules for what is allowed to be contained within them. Rooms can also have various algorithms that handle different tasks.To allow rooms to be improved upon through new algorithms or rules, “room versions” are employed to manage a set of expectations for each room. New room versions are assigned as needed

Troubleshooting

How do I remove unverified sessions

  1. Navigate to All Settings → Security & Privacy → Where you're logged in

  2. Select all sessions except the bold one (that's your current one)
  3. Click on Delete X sessions
  4. Confirm by entering your LDAP password
  5. Logout and login again on your browser and all other devices


How do I reset the secure backup & security keys

Warning: By executing the following steps you will lose all previously encrypted messages forever

  1. Login on chat.ethz.ch with LDAP username/password and click on Sign in
  2. In the windows Verify this login click on Use Security Key
  3. Click on Reset all in the pop up window
  4. Confirm by clicking on Reset
  5. Generate a new Security Key & make sure you safe this at a secure location (e.g. password-safe)
  6. Finish setting up new keys by entering your LDAP Password again