Live data from Hacker News

Why even let users set their own passwords?

devever.net

381–390 of 392 posts

Re: Why even let users set their own passwords?

#381

> Often this will be combined with fallacious notions such as “remember this device”, the idea being you only have to go through all this the first time when logging in from a particular device. This idea is fallacious because the web has no notion of a “device”, and this is a very intentional design choice made for privacy purposes. We are literally living through the gradual phase-out of third-party cookies, amongs…

I kinda wish there was something like cookies, but even more persistent. Lets call them permacookies. I want to "remember my device", and have that keep me logged in forever with a permacookie. I don't even want to have a username and password. I want to create an account and be forever logged in. There would be mechanisms to backup my permacookies, or transfer them to other devices. I'd have control of which sites c…

Cookies already last months or years, I don't think the tech limits duration so much as the sites explicitly set a time, or clear the token on the backend.

What I'd really like is to just be able to use the native filesystem. But Firefox doesn't like that, and people apparently use that, so it's not a real standard.

At the very least, they should make the origin private filesystem user-visible with a flag. Don't allow everything, just ~/WebData/default/DOMAIN_NAME

Re: Why even let users set their own passwords?

#382
post #314

Earlier quoted context omitted.

> Or consider a PWA music player - 50MB of music is all you can play offline. > Or a photo editor - 50MB is the limit for all your saved files unless you want to save them to a cloud server. Why should either of these be saving files in an app-specific private datastore? Music, photos, videos, etc. should be in the standard system locations. The app's data storage should be solely used for settings, cache, and other…

Because you might not have unrestricted rights to the files. The Netflix app allows me to download movies to watch offline but they're DRMed and rented to me by Netflix, not owned by me. A Netflix PWA would not allow for such feature.

DRMed files can be stored on the normal filesystem just fine, if they're DRMed that means they're encrypted at rest and decrypted on the fly.

DRMed content providers might not want to store their files on the normal filesystem because then they might have to answer uncomfortable questions like "why can't I copy this file to X and play it there?" but there's no technical reason they can't do just like every DRMed content provider on normal PC platforms has always done and store encrypted files on the normal filesystem.

Re: Why even let users set their own passwords?

#383

Earlier quoted context omitted.

This is what HTTP auth headers are for, but the UX for using header authentication on modern browsers is utter garbage. There's no way to present a themed login form, no way to log the user out at all , and all sorts of weird papercut bugs[0] in between. [0] My favorite: opening DevTools triggers a second credential prompt because the DevTools session wants to download some mapfiles or something. No infrastructure ex…

I wish there was better browser support for this but I still use it for pet projects. Last year I wrote about why I’m still using HTTP Basic Auth. https://joeldare.com/why-im-using-http-basic-auth-in-2022

Maybe you don't listen on port 80 but I can imagine a standard web server using Let's Encrypt, for example, that could suffer from a user leaking credentials by inadvertently using HTTP rather than HTTPS.

I have to look into some protections to this. I recently did a project and used Basic Auth for expediency thinking that later I would replace with a "proper" auth form. My theory was that this was better because sending cookies is based on the protocol also not just the domain.

Re: Why even let users set their own passwords?

#384

Earlier quoted context omitted.

There isn’t encryption nor a generated password involved with passkeys. Rather, your device generates a private key and stores it in your password manager - and only the public key is sent to the server. When you log in later, the server uses an API to give your client a random unique challenge (just some bytes), you unlock and approve and the pwm signs some stuff including the challenge and sends the signature back.…

There isn't encryption involved? I mean how can you use public and private keys without encryption? Anyways yes, I agree otherwise. That said for all intents and purposes, the private key is a password. It’s the thing you store that gives you access to the service. That it’s not transmitted, but instead the whole public key / challenge response dance is done, is IMO sufficiently well summarized as “well, it’s a speci…

> how can you use public and private keys without encryption

Signing is different from encrypting.

https://en.wikipedia.org/wiki/Digital_Signature_Algorithm

And yes, 100% agree we can do better in terms of explaining passkeys. The hardest part is that different audiences require such different approaches.

Re: Why even let users set their own passwords?

#385

Earlier quoted context omitted.

I kinda wish there was something like cookies, but even more persistent. Lets call them permacookies. I want to "remember my device", and have that keep me logged in forever with a permacookie. I don't even want to have a username and password. I want to create an account and be forever logged in. There would be mechanisms to backup my permacookies, or transfer them to other devices. I'd have control of which sites c…

> I kinda wish there was something like cookies, but even more persistent. Fruitcakes.

My first thought was "ship's biscuits".

Re: Why even let users set their own passwords?

#386
post #358
post #335

Earlier quoted context omitted.

