I'm not arguing the complexity of hacking a password, I'm familiar. So instead of responding with rainbow tables or how knowing the schema informs you the location of salts for the salted hash (which is the actual proper way), I'll just point to an example.
Look at how RSA is implemented. Look at the intentional obscurity of S tables and lack of detailed information.
There is a reason information is withheld. DB schema is just that, information that increases increases the threat.
And running a DB on someone's infrastructure doesn't necessarily give you access. You need to read up on AuthN and AuthZ.
If you listed an open source example I'd take the time to poke holes in your strawman argument but you honestly just need to take a step back and think about what you are really arguing.
Do you really think not having the schema is as inconsequential as having the schema when attacking something? I mean what is the first step most folks do in reverse engineering? I honestly can't believe I'm having to say this.
I don't want to take away any steam from your sails but giving bad information in regards to case law shouldn't be taken lightly. Your "expert witness" did you a disservice.
Schema is very much a critical field in terms of AuthZ privileges. Just knowing the structure is not far off from knowing the max entropy a password may hold. In regards to InfoSec, table structure is the recon phase which limits effort and minimizes time. Someone with that much time in security knows DBs will be hacked, not if but when. Time is an incredibly important tool which is why we have expirations on so many authN and authZ windows of attack.
I'm glad that you are challenging them but I believe a credible engineer would have made mince meat of your expert and hurt the rest of us who want to see you successful.
It's possible rewriting certain statutes can help us but there is no company worth its salt that would share DB schema.
I get what they are saying: There is a difference between theoretical and applied.
I think the OWASP/NIST/InfoSec has always been a bit behind because of this mentality. I think there is a progressive forward looking mindset that is often seen as "mad" or "unhinged" when it's ultimately throwing paint at a wall to see what sticks.
The driver is curiosity but then someone comes along and applies CBA and ROI, and CAC...the person who was curious has left because that wasn't the goal. Eventually something will stick that meets all of those mainstream ideas.
If you think of the body as a computer, it communicates through DNA, a much larger scale of information passing. Binary is just arbitrarily selected because it was there. Should we stop exploring binary computational systems? No but we also don't need all our eggs in one basket.
I'm not sure how I feel about this. On one hand kudos to them for the self-reflection, facing hard truths, and building a really wide set of tools.
But when you look under the hood it's tooling that wraps tooling. The API categorization tool arguably hands off a large portion of the heavy lifting to OpenAI.
"You are a world class categorizer. Fit these APIs into one of these groups."
The rest of the file is just wiring and a little blurring of the lines of model, view, and controller. I saw some testing and was like, okay this is going to be important if you are wrapping a lot of tooling because "change outside of your control" but then it's just a the default contextLoads() functional test Intellij gives that makes sure dependencies exist and nothing fails at compile.
I think the vision is there and it is definitely aligned to the Pareto principle but it feels like the idea was tested that markets aren't interested in maintaining their stuff while internally they haven't even addressed maintaining their own stuff.
Feels like a Catch 22 where if they could address that reason for themselves first then they could probably solve that for other people. But addressing it means having a product that is being used in order to feel the pain and empathize with the end user.
I'll be blunt, a lot of what you explained went over my head.
I saw some charts that expressed 1hz in the A4 range a bit higher but essentially what you explained. The lower in the scale the more cents per hz but each "scale" has 1200 cents broken up evenly per semitone.
We could create a reference chart that shows the "increase" in the scale in hz which would be a logarithmic curve while the cents would be growing linearly based on an underlying logarithmic scale.
In my previous response I was being prickly with the previous responder because they came off with strong "well awkshually..." energy.
I get what they are saying but I don't think it's outlandish to speak in hz when the extra precision from cents is arguably beyond the average musically trained ear.
Now that you are caught up with the rest of us, read my response.
Am I saying I don't understand or am I saying I understand but the response is too nitpicky for me and what I feel is reasonably acceptable by the average person.
Tell me you don't understand how the ear perceives music without telling me you don't understand.
Don't be pretentious man, we are tuning guitars and violins not prepping the kids for Juliard.
The same as how you use hz to talk about a specific note, your ear understands hz when listening. Cents are just ratios of intervals subject to a given scale. Do you think we are so bad we are messing up A3 as being close to B5?
How about we use Just Intonation or 12-TET? But then should we base it on 5 limit[0] or Pythagorean[1] tuning.
The way the article read it seemed as they though they had many domains and customers could bring theirs into that ecosystem.
If the customer left it behind they could send it to the wayside.
If they are merely a broker then I agree, I don't see them as rent-seeking. The article left me with the impression that they had a large number of domains they rent out to customers.
You own the domain. You can take it and they can't withhold it.
The registrar is already doing what this site is doing. I don't have a problem with a site making it easy to setup. It's the site holding a thousand website domains.
What you are asking for is different.
If FolioHD said:
Have a domain in mind that you'd like to use? Type it here and we'll do all the work setting that up.
What they are actually doing is:
We've bought these 900~ domains and we are holding them. Pick one you'd like and we'll set it up.
If you want to be an artist then control of your intellectual property is probably a topic you care a great deal about.
Your domain and how people reach you is probably the first lever. If you are giving that up happily, I assume renting without the option to own or leasing a car is a sensible business model to you and you are just experimenting without any real intention of starting.
The effort and time in becoming an artist outweighs by at least two or three orders of magnitude the time it would take to read an article and setup a domain. Namecheap, GoDaddy, all these registrar's do it for you.
Imagine having 900 houses and renting them out to a community of like minded folks.
Whether it is at cost or slightly above, it is "rent seeking" in the sense they own, you borrow.
I feel like this article is more of a "Here's all the things I think about perfect pitch and my journey with music"
Maybe I took the title too literally.
As someone who wants to gain perfect pitch (and still feels mildly distant from this ability) one thing I can say has been the most helpful:
* Get a string instrument
* Strum the strings
* Try to tune the first string by ear
* Once you think you have it, check it against a chromatic tuner.
This way will you see how progressively your feeling of "in tune" can be measured in hertz.
I can get pretty pretty close (within about 5hz).
I used to have competitions with my children on who could get the note closest without a tuner. One of my kids got pretty good where they could almost nail it within 1 hz. It made things fun and a little less "maintenance".
The best way I can describe the process is you have a sensitivity to a threshold of being in tune. I hear the note but there is something inside myself, it almost feels like anxiousness that kinda peaks right before I hit the note and then stops when I "feel" I've hit that note I'm aiming for. As I've said, I can get within about 5hz which to a musician they can probably notice it is off but for the average ear, it feels muddy but close.
Long story short, practice with a tuner and within a year you'll surprise yourself.
Tradeoffs for mono are drivers of micro and vice versa.
Looking at the GitHub insights it becomes pretty clear there are about two key devs that commit or merge in PRs to main. I'm guessing this is also whom the code reviews happen etc. Comparing itself to Linux where the number of recurring contributors are more by orders of magnitude just reeks of inexperience. I'm being tough with my words because at face value, the monorepo argument works but it ends in code-spaghetti and heartache when things like developer succession, corporate strategy, market conditions throw wrenches in the gears.
Not for nothing I think a monorepo is perfectly fine when you can hold the dependency graph (that you have influence over) in your head.
Maybe there's a bit of /rant in this because I'm tired of hearing the same problem with solutions that are spun as novel ideas when it's really just: "Pre-optimization is the root of all evil."
You don't need to justify using a monorepo if you are small or close to single threaded in sending stuff into main. It's like a dev telling me: "I didn't add any tests to this and let me explain why..."
The explanation is the admission in my mind but maybe I'm reading into it too much.
Article is nicely written and an enjoyable read but the arguments don't have enough strength to justify. You are using a monorepo, that's okay. Until it's not, that's okay too.
I think this has more to do with testing, maintenance, and how it simplifies portability/flexibility.
There is a point where software diving down meets the hardware coming up. When you import a library you start creating harder to separate internals and testing becomes more of a blackbox approach (I don't care what happens inside as long as my results are consistent) as opposed to unit and function. It eventually does reach a point where dependencies are harder wired but the deeper you can create this DI, the more dynamic things become (function arguments, library injection, os virtualization, even hardware at points [PCI-E, serial]).
I think you are right about DI being less common but that is because it's not a natural reaction until you reach the maintenance side of software. It's much easier (and more performant) to just load it up on startup and call it directly. When you get into the way languages work you will see DI is integral to their accessibility and maintenance.
Look at how RSA is implemented. Look at the intentional obscurity of S tables and lack of detailed information.
There is a reason information is withheld. DB schema is just that, information that increases increases the threat.
And running a DB on someone's infrastructure doesn't necessarily give you access. You need to read up on AuthN and AuthZ.
If you listed an open source example I'd take the time to poke holes in your strawman argument but you honestly just need to take a step back and think about what you are really arguing.
Do you really think not having the schema is as inconsequential as having the schema when attacking something? I mean what is the first step most folks do in reverse engineering? I honestly can't believe I'm having to say this.