In version 24.0.0, we introduced a registration validation system to improve the already existing registration system. This validation system is able to track the number of devices a customer has registered EmEditor on.

This page aims to be transparent about our motivations and to document how the validation system works. If we update the validation system in the future, we will also update this page.

Motivation

In the past, there was no way for us to detect users who were sharing their licenses with multiple people or using their licenses on more devices than allowed by the EULA (End-User License Agreement). We would like customers to purchase enough licenses to follow the terms of the license. This would ensure fairness among customers who have purchased multiple licenses and help us keep delivering a quality product.

Terminology

• Registration: The one-time process of activating EmEditor Professional with a registration key or Emurasoft Customer Center credentials.
• Validation: The periodic check that runs each time EmEditor starts to verify that the current installation is associated with a valid license.
• Registration key: A string used to register EmEditor.
• Offline registration: A type of registration that lets users register and validate EmEditor without connecting to the EmEditor server.
• Device: A single counted unit under the license, representing one EmEditor installation. Multiple per-user installations of EmEditor on the same machine are treated as one device.
• Device limit: The maximum number of devices that may be registered to a user, based on the number of licenses the user owns, as defined in the EULA.
• Machine: A Windows environment where EmEditor is installed and can run. A machine is uniquely identified by its machine ID. A machine is not necessarily equivalent to a physical computer, because multiple virtual machines can be installed on one computer.
• Machine ID: A combination of several Windows attributes (MachineGuid, OS install date, volume serial number, processor name, and motherboard name) that is used to distinguish one machine from another.
• MachineGuid: An identifier for a Windows installation, used as one of the inputs to the machine ID.
• Virtual machine (VM): A Windows machine running inside a virtualization environment.
• Local device token: A signed token stored on the user’s machine that verifies that the device was registered.
• History record: A database record associated with a 2Checkout or reseller purchase.
• Stripe subscription ID: The identifier of a user’s Stripe subscription, used to associate registered devices with the Stripe subscription.
• Reseller: A third-party vendor that sells EmEditor licenses (other than 2Checkout or Stripe). Customers who purchase through resellers must register the product and create a Customer Center account to view and manage devices online.
• Registered Devices page: A page in the Emurasoft Customer Center that lists all devices currently registered for a customer’s licenses and subscriptions.
• Go: A programming language used for server-side logic.

Requirements

This section lists the requirements for the validation system.

Functional

• The validation system should loosely enforce the device limit clause of the license. It must not sacrifice customer satisfaction, and the limit should never come as a surprise to users.
• Registration runs once when the user submits the Register Product dialog box or completes any other registration flow. Validation runs each time EmEditor is opened.
• Registration requires EmEditor to be able to connect to support.emeditor.com via HTTPS, while validation does not require an internet connection.
• Users should be able to use an offline license that allows the app to register and validate without connecting to our server. If a user encounters errors during normal registration, an offline license should provide an alternative way to register.
• Users’ privacy rights must be maintained. The collection of personal information will be opt-in.
• The system should fit into the existing registration flow and must not introduce an entirely new way to register. Current users should be able to register without having to learn new steps.
  • Uninstalling the app should unregister the device.
• Users can log in to the Emurasoft Customer Center to view devices so that devices can be unregistered outside of the app.
• Customers who purchase from resellers other than 2Checkout must register the product and create a Customer Center account, since otherwise there is no way for them to view and manage their devices online.
• The system should be tested in the background in version 23, and should be fully enforced starting with version 24.
• We will start selling subscriptions via Stripe, so the system must be able to integrate with Stripe.
• We will offer registration keys for Stripe subscriptions.
• Users should be able to use EmEditor in a VM environment without having to re-register frequently.

Technical

• The system should be simple so that it is easy to maintain.
• A machine can be identified by its machine ID.
  • The machine ID is a combination of several Windows constants used to identify a machine.
  • Because these values can uniquely identify a machine, they should be hashed to avoid storing the raw values in plaintext.
  • EmEditor Portable can be installed on a USB drive, with its settings stored on that drive. The USB drive can be used on many machines, and the validation system would detect different machine IDs. Therefore, if the app detects that it is a portable version running from a USB drive, registration does not occur.
• EmEditor can be installed per-user on a multi-user machine. All per-user installations of EmEditor on the same machine must be counted as a single device.
• There should be a way for us to override the device limit for a given registration key if necessary.
• A signed token containing the device information should be stored on the user’s device. This associates the current device with the device record stored in the database.
• The system should be designed so that a floating license mechanism can be integrated in the future, if needed.

Output

