12 ms·

> JavaScript, captchas, and logins, are the main “gotchas” for text-based browsing, if the functionality of a site (or part of the site) relies on any of these

by ktpsns 7y ago

> JavaScript, captchas, and logins, are the main “gotchas” for text-based browsing, if the functionality of a site (or part of the site) relies on any of these then most likely it will not work. Really, there is no reason why a form should require JavaScript. When jQuery was hip, the js community celebrated "Graceful degradation". I frequently have the feeling this attitude is lost. That's super sad because it also excludes all the handycapped people. Does even anybody remember the good old HTTP basic acess authentification? This is one of the most accessible ways of protecting ressources, it can be consumed by any HTTP client (!), and it is just reduced to the basic. One of the worst things are these terrible captchas everywhere. I wonder why we cannot come up with a web standard interface in a way the captchas could be offloaded to customizable and adaptable GUIS rendered by the browsing client. This way, clients (users) could even declare what kind of captcha they can solve (blind people obviously cannot read images).

skybrian 7y ago
It's doable, but filling out forms with no immediate feedback about whether you entered your data correctly doesn't seem great from a UI perspective. Consider how useful a calendar picker is for travel. Also, no JavaScript means no Google Maps.
ohithereyou 7y ago
>I wonder why we cannot come up with a web standard interface in a way the captchas could be offloaded to customizable and adaptable GUIS rendered by the browsing client. Because then Google would lose a large free pool of labor for training its machine learning.
- moksly 7y ago
  So that’s why it’s always traffic stuff.
  - zonidjan 7y ago
    Yes, and that's why it used to be text from books, where they wanted to confirm their OCR.
    - saagarjha 7y ago
      The OCR actually helped digitize books, whereas the new captcha only helps Google's self-driving efforts…
      - thekyle 7y ago
        I highly doubt that selecting traffic signs in pictures does anything to help Google's self-driving efforts. The models used in autonomous vehicles are extremely state of the art and object detection is largely a solved problem (many people make object detection apps as Hello World projects).
        saagarjha 7y ago
        I'm no expert in this area, but as far as I'm aware object detection at the level required for self-driving vehicles is far from a "solved problem" (and requires significantly lower error rates than a "Hello World" project…).
        dillonmckay 7y ago
        So, if it is largely a solved problem, the captcha is near useless, no?
        thekyle 7y ago
        Yes, people have used Google Cloud's own public APIs to bypass reCAPTCHA v2.
      - zonidjan 7y ago
        It helped digitize books... for Google. AFAIK they didn't release it to anyone else? Also, for a while they used it to determine street numbers for Google Maps.
  - Moru 7y ago
    It started out as scanned books 10? years ago before Google bought them up.
VBprogrammer 7y ago
> excludes all the handycapped people I'm a big fan of judging people by what they are saying than by the words the use, and in context it's clear that you are not intentionally being offensive. However, in my cultural bubble, that term has been a poor choice for 20 years or more. It smacked me in the face when I read it.
- PopeDotNinja 7y ago
  What is the current best word to use?
  - VBprogrammer 7y ago
    It's probably culture / location dependant. In the UK disabled or lesser-abled would probably be preferred. I'd probably have skirted the issue by saying it may exclude people using screen readers.
    - GhostVII 7y ago
      Avoiding discussing a particular issue simply because you don't want to refer to people as handicapped or disabled seems absurd to me. Language is a tool, and we shouldn't reduce it's effectiveness simply because we are afraid of offending someone. Some people in the world are disabled, I think it is far more offensive to avoid talking about them then to use the term disabled or handicapped - how do you think it would feel to be a disabled person, and have people think that it is so offensive that they don't even feel comfortable saying that disabled people have a hard time on the modern internet?
      - VBprogrammer 7y ago
        I don't think we should avoid discussing the issue at all. But I also feel that groups have the right to determine what they find acceptable as a collective noun. If disabled people in the UK are uncomfortable with the term handicapped then I won't use it; that has been the case for as long as I can remember so it struck me when I read it.
yoz-y 7y ago
> I wonder why we cannot come up with a web standard interface in a way the captchas could be offloaded to customizable and adaptable GUIS rendered by the browsing client. What would prevent the client from not rendering anything and always replying "yes this is a human"?
- megous 7y ago
  That's not how any captchas work. It's more like a challenge/response mechanism, so there would have to be a standard for defining a challenge and accepting a response. The client would take care of displaying the challenge, and taking and sending the repsonse.
