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 could set permacookies for when I didn't want to be tracked too.
Either I use a short, easy to type password for my banking so I can log in all the time, or I use a long one and use a password manager to fill it for me and we’re basically back to “use the phone’s biometric authentication” with extra steps.
There’s already a strong, secure option for authenticating the user on a mobile device… I wish everyone would use it instead of trying to use the crap option we’re using elsewhere, especially since passwords are a pain on a tiny touchscreen keyboard.
I would like it if they were more discoverable, but not necessarily with the obnoxious pop ups. It would be awesome if they let you list a PWA in the App Store for a fee or the 30% cut.
Besides - there are plenty of other things Apple can do to ensure PWA's don't take off. For example, there is no ability for a web-app to have a "click here to install to desktop" button - the website must try to guide the user into clicking the share button and then creating a desktop icon - which most users don't associate with 'installing' something.
Also, the 50Mb limit on PWA's prevents a lot of usecases - like photo/video editors, and even most messaging apps.
Firefox refuses to implement pwa. Chrome has pwas but they're not isolated.
Apple is the only one with sane pwa but somehow they're the worst and are totally sabotaging PWAs because something something walled garden?
The entirety of TempleOS (including dozens of programs and multimedia games) is 2MB.
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.
> 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 internal data only useful to the app.
I'm not familiar with PWAs but if they can't access system storage then I don't think they're a useful choice for a music player or photo editor.
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.
Like can't the login-state be part of the backup? If I was logged in when the backup was taken, I should still be logged in when restored to a new device.
Almost every single app on my phone forgets who I am even after minor updates.
Apps I use infrequently? It's like they never knew me to begin with.
I agree with this, but...
> users are too stupid to use them
they are. Key management is not trivial.
Among the steps of generating a key pair, getting the public key (not the private one) into their authorized_keys file (which is in a hidden directory, for pete's sake) without introducing any extra characters or line breaks or getting the wrong permissions on the file, getting their ssh client programs to use the proper private key for the host they are trying to log in to, or figuring out ssh-agent, there are just way too many opportunities to screw up or get confused.
I think the world would be a better place if LetsEncrypt had come into being about five years earlier.
Save for minorities with genuine learning disorders, people can learn how to click/tap a bunch of buttons in a sequence. They aren't running a PKI (that's on platform/browser vendor), they are just picking an identity from the list after all. They learn how to click the right buttons all the time, as UI designers' managers decide it's time for a new bonus and swing things around with a "new graphic language".
Basic certificate management (from end-user perspective) is not harder than password management. Passkeys are conceptually the exact same thing² as TLS client certificates, just without a purposefully neglected UI and a DIY attitude³ (TLS is supported by nearly anything, barely anything knows about WebAuthn JS shenanigans).
1) Not in a bad way. "Lazy" as in "lazy evaluation", not "lazy ass". Maybe there's a better word for this.
2) Save for some technical details, both are essentially keypair management.
3) There is almost no UI, it's just an API then all the visual bits are left out as an exercise to individual app designers (partially on platform/browser developers, partially on website developers). Browser vendors just hated those areas because they weren't deemed cool and fancy ([un]like some JS framework of the day) and shoved them under the rug as deep as they could. And unlike TLS, there is no standard how to pass data around, everyone invents their own `POST /login/webauthn` semantics.
I would burn client certs to the ground if I could.
It was surprising the first time I used it but now I wish everything that didn't handle cash worked that way.
There would also be intentional and unintentional mechanisms for stealing these permacookies.
Or browsers could treat cookies more like passwords and have a user-controllable flow on each new session: "Here's this site's cookies from your last session, do you want to place these back in the browser storage?"
The fundamental issue is that browser cookies and password managers have an overlap in their usage domain.
(eg, my password manager includes github recovery tokens, ssh keys and passphrases, recovery questions, my tax and health service identifiers, wifi passwords and the admin passwords)
Fruitcakes.
is it secure? hell no, but it can be used.
You really want support for key authentication just like ssh.
You shouldn’t move private keys between devices, you should have easy way to add new public keys to a service when you setu new device.
Problem is permacookies or private keys don’t really allow ad-hoc access but maybe nowadays people don’t need to login to their accounts from cyber cafes :)
Log in once, on one website, then be logged in on all websites forever.
If you work for advertisers this sounds like a great idea. Better than eating babies.
BUT... the problem is that if handled incorrectly it would be a disaster for web security, would open up tons of holes for user tracking and data theft, and would basically be a horror show. There are a dozen things that could go wrong with the spec, and all of them would be serious problems if they did go wrong.
And Chrome is heavily involved in the spec. So it's a tough position to be in to try and figure out whether it's worth advocating for. Mozilla currently considers native filesystem access to be harmful, and I don't know whether or not I agree with them. I wish Mozilla would propose an alternative spec developed entirely internally without interaction from Google.
We are talking about tablet phone and laptop sharing a data store.
Not multiple user agents on the same device sharing a data store. Though we have entered the era where the names of specs or initiatives have little to nothing to do with the actual meat of the thing.
Maybe you're right though and the UI would need to be different :shrug:
[0] My favorite: opening DevTools triggers a second credential prompt because the DevTools session wants to download some mapfiles or something. No infrastructure exists to make that HTTP request in the context of the current tab, apparently.
“No themed login form” oh no! Anyway. (I really think that the “theming” on login and sign-up forms breaches which bits are done by the browser and which bits are not. We’ve had to kludge back support)
non-iOS browsers seem to handle HTTP basic auth gracefully.
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.
They're even deprecating auth via non-browser means in newer OAuth/GNAP standards. It's like they're designing around what things are now, rather than thinking ahead as to what would be best. Like rather than website - managed auth, it be fully browser controlled (not HTML forms). Not cookies, but something prescribed by the browser (or whatever other application you might use, rather than needing to embed a browser yet again in everything).
I had assumed the cause was something like this: Product management people want functionality which is fundamentally incompatible with security-- like complete control of the appearance and behavior of the login form (which can't be squared with impersonation attacks). Security people substantially control the https auth experience, and say NO. Product management people say fine, and just don't use the secure login functionality.
Everyone is happy: PMs get the security dumpster fire they asked for, Security people keep their perfect ice castle and can complain that all breaches are the fault of the PMs doing the wrong stuff. Except the users, of course, who get a needlessly insecure experience because there are many improvements to the http auth process that don't substantially compromise security.
For some apps this would suffice. But for apps we use to live our lives, what do you do when someone has no access to their devices and they need to log in to a fresh device? Some apps will need passwords, or some other mechanism to prove you are who you say you are. But then you can leverage those apps to get back into your other apps in the case of, say, a fire.
Learn to use a password manager.
I think expiration fields on cookies are optional (correct me if I'm wrong), you just can't rely on them sticking around because the user might clear them (I'd have control of which sites could set permacookies for when I didn't want to be tracked too). Which is honestly desired behavior, I'm assuming you would want the ability to delete a permacookie.
Cookies can't be synced through Firefox sync (I thought they could but just checked and my bad, they can't) -- but there's nothing preventing browser sync from handling that, and Firefox sync is E2EE so it would as secure as any other transfer method. It wouldn't be too hard to build a browser extension to allow exporting them or importing them manually; cookies are just text content so they're trivial to inspect and manipulate and even manually copy and paste into new browsers through the dev tools.
As a login mechanism, having a permacookie is somewhat insecure so most sites use expiration dates. I'm sympathetic to the desire to be able to override that, but... the mechanisms most sites use are things like signed tokens with expiration dates checked serverside, so there's not much a browser can do about blocking a website from doing that. Short of using stateless key-based authentication I'm not sure how it would be technically possible to get rid of that behavior.
----
I'm being a little bit disingenuous here in the sense that... yeah I want native file access too. I understand that cookies are not the same as native file access and the controls aren't really the same. But that's a much larger conversation with much larger scope and with more implications for browser security.
But if you're talking specifically about login, it does seem like cookies are mostly doing everything you want and your bigger problem is just that websites time-out logins? And that Firefox sync doesn't currently sync them, which... an extension could handle that.
What is the non-permanent part of a cookie, is it just that user controls for clearing cookies aren't granular enough and they're too easy for the user to accidentally delete?
I guess mobile too, iOS safari will clear localstorage sometimes. That's a very real issue (and a big reason why I want native file access), but it's less of an issue for login since occasionally losing your login permacookie isn't a big deal, it's only a big deal if you lose offline serverless webapp data.
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
This is... sorta true? Insofar as creepy advertisers also "remember this device". But a first-party site storing a cookie to remember a login session is not at all in the same category for me.
Sounds like a you problem, dude. You have to go out of your way to force this behavior with any mainstream browser.
All post reads like Dunning-Kruger case, he seems to know quite some stuff but also misses 3rd party cookies. Overly focuses on weak passwords completely skipping password leaks or just mentioning password reuse.
Ignoring that TOTP is actually decent interface for getting non technical and not caring at all users use random high entropy secrets. Getting regular people to keep some generated random strings won’t work.
In the end ignoring all experience of industry which is:
leaked passwords and email lists can be used in password spraying attacks where specific user is not targeted it is just opportunistic low hanging fruit automated exploitation.
Then those easy exploitable accounts in services can be used to ask connected users for loans or financial help as a scam.
I should be able to authenticate by proving access to a device such as a yubikey, as an example. Now, the site can properly remember the user. This missing feature is the fault of crummy UX, not the user.
Queen, please. I have no objection for people choosing the "forget my device" option, but the nonsensical whining about explicitly choosing this option and then bemoaning that a website doesn't remember you is absurd.
> the web has no notion of a “device”, and this is a very intentional design choice made for privacy purposes [...] why do web developers persist in believing in this fiction of a “device”?
Whether a device (however you build that abstraction) has previously logged in is a high-signal data point that meaningfully increases account security at login time and all serious web security teams use it to protect their users.
It will forever be a mystery for me why people deliberately make their browsers work in ways that contradict the standards the web is built on and then manage to find blame in others when stuff doesn't work. It's already difficult enough to support all major browsers when their interpretations of the standards differ very slightly.
https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
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...
Even if you multiplied the 0.2 by 10 or 20, you're still looking at a slice not large enough to build for.
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.
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 see the whole Internet agreeing to discard the decades of advancements in FE technologies to go back to script-free HTML.
All that said, boy would that be a great jobs program for developers over age 35 though! Imagine developing for the web with no Webpack, no JS compilers, transpilers, bundles.[1]
[1]: Or whatever you frontend folks use for your toolchain this year, or this nanosecond...
I don’t think modern webshit which requires downloading megabytes and megabytes of obfuscated code to view someone’s blog is an “advancement” for anyone except the adtech bastards.
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 still lots of good managers and good devs that value adequately done products, but on average that's not the case and the Web gets more and more bloated as a whole.
One day you decide to disable JavaScript in your phone (which BTW is an incredible way to speed up modern webshit, as the sibling comment puts it, in under-powered mobile devices), and turns out that lots of f*ing blogs don't load their plain text and static pictures if JS is not enabled. That's an absurd situation we've collectively ended up in.
The mere thought of having a Word document with just text, images, and a couple tables, and not being able to open it if VB macros were disabled, sounds absurd. But that's exactly what large parts of the Web have become.
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).
Then read this comment:
https://news.ycombinator.com/item?id=36849820
> you can still view it through https://nitter.net, which I guess makes the open source Javascript-less front-end to Twitter more accessible for SEO
WHAT? I had no idea. So there is Nitter [1] frontend for Twitter -which is a platform clearly more complicated than HN- and they manage to not only work without JavaScript, but have it as one of their core motivations.
Things get even better, from that project I find about Invidious [2], a frontend for nothing else than YouTube! And again, no JS is not only an option but a highlighted feature.
After these discoveries, my bar for how JS-free we should expect most websites to be has just gone up, not down. Especially those websites consisting on just presenting text and media (i.e. the immense majority)
I agree the war is lost, though. Luckily there will still exist people desiring and making noise for a leaner and faster experience. The problem is bloated frameworks and privacy invasion via JS. Those are essentially my main reasons to want to browse the Web without JS.
Of course, a lot of those "fixes" now break things, because the underlying workings of windows changes a lot, but every last person I know who uses these has very odd problems with Windows that I have never once seen myself.
a lot of these things that only experts knew how to do 20 years ago are now the causes of very odd problems, because these folks don't bother to verify that these registry settings are still the correct way to make the intended changes.
In short, I entirely agree with @brasic: the article author has a nonstandard configuration (clearing cookies automatically before their expiry date) and based their entire article on the difficulties that this highly unusual and unnecessary choice has caused for them. "Hair shirt" is a great way to describe it.
> Making healthy security conscious decisions like low TTLs on local cookie storage (such as cookie purge on browser/tab close) feels unrewarded when the site enforces additional security gates on login. The point is: unique login devices may have been a good idea, but in practice the design of the web does not make them an ideal candidate for bolstering user security.
This is exactly @brasic's point, though: if a website can affirmatively identify that you've logged in from this machine before, that's a pretty good indicator that this new session is a legitimate login. We can do that through cookies, and for most users that's just fine. If you clear cookies regularly for security reasons, then you shouldn't be offended that a website asks you for extra confirmation that you are you, since that is also done for security reasons.
Clearing cookies for a domain is instructing your browser to identify itself as though it had never spoken to that server before. If you want the server to know you're still you, maybe just leave the cookies there?
The last two posts from the same author[1][2], in the past month, where of the same kind and got the same kind of reception (except that for the fediverse blog post, the top comments were either discussing about the topic of the title without addressing the (dumb) content of the article). So yeah, the mystery is why it keeps coming back.
[1]: https://news.ycombinator.com/item?id=36549218 [2]: https://news.ycombinator.com/item?id=36466133
I don't think so. Most people who understand that that will break "remember this device" also understand that clearing cookies doesn't help much with privacy. So the people who do enable that setting generally only know that cookies == tracking and do not understand that that will break "remember this device" ("Dunning-Kruger").
Cookies are cookies, not a "device". You could theoretically copy whatever cookies they put in to authenticate in other place and get automatically logged in.
> The author has configured their browser to throw away cookies when the last tab closes
If web was supposed to be stateful, this would be a bug, and the author would have had to dig through experimental or advanced settings to enable it. But because web(HTTP) is fundamentally stateless, it is a feature, and it's a feature that every browser exposes to normal user. Your browser is not expected to keep your cookies, just like your browser isn't expected to support javascript to access a website, or that you should enable them even if you could.
The phasing out of third-party cookies has nothing to do with the "remember this device" functionality, because those are almost always powered by first-party cookies, which are not being phased out.
The author has configured their browser to throw away cookies when the last tab closes, and that's their prerogative, but anyone who is savvy enough to configure that setting is also savvy enough to understand that that will break "remember this device". For everyone else, that phrasing is a perfectly reasonable abstraction on what is actually happening.