Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Post History

81%
+7 −0
Q&A Is there a problem in making Captcha an HTML builtin with an attribute setting which type of Captcha

As the comments in that thread mention, Captcha is a service, not mere software. The distinction is that Captcha are in an arms race with spammers, and must continually evolve to remain effective. ...

posted 4y ago by meriton‭  ·  edited 4y ago by meriton‭

Answer
#3: Post edited by user avatar meriton‭ · 2021-03-23T15:22:19Z (almost 4 years ago)
  • As the comments in that thread mention, Captcha is a service, not mere software. The distinction is that Captcha are in an arms race with spammers, and must continually evolve to remain effective.
  • In particular, many popular Captcha approaches have been made obsolete by advances in AI: The "distorted text as image" trick was made largely obsolete by advances in text recognition algorithms, and the "identify this image" trick will likely be made obsolete in the near future by innovations in image recognition fueled by the development of self driving cars (in fact, training AI systems is probably the reason Google offers reCAPTCHA as a service in the first place).
  • This continued evolution makes Captcha standardization difficult:
  • * If W3C standardizes an implementation, it will require browser vendors to participate in this arms race, which they have no incentive to do. In addition, if the standardized approach becomes insecure, W3C and all browser vendors would need to fix that quickly, but the W3C standardization process often takes years, which is a wholly unsuitable time period for fixing security issues.
  • * If W3C did not standardize the implementation, browsers would offer radically different levels of security. Since the website wishing to employ a Captcha must trust that security, it won't want to buy a pig in a poke, so will likely not use the browser feature, but continue to use Captcha services of known quality, making the standardized Captcha feature useless.
  • The only benefit standardization could possible provide is to define a uniform interface for embedding Captcha provided by third parties into a website, but since embedding Captchas is trivial with the means HTML already provides, this wouldn't add significant value.
  • So the key difference between Captchas and a date input is that Captchas must evolve alongside the start of the art of AI research, but date inputs can remain as they are for ever.
  • And by the way, even the standardization of date inputs by W3C was not really successful, because the browser implementations are of such varying quality that many web developers prefer custom JavaScript controls for consistency of user experience. For instance, MDN [writes](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date):
  • > At the moment, the best way to deal with dates in forms in a cross-browser way is to have the user enter the day, month, and year in separate controls, or to use a JavaScript library such as jQuery date picker.
  • As the comments in that thread mention, Captcha is a service, not mere software. The distinction is that Captcha are in an arms race with spammers, and must continually evolve to remain effective.
  • In particular, many popular Captcha approaches have been made obsolete by advances in AI: The "distorted text as image" trick was made largely obsolete by advances in text recognition algorithms, and the "identify this image" trick will likely be made obsolete in the near future by innovations in image recognition fueled by the development of self driving cars (in fact, training AI systems is probably the reason Google offers reCAPTCHA as a service in the first place).
  • This continued evolution makes Captcha standardization difficult:
  • * If W3C standardizes an implementation, it will require browser vendors to participate in this arms race, which they have no incentive to do. In addition, if the standardized approach becomes insecure, W3C and all browser vendors would need to fix that quickly, but the W3C standardization process often takes years, which is a wholly unsuitable time period for fixing security issues.
  • * If W3C did not standardize the implementation, browsers would offer radically different levels of security. Since the website wishing to employ a Captcha must trust that security, it won't want to buy a pig in a poke, so will likely not use the browser feature, but continue to use Captcha services of known quality, making the standardized Captcha feature useless.
  • The only benefit standardization could possible provide is to define a uniform interface for embedding Captcha provided by third parties into a website, but since embedding Captchas is trivial with the means HTML already provides, this wouldn't add significant value.
  • So the key difference between Captchas and a date input is that Captchas must evolve alongside the state of the art in AI research, but date inputs can remain as they are for ever.
  • And by the way, even the standardization of date inputs by W3C was not really successful, because the browser implementations are of such varying quality that many web developers prefer custom JavaScript controls for consistency of user experience. For instance, MDN [writes](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date):
  • > At the moment, the best way to deal with dates in forms in a cross-browser way is to have the user enter the day, month, and year in separate controls, or to use a JavaScript library such as jQuery date picker.