deleted 7y ago
[deleted]
megous 7y ago
> Does even anybody remember the good old HTTP basic acess authentification? This is one of the most accessible ways of protecting ressources, it can be consumed by any HTTP client (!), and it is just reduced to the basic. Yes! I recently used an e-shop that uses HTTP auth for user accounts. It was a bit unsettling, when the browser asked me for login credentials. :)
- heavenlyblue 7y ago
  It's also quite disappointing that I can't use my 1Password vault when a website asks for my HTTP password via a standard dialog in Firefox. PS: I am using Ubuntu so I can't use 1Password as a standalone application; but how does it happen that a website is perfectly capable of blocking my interaction with the browser? Why doesn't Firefox ask for the password as part of the actual webpage instead? Hadn't tried it in other browsers - does it work at all?
  - dylz 7y ago
    In this case, the u/p needs to be sent along with the request - which means it needs to be asked for by the browser before the request to the site is ever sent..
    - heavenlyblue 7y ago
      No, I mean just show a customised page for 403 that also has a username/password that you could put in and log in. The cross-browser modal dialog is entirely anti-Ux.
  - silverwind 7y ago
    Bitwarden is able to auto-fill basic auth dialogs in Firefox, but only if there is only a single entry for the page in store. Thought, sometimes it sometimes does not work. I do wish Mozilla would finally do away with the modal auth dialog and use in-tab content that extensions can interact with.
- smartmic 7y ago
  I just set up my own Git central using HTTP basic auth (with cgit and Gitolite). It is refreshingly simple and also looks good in text-based browsers. https://github.com/h2o/h2o/wiki/Hosting-private-and-public-repositories-with-cgit-and-Gitolite https://github.com/h2o/h2o/wiki/Hosting-private-and-public-r...
yoz-y 7y ago
> Does even anybody remember the good old HTTP basic acess authentification? This is one of the most accessible ways of protecting ressources, it can be consumed by any HTTP client (!), and it is just reduced to the basic. Basic authentication is fine if all you need is to control access to documents, but it can not be used for access delegation or any scope control.
- duijf 7y ago
  That depends entirely on how/where you implement this. You can make your application code check the authorization header, get the username from there and do authorization based on that.
- kalleboo 7y ago
  > but it can not be used for access delegation or any scope control Why not? It's just a header with a username and password. Your app can do whatever you want with that info. It also doesn't strictly have to be a username and password, you allow app tokens or whatever you want in there, that's just what the browser UI calls it.
- SmellyGeekBoy 7y ago
  I assume you're not a .NET developer...
  - yoz-y 7y ago
    No I'm not. Care to elaborate?
want2know 7y ago
> Really, there is no reason why a form should require JavaScript. True. But I'm glad to use Javascript on forms where fields are depending on input from other fields. Or when you want to give the user the option to submit multiple entries of the same field type. For example when you ask for a job history. Yes you can sumbit the form on every step but this is much harder to develop and has a lot of negative interactions for the user. For example the scrollposition is gone on each submit. And the user has to wait for a reply from the server on each submit. Javascript is not the problem, bloated and spammy websites are.
- ekianjo 7y ago
  > Javascript is not the problem, bloated and spammy websites are. It is part of the problem. Because of what Javascript allows and makes possible, bloat can thrive and endure in the modern web.
  - want2know 7y ago
    Well the same applies to images because they can be used for tracking.
    - ekianjo 7y ago
      Images don't access your device and check your system's configuration, extensions, plugins and more, as far as I know.
- shadowoflight 7y ago
  > For example the scrollposition is gone on each submit. Could this be fixed by dynamically-created anchors, so for instance when one is adding a new row to the "job experience" section of an application form, the reload to add the new row could also direct the user to "somesite.com/jobapp#JobExp2"?
  - ubercow13 7y ago
    That would be where the new row is, but not where you were scrolled to previously.
Wohlf 7y ago
Because captchas do more than just "user clicked on image", and has to be very wary of creating openings bots can abuse.
- makapuf 7y ago
  from the server (which is the only one you shall trust) captchas are a challenge sent as some bytes in a http request, and then returned later as some bytes in a http request. What the client does with them should be hard for a computer. It may involve javascript, clicking on images, hearing something and entering as text or solving the 3rd riemann conjecture. You cannot prove the javascript has even be interpreted client-side. All you can be sure is that the naswer is correct and that it's hard to do by a computer.
  - majewsky 7y ago
    The problem is that we're quickly running out of things that: 1. can be done by humans most of the time 2. cannot be done by machines most of the time 3. fit into the workflow of a web form Point 3 is the interesting bit: You cannot build a captcha that tests dexterity, emotional intelligence or creative problem solving but is still accessible to a large internet audience.
