For the juniors reading this, here's what you do:

Buy a second domain, ideally using the same TLD as your production domain (some firewalls and filters will be prejudiced against specific TLDs). Mimic the subdomains exactly as they are in production for staging/dev.

Yep. Even within the prod environment it's ideal to have a separate domain (as defined by the Public Suffix List) for sketchy stuff like files uploaded by users. Eliminates a whole class of security issues and general fuckery

I had the option to re-use the prod domain for non-prod a few years ago (the company's other two projects use the prod domain for all non-prod environments).

I didn't really think about cookies back then but it just felt like a generally bad idea because disastrously messing up a URL in some config or related service would be much easier.

I'm sure this will be replicated in future projects because it's much easier to argue "we're already following this pattern so let's be consistent" than "this pattern is bad and let's not have two ruined projects"

This is one of those things where specs are still hard to parse.

It is considered invalid syntax to lead with a dot by the rules. But it also must be ignored if present. Its lacking a “MUST NOT” because the spec is defining valid syntax, while also defining behavior for back compat.

It would break too many things to throw here or serialize while ignoring the leading dot. Leading dots are discouraged, but shouldnt break anyone following the spec. Maybe a warn log in dev mode if serializing a domain with dot, to try and educate users. Dunno its worth it though.

The point of jshttp IMO is to smooth over these kinds of nuances from spec updates. So devs can get output which is valid in as many browsers as possible without sacrificing functionality or time studying the tomes.

Can you elaborate? I'm having a tough time finding references to that. (Disclaimer: I'm not an avid JS developer)

I am using path to wire my http only cookies to be sent only to /api not in assets/html requests. The cookie will eventually contain a JWT token I do use as an access token. Consequently I will probably wire my refresh cookie only to be sent to /api/refresh-token and not in other requests.

The client won't get to decide which cookie to send where.

Looks like a good pattern to me.

But if the attributes are exactly the same then the cookies replace each other. So this isn't a general mechanism for representing a list.

Not to mention that the way to delete a cookie is sending a replacement cookie that expires in the past. How are you supposed to delete the right cookie here?

Not really. A lot of essential third party Rust crates and projects have "weird" names, eg. "nom", "tokio", etc. You can see that from the list of most downloaded crates [1].

This one just happens to have been owned and maintained by core Rust folks and used in a lot of larger libraries. This is more the exception than the rule.

It's a given that you should do due diligence on crates and not just use the first name that matches your use case. There's a lot of crate name squatting and abandonware.

Rust crates need namespacing to avoid this and similar problems going forward.

[1] https://crates.io/crates?sort=downloads

Would “rookie” be the obvious name in that case?

> middleware boxes which block any protocol they don't understand-- because, hey, it's "more secure" to default-fail, right?

If the intent is to secure something then failing-open will indeed be at odds with that goal. I suspect you’re not implying otherwise, but rather expressing frustration that such providers simply can’t be bothered to put in the work and use security as an excuse.

That was the model that Microsoft used at the height of their power and dominance in the 1990s and 2000s.

> a monopoly dictate a nice clean spec which they can force-deprecate whenever they want

We already have that at times. Apple forced a change to cert expiration that nobody else wanted, but everyone had to pick up as a result. Google regularly forces new specs, and then decides "actually we don't like it now" and deprecates them, which others then have to do as well. Virtually all of the web today is defined by the 3 major browser vendors.

If all these "specs" actually had versions, and our clients and servers had ways to just serve features as requested, then we could have 20 million features and versions, but nothing would break.

Example with cookies: if the cookie spec itself was versioned, then the server could advertise the old version spec, clients could ask for it, and the server could serve it. Then later if there's a new version of the spec, again, new clients could ask for it, and the server could serve it. So both old and new clients get the latest feature they support. You don't have to worry about backwards compatibility because both client and server can pin versions of specs and pick and choose. You can make radical changes to specs to fix persistent issues (without worrying about backwards compatibility) while simultaneously not breaking old stuff.

But we can't do that, because "cookies" aren't their own spec with their own versions, and clients and servers have no way of requesting or advertising versions of specs/sub-specs.

You could actually implement this on top of HTTP/1.1:

  1. Make cookies their own spec, and version it
  2. Add a new request header: "Cookie-Spec-Ver-Req: [range]"
  3. If there's no request header, the spec is version 1.0
  4. If Server sees a request header, it determines if it supports it
  5. Server replies with "Cookie-Spec-Ver: <version>" of what it supports, based on the request
  6. Client receives the spec it requested and handles it accordingly

This actually makes sense from a programmatic standpoint, because "Cookies" are implemented as their own "Spec" in a program anyway, as a class that has to handle every version of how cookies work. So you might as well make it explicit, and have 5 different classes (one per version), and make a new object from the class matching the version you want. This way you have less convoluted logic and don't have regressions when you change things for a new version.

There's no differences between a monopoly and an open standard when it comes to breaking users. They both would rather not for the same reasons

They are not the only place to store tokens. You can store tokens with localStorage for JS-heavy website, in fact plenty of websites do that. It's not as secure, but acceptable. Another alternative is to "store" token in URL, it was widely used in Java for some reason (jsessionid parameter).

Imagine pwning a frontend server or proxy, spawning an http/s server on another port, and being able to intercept all cookies and sessions of all users, even when you couldn't pwn the (fortified) database.

This could have a huge advantage, because if you leave the original service untouched on port 80/443, there is no alert popping up on the defending blueteam side.

This gives me an idea for a project...

[flagged]

I think one important use case we have for cookies is "Secure; HttpOnly" cookies. Making a token totally inaccessible from JS, but still letting the client handle the session is a use case that localStorage can't help with. (Even if there's a lot of JWTs in localStorage out there.)