#2: Post edited by user avatar meriton‭ · 2021-03-23T12:36:58Z (almost 4 years ago)
  • As the comments in that thread mentions, Captcha is a service, not mere software. The distinction is that Captcha are in an arms race with spammers, and must continually evolve to remain effective.
  • In particular, many popular Captcha approaches have been made obsolete by advances in AI: The "distorted text as image" trick was made largely obsolete by advances in text recognition algorithms, and the "identify this image" trick will likely be made obsolete in the near future by innovations in image recognition fueled by the development of self driving cars (in fact, training AI systems is probably the reason Google offers reCAPTCHA as a service in the first place).
  • This continued evolution makes Captcha standardization difficult:
  • * If W3C standardizes an implementation, it will require browser vendors to participate in this arms race, which they have no incentive to do. In addition, if the standardized approach becomes insecure, W3C and all browser vendors would need to fix that quickly, but the W3C standardization process often takes years, which is a wholly unsuitable time period for fixing security issues.
  • * If W3C did not standardize the implementation, browsers would offer radically different levels of security. Since the website wishing to employ a Captcha must trust that security, it won't want to buy a pig in a poke, so will likely not use the browser feature, but continue to use Captcha services of known quality, making the standardized Captcha feature useless.
  • The only benefit standardization could possible provide is to define a uniform interface for embedding Captcha provided by third parties into a website, but since embedding Captchas is trivial with the means HTML already provides, this wouldn't add significant value.
  • So the key difference between Captchas and a date input is that Captchas must evolve alongside the start of the art of AI research, but date inputs can remain as they are for ever.
  • And by the way, even the standardization of date inputs by W3C was not really successful, because the browser implementations are of such varying quality that many web developers prefer custom JavaScript controls for consistency of user experience. For instance, MDN [writes](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date):
  • > At the moment, the best way to deal with dates in forms in a cross-browser way is to have the user enter the day, month, and year in separate controls, or to use a JavaScript library such as jQuery date picker.
  • As the comments in that thread mention, Captcha is a service, not mere software. The distinction is that Captcha are in an arms race with spammers, and must continually evolve to remain effective.
  • In particular, many popular Captcha approaches have been made obsolete by advances in AI: The "distorted text as image" trick was made largely obsolete by advances in text recognition algorithms, and the "identify this image" trick will likely be made obsolete in the near future by innovations in image recognition fueled by the development of self driving cars (in fact, training AI systems is probably the reason Google offers reCAPTCHA as a service in the first place).
  • This continued evolution makes Captcha standardization difficult:
  • * If W3C standardizes an implementation, it will require browser vendors to participate in this arms race, which they have no incentive to do. In addition, if the standardized approach becomes insecure, W3C and all browser vendors would need to fix that quickly, but the W3C standardization process often takes years, which is a wholly unsuitable time period for fixing security issues.
  • * If W3C did not standardize the implementation, browsers would offer radically different levels of security. Since the website wishing to employ a Captcha must trust that security, it won't want to buy a pig in a poke, so will likely not use the browser feature, but continue to use Captcha services of known quality, making the standardized Captcha feature useless.
  • The only benefit standardization could possible provide is to define a uniform interface for embedding Captcha provided by third parties into a website, but since embedding Captchas is trivial with the means HTML already provides, this wouldn't add significant value.
  • So the key difference between Captchas and a date input is that Captchas must evolve alongside the start of the art of AI research, but date inputs can remain as they are for ever.
  • And by the way, even the standardization of date inputs by W3C was not really successful, because the browser implementations are of such varying quality that many web developers prefer custom JavaScript controls for consistency of user experience. For instance, MDN [writes](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date):
  • > At the moment, the best way to deal with dates in forms in a cross-browser way is to have the user enter the day, month, and year in separate controls, or to use a JavaScript library such as jQuery date picker.
#1: Initial revision by user avatar meriton‭ · 2021-03-23T12:36:42Z (almost 4 years ago)
As the comments in that thread mentions, Captcha is a service, not mere software. The distinction is that Captcha are in an arms race with spammers, and must continually evolve to remain effective. 

In particular, many popular Captcha approaches have been made obsolete by advances in AI: The "distorted text as image" trick was made largely obsolete by  advances in text recognition algorithms, and the "identify this image" trick will likely be made obsolete in the near future by innovations in image recognition fueled by the development of self driving cars (in fact, training AI systems is probably the reason Google offers reCAPTCHA as a service in the first place).

This continued evolution makes Captcha standardization difficult: 

* If W3C standardizes an implementation, it will require browser vendors to participate in this arms race, which they have no incentive to do. In addition, if the standardized approach becomes insecure, W3C and all browser vendors would need to fix that quickly, but the W3C standardization process often takes years, which is a wholly unsuitable time period for fixing security issues.
* If W3C did not standardize the implementation, browsers would offer radically different levels of security. Since the website wishing to employ a Captcha must trust that security, it won't want to buy a pig in a poke, so will likely not use the browser feature, but continue to use Captcha services of known quality, making the standardized Captcha feature useless.

The only benefit standardization could possible provide is to define a uniform interface for embedding Captcha provided by third parties into a website, but since embedding Captchas is trivial with the means HTML already provides, this wouldn't add significant value.

So the key difference between Captchas and a date input is that Captchas must evolve alongside the start of the art of AI research, but date inputs can remain as they are for ever. 

And by the way, even the standardization of date inputs by W3C was not really successful, because the browser implementations are of such varying quality that many web developers prefer custom JavaScript controls for consistency of user experience. For instance, MDN [writes](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date):

> At the moment, the best way to deal with dates in forms in a cross-browser way is to have the user enter the day, month, and year in separate controls, or to use a JavaScript library such as jQuery date picker.