ubermonkey 7y ago
>Really, there is no reason why a form should require JavaScript. This is one of those things that's technically true, but misleading. Without scripting, you can't do any client-side validation, so you have to submit the form. Without scripting, it's then harder to repop the form for the user when it fails. I'm not saying things aren't excessive today -- they clearly are. But tossing client-side scripting entirely seems like a baby/bathwater situation.
- gdfasfklshg4 7y ago
  You need to re-do all your client-side user assistance prompts+ with real validation serverside anyway... + client-side validation is not validation.
  - spookthesunset 7y ago
    Server side validation is a backstop. It doesn't need to have fancy error messages or anything like that. Client side can have friendly, nice error handling and validation. Server side can damn near barf on the user's shoes when it encounters a validation issue.
- dfox 7y ago
  Most forms either don't need any kind of validation or you still have to validate the data on the server and do something reasonable when it fails. Repopulating the form on the server side after validation failure is trivial and even more so when there are libraries that abstract that away (eg. wtforms). On a similar note I somehow fail to see the benefit of writing (and often duplicating) large parts of business logic in client-side javascript and replacing perfectly good HTML form-submission mechanism with random JSON "REST" APIs.
  - GrinningFool 7y ago
    > Repopulating the form on the server side > after validation failure is trivial You'd think so, but the number of sites out there that still require me to re-type the full form because one field failed validation is mind-boggling.
FigBug 7y ago
> Does even anybody remember the good old HTTP basic acess authentification? Yes, I use it on some of my sites. For some reason chrome password manager won't work with it. Not sure why.
- avian 7y ago
  HTTP basic auth has also been broken on Firefox for iOS for a long time https://bugzilla.mozilla.org/show_bug.cgi?id=1437817 https://bugzilla.mozilla.org/show_bug.cgi?id=1437817
__ryan__ 7y ago
> Really, there is no reason why a form should require JavaScript. I’m a web developer who has never done significant forms without JavaScript. So I’m curious: how would you handle reactive form fields without client side scripting? For example (perhaps a bad example): the user is entering data in “rows”. The user clicks “add row” and then a new row of fields appears. The user can also delete rows on a whim. Their changes should only be persisted once submit is clicked. Would the “right” way be a full page reload with the row added/deleted, and caching all the values? Not to mention, if fields require cross validation, is it customary to have to submit the form to get the validation error messages to occur? On some of the forms I’ve worked on, this would be very complex.
- AtticusTheGreat 7y ago
  In the old days the user would submit the form, the validation would happen on the server, then return a result. If the result was a failure, you would render the errors on a new page load. If the result was a success, you could redirect the user to "confirmation" page or reload the same page but with a different output.
- malvosenior 7y ago
  > Would the “right” way be a full page reload with the row added/deleted, and caching all the values? If the user didn't have Javascript enabled, then yes. You'll have to do the validation server side anyway, client side scripting is just a "nice to have" it shouldn't be mandatory. There are also probably too many people using the web to build applications that should be native.
  - danShumway 7y ago
    > There are also probably too many people using the web to build applications that should be native. I hear this a lot, but I'm personally glad I don't need to download an app to my phone/computer to order pizza or find directions. Obviously this is a balance, but of the two extremes that could exist, having too many web-apps seems to be better than having too few. The quickest, simplest step you can take ATM to improve your device security is to install fewer apps -- particularly if you use an OS like Android. It's not clear to me that situation would get any better if half of the web disappeared.
hartator 7y ago
> the captchas could be offloaded to customizable and adaptable GUIS rendered by the browsing client Using Chrome with all tracking enabled is basically that. You just don't see CAPTCHAs. Blocking bot is a hard problem to solve.
malvosenior 7y ago
Captchas are an anti-pattern. Make account creation easy then handle any spam issues within the system yourself. Why make your users suffer for what is basically the service's problem to fix? It's a lazy way out.
- davidweatherall 7y ago
  With invisible recaptcha most users won't even see a captcha challenge when they sign up to forms
- ebiester 7y ago
  Because most users won't subject themselves to the signup fee to make this revenue neutral. It's an interesting alternative, though. Pay 5 bucks with the credit card to validate your identity if you don't want to subject yourself to captcha...
  - eastof 7y ago
    Tutanota does this, you choose between solving a Captcha and donating a minimum amount
