Re: Rewriting SSA. Is This A Chance For GNU/Linux?

On 4/9/25 16:51, c186282 wrote:

On 4/9/25 2:18 PM, -hh wrote:

On 4/8/25 22:29, c186282 wrote:

On 4/8/25 7:18 PM, Charlie Gibbs wrote:

On 2025-04-08, -hh <recscuba_google@huntzinger.com> wrote:
>

Plus front-loading it before you've run your in-house checks means that
your operating expenses to this contractor service go UP not down. Yes,
that's a deliberate waste of taxpayer dollars.

>
You'd think someone would want to try to reduce that waste.
Maybe set up a Department Of Government Efficiency or something...

>
>
   Hey ... humans are only JUST so smart, AI is
   even more stupid, and govt agencies .........
>
   Likely the expense of the earlier checks do NOT add
   up to much.

>
It might not be, but in this case, the benefit of the change is literally zero ... and the expenses are not only more money to the contractor who gets paid by the check request, but also the cost of higher bandwidth demands which is what caused the site to crash.
>
>

   I did mention one possible gain in doing the ID checks
   earlier - giving Vlad and friends less access to the
   deeper pages/system, places where more exploitable
   flaws live.
   In short, put up a big high city wall - then you>    don't have to worry AS much about the inner layers
   of the city.

>
I don't really buy that, because of symmetry: when the workflow is that a request has to successfully pass three gates, its functionally equivalent to (A x B x C) and the sequence doesn't matter:  one gets the same outcome for (C x B x A), and (A x C x B), etc.
>
The primary motivation for order selection comes from optimization factors, such as the 'costs' of each gate: one puts the cheap gates which knock down the most early, and put the slow/expensive gates late, after the dataset's size has already been minimized.

     I understand your reasoning here.
    The point I was trying to make is a bit different
   however - less to really do with people trying to
   defraud the system but with those seeking to
   corrupt/destroy it. I see every web page, every
   bit of HTML/PHP/JS executed, every little database
   opened, as a potential source of fatal FLAWS enemies
   can find and exploit to do great damage.
    In that context, the sooner you can lock out pretenders
   the better - less of the system exposed to the state-
   sponsored hacks to analyze and pound at relentlessly.

Sure, but that's not relevant here, because from a threat vulnerability perspective, its just one big 'black box' process.  Anyone attempting to probe doesn't receive intermediary milestones/checkpoints to know if they successfully passed/failed a gate.

   Now Musk's little group DID make a mistake in
   not taking bandwidth into account (and we do
   not know how ELSE they may have screwed up
   jamming new code into something they didn't
   write) but 'non-optimal' verification order
   MIGHT be worth the extra $$$ in an expanded
   'security' context.

Might be worth it if it actually enhanced security.  It failed to do so, because their change was just a "shuffling of the existing deck chairs".
-hh