The max age of a cookie is a little more then a year, meaning that as long as you visit a site more then once per year, this is possible.

Coookies can live longer than a year. Making it no longer possible to make them "permanent" is a browser specific thing.

Honestly that feels like what apps are. One of the most compelling reasons to install an iOS app for something like an online bank is so that I won't have to worry about my cookies expiring and forcing me to login again.

My banking app makes me log in every time. I prefer that, but I didn't realize some apps don't do that?

My banking apps ask only for my fingerprint, or a short PIN if biometrics are not available. You could call that “logging in”, but it’s certainly not as serious of a log-in as you would have on the web (with a username and a password, and if the computer is unrecognized, authentication on the phone).

Most of mine do too so I don’t use them.

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.

This is why I hope PWAs take off more. If there is an implicit "save first party cookies forever" for PWAs that have been "installed" and we make them discoverable it's a net win.

Apple will make sure PWA's aren't successful. They can't risk their control over the app ecosystem.

Are you aware that iOS supports PWAs, and recently implemented notifications for them?

Exactly, they are in recent years moving to address these previous issues, I applaud them.

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.

Only 8 years late: https://developer.chrome.com/blog/push-notifications-on-the-...

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.

Fascinating how to keep moving the goalposts.

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?

If you want to use a PWA on an iPhone, you are fully dependent on Safari support. Firefox's decisions here aren't blocking anyone.

Firefox Android certainly supports Progressive Web Apps with push notifications, I use them daily.

>50 MB excludes most messaging apps

The entirety of TempleOS (including dozens of programs and multimedia games) is 2MB.

At 640x480 (for the whole screen) and 16-bit color

Hey, TempleOS is simply using the resolution God requires.

This isn't just the limit for css/js... It's the limit for user data too. Ie. if you share some videos with a PWA app, then all the videos have to fit inside 50MB unless you want to fetch them from a server each time you play them.

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 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 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.

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.

But then there are apps like Discord which log you out of the app if you don't use it for X days.

I hate the fact that if you lose your phone and restore to a new one, suddenly every app is logged out again.

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.

On iOS many (most?) apps do store your credentials in a way that you don’t have to login if you have restored from backup or setup a new device from backup. Not all do this. Google is one annoying example that requires a fresh authentication.

I think if you do an encrypted itunes backup to your mac, they should remain signed in

Note that this is now in Finder, not iTunes, as of.. some recent MacOS? 11?

> Honestly that feels like what apps are.

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.

You don’t force login on your banking apps? Eek. Or maybe you mean they do biometric auth instead of user/pwd? Leaving banking/finance apps unprotected sounds sketchy AF to me.

Might as well use client certificates at that point. Along with TFA, if we don't have users choose passwords, then just issue a client cert and have it installed in the browser, would probably require some new web standard.

So, like Passkeys / WebAuthn?

passkeys is a common noun (like the word “password”) and therefore should always be lowercase unless it’s the first word in the sentence.

What you're looking for is client certificates. This has existed for years but webby people think users are too stupid to use them, so we get the menagerie of half baked trash we have now instead.

> What you're looking for is client certificates.

I agree with this, but...

> users are too stupid to use them

they are. Key management is not trivial.

Yes, if you've ever managed a shared unix system that uses ssh keys for login, you know that a large fraction of users cannot manage them.

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.

It seems a little bit uncharitable to assume the UX on client certs has to be as bad as the UX on SSH keys, although I'll concede the point that historically it has been.

When I worked on a code signing app, I had front row seats to how magical everyone thinks certificates are. It took me several years to convince the group that they aren't that complicated.

I think the world would be a better place if LetsEncrypt had come into being about five years earlier.

It's a myth, they are not. They are uneducated and lazy¹, not stupid.

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.

The UX for client certificates is horrible and practically an afterthought, so it's no surprise.

Client cert handing at the load balancer level and reverse proxy level are stupid hard to get right.

I would burn client certs to the ground if I could.

Sounds like certificates. You can use ssh this way, for example.

You can use mTLS client certificates (kept in the system key store) in browsers this way; but the UX is pretty hard to get right, and certificates nearly always have to have an expiry date to deal with the compromise-able nature of keys imported into the system key store.