vast 7y ago
> "Graceful degradation". I frequently have the feeling this attitude is lost. Lost? It is just ignored for the sake of cool SPAs and hottest new js stuff.
jchw 7y ago
>That's super sad because it also excludes all the handycapped people. That’s not how accessibility works. Requiring JavaScript does not change how accessible your site is to persons with disabilities. What does hurt is making sites that are difficult to navigate by keyboard, without proper accessibility hints, and actually it’s quite easy to do that without JavaScript.
UncleMeat 7y ago
Http auth is a mess of a system that has been a net negative for security by making people screw up hostname parsing because they didn't expect the auth syntax.
- icedchai 7y ago
  Why are you parsing URLs yourself? It's been a solved problem for decades, so use a library.
cp9 7y ago
are people really suggesting basic auth again, is it 1993 outside? Basic auth is horrendous security practice, you're passing a header that has your user and password in plaintext, it's insane to suggest that in 2019
- thekyle 7y ago
  What makes submitting a plaintext password in an Auth header worse than submitting a plaintext password in a POST body?
  - cp9 7y ago
    there's no way to log out, the browser has to store it instead of a session cookie which can be invalidated if it's stolen. plus what's in this comment https://security.stackexchange.com/questions/988/is-basic-auth-secure-if-done-over-https#comment209113_17216 https://security.stackexchange.com/questions/988/is-basic-au...
    - thekyle 7y ago
      Thanks, I didn't realize that the password was re-sent for every request to the site.
