I was asked many times to build something similar to owayo although not perfect but I’ve tried imitating the features and experience here https://globaltech-jersey.netlify.app/ . But something caught my eyes when I want to try using their 3d model, I download the file from the devtools network tab, the 3d file has extension of .mirl which I think it’s their/developer own proprietary binary file.
I’m not sure how they do it, so I go ahead creating something similar, the point is to prevent anyone to use my client’s 3d models. So here’s what I did and hopefully you guys have an idea on how to improve it.
Basically I modify a GLB file, obfuscate the content with a secret key. Then on my app, I made a custom loader extending the GLB and DRACO loader but i deobfuscate the file first with the same secret key , create a blob then use DRACO loader to load the blob file.
Currently do the trick, I can use whatever extension I want but not sure if this is something close to production-ready solution, any thought?
You cannot.
You can only make it difficult or very difficult, but you cannot make it impossible, unless you do everything server-side and stream images/video to the client.
And even this will soon be questionable, as I’ve already seen AI reconstructing a 3D model from a series of images.
1 Like
Yes what i mean is that, preventing anyone from re purpose/leveraging my client’s 3d model. Take Owayo for example, I never heard .mirl extenstion before, which i couldn’t figure out how to somehow alter the 3d model so I can leverage that file illegally. That’s what i want to achieve, currently by obfuscating with secret key do the trick and export to .nts file which no one could’ve guess what it is
although I’m happy with current implementation, I also made blender extension so it’s easier for future projects, I’m looking for an advice on how to improve this implementation
I think obfuscation is a reasonable compromise for a client who is concerned about the data being “misused”, and the technical reality: rendering a 3D model on someone else’s GPU means you must give them the data in a machine-readable format, no matter how many hoops the data jumps through before arriving in that format.
If you can explain the limitations to the client, all the better, but if your Blender extension works well and deobfuscation is fast (not causing hitches during pageload) then I probably wouldn’t worry much more about it.
1 Like
not sure what u mean by this, do we able to access someone else threejs scene from devtools?
1 Like
Currently working well without any hiccup, thanks I think for now I’ll keep this as temporary solution until I found the best way to achieve this
Yes you can export or extract models from a webgl app in a variety of ways ranging from simple (scene.toJSON()) to more complex tools like spectorjs or other chrome extensions.. down to even lower level tools on the desktop like ninjarippper et al. (Not limited to web)
Hmmmm I’ll think about it, thanks. I guess that’s for some serious developer who wants to misused our assets, but good to know I’ll find a better solution to achieve this or check if my solution still solid even with that abuse
I don’t think there are many workarounds short of only transmitting/decoding/displaying mangled versions of your assets.
If it’s being rendered on your GPU.. someone can read it.
I’m not saying I don’t want someone read the file, what I mean is preventing user from ilegally using my clients 3d model for their own product. If u try opening Spized configurator, we can ilegally download .glb file which we can later ilegally use using glb/draco loader, but with Owayo it has .mirl file extension which no one knows what it is, can’t be opened on threejs editor or blender let alone use it on our own app, at least to my current knowledge
I guess just save your .glb as a .naonao instead. 
1 Like
yes that’s what I did, but since u can inspect glb, I obfuscate/encrypt the content so people won’t be able to use it even if they download the file or try to open as glb, unless they have the key
Right but as soon as its loaded and displaying on their machine, they can grab it from the scene graph in the debug console… or put a breakpoint at the end of your decryption routine, and intercept it there.
I’m not trying to be negative.. just letting you know that this can and most likely will happen if there is any hint of commerce involved in your app.
2 Likes
This may be misconstrued as demeaning… your three journey in “the industry” will dictate!
Subscription models (Adobe, GamePass) now often require an Internet connection to access content. This implies a tracking beacon with long polling. In your case, the client could (1) log on restricted by geolocation (2) receive partial loads from multiple obfuscated servers (3) combine them using some randomized harmonic key embedded in the asset (4) notify lawyers if logs report any violation. Depending on your countries the lawsuit may be more profitable than the core sales model. Needless to say, countersuits may follow… or anonymous correspondences outside of your spotless SOTA business reputation.
~ Hayseed “WADboard” Carmack
Right, tho I’m curious how we access scene graph in debug console?
I Understand, anyway just want to put my client’s mind at ease someone won’t steal and leverage their 3d models for their product. Because it has happen before, multiple times I saw my client downloading all of the competitor’s assets without permission, I don’t think it’s ethical to do even if we can download it doesn’t mean we can own it, cmiiw
1 Like
You hit the pause button.. it will randomly break somewhere in the code but usually on the boundary of some running process like requestAnimationFrame…
You may have to pause/resume a few times.. Or you can look in the sources tab to find the most likely main source file.. (perhaps based on clues of loading order of assets vs js in the network tab)
Once you have it paused inside a requestAnimationFrame.. you step through until you see something like renderer.render, and you know the first parameter to that is the scenegraph.
Sometimes it will be obfuscated to o.e( i,j ) or something.. but… the pattern is usually there in some form. You then mouseover that structure to inspect .children, or in the chrome console.. i.toJSON()