I saw this pattern done on a forum. You just provided your email, and it would set a super-long-lived cookie. There was a button for "recreate my cookie" which sent you an email - like a password reset function without a password.

It was surprising the first time I used it but now I wish everything that didn't handle cash worked that way.

And then the credentials get stolen through phishing

The idea with client certificates is that they'll live in a secure keychain and never leave it. The API exposed by whatever manages them will expose functions of the key (authenticate, encrypt) but not the key itself. If the implementation is decent, you'll authenticate every request, so it isn't possible for requests to be forged or credentials stolen unless you've got a vector to attack the OS's keychain.

>There would be mechanisms to backup my permacookies, or transfer them to other devices.

There would also be intentional and unintentional mechanisms for stealing these permacookies.

Password managers could take over and manage cookie storage/retrieval.

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.

Firefox remembers my passwords for me already. Why would I need an extra tool to do it? And so does Android.

not all of my passwords are for browser-based services, not all of my secrets are passwords, and I have several devices with different operating systems.

(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)

I think SQRL does this. But since no one can own it or sell it, it will never be adopted by anything that matters.

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

Fruitcakes.

My first thought was "ship's biscuits".

we already do have that and needs no certificates or other complex things for the end user: https://developer.mozilla.org/en-US/docs/Web/API/Window/loca...

is it secure? hell no, but it can be used.

[citation needed] on local storage being more durable than cookies.

Webauthn should allow use of private key authentication stored on external hardware key or in device.

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 :)

How about local storage? Only downside is that this data isn't sent automatically on ever request (unlike cookies). It would be possible though to send this secret from local storage via a separate request and receive a session cookie that then let's you be logged in automatically

Maybe shared local storage should be a browser standard. Let me keep track of my own data, but also share it with my tablet and phone by clicking a bunch of buttons.

Even better: shared storage where every website has access to the same storage data.

Log in once, on one website, then be logged in on all websites forever.

Isn't that basically third party cookies all over again?

If you work for advertisers this sounds like a great idea. Better than eating babies.

This is circling around Native File Access, which is absolutely something the web needs and if handled correctly would be a huge improvement for user privacy and user autonomy. It would open the door for fully offline webapps with no accounts or serverside components, with much better sandboxing than native apps, and with full user control over app data using just a file browser. And it would allow for app data that could be easily shared between apps when necessary without compromising user privacy or security because the app data would just be a directory with files.

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.

Is that what I'm talking about though?

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.

I don't know, I use filesystem sync for all of that. All that really means is that on iOS/iPad you'd have a file portal sitting in front of your browser. And on Android, it's already filesystems anyway.

Maybe you're right though and the UI would need to be different :shrug:

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 exists to make that HTTP request in the context of the current tab, apparently.

You can log the user out by changing the “realm” parameter, which is a freeform string and can be quite long. As well, setting realm will cause devtools to use cached credentials similar to a new tab.

“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)

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

Safari on iOS does not play nice with Basic Auth. No credential saving, re-promting you for credentials on each page you navigate to.

non-iOS browsers seem to handle HTTP basic auth gracefully.

There was a time that I can remember practically every site that needed a login using basic auth, before people switched to textboxes.

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.

Know what my favorite part of the whole modern auth is? The most "reliable and secure" way to enter and transmit credentials is the browser. You know, that thing that has had absolutely tons of footguns with XSS problems, terrible cookie management/stealing, and generally leaving things up to websites to do auth.

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).

> This is what HTTP auth headers are for, but the UX for using header authentication on modern browsers is utter garbage.

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.

That’s what Passkeys are supposed to do. You have an identity tied to that website, shared across all your devices.

Pulling on this thread a bit, when I get a new set top box, most of the apps have a url or a QR code you can use to copy your session to a new machine. You could just do that for all machines and have no cookies at all. iOS even has some ways to make that a bit easier.

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.

Many websites and apps can do this, but explicitly do not in the interest of 'security' and 'anti-fraud'. Discord is a pretty bad offender of this.

Passkeys?

Isn't such a thing called a crypto key? And if you had such a thing, why in the hell would anyone sensible ever use browser cookie functionality to store that?

Learn to use a password manager.

I'm sure I'm missing something, but... isn't that cookies?

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.

That basically sounds like what yubikey’s and the like try to do.

Passkeys are what you describe here.

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