Author: shadow_wp_admin

Starting with the Shadow client v1.12.2, the feature of remote deletion is available. Having posted a message erroneously, one can delete it not only for themselves, but also for the remote part of the conversation. This kind of deletion can be performed within a reasonable interval of time since the message of question has been posted (currently three hours).

The new Shadow client v1.11.0 introduces the possibility to set the depth of message storage in terms of time – this in addition to the same in terms of number of messages in a chat (which option has long been available and remains to stay). All messages older than the specified amount of time are automatically deleted. This is local to your client and applies to all messages in all chats at once, as opposed to the “Disappearing messages” functionality applicable to individual chats. Of course you still can keep messages forever if you wish.

The setting is accessible via the Storage -> Keep messages menu.

With new Shadow client v1.10.0 the old client-side activation model is phased out. The new client requires Shadow server v2.00 or above and is incompatible with old server versions.

The new Shadow server v2.00 is the first release to implement the new activation paradigm. Instead of activating each Shadow client individually, a single activation key related to the Shadow server itself has to be used. Currently, the only parameter “activated” is the number of user accounts (active and pending) provisioned on the server. It is important that this parameter is completely deindividualized in relation to usernames or client devices – only the total number matters. What is perhaps even more important, no activation at all is required if the number of accounts is three or less!

For a short transition period the two activation schemes (old and new) are run in parallel, but the old client-related activation will be phased out with the next release of the Shadow client. The old client activation API of the server will still be supported for some time for backward compatibility.

Another notable change in v2.00 is that the admin-side “soft deletion” is no more: a removed account is now removed from the server completely (and not simply inactivated).

The new Shadow client v1.9.x brings two notable improvements. The first one is that link previews are now available for arbitrary web links, and not only for a subset of pre-approved websites as it has been hitherto. The second improvement addresses the possibility of the unfortunate event of the server certificates’ expiry having been missed. Previously that would either make new registrations impossible or lock the existing users out of service, depending on whether the administrator chose to keep expired certificates or rotate for the new ones. Starting with Shadow client 1.9.2, certificate pull is introduced, enabling users to download new certificates from the server while still trusting the old (expired) ones. This way, certificate rotation on the server can be done without interrupting service for the end-users.

Starting with version 1.12, the Shadow server now supports reproducible builds.

Making one’s source code open and publicly available for inspection is only one side of transparency. The other side is to confirm that the published binaries are indeed built from this very source code without any alterations, backdoors, and so on.

This means that one can validate whether the pre-compiled jar file published on our downloads page is really built from exactly the same source code as published on our GitHub page. This validation is done by building the jar file from the source code, calculating its checksum and comparing the latter with what is published on our website. If the two checksums match, then there are no alterations.

Making a build reproducible is a tricky task, since the checksum may differ for different build environments even if there are virtually no changes in the source code. Reproducibility must be supported by the source code itself and by the compiler, but the final piece is to provide the same build environment every time. That is why we use Docker for reproducibility. Our respective documentation page specifies the relevant Dockerfile and brief instructions.

We hope to announce support for reproducible builds for our Android client as well in the near future.

The need for the open-source on-premises secure messenger solution has been manifesting itself throughout the recent years when end-to-end encryption became a de-facto standard in the world of secure messaging. We are humbly attempting to address this need with the launch of Shadow, which:

a) is fully open-source (both for its client and server parts)
b) uses end-to-end encryption as its only mode (no optional and all that!)
c) puts the system server under your own administration – in contrast to all the mass market solutions out there where you have no control over what’s happening behind the silver (or dark) lining of the cloud.

Shadow is built on the Signal secure messenger, as we believe Signal to be the leader of the secure messaging technology. Preserving the best features of Signal, Shadow is anticipated to develop towards the needs of (relatively) small teams and the B2B market, which (again!) is in contrast to mass market solutions targeted at huge audiences of millions of individual subscribers.

Here’s a brief list of what’s different in Shadow versus Signal.

• There’s no binding to phone numbers (and to the mobile network in general). As long as you have an internet connection, your device may even do without a SIM card. Instead of E.164 numbers we use alphanumeric user logins which are set by the system administrator (that is, by you), and are under your full control. Hence, no more SMS or callback verifications. The system directory is maintained on the server and any change is communicated to the clients.
• As it quite naturally follows from the above, there are no complications such as Signal‘s “Contact Discovery Service” or registration lock with a PIN.
• Registration in the system is a three-step process which is fully controlled by the system administrator – firstly, the would-be end-user scans the registration QR code provided by the administrator, next s/he enters the user login (which is set up and provided by the system administrator as well), and thirdly, s/he enters the one-time password (which, as you probably have guessed, is provided by the administrator). In this process, there is really very small opportunity for a malicious party to register on your server in the first place, so your client base is trusted as long as you trust each of your individual end-users.
• There’s no reliance on public clouds (such as Amazon or Google) for storage. Instead, the server part of the solution includes a private cloud component where all profiles, attachments and debug logs are stored. Of course, we still need to rely upon Google Cloud services for push notifications or geotargeting.
• The fact that the system server is under your own control lets you customize some service level parameters – for example, set your own FCM (Firebase Cloud Messaging) Sender ID or configure the email address whence debug log reports would be sent.
• We provide detailed system administration documentation – which is not free of charge, – but there is also the freely available Quick Start guide which provides enough information on how to launch and operate the service. And, of course, our source code is public (but this is not a difference from Signal).

This is just the beginning of the way, and we hope to be able to add more features in the not-so-distant future.

In these uneasy times when whirlwinds of danger are raging around us, may Shadow be your shade and shelter.