C is for Cookie 🍪 - Russell Keith-Magee

Well

Speaker 1: hello internet. My name is Russell Keith McGee. I am speaking to you today from Wajuk Nunga Budja, otherwise known as Perth Western Australia. And I'd like to begin by recognizing the Wajuk Nunga as the traditional owners of the land where I'm presenting today and to pay my respects to their elders past and present. I have been a long-term fixture at DjangoCon. I joined the Django Core team way back in 2006. Now, at one level, there have been a lot of changes to the web over those 14 years. We've seen websites become more dynamic. uh rise in the importance of JavaScript in front-end development. Uh front-end frameworks uh have risen and fallen. We've seen the emergence of serverless. In short, the web of today doesn't look a lot like the web of 14 years ago. But on another level, there are some things that really haven't changed at all.

Speaker 1: And I'd like to talk about one of those things today, cookies. Cookies predate Django by over 10 years. And although there have been some changes over the years, fundamentally the cookies that existed 10 years ago or even 25 years ago are the same cookies that we have today. That said, the changes that have occurred are very important. And there are some more changes on the horizon that as practitioners of web technology we should be aware of. So today I'm going to talk through the history of cookies, dive deep into what a cookie is, how they're used, how they're abused, and what the future holds. So what is a cookie? Well, at its core, a cookie is a neat hack layered over the original design of the web The web that Tim Berners-Lee developed in 1989

Speaker 1: is a very different web to the one we have today. Berners-Lee was working at CERN, where he was working on a document sharing platform. It was a way for one researcher or academic to share their research with another researcher or an academic. Back then, a document was a single standalone HTML page, marked up with headings and paragraphs and so on The really revolutionary thing that Tim Berners-Lee added was that anyone in the world could see the document. Any document could link to any other document, either on your own server or on someone else's server. And those documents could link to other documents, building this worldwide web of documents. But every web request was completely stateless. You ask, give me the document, research 2019 emerging pandemic.

Speaker 1: and it would return a single document. And if you followed a link to another document, that request was completely detached from the first request. But once you move beyond displaying static documents, you need state. Now, let's imagine I'm visiting a hardware store where all of the interactions are completely stateless. I walk up to the sales assistant. server if you will and I say I'd like to buy a shovel and the sales assistant turns to me and says ah they're over at aisle three And so I wander over to aisle three and I don't find what I want. And I so I come back to the server and I say, I was hoping for something with a longer handle. And the sales assistant comes to me and says, uh what with a longer handle? And I say a shovel. And this disabled system says, well, they're over in aisle three.

Speaker 1: At which point I table flip in frustration The moral of this story is that complex interactions over time require preservation of state. When I asked that second question, the sales assistant didn't have the context of the first question that I'd asked, so they weren't able to provide a useful answer. Now, it's important to remember though that the web's stateless nature is also one of its greatest strengths. Because each request is stateless, every request can be handled independently, and that is incredibly powerful for web load balancing. Going back to our original shop assistant example, imagine our hardware store only had one shop assistant and thousands of customers appear. Most customers are going to be waiting a long time to get a response to their question But because this is a stateless system, we can fix the problem by adding more sales assistance, by adding more servers.

Speaker 1: Now that doesn't improve the quality of the answers, but it does mean we can ensure that everybody is satisfied in a timely fashion. We have a built-in scaling mechanism. no matter how many people come to the store. So we don't want to lose that benefit. If we made the store stateful, every customer who had a question would need to go back to exactly the same sales assistant. And you'd end very easily end up with one sales assistant being flooded with follow-up queries while others sat around idle. So what we needed to do really is to make our shop assistant a little bit more helpful. So how do we do that? Well, one approach, and often the approach that was actually first done before the time of cookies, was to use a token to represent the person and encode that token into the request itself and store the state for each person. keyed to that token.

