Re: Another "security" feature that SM can't handle

From	Dirk Fieldhouse <surname@gmx.net.plusremovethisandtherest.invalid>
Newsgroups	alt.comp.software.seamonkey
Subject	Re: Another "security" feature that SM can't handle
Date	2026-01-09 11:09 +0000
Organization	speaking personally
Message-ID	<10jqnkr$2ubbv$1@solani.org> (permalink)
References	<10jnedj$18bbc$1@dont-email.me> <R8K7R.64565$IUfa.9829@usenetxs.com> <10joj5o$1jt38$1@dont-email.me> <10joko9$1l0gp$1@dont-email.me>

Show all headers | View raw

The great feature here is that the graphical captcha shows a big tick if
you accept its challenge to slide the tile to the right end of its
travel, and **then** redirects to Access Blocked. With FF140, that
doesn't happen, and you get to see the sooper-sikrit demographic
projections.

Has anyone got the alternative voice challenge to work? It fails for me
because SM rarely manages to play sound once a few tabs are open,
apparently a long-standing Linux (32-bit?) issue.

My guess is that the JS is working up to the point where it has to set
the result cookie(s): either constructing (JS) or setting (3rd party
blocked?) the cookie(s).

>>> Paul B. Gallagher wrote:>>>...>>>>> Reuters uses the same type of test, from >>>>
<https://geo.captcha-delivery.com/captcha/>.
This (empty page) belongs to Data Dome.

At <https://github.com/MoterHaker/bypass-captcha-examples>, the French
tyre shop URL
<https://www.allopneus.com/liste/pneu-auto?saison[]=4seasons&saison[]=ete&saison[]=hiver&page=1>
is said to be protected, but not for me even after enabling datadome.co.
I would expected to be able to formulate my Peugeot tyre purchase at
least up to the point of completing the purchase.

/df

-- 
London
UK

Back to alt.comp.software.seamonkey | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Another "security" feature that SM can't handle "Paul B. Gallagher" <mozilla@pbg-translations.com> - 2026-01-08 00:13 -0500
  Re: Another "security" feature that SM can't handle Brian Schrimpp <schrimppb@no-spam.invalid> - 2026-01-08 09:45 +0100
    Re: Another "security" feature that SM can't handle "Paul B. Gallagher" <mozilla@pbg-translations.com> - 2026-01-08 10:40 -0500
      Re: Another "security" feature that SM can't handle Schugo <schugo@schugo.de> - 2026-01-08 17:07 +0100
        Re: Another "security" feature that SM can't handle Daniel70 <daniel47@nomail.afraid.org> - 2026-01-09 22:01 +1100
        Re: Another "security" feature that SM can't handle Dirk Fieldhouse <surname@gmx.net.plusremovethisandtherest.invalid> - 2026-01-09 11:09 +0000
      Re: Another "security" feature that SM can't handle Brian Schrimpp <schrimppb@no-spam.invalid> - 2026-01-10 09:48 +0100
        Re: Another "security" feature that SM can't handle "Paul B. Gallagher" <mozilla@pbg-translations.com> - 2026-01-10 15:04 -0500
          Re: Another "security" feature that SM can't handle Daniel70 <daniel47@nomail.afraid.org> - 2026-01-11 18:35 +1100
          Re: Another "security" feature that SM can't handle Brian Schrimpp <schrimppb@no-spam.invalid> - 2026-01-11 09:44 +0100
            Re: Another "security" feature that SM can't handle "Paul B. Gallagher" <mozilla@pbg-translations.com> - 2026-01-11 12:45 -0500
              Re: Another "security" feature that SM can't handle Daniel70 <daniel47@nomail.afraid.org> - 2026-01-12 20:05 +1100
                Re: Another "security" feature that SM can't handle ant@zimage.comANT (Ant) - 2026-01-13 01:34 +0000
                Re: Another "security" feature that SM can't handle Schugo <schugo@schugo.de> - 2026-01-13 02:39 +0100
                Re: Another "security" feature that SM can't handle ant@zimage.comANT (Ant) - 2026-01-14 03:42 +0000
                Re: Another "security" feature that SM can't handle Daniel70 <daniel47@nomail.afraid.org> - 2026-01-14 19:27 +1100
  Re: Another "security" feature that SM can't handle ant@zimage.comANT (Ant) - 2026-01-09 07:55 +0000

csiph-web