• You can view a list of all devices on the Registered Devices page of Customer Center.
• If the device limit is reached, a notification will appear. The app will not prevent its use when the device limit is exceeded.

• If the user bought the app from a reseller (not 2Checkout or Stripe) and has not registered the product, a notification will ask the user to register the product.

Device table

The device table is stored in our database and records all devices that were registered. Note that a History record is associated with a purchase and it is where a legacy registration key is stored. A Device record is defined in Go as follows.

type Device struct {
	DeviceID             string
	UserID               int
	HistoryID            sql.NullInt64
	StripeSubscriptionID sql.NullString
	MachineID            MachineID
	RegistrationDate     time.Time
	ValidationDate       time.Time
	InstallationType     InstallationType
	Label                string
	Unregistered         bool
}

The fields are explained in the documentation for Registered Devices. The MachineID field is explained below.

Privacy measures for label

The Label field may contain personal information. The Label device field in the Register Product dialog box defaults to {computer name} {user name}. The personal information inside the label field is not necessary for the basic functionality of the app. Therefore, we made the label field opt-in to stick to our policy of privacy by default.

Machine ID

The machine ID is used to identify a machine and is stored in the following structure.

type MachineID struct {
    // Identifies a Windows installation
    // HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineGuid
    MachineGuid string

    // Time of Windows installation
    // SOFTWARE\Microsoft\Windows NT\CurrentVersion\InstallTime
    OSInstallDate string

    // Filesystem identifier created when a storage drive is formatted
    // Volume serial number from GetVolumeInformationW()
    VolumeSerialNumber string

    // Name of processor
    // HARDWARE\DESCRIPTION\System\CentralProcessor\0\ProcessorNameString
    ProcessorName string

    // Name of motherboard
    // HARDWARE\DESCRIPTION\System\BIOS\BaseBoardManufacturer and HARDWARE\DESCRIPTION\System\BIOS\BaseBoardProduct
    MotherboardName string
}

Each field is securely hashed on the client’s machine before the registration request is sent. The hashed machine ID is stored securely in our database with end-to-end encryption. The plaintext identifier values are never transmitted and are not stored on our servers.

Comparing Machine IDs

We use multiple Windows constants to determine whether two machines are the same. Previously, we assumed that the MachineGuid would remain constant for a given machine, but this turned out to be false. A common case where the MachineGuid changes for a single EmEditor installation is when the customer installs the app on a VM drive that is then booted into different Windows installations.

To improve robustness, we use multiple values from the OS that are mostly constant and together help identify a machine. Using the following algorithm, we decide whether two machines are considered the same.

// Returns true if machine a and b are considered to be equal.
// Machines are considered equal if it scores at least 3 points from the following points.
// 3 points: MachineGuid matches
// 2 points: OS install date matches
// 2 points: Volume serial number matches
// 1 point: Processor name matches
// 1 point: Motherboard name matches
func IsMachineIDSame(a, b MachineID) bool {
	// Quick check: MachineGuid matches (3 points)
	if a.MachineGuid == b.MachineGuid {
		return true
	}

	score := 0

	// 2 points: OS install date matches
	if a.OSInstallDate == b.OSInstallDate {
		score += 2
	}

	// 2 points: Volume serial number matches
	if a.VolumeSerialNumber == b.VolumeSerialNumber {
		score += 2
	}

	// 1 point: Processor name matches
	if a.ProcessorName == b.ProcessorName {
		score += 1
	}

	// 1 point: Motherboard name matches
	if a.MotherboardName == b.MotherboardName {
		score += 1
	}

	return score >= 3
}

If the MachineGuid is the same, we immediately consider the machines to be the same. Otherwise, we look for a total score of 3 or more points, which corresponds to at least two other matching values. The device count, explained below, uses this logic to determine the number of unique machines.

Before version 24.5, we considered only the MachineGuid when determining whether machines were the same. Some customers using VMs then had a negative experience, quickly reaching the device limit even though they believed they had not registered that often. By considering other constants in addition to the MachineGuid, we help ensure that EmEditor can be used in VM environments without unexpectedly hitting the device limit.

Device count

This section describes how we determine how many devices you can register.

First, we query all devices associated with a given registration key or Stripe subscription ID and filter them to those that are currently registered.

Next, we count the number of unique machines using the logic described above. If two devices have the same machine ID according to IsMachineIDSame, then device count is 1. If two devices have different machine IDs, the device count is 2. If there are multiple devices that are considered to be on the same machine, they may represent per-user installations on the same machine or VM.

The EULA allows the licensee to install EmEditor on up to two devices per license. If EmEditor is for personal use and is not installed on corporate computers, the licensee may install EmEditor on up to five devices per license.