Every privacy advocate I know hands over exquisitely detailed private and personal information to Google and/or Apple. It seems unfair to generalize as “privacy advocates” so much as it is people who are anti-ads.

Being anti-ads is a valid opinion. It has less intellectual cover than pro “privacy” though.

Safari is a lot more strict about cookies than Chromium or Firefox, it will straight up drop or ignore (or, occasionally, truncate) cookies that the other two will happily accept.

I had hoped when writing this article that Google would look at Safari and see that it was always strict about feel comfortable about changing to be the same. But doing so now would unfortunately break too many things for too many users.

If I open a second window or tab I expect when I go to 'myemail.com' that it knows who I am and shows me my account even though the url in the 2nd tab doesn't have any extra info in the URL

Definitely don't use "SuperCookie" as that's a thing: https://en.wikipedia.org/wiki/HTTP_cookie#Supercookie

His Majesty's English might suggest "biscuit".

A Dookie is a digested Cookie.

Muffin? Cake?

You graduate from consuming cookies to eating...

TrickOrTreat would seem appropriate.

We already have Macaroons

https://en.wikipedia.org/wiki/Macaroons_(computer_science)

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

https://xkcd.com/927/

Isn't it a lot more than 3%? I don't think I've heard anyone say url-safe-base64 and actually mean urlencode(base64(x))

oh, geez. No, just base64, using the URL safe alphabet. (The obvious 62 characters, and "-_" for the last two.

It's called "urlsafe base64", or some variant, in the languages I work in.

> This encoding may be referred to as "base64url".

https://datatracker.ietf.org/doc/html/rfc4648#section-5

But yeah, it's not base64 followed by a urlencode. It's "just" base64-with-a-different-alphabet.

I agree that being liberal in what you accept can leave technical debt. But my comment was about the place in the code where they set a cookie with JSON content instead of keeping to a format that is known to pass easily through HTTP header parsing, like base64. They should have been conservative in what they sent.

Following Postel's law does not mean to accept anything. The received data should still be unambiguous.

You can see that in the case where ASN.1 data need to be exchanged. You could decide to always send them in the DER form (conservative) but accept BER (liberal). BER is still an unambiguous encoding for ASN.1 data but allow several representations for the same data.

The problem with BER mainly lies with cryptographic signature as the signature will only match a specific encoding so that's why DER is used in certificates. But you can still apply Postel's law, you may still accept BER fields when parsing file. If the field has been incorrectly encoded in a varied form which is incompatible with the signature, you will just reject it as you would reject it because it is not standard with DER. But still, you lessen the burden to make sure all parts follow exactly the standards the same way and things tend to work more reliably across server/clients combinations.

You could split the difference with a 397 TOLERATING response, which lets you say "okay I'll handle that for now, but here's what you were supposed to do, and I'll expect that in the future". (j/k it's an April Fool's parody)

https://pastebin.com/TPj9RwuZ

And yet the html5 syntax variation survived (with all it's weird now-codified quirks), and the simpler, stricter xhtml died out. I'm not disagreeing with out; it's just that being flexible, even if it's bad for the ecosystem is good for surviving in the ecosystem.

[flagged]

So the problem with Postel's law is that people don't follow Postel's law?

What about things like local storage?

They are not bad they just are unnecessary. If your application uses local state, use local storage. If you store session data on the server, identify the user using the Authorization header. Why send arbitrary strings back and forth often with requests that don’t need them. Plus the technology is clearly rotten. They never got namespacing snd expiration right so you can just do weird stuff with them. Also, CSRF wouldn’t be a thing if cookies weren’t. This is like saying “why is finger/gopher/etc. bad?” They are not exactly bad but they are obsolete.

[flagged]

JSON is explicitly a string serialization format.

Combine local storage with service worker, so you pass the data to the server if needed. Completely without setting cookies.

Jwt is encoded and it is used for data without a server session.

I'm not a fan for jwt and it used more often than it should, but sometimes it makes sense.

But at least they’re base 64 encoded so you don’t have to worry about the special characters

How?

At the very least localstorage is supported across the board

I don't think you can blame postel's law for people not following it.

> when the whole ecosystem follows it you get a gigantic ball of slightly different interpretations

You're describing the properties of a long-lived, well-used, well-supported, living system. We'd all like the ecosystems we have to interact with to be consistent and well-defined. But even more importantly, we'd like them to exist in the first place. Postel's law lets that happen.

If your app is a leaf node in the ecosystem, and it's simple enough that you have direct control over all the parts of your app (such that you can develop, test, and release updates to them on a unified plan/timeline), then, yes, fail-early pickiness helps, because the failures happen in development. Outside of that you end up with a brittle system where the first place you see many failures is in production.

Quotes don't delimit the value.

But it's so solvable that I shouldn't have to solve it

Native desktop development.

They still do take the store page offline in the leading hours and during a keynote.

Well, we’re getting into how to choose metaphors here. Not being literal, there’s always room to stretch. Still, you try to choose a metaphor with characteristics congruent with the topic.

With a minefield, you can be doing something perfectly reasonable, with eyes open and even paying attention yet nevertheless it can blow up on you.

Here, though, there’s no special peril. If you just follow the standard everything will be fine.

If this is a minefield, then practically everything in software development is equally a minefield and the metaphor loses its power.

(Later in the article they touch on something that is a minefield — updating dependencies. There’s probably a good article about that to be written.)

Probably just semantics.

It sure doesn't, that was a comment for a completely different post. I have no idea why HN posted this comment on this article instead of the PHP 8.4 article I thought I was commenting on O_o