Path: ...!Xl.tags.giganews.com!local-3.nntp.ord.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 10 Apr 2025 03:11:11 +0000
Subject: Re: Rewriting SSA. Is This A Chance For GNU/Linux?
Newsgroups: comp.os.linux.advocacy,comp.os.linux.misc
References: <pan$54963$b3f3d4e6$ae35ff46$71fe05c9@linux.rocks>
 <m581c7Fd22eU2@mid.individual.net>
 <DJOdnXslWrdAbHP6nZ2dnZfqnPudnZ2d@giganews.com>
 <m58mnpFguqjU2@mid.individual.net> <vso5qc$31clb$1@dont-email.me>
 <E2WdnXiNaZ9CTXL6nZ2dnZfqn_idnZ2d@giganews.com>
 <pan$f2307$df5236a$923c4908$a6fb4a1f@linux.rocks>
 <6BidndvG26Vec236nZ2dnZfqnPadnZ2d@giganews.com>
 <vsr383$2421k$1@dont-email.me>
 <Tz2dnbEsYvaaHmz6nZ2dnZfqnPWdnZ2d@giganews.com>
 <vss108$2vde2$6@dont-email.me>
 <MI-dnf3_6bzzM2z6nZ2dnZfqnPidnZ2d@giganews.com> <vt1d6c$e0sl$2@dont-email.me>
 <TsudnYL_HJhO12n6nZ2dnZfqnPidnZ2d@giganews.com>
 <1834560e02e32793$90856$735129$802601b3@news.usenetexpress.com>
 <vt3456$26qph$1@dont-email.me>
 <9PCcnTNvhsJdr2j6nZ2dnZfqnPGdnZ2d@giganews.com>
 <vt40q3$2rc8f$4@dont-email.me> <f9iJP.1877219$t84d.916817@fx11.iad>
 <wv6dndwsnOkdRmj6nZ2dnZfqn_ednZ2d@giganews.com> <vt6dl2$k23l$3@dont-email.me>
 <x2ydndjj6556QGv6nZ2dnZfqnPWdnZ2d@giganews.com>
 <vt7ami$1dt37$7@dont-email.me>
From: c186282 <c186282@nnada.net>
Date: Wed, 9 Apr 2025 23:11:06 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <vt7ami$1dt37$7@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <u56cneefVq9Sq2r6nZ2dnZfqnPqdnZ2d@giganews.com>
Lines: 122
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Y49ckVPRm7XITKaJsX36vtLcpU24El0sVph4Q4jHmPdYR8GFqhcTiDPcTRz2IwExjQIlx7cWYHj5Ue/!UcRj1Raltbn61ZF0uFmVZi+KQnj4QISaQcUjZNrw9d43+O4ATroT6mgBnz3OBIjSnPcdXupIJ6eo
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
Bytes: 7282

On 4/9/25 10:33 PM, -hh wrote:
> 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.

   Alas, the box is only "black" to OUR people.

   Remember a few months ago when China got into
   several major US phone/net carriers - and DID
   mess with them ?

   They got partway into the systems, then probed
   everything they found and found FLAWS they could
   exploit. THEY put 100 times more effort into it
   than the corp people spent looking for flaws.

   EVERY page is likely to have one or two tiny
   flaws - so the FEWER pages "They" can get into
   the system the BETTER.


>>    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".

   THIS time, maybe. But some deck chairs are better
   than others.

   Alas, as long experience shows, there's likely NO
   way to solidly secure any public-facing system -
   esp with interactive web pages and such. Instead
   it becomes a statistical exercise. Can the damage
   be kept SMALL/RARE ?

   The cyber-access paradigm DOES seem to be the
   harbinger of doom. "They" have proven they CAN
   get into ANYTHING net-connected - govt, banks,
   utilities, nuke plants ... anything. There are
   ALWAYS sneaky back-doors, ALWAYS flaws that can
   be exploited.

   I'll go back awhile to when the USA exploited
   flaws in Siemens industrial-process units to
   trash all the Iranian uranium centrifuges.
   Alas, now, "They" can instruct yer local nuke
   reactor to pull all its control rods, or just
   shut down a cooling pump, or distort sensor
   readings, or .... the more access the more
   "in"s ..........

   2FA ? 3FA ? Required biometrics ? It can ALL
   be faked these days. "Security" is more a
   collective illusion/delusion.