groby_b 7y ago
> Does even anybody remember the good old HTTP basic acess authentification? Yes! It was great! People would just transmit username and password in plaintext! Wait. That's actually the opposite of great. That's why nobody uses it any more. And no, handycapped people aren't excluded just because something doesn't degrade gracefully into a no-JS environment. You can (and many people do) make perfectly accessible web sites that still require JS. As for offloading captchas to the client? That suffers a similar problem to basic auth - it's extremely vulnerable because attackers can obtain access to information that makes their job trivial. That's why we cannot "come up with a standard" - the client has to be treated as hostile, because there's no way to verify their integrity.
- messe 7y ago
  > Yes! It was great! People would just transmit username and password in plaintext! > Wait. That's actually the opposite of great. That's why nobody uses it any more. Unless of course, if you're using HTTPS, in which case HTTP basic auth is fine and very simple to configure for many use cases.
  - smacktoward 7y ago
    Yeah, I'm kind of surprised that the age of HTTPS-All-The-Things hasn't led to a resurgence in the use of Basic Auth. As you note, the security problems that have been the big knock on Basic Auth for decades are completely obviated if your whole site is served over HTTPS. My guess on the reason why is two-fold. First, we've been telling people that Basic Auth is a terrible thing only stupid people would use for more than two decades now, and once a lesson like that gets hammered deep enough into the mass consciousness it tends to stay there even long after the underlying facts have changed. And second, using Basic Auth means giving up any possibility of styling/designing your login experience and relying instead on the browser's built-in dialogs, which tend to be clunky and ugly in the extreme.
    - organsnyder 7y ago
      The UX for basic auth is terrible on most browsers. In Firefox, the dialog box refuses to give up focus, preventing me from copying the password from my password manager (which, while integrated into the browser, doesn't support filling basic auth dialogs).
justinsaccount 7y ago
> Does even anybody remember the good old HTTP basic acess authentification? old, yes. good, no. * Browsers never implemented a way to "log out", so creds end up cached in memory until the browser is restarted. * There is no concept of a session so the credentials need to be included in each request and verified every time. If you use something like bcrypt or pbkdf2 on the backend that means every request will take hundreds of milliseconds. * Since every request needs to be verified you can't easily use 2FA, without ugly hacks that 'remember' that the earlier creds were valid. Hopefully things like WebAuthn will result in a resurgence of browser native autentication.
- c22 7y ago
  How does a "session" exist without "credentials" that have to be verified every time? Http is stateless so even non-native authentication solutions have to deal with these problems. Why can't your server generate a "session token" and require it to be passed using basic auth? Wouldn't you want to hash these "session tokens" on your server in case it becomes compromised?
  - justinsaccount 7y ago
    non-native authentication solutions do deal with these problems. HTTP Basic auth does not. full stop.
OldSchoolJohnny 7y ago
Wow; of course there are plenty of reasons why forms require javascript unless you've never coded anything of substance before then yes, in your limited experience no forms require javascript. If you write even mildly complex business applications with business rules and want a professional and non shitty user experience you absolutely need Javascript, there's no substitute. If you make simple sign up forms then by all means don't use Javascript.
- chipotle_coyote 7y ago
  I've written a SaaS system for SOX compliance tracking that ended up being a multiuser, role-based task manager that had to track dependencies between assignees and tasks. Did the application require JavaScript? Yes. But the JS had nothing to do with it being a "complex business application with business rules." If I'd implemented business rules in JavaScript, running on the client, I'd have been exposing the company to lawsuits. JavaScript doesn't deserve all the hate it gets, but the flip side of that is that it gets most of that hate because of the way developers keep using it.
- davesmith1983 7y ago
  You can do the logic on Postback. Yes it requires a round trip to the server it it works perfectly fine.

by ktpsns 7y ago

skybrian 7y ago

It's doable, but filling out forms with no immediate feedback about whether you entered your data correctly doesn't seem great from a UI perspective. Consider how useful a calendar picker is for travel. Also, no JavaScript means no Google Maps.

ohithereyou 7y ago

>I wonder why we cannot come up with a web standard interface in a way the captchas could be offloaded to customizable and adaptable GUIS rendered by the browsing client. Because then Google would lose a large free pool of labor for training its machine learning.

moksly 7y ago
So that’s why it’s always traffic stuff.
- zonidjan 7y ago
  Yes, and that's why it used to be text from books, where they wanted to confirm their OCR.
  - saagarjha 7y ago
    The OCR actually helped digitize books, whereas the new captcha only helps Google's self-driving efforts…
    - thekyle 7y ago
      I highly doubt that selecting traffic signs in pictures does anything to help Google's self-driving efforts. The models used in autonomous vehicles are extremely state of the art and object detection is largely a solved problem (many people make object detection apps as Hello World projects).
      - saagarjha 7y ago
        I'm no expert in this area, but as far as I'm aware object detection at the level required for self-driving vehicles is far from a "solved problem" (and requires significantly lower error rates than a "Hello World" project…).
      - dillonmckay 7y ago
        So, if it is largely a solved problem, the captcha is near useless, no?
        thekyle 7y ago
        Yes, people have used Google Cloud's own public APIs to bypass reCAPTCHA v2.
    - zonidjan 7y ago
      It helped digitize books... for Google. AFAIK they didn't release it to anyone else? Also, for a while they used it to determine street numbers for Google Maps.
- Moru 7y ago
  It started out as scanned books 10? years ago before Google bought them up.

VBprogrammer 7y ago

> excludes all the handycapped people I'm a big fan of judging people by what they are saying than by the words the use, and in context it's clear that you are not intentionally being offensive. However, in my cultural bubble, that term has been a poor choice for 20 years or more. It smacked me in the face when I read it.

PopeDotNinja 7y ago
What is the current best word to use?
- VBprogrammer 7y ago
  It's probably culture / location dependant. In the UK disabled or lesser-abled would probably be preferred. I'd probably have skirted the issue by saying it may exclude people using screen readers.
  - GhostVII 7y ago
    Avoiding discussing a particular issue simply because you don't want to refer to people as handicapped or disabled seems absurd to me. Language is a tool, and we shouldn't reduce it's effectiveness simply because we are afraid of offending someone. Some people in the world are disabled, I think it is far more offensive to avoid talking about them then to use the term disabled or handicapped - how do you think it would feel to be a disabled person, and have people think that it is so offensive that they don't even feel comfortable saying that disabled people have a hard time on the modern internet?
    - VBprogrammer 7y ago
      I don't think we should avoid discussing the issue at all. But I also feel that groups have the right to determine what they find acceptable as a collective noun. If disabled people in the UK are uncomfortable with the term handicapped then I won't use it; that has been the case for as long as I can remember so it struck me when I read it.

yoz-y 7y ago

> I wonder why we cannot come up with a web standard interface in a way the captchas could be offloaded to customizable and adaptable GUIS rendered by the browsing client. What would prevent the client from not rendering anything and always replying "yes this is a human"?

megous 7y ago
That's not how any captchas work. It's more like a challenge/response mechanism, so there would have to be a standard for defining a challenge and accepting a response. The client would take care of displaying the challenge, and taking and sending the repsonse.

deleted 7y ago

[deleted]

megous 7y ago

> Does even anybody remember the good old HTTP basic acess authentification? This is one of the most accessible ways of protecting ressources, it can be consumed by any HTTP client (!), and it is just reduced to the basic. Yes! I recently used an e-shop that uses HTTP auth for user accounts. It was a bit unsettling, when the browser asked me for login credentials. :)