Speaker 1: Let's go back to our hardware store. The exchange now looks something like this. I walk up and I walk up to the server and I say hi I'm Russell and I'd like to buy a shovel. Sales assistant looks up the history, finds nothing for Russell in his records and says, ah, go over to aisle three. I then walk over to aisle three, discover that there's no shovel that I want, I come back to the server and say, hi, I'm Russell. I was hoping for something with a longer handle. The sales assistant can now look up the history associated with Russell Find that I've previously been asked about asking about shovels and say, ah, okay, you want to go over to aisle seven then. Everything, you know, every request in this interaction. also includes a token that identifies me as the person making the request. And that provides something that the sales assistant or the server can use to identify me and thus my historical requests.

Speaker 1: More importantly, it allows any sales assistant to satisfy the second request. There's nothing about this request that is tied to the sales assistant who served me. It's tied to my token as a user Now, since this is the web, the obvious place to put this token is in the URL. Every request contains a little bit of content that identifies the state, in this case, the person making the request, customer equals Russell. However, if you do this, the token being passed around to identify me is public. There's no difference between me making a request with customer equals Russell as an argument and an attacker making a request with customer equals Russell as an argument. argument. Anyone looking over my shoulder can see that token and they can start making requests with the same token. It doesn't even necessarily have to be malicious. I could copy the URL from my browser, send it to my friend, and now my friend is making requests as if they were me.

Speaker 1: Now in this case, you know, who cares? We're looking at loghandled shovels. But imagine I was looking at my medical records. Now my attacker can see everything see everything about my history. Or if I was buying a limited edition gold-plated shovel, the attacker could get in before me and buy that shovel that I had previously been looking at. My session could be hijacked by someone else. So the concept of a token works, but putting it into the URL is a problem. So where else can we put it? Well, instead of the actual request, let's use the unspoken conventions around the uh the conversation itself. Let's go back to our hardware store. I go up to the hardware store and I say, I'd like to buy a shovel. The sales assistant says, ah, that's all over in aisle three and hands me a plastic tag with a number on it. I go over to while three, discover

Speaker 1: the shovel that I want isn't there, and I come back to the server waving the tag saying I was hoping for something with a longer handle. the sales assistant can look at the tag, look up the history associated with that tag, find my previous request, and then say, ah okay, you want aisle seven then. This time, I'm not verbally identifying myself with every request. The first request is just a request, but in the response, the server gives me a token in return. And if I present that token with subsequent requests without saying anything, the server can identify who I am and the history of my requests. And that information is tied to the way that I'm interacting with the server. not the content of the question that I'm asking. In order to impersonate me, an attacker needs to get a copy of the token that the server gave me.

Speaker 1: And that's all a cookie is. Cookies were originally invented by Lou Muntuli, who was one of the founding engineers at Netscape. Quick sidebar, Lou Montuli has another claim to fame. He was one of the authors of Lynx, which is the oldest web browser that is still maintained and in use today. For the youth in the audience who have never heard of Lynx, Lynx is a browser that you can run in your terminal in text mode. Why is this interesting? Well, Montulli wrote Lynx while he was at university, the University of Kansas Lawrence. a city that 12 years later was the birthplace of Django. Lawrence really is one hell of a town. But back to cookies Cookies are formally part of the HTTP specification. They're included as part of the metadata that accompanies a request and a response.

Speaker 1: In terms of the formal standard, cookies were originally formalized in 1994 in RFC 2109. The RFC was revised in 2000 as RFC 2965 and again in April 2011 as RFC 6265. The W3C is currently working on a revision to the cookie standard. The most recent draft is called RFC 6265 BISO5. Now, in practice, most browsers today implement something somewhere between the formal 6265 spec and the BIS5 variant. That's because web standards are a little bit weird. Implementations often precede the formal standardization process. If you read RFC 6265, which is the last ratified standard, it's what's referred to as a proposed standard, even though it's the thing that pretty much everyone uses.

Speaker 1: However, the core of this standard hasn't changed that much since 1994. So what does a cookie look like in practice? Well Let's look at our interaction with the hardware store and replace our human server with an actual computer server. Our original request is for a specific URL. http hardware store. com slash purchase. We make that original request on the hardware store's web server. We name the page that we want, slash purchase, the host we're requesting and the content, some information about the browser we're using to make the request, the content that we're happy to accept. There's a response. And in a stateless world, the response from the server would look something like this. It gives the server response code. a time span for timestamp for the response and details about the content that's going to be returned. And then the actual HTML content

