Anti-Piracy Placeholder: Unique ID for a user (that the user doesn't know)

[Vankka]

The %%__USER__%% placeholder is a good idea in theory, but it's very trivial to find it in a plugin's source code. What i'm suggesting is a secondary ID; that would be based on the user id but encrypted on a per-resource or per-resource author basis, so the resource author can reverse the encryption, but the downloader wouldn't be able to find it (without reverse engineering the whole anti piracy system).

The only potential problem would be having to change the encryption key; I'd suggest that every new version that is released should use the most recently uploaded key when the update was made

 

[Vankka]

Instead of that it would be better if they made a licensing api so that users could generate a license key on website which would be linked to resource.

this would be good for any kind of software so we could have a licensing system in place for everything not just plugins.

The placeholders already act like a pseudo license, without the user actually having to generate a license key; as you can disable any specific file (%%__NONCE__%%) or all of a specific users files (%%__USER__%%). Making the user generate a key seems like a unnecessary step to using a product.

The placeholders are already compatible with all kinds of software (at least any language the replacer can handle)

 

[Justis]

This whole "pseudo anti-piracy system" is a joke. It should be an authentication api so users can login to their programs with their mcm account and check if they have access to the resource.

How would such a system work with any resource section other than java plugins?
Moreover, that idea is actually much less effective in practice than proper implementation of the placeholders we’re providing. If MCM provided a standard DRM system that was injected into all plugins upon download, every cracker that downloads a resource would know exactly what to look for, exactly where to look for it, and once they figure out how to remove it, they’ll have figured out how to remove it for every resource on our website. Once a pattern is established, you could even write a short script to remove the DRM system from any file automatically.
When you give someone a file, you give them complete control to manipulate that file. The reason we went with placeholders like these, is because it forces resource authors to come up with their own (hopefully unique) DRM systems, which cannot be predicted and simply removed by crackers. They won’t know what to look for each time, and they’ll make mistakes, they’ll miss something, and we’ll catch them.

The %%__USER__%% placeholder is a good idea in theory, but it's very trivial to find it in a plugin's source code. What i'm suggesting is a secondary ID; that would be based on the user id but encrypted on a per-resource or per-resource author basis, so the resource author can reverse the encryption, but the downloader wouldn't be able to find it (without reverse engineering the whole anti piracy system).

The only potential problem would be having to change the encryption key; I'd suggest that every new version that is released should use the most recently uploaded key when the update was made

Already suggested here: https://www.mc-market.org/threads/552978/#post-4337750
But I do think this is a very very good idea.

 

[Justis]

I think you misunderstood me. I'm suggesting an http api so users can sign into their mcm account, the same way discord, GitHub, and many other sites do it. It would work on all platforms, and would be less janky than the current system.

EDIT: I just realized you meant platforms outside of programs, in that case the current system is best for that. Outside of cases like graphic design where implementing an oath flow is impossible, I think a proper api will be much more secure.

I must have misunderstood you. When you called the injection system a joke and proposed something else, I assumed you meant it to be a replacement, rather than something to augment the current anti-piracy features.
In that case, we already have an API planned. The current plan is to make it available solely to Ultimate users, which will allow us to offer far more features with less restrictions and not need to worry so much about abuse. However, I’m personally still open to changes. If you have any features you really want to see included in this, I’d be interested in reading about them and probably incorporating them into our development documentation. A suggestion thread specifically for that would be best, though.

 

[Vankka]

This whole "pseudo anti-piracy system" is a joke. It should be an authentication api so users can login to their programs with their mcm account and check if they have access to the resource.

I think you misunderstood me. I'm suggesting an http api so users can sign into their mcm account, the same way discord, GitHub, and many other sites do it. It would work on all platforms, and would be less janky than the current system.

EDIT: I just realized you meant platforms outside of programs, in that case the current system is best for that. Outside of cases like graphic design where implementing an oath flow is impossible, I think a proper api will be much more secure.

Anyone reverse engineering your program will also know the exact URLs and Responses for that api (just by reading the documentation); so they can 1) find it (eg. look for the url if not obfuscated) and remove it, or 2) imitate it & always give a success response. Yes both of these are also possible with the placeholder system, however more difficult.
Obviously this does have some benafits; nobody would share their credentials, and checking the buyer list directly. But the latter could also be accomplished using the placeholder system (eliminating the first point); User with the program -> Program's server -> MCM buyer list api (if such an api existed). Without every having to prompt the user to login.

 

[Jack]

When you give someone a file, you give them complete control to manipulate that file. The reason we went with placeholders like these, is because it forces resource authors to come up with their own (hopefully unique) DRM systems, which cannot be predicted and simply removed by crackers. They won’t know what to look for each time, and they’ll make mistakes, they’ll miss something, and we’ll catch them.


Already suggested here: https://www.mc-market.org/threads/552978/#post-4337750
But I do think this is a very very good idea.

Concerning developers implementing their own DRM - do you mean selling products outside of MCM, or somehow leveraging these placeholders? Having some sort of MCM API endpoint to verify a nonce or purchase ID would help with this, but at the moment the placeholders just seem to be for traceability, no? If something gets leaked, you know who leaked it, as you said.

It would also be possible (but not for all types of resources, as you mentioned) to have a user enter their MCM credentials and login to the application to be able to use it (obviously up to the developer to implement it, so you would have to trust them that they're not saving your user/pass), but between Cloudflare and MCM's ToS I think there are better solutions.

For example, every user on MCM could have access to their own resource/API key (think about how you can get a developer API key from Twitter, etc) which could be used to verify a user, without needing their credentials.

 

[Mick]

As Justis has said, there is another suggestion that was created just a few hours before this one about the same idea, which has now been set to pending for us to work on implementing in the future.

I'll move this to denied, thanks for the suggestion