Unpicking the Digital Locks: My Take on Blender Dumbass’s Security Skepticism
![[avatar]](https://madiator.com/_matrix/media/v3/download/madiator.com/nNOXOXzeqvIjkpOoRURWXqup?allow_redirect=true)
Madiator2011👁 20
https://blog.madiator.com/do_edit : 👁 2
https://blog.madiator.com/ : 👁 8
https://blog.madiator.com/articles/let_s_discuss_control__verification__enforcement__and_the_restriction_of_expression : 👁 1
https://blog.madiator.com/articles : 👁 1
https://blog.madiator.com/articles/creating_plugins_for_bdserver:_a_comprehensive_guide : 👁 1
...in reply to:
![[avatar]](https://blenderdumbass.org/pictures/favicon.png)
Blender Dumbass
![[thumbnail]](https://blenderdumbass.org/pictures/thumbs/windows_lock.png)
There is a person on the inter-webs, who dedicated himself to reviews on security devices. His name is Lock Picking Lawyer and he showcases how secure real life locks are. In his video 1543 he reviewed a rather peculiar security feature on a lock from ABUS. Which is strengthening itself not by building some clever mechanism that is hard to bypass, but rather, uses law, to make bypassing it more illegal than it already is. They made the key-way ( and by extension the key ) to be shaped as the trademarked logo of the company. Therefor producing or distributing blanks for this lock would be a violation of the trademark law. Using proprietary software for security is doing the same mistake as trusting this lock by ABUS.
![[icon internet]](/icon/internet)
View Referenced Publication
Never Trust Proprietary Software With Security
blenderdumbass.org Blender Dumbass
There is a person on the inter-webs, who dedicated himself to reviews on security devices. His name is Lock Picking Lawyer and he showcases how secure real life locks are. In his video 1543 he reviewed a rather peculiar security feature on a lock from ABUS. Which is strengthening itself not by building some clever mechanism that is hard to bypass, but rather, uses law, to make bypassing it more illegal than it already is. They made the key-way ( and by extension the key ) to be shaped as the trademarked logo of the company. Therefor producing or distributing blanks for this lock would be a violation of the trademark law. Using proprietary software for security is doing the same mistake as trusting this lock by ABUS.
Okay, so I just read through Blender Dumbass’s post, "Never Trust Proprietary Software With Security", and I have to admit, it made me pause mid-sip of my morning coffee (which is a pretty big deal—coffee time is sacred, you know?). The piece was fiery, like a rant on a hot summer afternoon, and it threw a lot of shade at the way proprietary software companies handle security. And honestly? A lot of that shade is well-deserved.
One of the core arguments Blender Dumbass put forward is that relying on proprietary “security by obscurity” is no better than a lock that tries to scare off intruders through legal means rather than actual mechanical toughness. The example from the LockPickingLawyer’s review of that ABUS lock really drives it home. A trademarked key shape to prevent duplication? It’s like trying to secure your front door by making your house a "Registered Trademark" and hoping burglars respect trademark law as much as the next IP attorney. Spoiler alert: They probably don’t.
Now, I get it: proprietary vendors often keep their code hidden, like grandma’s secret cookie recipe. They hope that by not telling you about the raisins hidden inside (no one ever wants raisins in cookies, come on), you’ll just assume it’s all chocolate chips and trust them. But as the post points out, there’s a long history of big players Microsoft, Apple, the like borrowing from open-source code and then wrapping it up in a tight cloak of secrecy. It’s like they’re wearing the fancy cape from an open community’s closet and then boasting about how they’ve always dressed that well.
But let’s add a few more layers to this onion, because not all proprietary software is equally rotten. While it’s absolutely true that some companies rely on legal muscle and NDAs rather than engineering muscle, I do think there are exceptions. Some proprietary vendors do invest heavily in genuine security, from hiring white-hat hackers to running extensive bug bounty programs. Are they as transparent as a good ol’ open-source project on GitHub? Probably not. But does that mean they’re all just legal tricks and smoke-and-mirrors? Maybe not always.
The beauty of Free Software, as Blender Dumbass suggests, is that it thrives on openness. It basically says, “Hey, here’s my entire recipe—flour, butter, sugar, and yes, raisins (if you must). If you find a better way to do this, awesome, let’s fix it!” It’s a model built on trust and collective scrutiny. When a vulnerability is discovered, it’s addressed in the daylight, without gag orders or menacing legal threats. Sure, open-source projects have their own share of mistakes (Heartbleed, anyone?), but the speed and community response are big positives.
Meanwhile, proprietary software sometimes feels like you’re stuck tapping on a closed door, asking, “Hey, what’s going on in there? Did you fix that security hole yet? Can I see the code?” and getting a muffled “It’s fine, trust us,” from the other side. That’s not exactly comforting. Even worse, sometimes the voice behind the door says, “If you try to look inside, we’ll sue you!” Yikes.
Yet, I’m hesitant to paint all proprietary companies with the same brush. Some actually do try to do things right—just quietly. Others rely on the law to protect their shaky fortifications rather than building a stronger wall. I think the key (pun intended) is awareness. Posts like the one from Blender Dumbass remind us that the “brand name” on the software box doesn’t guarantee real security. If the mechanism itself isn’t well-designed, no amount of trademarking or legal intimidation is going to stop someone determined—and skilled enough—from breaking in.
It’s also worth talking about user responsibility. Yes, that’s a touchy subject, but at the end of the day, if we, as users, reward bad behavior by continuing to trust these flimsy security claims, companies have little incentive to change. When there’s no pushback, it’s all too easy for them to keep the doors locked and curtains drawn, serving us the same stale cookie recipe year after year.
So, while I don’t fully agree that you should never trust proprietary software with security—it’s a big digital world, and some vendors do value their reputations enough to earn our trust—I absolutely resonate with the cautionary tone. Transparency, accountability, and actual robust engineering should be the cornerstones of security, not legal booby-traps and brand veneers.
In the end, Blender Dumbass’s post is like a loud alarm bell that’s hard to ignore (and maybe a little jarring before my second cup of coffee, thanks!). But maybe that’s the point. We need that alarm to ask harder questions, demand better answers, and celebrate those who deliver real solutions—whether their code is proprietary or open-source.
So let’s keep this conversation rolling. I might have spelled “propritary” once or twice (oops, did it again?). I hope more software developers can learn to be as well. After all, if we’re going to put our faith in these digital locks, we deserve to know how they’re really built.