Speaker 1: If we want to make this a stateful response and include a cookie, we add one line to the header of the response. We add a set cookie header. and the cookie itself is then key equals value. In this case we're setting a cookie uh SID, the session ID, and we're setting it to a value of 6789. We could, if we wanted to, set multiple cookies by including multiple set cookie lines in our header. So here we set a second a second cookie for favorite color equals red. Then in subsequent requests we include the cookies as part of the request header. So if there are multiple cookies, the key value pairs are then separated by semicolons. Subsequent server responses can then update the value of cookies that have already been sent. So in the next response, we might return favorite color equals blue. The cookie store on my browser is then updated to reflect that.

Speaker 1: And fundamentally, that's all a cookie is. The key and the value can be any printable ASCII character, excluding comma, the semicolon and white space, or including excluding semicolon, comma, semicolon, and white space Equals is valid in the value, but not in the key. Strictly speaking, RFC 2965 is a little bit more restrictive than this, but in practice, browsers don't actually implement most of those restrictions, so you're generally good with any printable ASCII. The value can be anything up to 4,096 characters in length. Nothing will stop you from trying to send a cookie that's longer than 4,096 characters in length six characters though and some browsers will even return longer cookies but it's not guaranteed by the spec so it's generally not a good idea to rely on that Now the examples that I've given so far are the simplest possible form of a cookie.

Speaker 1: They're what's called a session cookie. They disappear as soon as you close your browser. Now that distinction has become a little bit more hazy with browsers that restore sessions after after you close the browser. But in principle, session cookies aren't are only supposed to last until the browser is closed. Once you close the browser, the cookie goes away But there are other keywords you can include on the cookie definition that will modify the behavior of the cookie. And I'm going, although I'm going to talk about them one at a time, they're not mutually exclusive. You can set all of these values on a single cookie if you wanted to. A permanent cookie is a cookie that has an expiration date. A cookie is stored in your browser and will persist even if you shut down your browser and reopen it It's expected that the browser will include that cookie on all requests up until that expiration time, at which point the cookie is then discarded.

Speaker 1: The standard has, since the very first cookie RFC, allowed two ways to specify this expiration date, expires, specified as a date time, and max age, specified as the number of seconds into the future. If the date is set into the past or the max age is zero, the cookie uh is supposed to be deleted. However, Internet Explorer didn't honor max age until 2016. Which does raise an interesting point. All this cookie behavior that I'm talking about is entirely up to the client to honor it. It's entirely up to the browser to honor these cookie settings. And this will come up again later. Now by default cookies are bound to the domain of the originating request. So you can't set a cookie for someone else's domain. However, you can apply a scope to a cookie.

Speaker 1: So that scope can be a domain or a path or both. So if you want to set a cookie for a specific subdomain, for example, you can specify the subdomain that you want the cookie to apply for. In recent standards, cookies can be read by any subdomain of the domain to which they were set. However, all the standards required you to use a dot prefix if you wanted a cookie to be explicitly visible on subdomains. So yeah, arguable it might be a good idea to keep using that dot prefix. This isn't completely open-ended though. The domain that you set the cookie for needs to match the domain that was serving the page that was requested. So hardware store. com can't set a cookie for domain equals cheeshop. com. Path level scoping allows you to restrict the cookie even further, so you can restrict a cookie to only be applicable to paths.

Speaker 1: under the, for example here, slash purchase path, including all the subpaths of slash purchase. But if you went to slash account, the cookie wouldn't apply in this case. And you can then combine domain and path on the same cookie. You can also mark a cookie as being secure. Now you need to be careful here. Marking a cookie as secure doesn't actually provide any real security around the cookie itself. It doesn't do any extra encryption or protection of the cookie value. It is purely a flag that says this cookie should not be sent over insecure channels. So if the cookie is flagged as secure, it won't be sent over HTTP. It will only be sent over HTTPS. This is also a good time to point out that cookies are ultimately user-provided content. This means you need to treat them as hostile