heavenlyblue 7y ago
It's also quite disappointing that I can't use my 1Password vault when a website asks for my HTTP password via a standard dialog in Firefox. PS: I am using Ubuntu so I can't use 1Password as a standalone application; but how does it happen that a website is perfectly capable of blocking my interaction with the browser? Why doesn't Firefox ask for the password as part of the actual webpage instead? Hadn't tried it in other browsers - does it work at all?
- dylz 7y ago
  In this case, the u/p needs to be sent along with the request - which means it needs to be asked for by the browser before the request to the site is ever sent..
  - heavenlyblue 7y ago
    No, I mean just show a customised page for 403 that also has a username/password that you could put in and log in. The cross-browser modal dialog is entirely anti-Ux.
- silverwind 7y ago
  Bitwarden is able to auto-fill basic auth dialogs in Firefox, but only if there is only a single entry for the page in store. Thought, sometimes it sometimes does not work. I do wish Mozilla would finally do away with the modal auth dialog and use in-tab content that extensions can interact with.
smartmic 7y ago
I just set up my own Git central using HTTP basic auth (with cgit and Gitolite). It is refreshingly simple and also looks good in text-based browsers. https://github.com/h2o/h2o/wiki/Hosting-private-and-public-repositories-with-cgit-and-Gitolite https://github.com/h2o/h2o/wiki/Hosting-private-and-public-r...

yoz-y 7y ago

> Does even anybody remember the good old HTTP basic acess authentification? This is one of the most accessible ways of protecting ressources, it can be consumed by any HTTP client (!), and it is just reduced to the basic. Basic authentication is fine if all you need is to control access to documents, but it can not be used for access delegation or any scope control.

duijf 7y ago
That depends entirely on how/where you implement this. You can make your application code check the authorization header, get the username from there and do authorization based on that.
kalleboo 7y ago
> but it can not be used for access delegation or any scope control Why not? It's just a header with a username and password. Your app can do whatever you want with that info. It also doesn't strictly have to be a username and password, you allow app tokens or whatever you want in there, that's just what the browser UI calls it.
SmellyGeekBoy 7y ago
I assume you're not a .NET developer...
- yoz-y 7y ago
  No I'm not. Care to elaborate?

want2know 7y ago

> Really, there is no reason why a form should require JavaScript. True. But I'm glad to use Javascript on forms where fields are depending on input from other fields. Or when you want to give the user the option to submit multiple entries of the same field type. For example when you ask for a job history. Yes you can sumbit the form on every step but this is much harder to develop and has a lot of negative interactions for the user. For example the scrollposition is gone on each submit. And the user has to wait for a reply from the server on each submit. Javascript is not the problem, bloated and spammy websites are.

ekianjo 7y ago
> Javascript is not the problem, bloated and spammy websites are. It is part of the problem. Because of what Javascript allows and makes possible, bloat can thrive and endure in the modern web.
- want2know 7y ago
  Well the same applies to images because they can be used for tracking.
  - ekianjo 7y ago
    Images don't access your device and check your system's configuration, extensions, plugins and more, as far as I know.
shadowoflight 7y ago
> For example the scrollposition is gone on each submit. Could this be fixed by dynamically-created anchors, so for instance when one is adding a new row to the "job experience" section of an application form, the reload to add the new row could also direct the user to "somesite.com/jobapp#JobExp2"?
- ubercow13 7y ago
  That would be where the new row is, but not where you were scrolled to previously.

Wohlf 7y ago

Because captchas do more than just "user clicked on image", and has to be very wary of creating openings bots can abuse.

makapuf 7y ago
from the server (which is the only one you shall trust) captchas are a challenge sent as some bytes in a http request, and then returned later as some bytes in a http request. What the client does with them should be hard for a computer. It may involve javascript, clicking on images, hearing something and entering as text or solving the 3rd riemann conjecture. You cannot prove the javascript has even be interpreted client-side. All you can be sure is that the naswer is correct and that it's hard to do by a computer.
- majewsky 7y ago
  The problem is that we're quickly running out of things that: 1. can be done by humans most of the time 2. cannot be done by machines most of the time 3. fit into the workflow of a web form Point 3 is the interesting bit: You cannot build a captcha that tests dexterity, emotional intelligence or creative problem solving but is still accessible to a large internet audience.

ubermonkey 7y ago

>Really, there is no reason why a form should require JavaScript. This is one of those things that's technically true, but misleading. Without scripting, you can't do any client-side validation, so you have to submit the form. Without scripting, it's then harder to repop the form for the user when it fails. I'm not saying things aren't excessive today -- they clearly are. But tossing client-side scripting entirely seems like a baby/bathwater situation.