> people...who would like to disable JS, but it's just not practical As I tell my kid when he "wants" something, I want a pony, and a million dollars. I don't see why the fact that some people might like that matters. I mean, given the choice for free sure I'd "like" it too. But it will never remotely be worth it to build two entirely separate web applications for every website to make that dream a reality, nor do I…

Look. I agree with you, in the core idea. There have really been advances in technology, but for each step made with brilliance and prowess, there have been 3 steps back with laziness and carelessness. Some applications of the newer technologies merit their use. Most use cases, however, don't. Bad practices abound, the "art" of programming becomes a chore made by let's say not very skilled people. Luckily there are s…

Your complain is conflated. Turning off javascript is not akin to turning off macros in a Word document. It’s like deleting your desktop environment and complaining Word doesn’t work in a terminal.

I’m not sure if you’re really thinking about the impact of not having any javascript. Want to reply to a comment on HN? The whole page reloads. Want to upvote a comment? The whole page reloads. Sure you can give every comment an ID and reload back to where you were, but then you can’t have collapsible comments (because css, presumably what you’re hacking for collapsible comments without JS, can’t respond to anchor references).

There’s a million other usability things that require JS, it’s so much more than a macro language.

There are bad practices everywhere, in every field, and it feels like everyone feels they have the authority to beat down JS, and web dev as a whole, likely with zero experience working with it.

Web arguably has the best developer experience of any field. It’s so good, they took the web and put it in your desktop. Electron, GTK, KDE, everything is javascript.

The war is lost and over. Start arguing/discussing how JS can be improved instead that it shouldn’t exist (there’s PLENTY to complain about, don’t get me wrong).

Re: Why even let users set their own passwords?

#387
post #356

Earlier quoted context omitted.

If anyone tests their web pages without JS, it would be gov.uk. I'm an American but I frequently reference their guidelines on accessibility and similar because they're so thorough and conscientious about it.

Yeah but I am afraid every other website on the Internet is not done with the care and good craftsmanship that the gov.uk applies to its website. I wish, though! But then so many web devs (and so many of their managers, too!) would be lost without knowing what to do without a JS framework that weights several MBs worth of bloat...

It's about cost. If it takes a web dev a day to progressively enhance a page from html through css and JS, then it's a day they're adding value to a small slice of the users.

Even if you multiplied the 0.2 by 10 or 20, you're still looking at a slice not large enough to build for.

Re: Why even let users set their own passwords?

#388
post #335
post #329

Earlier quoted context omitted.

That might be a very misleading statistic. What if more than 0.2% of people wanted to disable JavaScript, but in the end surrended to the fact that those pesky web devs never test their creations with JS disabled? I know I am one of those who would like to disable JS, but it's just not practical. So stats really are a dangerous tool, they sometimes can end up telling you just what you want to hear...

> people...who would like to disable JS, but it's just not practical As I tell my kid when he "wants" something, I want a pony, and a million dollars. I don't see why the fact that some people might like that matters. I mean, given the choice for free sure I'd "like" it too. But it will never remotely be worth it to build two entirely separate web applications for every website to make that dream a reality, nor do I…

Actually rails hides much of that now. Passing html over the wire is super easy, and I never give JS a second thought.

Re: Why even let users set their own passwords?

#389

Earlier quoted context omitted.

I think that most people can come up with more effective ways to annoy someone.

They do this to the accounts you use to communicate simultaneous with an attack on your reputation, i.e., when being able to to communicate suddenly becomes critical (for defending yourself against the allegations).

An interesting attack I have never heard of up to now. Do you have a reference?

Re: Why even let users set their own passwords?

#390
post #356

Earlier quoted context omitted.

Yeah but I am afraid every other website on the Internet is not done with the care and good craftsmanship that the gov.uk applies to its website. I wish, though! But then so many web devs (and so many of their managers, too!) would be lost without knowing what to do without a JS framework that weights several MBs worth of bloat...

It's about cost. If it takes a web dev a day to progressively enhance a page from html through css and JS, then it's a day they're adding value to a small slice of the users. Even if you multiplied the 0.2 by 10 or 20, you're still looking at a slice not large enough to build for.

I'd say it's about priorities (i.e. very much related to cost, but with slight differences). That's why I mentioned the lack of people who cares. If you as a manager care, or if a dev with enough decision power cares, it will just be included as part of the time it costs to get the website done.

A worker putting a helmet and appropriate clothes is losing time that could be beter spent producing value. Or if we talk about social policies and minorities, for example, even if as the word says, it's a "minority" of people so it might seem that it's a slice not large enough to improve for. A bit extreme examples, but you get the idea.

Also a 0.2% of all world population is still a huge amount of people. It's just that people who can take decisions, just don't care. But some people do care, like those in charge of co.uk websites, and then we all see how well things can be done and how poorly we've been doing in comparison.

Post reply on HN