Speaker 1: content Store data in cookies, but verify that data, but definitely don't put code or executable objects like pickles in cookie in a cookie. Firstly, who would put pickles in a cookie? But more often, but more importantly than that, the end user could send you malicious content and cookie, uh pickles are executable content at the end of the day, so be careful about what you put in your cookie. Something that does provide some security is the HTTP only flag. Now this flags that the cookie should not be visible to JavaScript requests. Now this is useful because it prevents JavaScript on a page from reading a cookie, which is probably the easiest way to exfiltrate a cookie from a from a site, either intentionally or unintentionally. The last cookie option I want to talk about is the same site flag. Now, this is an option that isn't in the RFC 6265 spec, it's in the BIS5

Speaker 1: revisions, but it is already in wide use and the landscape around this flag is changing. It all relates to what is probably the highest impact change to cookies since they were first introduced. But to explain what's going on, I need to give a little bit of context and background. So far we've been talking about Hardware Store's website as if it was a single standalone site. As a user, you visit hardware store. com. All the content is served by hardware store. com servers. However, in the real world, you probably want to include content that's hosted on other sites. My homepage for hardwarestool. com might include static image content served from static. hardwarestool. com It might include framework code coming from a CDN, bootstrap, jQuery fonts. And it might include a reference to some analytics or an ad server. HardwareStore. com is my code surfed off my

Speaker 1: server. The static content is my content, possibly served by a completely different server or an S3 bucket. Frameworks, analytics, and ad content will be served by those respective companies' servers or CDNs. Every asset that is served is a unique request, and each request can set a cookie, but it can only set a cookie for the domain from which it is served. If I request content from hardwestore. com and it sets a cookie for hardware store. com, that's called a first-party cookie But if I request content from hardware store. com, which in turn requests content from a CDN or an analytics site or a server or any server that is a different site to the one I originally requested, that's called a third-party cookie

Speaker 1: Now, to be clear, this is purely about the context in which the request for the content occurs. It's nothing about the content itself. Content that is a third-party request on one site would be first party if it was directly requested by the browser. And when I say site, I'm generally talking about the first part of the name that you could actually go to a domain registrar domain registrar and and reserve. www. hardware store. com and static. hardwarestore. com are both the same site in that context. However, there are some notable exceptions. For example, my site. github. io and your site. github. io are not treated as the same site, even though github. io would under normal circumstances be the base site for both. You know, it's the name that

Speaker 1: you could or would have registered if you hadn't got in before GitHub. This is because GitHub. io is on something called the public suffix list. The public suffix list is a cross-vendor project that's around to give an accurate list of the true domain name suffixes. And this is essentially a security measure because github. io is a well-known hosting site that anyone can publish on. I don't want your website on github. io to be able to set cookies for my website. Okay, so back to the same site cookie option. When you set a cookie, you can set the context in which that cookie will be returned. Same site equals none means the cookie is allowed in third-party requests. That is essentially cookie behavior as of 2010. Allow the cookie no matter the context generating the quest. Same site equals lax

Speaker 1: means that the uh the cookies are restricted to first party by default. However, cookies will be allowed on safe requests. to third party sites. So for example, if I'm on hardware store. com and you follow a link to chishop. com, that is a third-party request, but as long as the request is a get or a head request, what's called a safe request, Same-site. lax will allow cheeshop. com cookies to be sent. Same-site equals strict is the extreme version of Lax. It will only include the cookie if it is strictly first party, no exceptions Now, as part of a broader effort to encourage developers to adopt HTTPS, the same site attribute can only be used if you also set secure. Same-site is a good example of where browser behavior really matters.

Speaker 1: Remember when I said earlier that adherence to cookie behavior is in the hound of the browser? Well, browsers have been changing their defaults Starting in February of this year, Chrome 's changed uh the default behavior of SameSite so that you don't ex if you don't explicitly specify same site. your cookie will be interpreted as same site equals lax, which effectively means that your cookie won't be served on third-party requests unless you explicitly request it. What about other browsers? Well that's a more complex story and I'll I'll come back to that Okay, so so far I've been talking in the abstract about the cookie standard, about the RSC. How do cookies actually interact with Django? Well at the low level, there are three methods on a HTTP response object For setting cookies, there's set cookie, set sign cookie, and delete cookie.