The algorithm to get the maximum device limit for a user will not be publically documented.

Local Device token

A LocalDevice token is stored locally on the user’s device in the form of a JWT (JSON Web Token). It associates the current device with the database Device record. It also allows EmEditor to do some validation even if it is offline. The token payload is defined as follows.

type LocalDevice struct {
	DeviceID  string
	MachineID MachineID

	// StripeSubscriptionID is empty if this device is not associated with a subscription.
	StripeSubscriptionID string
}

For per-user installations, the token is stored in the registry as LocalDeviceToken in Computer\HKEY_CURRENT_USER\Software\EmSoft\EmEditor v3\Common.

Offline registration

An offline license allows a user to register without an internet connection. Registration only requires a license file.

A customer can request an offline license file. The customer must include their legacy registration key or Stripe order ID in the request. We will reply to the customer’s email address within a few business days with the license file. The license file is a text file that contains a JWT token with the following payload.

type LicenseFile struct {
	LicenseID string
	UserID    int
	FullName  string
	Email     string

	// Is nil if not a Stripe subscription
	StripeSubscriptionID *string

	// Is nil if not a registration key
	HistoryID *int
}

The offline license token is saved to the registry entry OfflineLicense.

There are three ways that the device limit is enforced and illegal sharing of the license file is prevented. 1) When EmEditor can access the internet, validation is performed. 2) We will only send the license file via email instead of downloading from our website. 3) The Registration Information dialog will display the license owner’s full name and email.

OfflineLicense table

Usage of offline licenses is tracked using the OfflineLicense table. It includes the machine ID to track how many machines used the license and the Revoked flag to allow us to revoke a license.

type OfflineLicense struct {
	LicenseID            string
	UserID               int
	MachineID            MachineID
	StripeSubscriptionID sql.NullString
	HistoryID            sql.NullInt64

	// Revoked indicates that this license cannot be used
	Revoked bool
}

Registration Information dialog box

Registration Information displays information about the user’s registration. This is useful for knowing what your registration status is and for diagnosing any issues with validation. It also allows the user to edit the device information and to unregister.

The dialog runs validation and shows whether or not it was successful.

Stripe registration keys

We have introduced a new registration key format specifically for Stripe subscriptions, referred to as the “Stripe registration key” in this article. The older format is called the “legacy registration key,” while the term “registration key” is used to encompass both formats.

The Stripe registration key format is as follows:

r-xxxx-xxxx-xxxx-xxxx-xxxx

where x is a base58 character. Each character is generated randomly, which means that one Stripe registration key has 117 bits of entropy.

Registration process

There are four scenarios where the registration process may happen.

• Most users will register through the Register Product dialog box.
• Register using the MSI installer.
• Offline registration using the command line.
• If you unregister a device, then open EmEditor on that device, the device is registered automatically.

There are three online registration flows, depending on whether a legacy registration key is used (RegisterDeviceLegacyRegkey()), a Stripe registration key is used (RegisterDeviceStripeRegkey) or a Stripe subscription is used (RegisterDeviceSubscription()). There is an additional registration flow for offline registration (StoreOfflineLicenseAndValidate()).

In this section, “Client” refers to the local EmEditor app on the user’s machine. “Server” is our backend server and database.

Finding a subscription to use

1. If the user signs in, the server tries to find a valid Stripe subscription that has 0 associated devices.
2. If no subscription has 0 associated devices, then it tries to find a subscription that has not exceeded the device limit.
   1. If there is a usable Stripe subscription, RegisterDeviceSubscription() is called.
   2. If such Stripe subscription does not exist, it will find a valid legacy registration key that has not exceeded the device limit. RegisterDeviceLegacyRegkey() is used for legacy registration keys.

Registration with legacy registration key (RegisterDeviceLegacyRegkey())

1. If a device token already exists, the client sends an unregister request to the server. The token and registration key are deleted from the registry.
2. The client sends a registration request to the server, which includes the legacy registration key, email, machine ID, label, and installation type.
3. The server compares the input email with the actual email of the user to make sure they are similar.
4. The server gets the device count (defined in the previous section) to determine if the legacy registration key can be used to register the device
5. A Device record is created.
6. The client receives the device ID. Using the device ID, the client requests a local device token.
7. The server creates and responds with the local device token. The expiration date of the token is set to the legacy registration key expiration date. The client writes the token to local storage.

Registration with Stripe registration key (RegisterDeviceStripeRegkey())

