As you already said, it doesn’t. Anyone with the chops can copy anything live on the web (unless crucial parts hidden in inaccessible php files). Especially if you’re familiar with Elements, you know exactly where to look.
There is literally nothing Elements could do to stop piracy. Just makes it a little more tedious.
Well, actually there is something Elements could do to totally stop piracy.
Elements could only load encoded packs. But this would mean sacrificing exclusivity of the Elements store, as if devs had the ability to encode so loadable in Elements, they could distribute outside the store.
I use “encoded” I mean code signed, in exactly the same way the Apple App Store works. Apple can shut a rouge dev down at any time by revoking the code signing certificate.
Just to clear this up…
The pack encryption in the Elements Store isn’t about trying to hide code that’s already published on the web. Nothing can stop someone from copying frontend HTML, CSS, or JS once it’s live. That’s true for every platform.
What the encryption does stop is the simple redistribution of actual addon packs. In the old RW ecosystem, people could easily share or pirate stacks, projects, and themes by passing around the raw bundle. With Elements, that isn’t possible.
It’s more complex than this, but in simple terms: The downloaded pack is encrypted and only a user that has purchased the addon pack can use it, so copying the pack itself is pointless. That’s the piracy it prevents.
This system protects developers from their products being passed around in the same way stacks were for years. It’s not trying to solve the impossibility of “preventing someone copying web output”, nobody can fix that, it solves the very real problem of protecting the packs themselves.
Thanks for the explanation, I already understood how it works. My question is whether developers who publish their components can get this information or not.
I don’t want to sound polemical, a developer has the right to have control over his work on his own computer, there is nothing wrong with asking for it. but if I have to invest time and sign a commercial contract with a company, I expect maximum transparency.
My job also involves promoting your product; telling me it’s not useful to me isn’t a reassuring response.
Will you add this info to the guide? My advice is to also include it in the guide so it’s clearer for anyone who wants to publish.
I have some products to publish and hope to do so.
Again, I appreciate what you’re doing and I’m thrilled to be a part of it.
I don’t want to sound polemical (again) , but you should consider us as professionals, not fans. Our work will ensure the continuity of RWclassic customers.
Element packs are stored in an encrypted, app-managed location, and we don’t make that path public. The main reason is that if users start digging around in there, even with the best intentions, it can easily lead to broken installations, missing assets, or corrupted data, which creates a lot of avoidable support issues.
Since the packs can’t be easily inspected, backed up, or used outside the app, there really isn’t any practical benefit to knowing where they live on disk. Everything related to backups, distribution, encryption, and entitlements is handled automatically by Elements Cloud and shouldn’t be a concern for developers or end users.
Any issues that arise in these areas will be handled entirely by us.
At this time I can’t see any benefit to disclosing the exact file location of installed packs. Is there a specific concern you have about the encrypted pack itself?
I was just following with popcorn 
to see if I could put a .elemetspack at that location and see if elements would load it on launch 
You have the app deligate method for application: NSApplication, open urls: [URL] locked down (no install the bundle at url in there)
Thanks again for the detailed reply, I understand some things better now.
I understand all the benefits of encryption and believe the system can work well; I also understand the concerns about archive protection.
In our case the problem is of communication, not technical, no info for devs.
We have the right to fully understand how it works; it contains our work; might this apply to those who sign the contract?
If the issue concerns trust with external developers, simply specify everything in the guide and in the contract itself. Just be clear and everything will work smoothly.
thanks!
We’re happy to improve the developer documentation so it clearly describes the high-level process of how encryption, licensing, backups, and responsibilities on our side vs. yours work. That level of transparency is absolutely reasonable.
However, information about the exact on-disk location, the layout of distributed packs, internal database structures, encryption keys, and key-management details are not things we plan to document or commit to publicly. These are internal implementation details that may change between versions, and exposing them will almost certainly cause more problems than it solves.
In terms of communication and transparency, we’re absolutely happy to discuss things like:
But we won’t be exposing:
You still haven’t explained what your specific concern is, or what scenario you feel you need these details for. Without that context, it’s hard for us to address the underlying issue.
Thanks for the answer,! if everything is specified in the guide it will be clearer to understand how it works 
Looks like I really stirred the pot with this post 