Speaker 1: Why are there two methods to set a cookie? Well, because although the server sets the cookie, the client sends it. So if my server is using a cookie to store anything sensitive, like a user identifier or permissions, for example, I want to make sure that the cookie that you receive or that I receive as the server hasn't been tampered with by the user. To do that, Cookie allows you to sign a cookie. You can attach a cryptographic signature to the cookie value that can then be verified on subsequent requests. That doesn't stop the user from modifying the cookie. After all, the cookie is completely user-provided value, but it will identify if a cookie has been modified because the signature won't match if they have modified it. Other than that, the parameters on set cookie and set sign cookie match directly to the RFC. So they're just one-to-one correspondence with the with the uh the arguments that I was just

Speaker 1: I've just been describing. When you delete a cookie, the path domain and same site attribute need to match the values that were originally used to set the cookie or else the cookie may not actually be deleted. On the other side, how do you read the cookie? Well, if it's a simple unsigned cookie, the value is returned in the cookie's dictionary attribute on the request object If it is a signed cookie, you can get at it through the cookies attribute, but you just get the raw payload with the signature attached. To do that signature process, you're going to say request. getSignedCookie, provide the cookie and the and the salt to the used to sign it. By default, this will raise badge signature if the signature doesn't match. Alternatively, you can provide the default value that will be returned instead if instead of an exception. You can also ask for the age of the cookie to be checked at this point as well.

Speaker 1: There are a number of other areas of Django that use cookies. Django has cookies that will that it will use in various consequences, uh situations depending upon how it's configured. Django's session framework will store the session ID in a cookie, the name, max age, domain, all the other cookie flags, all those properties of cookies have settings to control them. The CSRF token is stored in a cookie as well. So is your language setting. And again, there are settings matching all of the cookie. specification flags that you can then use to control how your CSRF token or your language setting are con your language setting cookies are configured. However, for all these users, you don't actually need to care that much. Oh sorry, the the the one last place that Django might be using cookies is in your session data. I say might because it depends how you've configured your session backend, uh cookie storage, and fallback storage.

Speaker 1: uh session storage both use cookies as the way they persist uh that session information. However, for all these users, you don't really need to care that much. The cookies will just work. The only time you need to fiddle with those settings is if you do want to change like the domain where someone needs to log in or retain cookies across subdomains or improve the secur improve the security or make sure the cookies aren't being sent over HTTPS. So what uh what are the future of cookies? Well cookies have gotten a lot of attention in recent years, almost all because of one issue, user privacy. Let's say we need some extra revenue for our hardware store, so we and we insert ads provided by adserver. com. A user visits our site That page includes an ad from adserver. com. The user's browser requests the server, the ad from adserver. com, and the ad server sets a cookie to identify the user.

Speaker 1: Now, days later, the user visits cheeshop. com, which also has ads from adserver. com. When the user's browser requests that ad content, the cookie that was set during their visit to hardware store. com will be passed back to the ad server. And as a result of this interaction, adserver. com now knows that you are interested in both hardware and cheese. And if they've been clever, they don't just know the site you visited. They know things about the specific content you were looking at because of the referrer that get that sent the uh the request to the ad server in the first place. And they can use this to shape the ads you are served based upon what they know about your browsing history. And in the case where the ad server is a first-party provider as well, so Google and Facebook being the two major ones here They can shape the content that they show you as well.

Speaker 1: This means that ad servers and any other user-tracking sites now have a lot of information about users, and the evidence is that they're not always using it responsibly. Now there have been a couple of responses to this challenge. One has been legal. The EU passed EU Directive 2009-136EC as a direct response to this problem. This has led to the introduction of many, many annoying banners on every website, but hasn't had any appreciable change to the problematic behavior it was trying to address. There have been some standardization efforts though. In addition to a same site as a cookie change, there was an effort around an effort around this thing called the do not track header. something that browsers could inject into their requests to tell servers that their user was opting out of all tracking. That standardization effort didn't really change anything though.