gdfasfklshg4 7y ago
You need to re-do all your client-side user assistance prompts+ with real validation serverside anyway... + client-side validation is not validation.
- spookthesunset 7y ago
  Server side validation is a backstop. It doesn't need to have fancy error messages or anything like that. Client side can have friendly, nice error handling and validation. Server side can damn near barf on the user's shoes when it encounters a validation issue.
dfox 7y ago
Most forms either don't need any kind of validation or you still have to validate the data on the server and do something reasonable when it fails. Repopulating the form on the server side after validation failure is trivial and even more so when there are libraries that abstract that away (eg. wtforms). On a similar note I somehow fail to see the benefit of writing (and often duplicating) large parts of business logic in client-side javascript and replacing perfectly good HTML form-submission mechanism with random JSON "REST" APIs.
- GrinningFool 7y ago
  > Repopulating the form on the server side > after validation failure is trivial You'd think so, but the number of sites out there that still require me to re-type the full form because one field failed validation is mind-boggling.

FigBug 7y ago

> Does even anybody remember the good old HTTP basic acess authentification? Yes, I use it on some of my sites. For some reason chrome password manager won't work with it. Not sure why.

avian 7y ago
HTTP basic auth has also been broken on Firefox for iOS for a long time https://bugzilla.mozilla.org/show_bug.cgi?id=1437817 https://bugzilla.mozilla.org/show_bug.cgi?id=1437817

__ryan__ 7y ago

> Really, there is no reason why a form should require JavaScript. I’m a web developer who has never done significant forms without JavaScript. So I’m curious: how would you handle reactive form fields without client side scripting? For example (perhaps a bad example): the user is entering data in “rows”. The user clicks “add row” and then a new row of fields appears. The user can also delete rows on a whim. Their changes should only be persisted once submit is clicked. Would the “right” way be a full page reload with the row added/deleted, and caching all the values? Not to mention, if fields require cross validation, is it customary to have to submit the form to get the validation error messages to occur? On some of the forms I’ve worked on, this would be very complex.

AtticusTheGreat 7y ago
In the old days the user would submit the form, the validation would happen on the server, then return a result. If the result was a failure, you would render the errors on a new page load. If the result was a success, you could redirect the user to "confirmation" page or reload the same page but with a different output.
malvosenior 7y ago
> Would the “right” way be a full page reload with the row added/deleted, and caching all the values? If the user didn't have Javascript enabled, then yes. You'll have to do the validation server side anyway, client side scripting is just a "nice to have" it shouldn't be mandatory. There are also probably too many people using the web to build applications that should be native.
- danShumway 7y ago
  > There are also probably too many people using the web to build applications that should be native. I hear this a lot, but I'm personally glad I don't need to download an app to my phone/computer to order pizza or find directions. Obviously this is a balance, but of the two extremes that could exist, having too many web-apps seems to be better than having too few. The quickest, simplest step you can take ATM to improve your device security is to install fewer apps -- particularly if you use an OS like Android. It's not clear to me that situation would get any better if half of the web disappeared.

hartator 7y ago

> the captchas could be offloaded to customizable and adaptable GUIS rendered by the browsing client Using Chrome with all tracking enabled is basically that. You just don't see CAPTCHAs. Blocking bot is a hard problem to solve.

malvosenior 7y ago

Captchas are an anti-pattern. Make account creation easy then handle any spam issues within the system yourself. Why make your users suffer for what is basically the service's problem to fix? It's a lazy way out.

davidweatherall 7y ago
With invisible recaptcha most users won't even see a captcha challenge when they sign up to forms
ebiester 7y ago
Because most users won't subject themselves to the signup fee to make this revenue neutral. It's an interesting alternative, though. Pay 5 bucks with the credit card to validate your identity if you don't want to subject yourself to captcha...
- eastof 7y ago
  Tutanota does this, you choose between solving a Captcha and donating a minimum amount

vast 7y ago

> "Graceful degradation". I frequently have the feeling this attitude is lost. Lost? It is just ignored for the sake of cool SPAs and hottest new js stuff.

jchw 7y ago

>That's super sad because it also excludes all the handycapped people. That’s not how accessibility works. Requiring JavaScript does not change how accessible your site is to persons with disabilities. What does hurt is making sites that are difficult to navigate by keyboard, without proper accessibility hints, and actually it’s quite easy to do that without JavaScript.

UncleMeat 7y ago

Http auth is a mess of a system that has been a net negative for security by making people screw up hostname parsing because they didn't expect the auth syntax.

