41–50 of 113 posts
This has nothing to do with cookies, the banner is required if the site is processing data that is not just technically necessary. In this case the site needs to ask the user for consent or at least inform them of processing due to legitimate interests.
The only thing in this protocol that prevents the reuse of Authorization header is keeping track of nonce: > Validating that the nonce has not been used already for this session. Important: at this point, the nonce should be added to the ‘seen’ set, because nonces should be invalidated whether the signature validation passes or fails. Failure to do so can allow attackers to brute-force a valid signature for a single…
Yeah I think the proposal should add some optional binding of the web session to http resource semantics. Also re nonces if you only keep track of active nonces and have the server return a next-nonce, or use a counter like TLS, then you avoid the ugly need to keep track of seen nonces and only need to remember currently active nonces.
It’s also very common that a website wants credentials to be cleared when the user is inactive for a certain amount of time. This is important for sensitive applications such as banking and healthcare. Currently there’s no way to enforce that a cookie is cleared on device lock or user inactivity, especially because security requires that such cookies not be visible to JavaScript. A native session management solution…
From the article: > As a result of increasingly strict privacy laws across the world, users are now beset with cookie banners across the Web In the words of a law prof from the Radboud University, more accurate is to say "as a result of an entire industry colluding to undermine legislation".
> as a result of an entire industry colluding to undermine legislation Asking for a friend: Is the the European Parliament also a part of the industry colluding to undermine legislation? https://www.europarl.europa.eu/
What they should have done is raise the "Do Not Track" flag to legal status. If the flag is enabled it must be obeyed without any further questions to the end-users. Making it mandatory would have solved the problem with this flag which was that everyone simply ignored it and it only added an extra bit of entropy for fingerprinting.
If this flag had become mandatory, the browsers that have removed it would have brought it back immediately because it actually would have become functional. Also, the onus would have been on the advertisers to stop friction for those who don't mind to be tracked. Instead of tricking people with cookiewalls the focus would have been on making the "tracked" experience as frictionless as the flag itself is.
But I guess the industry lobbied very heavily for this flag not to become mandatory because it would have instantly cut their tracking to near-zero and therefore remove the raison d'etre of many of these adtech businesses. It would have shocked the industry more than Apple's ID thing did to facebook. No big deal though IMO because this industry is undesirable and it would have triggered some real innovation in context-driven ads that are not privacy invasive.
It would have been the only good option though for the citizens. What the EU has done has only backfired on itself with everyone including the lobbyists blaming them for the cookiewall mess.
Earlier quoted context omitted.
I thought I was misreading this. It seems onerous to keep track of every nonce, even scoped to a given session. Maybe I’m missing something.
A Bloom or cuckoo filter would allow for efficient tracking of nonces (depending if the security model prefers false positives with 4xx/resend, or false negatives)
> Because WebSession is dedicated to session maintenance and nothing else, a client could theoretically reject all cookies on any supporting site, ideally skipping the jarring cookie banner experience. This has nothing to do with cookies, the banner is required if the site is processing data that is not just technically necessary. In this case the site needs to ask the user for consent or at least inform them of proc…
DPoP[1] is on its way and already starting to see adoption by identity providers like Okta[2] (oh, the comedy). It's unfortunately specific to OAuth, so narrower in terms of application, but will cover how most web apps work today. 1. https://oauth.net/2/dpop/ 2. https://www.okta.com/blog/2023/06/a-leap-forward-in-token-se...
> Because WebSession is dedicated to session maintenance and nothing else, a client could theoretically reject all cookies on any supporting site, ideally skipping the jarring cookie banner experience. This has nothing to do with cookies, the banner is required if the site is processing data that is not just technically necessary. In this case the site needs to ask the user for consent or at least inform them of proc…
Still lots of sites have cookie banners because the legal department demands them, even though they are not needed for the cookies they use.
It’s also very common that a website wants credentials to be cleared when the user is inactive for a certain amount of time. This is important for sensitive applications such as banking and healthcare. Currently there’s no way to enforce that a cookie is cleared on device lock or user inactivity, especially because security requires that such cookies not be visible to JavaScript. A native session management solution…
https://github.com/googleapis/nodejs-firestore-session/issue...
I agree that WebSession would benefit from a time since last touched expiration, although I'll point out that a time-based approach doesn't handle the "when device is locked" requirement.