Speaker 1: It wasn't widely implemented by browsers and wasn't widely honored by servers. And so that effectively died out last year. What has brought about change is public opinion and pressure that's been brought on browser manufacturers to protect users against bad actors in the in the uh the web in the web world. Apple started this back in 2017, introducing something called intelligent tracking protect prevention or ITP. Initially ITP limited the context in which third party cookies will be served. Uh in the most recent iteration of ITP launched yesterday, two days ago, essentially means that no third-party cookie on any browser on iOS 14 will ever be on it. Firefox started blocking third-party cookies in 2019. And earlier this year, Chrome announced they were going to kill third-party cookies entirely

Speaker 1: in 2022. This has caused a bit of a flurry in advertising circles because user tracking is at the core of how modern advertising works. And while it's very easy to say, ha, you know, good, I hate web ads anyway. This will have a big impact. Now, while when ads aren't targeted, they become less effective, and as a result, the price, the rate that advertisers are willing to pay also drops. How much does it drop? Google's estimate, they did a study and published some results of a study they did where they said that uh removing targeted ads would possibly halve or in or more than halve the revenue of the top 500 uh publishers uh out there and uh you know pup putting ads on their on their websites. And ads pay for a lot of the modern web, in particular the news.

Speaker 1: News sites are already struggling and losing 50% of what little revenue they've been able to generate through advertising could be the death of a lot of journalism. That's a problem for modern civil society. And because of that impact of the cookie opalips is so profound. The ad tech have been working on proposals that will allow targeted advertising to continue even though the the cook third-party cookies go away. Uh Google's advertising department has been furiously churning out technical proposals, which for some reason are all acronyms based on bird names. Private interest groups including Noise, Pigeon, two uncorrelated requests, then locally execute a decision on victory, Turtledove. These proposals are designed to allow advertisers to determine that you belong to a target group without allowing an advertiser to identify you specifically. They're complex.

Speaker 1: It's not clear if any of them will end up being widespread standards or being implemented at all. The other approach is changes in the advertising industry itself, returning to contextual advertising rather than micro-targeting Uh Internet era ad tech has been overwhelmingly based on micro-targeting, finding individual user behaviors to determine what ads get displayed. However, before the internet, all ads were contextual. The value of an ad was determined by where it was on the page and the content it was going to be placed next to. That sales approach requires no information about the user, and so it might actually be a salvation. And there's been some suggestions that it could actually increase revenue for new sites. Eric Holsch 's ethical ads framework is is a is a version of this, it's contextual advertising. So that's cookies. They have been a cornerstone of the web

Speaker 1: since almost the beginning. They are have there are some changes in the works, but from the perspective of a Django developer building a site that only has first-party cookies, those changes won't really affect You should still understand how cookies work though because they are fundamental to how the web works. And because you've all been such good boys, girls, and babies listening along today, now you get a cookie of your own. But because this Django Con is online, it's a do-it-yourself cookie. This is my family Chock Chip cookie recipe. I say it's my family recipe. It's actually from this book called The Cookie's Egg by Clifford Stoll. It's a book written about 1990 about a physics grad student who has recycled into the computer science department and goes on a very true, very real Fascinating adventure. It's a fun read from a time well before cookies, before even browsers.

Speaker 1: And the cookies are also delicious and amazing. Thanks. I'll be around for as long as I can. It's coming into the evening here in Perth. I look forward to seeing you all around for as long as I can stay awake tonight. Thanks very much. So I can see a lot of people in the room. Um Looks like everyone is muted, so going through Q<unk>A, uh Adam Johnson says the public suffix list feels like a hack. Is it part of a standard? Is there anything going is anything going to supplant it? Um so yes, it is a hack, but then again, so is the entire web. Um it is A hack that seems to be widely supported by everybody, and that's kind of the way the web works.