icedchai 7y ago
Why are you parsing URLs yourself? It's been a solved problem for decades, so use a library.

cp9 7y ago

are people really suggesting basic auth again, is it 1993 outside? Basic auth is horrendous security practice, you're passing a header that has your user and password in plaintext, it's insane to suggest that in 2019

thekyle 7y ago
What makes submitting a plaintext password in an Auth header worse than submitting a plaintext password in a POST body?
- cp9 7y ago
  there's no way to log out, the browser has to store it instead of a session cookie which can be invalidated if it's stolen. plus what's in this comment https://security.stackexchange.com/questions/988/is-basic-auth-secure-if-done-over-https#comment209113_17216 https://security.stackexchange.com/questions/988/is-basic-au...
  - thekyle 7y ago
    Thanks, I didn't realize that the password was re-sent for every request to the site.

groby_b 7y ago

> Does even anybody remember the good old HTTP basic acess authentification? Yes! It was great! People would just transmit username and password in plaintext! Wait. That's actually the opposite of great. That's why nobody uses it any more. And no, handycapped people aren't excluded just because something doesn't degrade gracefully into a no-JS environment. You can (and many people do) make perfectly accessible web sites that still require JS. As for offloading captchas to the client? That suffers a similar problem to basic auth - it's extremely vulnerable because attackers can obtain access to information that makes their job trivial. That's why we cannot "come up with a standard" - the client has to be treated as hostile, because there's no way to verify their integrity.

messe 7y ago
> Yes! It was great! People would just transmit username and password in plaintext! > Wait. That's actually the opposite of great. That's why nobody uses it any more. Unless of course, if you're using HTTPS, in which case HTTP basic auth is fine and very simple to configure for many use cases.
- smacktoward 7y ago
  Yeah, I'm kind of surprised that the age of HTTPS-All-The-Things hasn't led to a resurgence in the use of Basic Auth. As you note, the security problems that have been the big knock on Basic Auth for decades are completely obviated if your whole site is served over HTTPS. My guess on the reason why is two-fold. First, we've been telling people that Basic Auth is a terrible thing only stupid people would use for more than two decades now, and once a lesson like that gets hammered deep enough into the mass consciousness it tends to stay there even long after the underlying facts have changed. And second, using Basic Auth means giving up any possibility of styling/designing your login experience and relying instead on the browser's built-in dialogs, which tend to be clunky and ugly in the extreme.
  - organsnyder 7y ago
    The UX for basic auth is terrible on most browsers. In Firefox, the dialog box refuses to give up focus, preventing me from copying the password from my password manager (which, while integrated into the browser, doesn't support filling basic auth dialogs).

justinsaccount 7y ago

> Does even anybody remember the good old HTTP basic acess authentification? old, yes. good, no. * Browsers never implemented a way to "log out", so creds end up cached in memory until the browser is restarted. * There is no concept of a session so the credentials need to be included in each request and verified every time. If you use something like bcrypt or pbkdf2 on the backend that means every request will take hundreds of milliseconds. * Since every request needs to be verified you can't easily use 2FA, without ugly hacks that 'remember' that the earlier creds were valid. Hopefully things like WebAuthn will result in a resurgence of browser native autentication.

c22 7y ago
How does a "session" exist without "credentials" that have to be verified every time? Http is stateless so even non-native authentication solutions have to deal with these problems. Why can't your server generate a "session token" and require it to be passed using basic auth? Wouldn't you want to hash these "session tokens" on your server in case it becomes compromised?
- justinsaccount 7y ago
  non-native authentication solutions do deal with these problems. HTTP Basic auth does not. full stop.

OldSchoolJohnny 7y ago

Wow; of course there are plenty of reasons why forms require javascript unless you've never coded anything of substance before then yes, in your limited experience no forms require javascript. If you write even mildly complex business applications with business rules and want a professional and non shitty user experience you absolutely need Javascript, there's no substitute. If you make simple sign up forms then by all means don't use Javascript.

chipotle_coyote 7y ago
I've written a SaaS system for SOX compliance tracking that ended up being a multiuser, role-based task manager that had to track dependencies between assignees and tasks. Did the application require JavaScript? Yes. But the JS had nothing to do with it being a "complex business application with business rules." If I'd implemented business rules in JavaScript, running on the client, I'd have been exposing the company to lawsuits. JavaScript doesn't deserve all the hate it gets, but the flip side of that is that it gets most of that hate because of the way developers keep using it.
davesmith1983 7y ago
You can do the logic on Postback. Yes it requires a round trip to the server it it works perfectly fine.