1. If a device token already exists, the client sends an unregister request to the server. The token and registration key is deleted from the registry.
2. The client sends a registration request to the server, which includes the Stripe registration key, email, machine ID, label, and installation type.
3. The server compares the input email with the actual email of the user to make sure they are similar.
4. The server verifies that the Stripe subscription is valid.
5. The server gets the device count (defined in previous section) to determine if the Stripe registration key can be used to register the device
6. A Device record is created.
7. The client receives the device ID. Using the device ID, the client requests a local device token.
8. The server creates and responds with the local device token. The expiration of the token is set to one month in the future if the subscription status is active. If the subscription status is canceled, the expiration date is set to the end date of the current billing period. The client writes the token to local storage.

Registration with Stripe subscription (RegisterDeviceSubscription())

1. If a device token already exists, the client sends an unregister request to the server. The token and registration key is deleted from the registry.
2. The client sends a registration request to the server, which includes the Stripe subscription, machine ID, label, and installation type.
3. The server verifies that the Stripe subscription is valid.
4. The server queries deviceCount (defined in previous section) to determine if the Stripe subscription can be used to register the device.
5. A Device record is created.
6. The client receives the device ID. Using the device ID, the client requests a local device token.
7. The server creates and responds with the local device token. The expiration is set to one month in the future if the subscription status is active. If the subscription status is canceled, the expiration date is set to the end date of the current billing period. The client writes the token to local storage.

Registration with offline license (StoreOfflineLicenseAndValidate())

The user registers an offline license by saving the license file to the filesystem, then running the command line option

/ol "licenseFilePath"

This list outlines the offline registration process.

1. Delete the registration key, local device token, and offline license token from the registry.
2. Read the license file and save it to the registry.
3. Run ValidateDevice().

Validation process (ValidateDevice())

Validation occurs every time the app is opened.

1. If local device token does not exist in the registry, call ValidateOfflineLicense().
2. The token’s signature is validated. The actual machine ID is compared with the machine ID in the token. The result is ignored if the app is running on a removable drive.
   • If validation fails due to expected reasons such as a mismatched machine ID, the reason is output as status text.
   • For other unexpected errors such as network error, validation succeeds.
3. A random number generator determines if validation should stop here. This is to reduce the load of requests to our server.
4. The validation function sleeps the thread for a certain duration. This is again to reduce the request load, as we assume that macros and other automated use cases that rapidly start and close the app would only run it for a short duration.
5. The client requests the Device data for the stored device ID.
6. If the device is associated with a Stripe subscription, the server verifies that the Stripe subscription is valid.
7. If device.Unregistered == true, the client attempts to register the device.
8. The device.ValidationDate is updated.
9. If the token was issued before current time - 7 days, a new token is created to renew the old token. The new token has an expiration date of one month.

Offline license validation process (ValidateOfflineLicense())

Offline license validation occurs if the registry does not contain the local device token. If an unexpected error occurs, validation succeeds. This means that if the user is offline, validation will still succeed.

1. If the offline license token does not exist, validation succeeds. One case where this may happen is if registration previously failed due to a network error but the registration key was valid. This allows EmEditor to be used in this case.
2. Read and validate the token.
3. Request the server to validate the offline license with the token and machine ID.
4. The server validates the token.
5. For Stripe subscriptions, the server checks that the subscription has the status active.
6. If an OfflineLicense entry for the license ID does not exist, it is created with the token data.
7. If the entry exists and license.Revoked == true, it returns StatusLicenseRevoked. Otherwise validation succeeds.

Uninstallation

When you uninstall the desktop version of EmEditor, your device will automatically be unregistered. This makes it easy to install to another machine without having to unregister the previous device manually.
Because the portable and Store App versions do not have an uninstallation process, they will not unregister automatically when you remove those apps. Therefore, if you have a portable or Store App and you are no longer using it on your device, you must manually unregister it from the Registered Devices page in Customer Center.

Security

We are using secure-by-design practices to ensure privacy and to protect against exploits in the validation system. The following lists some of the guiding principles that we used when implementing the system.

• End-to-end encryption
  • All client-to-server and server-to-server communication uses HTTPS with CA-validated TLS encryption with no insecure fallback.
  • Server-side database records are secured with Azure-managed encryption and secure settings.
• Token security
  • The local device token and offline license token follow the JWT standard and are signed with ECDSA. This allows client-side authentication without sharing the private key.
• PII privacy
  • The label option during registration is optional.
  • MachineID fields are securely hashed on the client side before being encrypted and transmitted. The plaintext contents of these fields are never transmitted or stored on our servers.
  • Client-side logs are not persisted. Server-side logs contain minimal data about requests and do not include request body content such as the registration fields.

Support

If you have any questions or feedback about the validation system, feel free to send us a message.