Speaker 1: Yeah, I I am not aware of anything that's gonna formally supplant it. I certainly wouldn't be surprised if something does though because it's you know the the net changes and everybody you know someone discovers a new way of doing something technically and they and they and they adopt that new standard. So I'm not aware of anything that's going to supplant it. Yes, it is a nasty hack. But it's also an like it is basically a nasty hack that works. So, you know, um at that level, does it matter if it's a hack? Um Anonymous asks, can't tracking trading information by cookies be substituted by different techniques like sending cookie data to services first using the first party backhand? Yes, yeah, so yes it can. However, it requires a lot more coordination to do that um and the sort of the the the infrastructure that's been set up at the moment, the

Speaker 1: ad ads need the response times are not particularly well disposed to ads going through uh third-party servers. The technique that's actually much more likely to be adopted and is is to some extent already being adopted is going to IP address because you can't mask an IP address. Your request comes from an IP and your the IP for your house is remarkably consistent. And there are databases available of these are all the IP addresses across the continental United States that are households. Um so yeah, there are definitely other ways of performing tracking. Um they are variously improved or not improved depending upon um so it won't go, yeah, uh the the removing cookies won't remove tracking.

Speaker 1: um it will change tracking. Um and we can we can hope that there are you know even IPs aren't aren't perfect The issue is with with cookies is just sort of the the ease with which they are able to be gathered and tracked. There's such a such a small little identifier and you can you can gather so much information along the way. I mentioned European laws about explicit cookie consent. If I have to do it, what are good resources to making it right? This is one where I have to defer because I have very little Expert knowledge about European law in this case. And in the process of putting together this talk, uh it became very clear that even inside Europe there's wide and varied regulations and how it gets applied is weird and and somewhat inconsistent.

Speaker 1: So I will definitely plead the fifth on this one and say consult your GDPR specialist about exactly what you have to do here. Um yeah, I will I will definitely defer to anyone who's uh got more knowledge on that one um if only because I'm not European and not subject to your laws directly. Another question. Most of the APIs use header-based authverror JWD basic. How do you think about having cookie-based session auth with an API which compared to token authors? So if if you are validating against your own server, then first party cook

Speaker 1: the change, there are no changes, the first the first party cookies are going to continue to exist. You won't be affected. Token, yeah, I don't know. That that's that's an interesting question. I would need to sit down and think about that one a little bit more and I will definitely defer to people who know more about security in this particular context. Um I'm aware that uh the JOTS DO GW JWTs have um security issues, but I'm not clear entirely whether that is because of the way Jot has implemented them or something fundamental about that bearer bearer token type um uh type access. Um Yeah, I will defer on that one.

Speaker 1: I don't have any strong opinions one way or the other, or expert knowledge in particular, in that space. This is very weird in that I 'm talking to a room full of no cameras and mutes. Um so Do I have friends?

Speaker 2: Hello Russell.

Speaker 3: Oh

Speaker 4: I'm not sure if this is less weird.

Speaker 3: Great poll by the way.

Speaker 1: Thank you. Thank you. Um

Speaker 5: Hi.

Speaker 6: We've got a round it with this other one now.

Speaker 1: Oh yes. Um yes, I I don't wanna don't wanna uh steal anyone away from another another excellent talk. Um

Speaker 3: Okay.

Speaker 1: Thank you.

Speaker 5: Thank you very much.

Speaker 1: I will I will hang around in this room if anybody wants to wants to continue to chat and already knows everything they need to know need to know about maps.

Speaker 2: Thank you for the recipe.

Speaker 1: Oh yes, very welcome. And I highly recommend that one. And I recommend the book. The book is also a very, very light read, but a deeply amusing read. And you'll note it does not include pickles.

Speaker 2: I'm gonna go to the other talk.

Speaker 1: Okay. Great exodus. Who is left? That looks like that.

Speaker 1: All right, so Looks like people are slowly disappearing. If there's no other questions, I guess I'll um slide quietly out of this room and move back to the main chat room I will try to be around as long as I can. Nice to see you all. And I hope I see you all in person in Portugal next year.

Speaker 3: Hope so.