feat(cloud): Use Signed Userdata To Protect Paywall Features On Vanilla Installations

[nekrondev]

TL;DR

The current implementation for handling user data fetched from LiYuan cloud service allows forging of sensible paywall features that otherwise would need patching, recompilation and replacing the kernel service.

1. THIS CHANGE NEEDS SOME LIYUAN CLOUD SERVICE MODIFICATIONS
2. THE EMBEDDED PUBLIC KEY MUST BE CHANGED MATCHING THE LIYUAN PRIVATE KEY

I also fixed two logging issues where not all function parameters would be rendered.

Context

User data is currently not protected by some digital signature allowing everyone to create a custom JSON data structure for enabling future paywall features.

This change adds required modifications to kernel service to

• allow deserialization of legacy user data based on JSON user string found in configuration file
• allow deserialization of new signed JWS token with userdata string as payload found in configuration file or returned by LiYuan cloud service

To make this change work the LiYuan backend service must return an additional result["datasigned"] value containing the JWS token when the user data is fetched. This is needed to allow backward compatibility to older SiYuan installations that rely on the return of plain userdata JSON string located at result["data"] (see

siyuan/kernel/model/cloud_service.go

Line 516 in da41c6a

dataStr := result["data"].(string)

)

Nonetheless this change wouldn't prevent patching and recompilation of kernel service to circumvent any paywalls, but

• without access to the private key used for signing the JWS token any forging of the user data inside the configuration file or by MitM Liyuan cloud service API calls, it is no longer possible to enable paywall features on a vanilla SiYuan installation
• you can verify the authenticity of a userdata structure in case someone wants to tell you that paywall feature foo was enabled providing his configuration file
• the userdata license data is protected by digital signature that can only be signed by SiYuan cloud services private key without breaking the open source statement by e.g. implementing proprietary blobs

[88250]

Hello, first of all, thank you for your help, but we decided not to use digital certificate signature after consideration. The main reason is that it can be easily bypassed through the source code, so in order not to add extra complexity, we gave up this part.

Can the two issues of the log be submitted separately? Thanks.

[88250]

Thank you #8977

[nekrondev]

Hi D,

I can understand your decision to reduce complexity as Siyuan frontend and kernel keeps growing and becoming more difficult to handle over time so this is no problem for me as it was fun to work with JWS.

With the digital signature my main idea was to prevent forging a vanilla installation of SiYuan, i.e. someone installs it using the official installers, replaces the (unsigned) userdata with a forged one enabling paywall features. Using a digital signature this wouldn't be possible anymore.

But you are right that this doesn't prevent patching the sources to bypass any paywall checks and it would also be possible to remove digital signature at all from the sources. Alas this comes with the penalty of cloning the source code, patching the source code and recompiling it to have a binary that must be replaced on your client(s). If you want to keep track with the frequent updates this soon could become annoying.

My second though, more on a LEGAL thinking, was to seal the contract between your customers and the subscription type they bought. The signed userdata could be seen as a signed contract for the activated paywall features that had been approved by you through the signature. The user gets the signed "contract" in return for paying for the additional features.

But in the end there is no secure solution for this problem if you plan to stay open source (which I really appreciate). Other projects and commercial services put things behind a cloud-based paywall for dedicated proprietary services that run inside the cloud. However this would break the promise of a local PKM, privacy and being fully open source.