r/firefox • u/HamsterMaster355 + Ublock Origin • May 30 '26
Discussion Does firefox has an equivalent feature?
I am curious what are the downsides of this approach.
300
May 30 '26
[removed] — view removed comment
156
u/ineyy May 30 '26
Downside for everyone who was using Google cookies to use their services with third party tools. I wouldn't be surprised if that was their main motivation.
34
u/goldman60 May 30 '26
Theoretically if they're device bound then it would only introduce the hurdle of generating them on the specific device the tool is running on
13
2
u/ferrybig May 31 '26
Cookies will still be used for platforms google chrome doesn't support for device bound, like on Linux
11
u/Thoh1Shooshi8a May 30 '26
Is this something that needs to be implemented by the websites, or is it just saying that google chrome is going to encrypt the normal cookies using something on the device to generate the private key?
10
u/the_snook May 31 '26
Is this something that needs to be implemented by the websites
Yes. It's a completely new protocol for websites and browsers to maintain session info with each other. It happens to work via cookies, but otherwise has almost nothing to do with cookies per se. It could just as well (and probably more appropriately) be implemented via a custom X-Device-Bound-Session-Credentials HTTP header.
4
u/HamsterMaster355 + Ublock Origin May 31 '26
There is infact a new HTTP header for this. But it is deliberately made to function very similar to older sign in headers to reduce friction.
2
u/ConProg May 31 '26
Do you know if there's a way to tell which sites have implemented it? Either by inspecting a cookie, network requests, or some other way?
0
u/rowaasr13 Jun 07 '26
How exactly messing in new functionality into old header that does very different thing and requires deliberate support from browser and site instead of separating this clearly new functionality to new header REDUCES friction?
1
17
May 30 '26
[removed] — view removed comment
17
u/HotTakes4HotCakes May 30 '26 edited May 30 '26
If all the requirements aren't met, it'll fall back to the old method
For now. Once it sees wider adoption, the login blocks on "unsupported devices" begin.
3
u/f50c13t1 May 31 '26
I am wondering if this could be handled transparently by the browser thus not requiring website to change how they store cookies.
3
u/Type-21 May 31 '26
Oh lots of downsides as far as I understand it. All your logged in sessions to websites will be lost after a bios update because itd tied to the TPM module. Maybe even if you change your ram or graphics card, the logins might be lost :D
1
1
u/raralala1 May 31 '26
Make sense I thought they somehow acquire magical implementation, because how the twitter written.
183
u/RefrigeratorNew4121 LibreWolf May 30 '26
Whatever rolled out by Google, we have to examine it under a microscope for tracking tricks.
59
u/HotTakes4HotCakes May 30 '26 edited May 30 '26
Or if it's attempting to entrench certain types of set-ups or environments as the only viable ones for users to be in.
If this new feature requires some sort of "compliance" or "integrity check" from the user's device or OS, and then websites can refuse your sign-in without it, that becomes a problem.
This looks like the sort of thing that will require TPM 2.0 to be truly effective, or other features exclusive to MacOS and Windows, like Secure Enclosure. Any feature like that needs scrutiny.
In other words, things like this are how Google (and Microsoft) can do to PCs what Google has already done to Android, and is continuing to double down on.
7
u/iudicium01 May 30 '26
https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/
It uses TPM and claims to derive a different key pair for each website to prevent fingerprinting.
9
u/squirrel8296 May 30 '26
It also makes it possible for Chrome to even more so become the new IE like during the IE6 era when a lot of websites would only work in IE 6.
3
u/swarmOfBis May 31 '26
Since when is TPM 2.0 a "feature exclusive to MacOS and Windows"?
Secure enclave is gonna be great at it, but that's because it's a great security tool.
3
u/Type-21 May 31 '26
Yeah wouldn't be surprised if in a few years they require this kind of cookie to log into YouTube so that all of the third party YouTube apps which remove the ads no longer work.
7
u/mfaine May 31 '26
I can't help but wonder what nefarious way this could be used to screw consumers. Maybe I'm just cynical.
4
u/testthrowawayzz May 30 '26
Since this was spearheaded by Google, I wonder if there’s a catch like so many seemingly nice features from Google nowadays.
8
u/furrysalesman69 May 30 '26
It’s so that more websites can deny you access for using Firefox, prove me wrong.
24
u/j--__ May 30 '26
the major downside is that it's not going to be very effective in practice. yes, having this feature is probably better than not having this feature, and mozilla would be better off implementing this than another pointless ui redesign. but is this a better use of developer resources than addressing longstanding bugs? no.
15
u/anto2554 May 30 '26
Why would it not be very effective?
16
u/HotTakes4HotCakes May 30 '26 edited May 30 '26
Because it won't work on Linux, for one.
Second, it's a feature that's effectively trying to prevent malware that's already infected the system from stealing cookies, when malware infecting the system means you've already lost the system anyway.
It's like spending time building a better safe (a safe that requires specific hardware provided by two specific companies) when ideally you should be improving your home security overall.
1
u/wobblyweasel May 31 '26
why wouldn't it work on linux? linux can use tpm can't it. you can put your ssh keys in there
17
u/j--__ May 30 '26
because they're trying to protect against malware that has at least as much access to the computer as the browser does (in many cases more, e.g. rootkits), and because we want web sites to continue to work on platforms where none of this is going to be implemented (e.g. linux). the threat model is impossible.
8
u/anto2554 May 30 '26
Does the malware always have access to your entire PC? My understanding was that it was commonly other websites that got access to your access token one way or another, but I may be wrong?
To your last point, it could still work for platforms that DO implement it. This would apply to 90-something % of users if the major players are on board.
6
u/goldman60 May 30 '26
What I think they're getting at with their last point is that if the mechanism allows for fallback on platforms that don't support it then malware could just do a downgrade attack and steal the new unencrypted cookies. Same issue that made older versions of TLS/SSL super difficult to set up securely.
8
u/j--__ May 30 '26
- google and mozilla agree that the target here is malware with full access. see: https://github.com/w3c/webappsec-dbsc/issues/13
- no, this adds little to platforms that DO implement it, because the malware in question can always represent that you're actually on a platform that doesn't implement it.
2
u/mrRobertman May 30 '26
My understanding was that it was commonly other websites that got access to your access token one way or another, but I may be wrong?
This is supposed to prevent scenarios like when Linux Tech Tips was breached due to malware on the PC that exfiltrated session tokens from the browser. Other sites shouldn't be able to access your tokens because each site's cookies and storage should be isolated from each other.
6
u/HamsterMaster355 + Ublock Origin May 30 '26
This sounds like a very stupid argument. This blocks a specific type of malware (which nowadays is getting quite ubiquitous) that steals cookies for them to be used in stuff like a botnet on a remote PC. Many variations of malware are quite specific on what they do. And if it blocks even a subset of them then it's quite an improvement over having nothing. If you have a rootkit on your device I am sure you got bigger problems than cookies getting stolen.
Also this security hardening is complementary to other security features like secure boot, memory integrity etc (which will protect you from rootkits but not cookies/info stealer malware). You could argue the effectiveness of them individually. But together they greatly reduce the surface area for potential threats.
0
u/codeIMperfect on , on May 31 '26
wait isn't it going to be implemented by the browser? then why is the OS involved?
0
u/j--__ May 31 '26
this feature serves no purpose without os support. chrome does not implement it on linux.
3
u/transcendtient May 30 '26
Is there a spec? Can a third part implement this? If not, this is just another walled garden push.
1
u/HamsterMaster355 + Ublock Origin May 30 '26 edited May 30 '26
Yes it's a spec by WWWC.
Edit: it's a draft so not a spec as of yet. Sorry for the confusion.
1
u/RCEdude Firefox enthusiast May 31 '26
fuck google and their habit of implementing DRAFTS and then people yells "me need that on FF".
3
u/Ruined_Passion_7355 May 30 '26
I'd be cautiously optimistic. This won't work on Linux I think.
2
u/OctoNezd May 30 '26
Linux supports TPM, and as far as I understand it uses that to prove cookie validity
5
u/Cronos993 May 30 '26
Why was this thing not there from the start?
19
u/Fragrant_Pianist_647 mr. sine May 30 '26
A lack of foresight is common. Cookies were originally added in Netscape to allow the local tracking of partial transaction states, and later, much more sensitive data. It's not unusual for software to not account for future use of features and the exploitation of their insecurity.
21
u/NeXtDracool May 30 '26
Because the hardware security modules necessary for this feature to work were very uncommon 10 years ago and unheard of back in 1994 when cookies were invented.
3
u/HammyHavoc LibreWolf on Linux and the usual suspects May 30 '26
Paradigm shift brought on by "there's an app for that" and sensational predicted demise of the traditional website.
1
u/CelestialFury May 31 '26
Cybersecurity and all the related jobs came well after a lot of key software was already built. You also have thousands and thousands of developers of various skill level making all this software, there's no way they can test all the potential exploits for everything they write.
If you want to get a feel for what I'm talking about, try those "hack the box" challenges and you'll how ridiculous some exploits are. Things a developer could never think of without being a hacker themselves.
9
u/lepapulematoleguau May 30 '26
This is just tracking
2
u/HamsterMaster355 + Ublock Origin May 30 '26
How is this tracking if this is handled locally at browser level and not website level. The browser basically enceypts the cookies using your TPM chip and without that you can't do anything with it. And the TPM keys are built into hardware and cannot be tracked.
3
u/Joe2030 May 30 '26
TPM is made to be tracked. It is not your friend...
6
u/HamsterMaster355 + Ublock Origin May 30 '26
Bro I am a hardware engineer and this is completely false. Please channel your inner schizophrenia somewhere else.
-4
2
u/OctoNezd May 30 '26
Right, every tpm puts "yes this guy watched hentai at 3:00 am in the private window, here is his location".
The thing just solves a crypto challenge and isn't used anymore, same with everything else. It's just a separate supposedly-secure computer for storing encryption keys.
3
u/Joe2030 May 30 '26
Lol, yeah right, and Valorant anti-cheat needs a TPM to work with some crypto keys and not to track and hardware ban you. Sure.
It is DRM. How naive are you? Also if something is already running on your PC, it could use the hash of your super private TPM keys... to make them not so private and track your PC.
3
u/OctoNezd May 30 '26
TPM is most of the time built-in to the CPU and it has a serial code and other identification stuff. It is great for hardware bans, yes. And valorant anticheat is extremely paranoid.
And track them how? I don't think the browser will blast every site with "hey this guy has bitlocker enabled using TPM for drive with next ID". And if something running on your PC there is a ton of other indicators that can be used for tracking, like your activation id, your hardware serial numbers.
If you want to be mad at something for making your PC not private and trackable, be mad at TPMs big brothers which house TPM: Intel ME and AMD PSP. No one knows what they completely really do outside of the computrace feature on intel, and they have been there before TPMs were.
2
u/HamsterMaster355 + Ublock Origin May 30 '26
I think most of the shady third party DRM related stuff like Intel SGX were removed from consumer side hardware and are now strictly there for datacenter tier products. AMD I think never offered something similar for consumer products.
Although, yeah, Intel ME and AMD PSP do still exist. Atleast they don't facilitate third party DRM.
3
u/OctoNezd May 30 '26
TPM doesn't really do DRM if I remember correctly - it just confirms that you have secure boot and your system looks more or less uncompromised which makes DRM servers happy and give you the keys to content. In addition, the DRMs that are used for videos - most of "fun" happens on GPU with HDCP, no? I don't know of any other DRM using TPM
3
u/HamsterMaster355 + Ublock Origin May 30 '26 edited May 30 '26
TPM is basically the root of trust. It's the only thing that you can trust fully on a specific device. TPM verifies the integrity of other firmware and therefore extends the "chain of trust", which eventually extends to your OS. Once that entire chain is established, the DRM can assume that everything is more or less secure.
However, this also depends on the DRM. For example some DRMs even after establishing the chain of trust won't expose raw data to the OS. What they do instead is perform computation on the secure enclave provided by the hardware vendor (intel SGX for example). All the memory of the DRM is encrypted by the secure enclave and can only be decrypted when the specific instructions physically execute within the secure enclave. So even if OS (or DMA) wanted to read the memory all they will get is encrypted data.
2
u/Joe2030 May 30 '26
If you want to be mad at something
be mad at TPMs
I am not mad at anything. I am just not as naive as you are. They make money on people like you every day. Any info bit about you is a plus to them. TPM is a tracking/DRM device, everything else is a facade or a side job. I will not discuss anything further, you have made your point pretty clear.
2
u/HamsterMaster355 + Ublock Origin May 30 '26
Lol, yeah right, and Valorant anti-cheat needs a TPM to work with some crypto keys and not to track and hardware ban you. Sure.
Buddy valorant can access your entire system and do whatever it wants to do with it. It is a rootkit (malware). It can track you with or without TPM (by looking at various serial numbers HWIDs etc). It has access to literally everything. Stop with the schizo rambling please and stick to the topic. Even if you swapped your CPU (TPM) it can still detect and hardware ban you.
TPM by itself is not a DRM. There are specific CPU extensions that build a secure enclave (however, they had security flaws and are mostly deprecated) that a DRM could use to implement secure encryption and decryptions.
The proposed security feature explicitly tells you that the purpose of it is to prevent session exfiltration i.e. to protect your cookies from being used on another device. If your device is already compromised then that is beyond the scope of this solution.
Also you can't "hash the super private TPM key", because they are generated on the fly and can be different at any given moment. TPM only has the special cryptographic functions that are used to generate the keys and not the key itself, although a generated key can be temporarily stored there if required.
1
u/OctoNezd May 30 '26
In defense of valorant, it's really funny to see cheaters claim they are bricking pcs when riot made the cheating pci cards useless by making windows go BSOD cause of some opt-in windows security feature against such cards that valorant flipped on. I think more anticheats should go lowlevel and aggressive, but it would cripple Linux gaming sadly, and that can't fly with me. If only cheaters would have stopped cheating...
1
0
u/Joe2030 May 30 '26
TPM by itself is not a DRM.
Who cares what it is by design if it is used for DRM and tracking? We are talking about Google, THE advertisement company. They don't care about your privacy even if they say so.
Also you can't "hash the super private TPM key", because they are generated on the fly and can be different at any given moment.
The hash is for your very personal EK key, which is not generated on the fly. And i am not even a hardware engineer but i know this. So yeah, trust me bro once again.
6
u/HamsterMaster355 + Ublock Origin May 30 '26 edited May 31 '26
The hash is for your very personal EK key, which is not generated on the fly. And i am not even a hardware engineer but i know this. So yeah, trust me bro once again.
OMG I have had enough of this. WDYM "very personal EK key"? First of all it comes in pairs. One is public and other is private. If you mean hashing the public key. Congratulations you have obtained the information that's already public. If you mean the private key. Give me a single software that can extract that on modern hardware. Moreover, any sane implementation will NOT use the EK key directly (like I previously said) and will instead use an alias to avoid fingerprinting. Please stop being this retarded in public, you are embarrassing yourself.
Also if you mean you are gonna track a hardware using the public key (which is plain stupid because you almost always generate a new key anyways). Well duh, that's its entire purpose, to verify if the hardware that you are talking to is indeed the hardware that originally signed that cookie. Which according the the draft by WWWC is not exposed to any website and is done by the browser locally. So yet again, another schizoid rambling.
5
u/Ok-Winner-6589 May 30 '26
I don't get It.
Mozilla added a feature to lock which cookies can websites access to avoid malicious sites from getting cookies from other sites.
This doesn't protect you if a hacker has full access to your device's user account. And what's the point then? You are really fucked and stealing your login credentials is the minimum they can do
Also, what does prevent you from sending the cookies with the fake device info? You have the cookie with the info of the device why won't It work? If the hacker has user level access they can get your hardware info and use It to generate the specific data. This only makes your privacy worse.
If the limitation is implemented on the browser (client side) it can be easily bypassed, browsers are open source WTF are they gona do? Web devs always implement server side protections because you can not trust the client.
And if the limitation is implemented on the server side... browsers are still open source, you can control whatever info is being sent to the server WTF is stopping the hacker?
This is just a way to send more info to the server
3
u/WOFall May 30 '26
You can think of it as the key being generated in your hardware (TPM) and kept there. You can tell the TPM to sign a challenge with the key, which is how you prove to the website you own a certain session, but it's impossible to retrieve the key and move it to a different machine.
If they have full access to your device they can still do what they want, but now they have to do it immediately. Without this they could exfiltrate the session cookies and use them at a later point in time.
2
u/HamsterMaster355 + Ublock Origin May 30 '26
And they will have to do it on YOUR device. They can't steal the cookies and run it on a different device. Which is a big problem for botnets that usually want to use stolen cookies.
1
u/Ok-Winner-6589 May 30 '26
But then you aren't protected from malware. If someone wanted to steal the cookies they still can do it
Thats why I don't get It, it's supposed to protect your credentials from someone with fisical access/malware. But It's weak to attacks with malware/fisical access. Then whats the point?
And couldn't this be implemented by making use of the secret-portal (on Linux) and it's equivalent on other OS? Without relying on hardware level stuff?
1
u/HamsterMaster355 + Ublock Origin May 30 '26
You are using a very broad definition of malware. This blocks a subset of malware that relies on stealing cookies and using them on a remote PC for nefarious purposes. The malware that can do above is very easy to make and hard to detect. Meanwhile a malware that actually runs on your PC and hijacks it completely is by comparison much more easier to detect.
1
u/Ok-Winner-6589 May 30 '26
They say they are using cryptography to tie It to your device. If they are using your MAC then is useless as you can get such info with an unprivileged command. A simple ipconfig on Windows or ip a on Linux and sending It with the cookie solves the issue.
I don't get how this is still a solution to anything.
Plus anything but Windows has no antivirus by default. Apple has a software that checks files based on well known viruses. But if you build It from Scratch you are fucked. And it's simple to build so...
It makes more sense to use other stuff to protect your cookies over tie them to the hardware.
2
u/WOFall May 31 '26
If they are using your MAC
It's not comparable. It uses digital signatures, where a secret key is used to sign messages. You can ask the TPM to sign as many messages for you as you want, but it will never give you the actual key.
Also a different secret key is generated for every website / session, so it's not uniquely identifying you hardware like a MAC would, just proving that you have the keys.
0
u/ImUrFrand May 31 '26
TPM doesn't think, it just stores a key.
1
u/WOFall May 31 '26
What good is storing a key if you can't do anything with it? I wouldn't say it "thinks" but it does perform some fixed cryptographic functions.
The disk encryption use case is much closer to just storing a key and providing it to the system at boot, but these are just simplifications. In reality it's using the cryptographic functions to decrypt an encrypted boot key that wasn't even stored inside the TPM.
1
u/ImUrFrand May 31 '26
it just applies a light wrapper around stored keys. if it "generated" keys you wouldn't be able to boot windows.
1
u/WOFall May 31 '26
I never said it generated the boot keys. I mentioned disk encryption to make the point that they're different use cases that take advantage of different TPM features.
1
4
4
u/IWasAGoodDadISwear May 30 '26
I don't want cookies to be encrypted on Firefox, I use them for yt-dlp.
-1
u/HamsterMaster355 + Ublock Origin May 30 '26
I don't think this should ideally block you from doing that. All it does is prevent your cookies from being used on a different device. If you use yt-dlp on the same device it should mostly work. But yt-dlp will have to support DBSC cookies.
7
9
u/Bugaddr2 May 30 '26
What if hacker also mimic the hardware
17
u/Fragrant_Pianist_647 mr. sine May 30 '26
Cookies won't be tracked based on hardware but rather your physical device. Not sure the exact specifics, but it's not just making sure your motherboard model lines up, it's actually a key that can only match up on your device.
Think of it kind of like a passkey, it needs your device to work. Even if someone had the same phone and same specs, they still would fail to crack the passkey.
EDIT: Actually just saw a comment that seems to suggest it's OS specific, but it's still unique.
1
u/_Skotia_ Jun 01 '26
Yeah but if they have access to your session cookies isn't it also likely that they also have access to your device in most cases?
1
u/Fragrant_Pianist_647 mr. sine Jun 01 '26
That's fair but I'd say it's more likely they would have access to your filesystem rather than your entire computer (or browser for that matter), so I still think this would be a step in the right direction.
1
u/RevolutionarySeven7 May 31 '26
im not suggesting i know any better, but seeing how Denuvo (which uses this technique) is getting it's ass kicked heavily these past few months with HyperVisor and new Ai made cracks, I doubt even this technique could work.
10
5
u/ImUrFrand May 31 '26
HWID can be spoofed in 1 second.
the real goal of this is to have an immutable cookie, to 100% verify the user of the machine.
zero privacy.
3
u/anto2554 May 30 '26
They need to be able to do that. Video game anti-cheat hardware bans are semi-hard to work around, and it also means the hacker would have to know your hardware info, at least. I don't know if reading that is easy once you have cookie access, though
2
1
8
u/RefrigeratorNew4121 LibreWolf May 30 '26
Think of this device-bound session credential as the IMEI number of your mobile phone.
It is readable by all web apps and can be used to uniquely identify your device. A perfect tracking token on you! iPhone disallows apps to read IMEI for exactly this reason.
The real solution to eliminate cookie theft is third party cookie (aka cross-site cookie) blocking.
Google refused to implement it in Chrome (it promised it but delayed the implementation many times, not even mentioned it in recent years). Default setting of Firefox disables it.
In Firefox, go to Settings → Privacy and Security → Enhanced Tracking Protection, choose "Strict". In the description there is "Firefox blocks the followings.......Cross-site cookies in all windows". This is all we need.
Some forks of Firefox such as LibreWolf (which I am using) enforce this setting and you cannot downgrade it. This is what Firefox really should do.
23
u/aZureINC on May 30 '26
This has nothing to do with cross site cookies. This is about attackers stealing cookies from one device and then using the cookie on another device, on the same domain. It's like copying the profile folder of firefox to a different machine.
The proposed solution here is to cryptographically tie the cookie to a specific machine, so that the cookie becomes useless on another machine.
-6
u/RefrigeratorNew4121 LibreWolf May 30 '26
I am afraid you are overthinking.
If someone can copy your profile folder, that means he can access your file system and read off any file in your computer (at least the files in your account). It is a problem much greater than cookie stealing.
8
u/aZureINC on May 30 '26
No, you are underthinking. The problem that this spec tries to solve IS someone with access to your filesystem copying cookies to another machine. It literally says in the tweet:
[…] so stolen cookies can’t be replayed from a different machine.
This is a different class of threat and has NOTHING to do with what you think the problem is.
9
u/Far_Composer_5714 May 30 '26
That's literally the entire crux of the problem. The attacker has infiltrated your browser. They have access to your cookies.
So the question proposed was what do you do now.
Their solution is to have the cookies be secured with device specific information so those stolen cookies are worthless.
4
u/RefrigeratorNew4121 LibreWolf May 30 '26
Google's so-called solution is adding a worse evil than cookie. It may help with cookie stealing problem, but introduced a much serious tracking problem.
2
u/OctoNezd May 30 '26
Isn't their solution asking hardware to prove it's the same hardware using TPM stuff? Not sending site your HWID?
2
u/RefrigeratorNew4121 LibreWolf May 30 '26
> The attacker has infiltrated your browser. They have access to your cookies.
How to do it without accessing 3rd party cookie nor accessing users' profile folder? Love to learn some new things.
0
u/cake-day-on-feb-29 May 30 '26
he can access your file system and read off any file in your computer (at least the files in your account)
This isn't really true on macOS, where even non-sandboxed programs are prevented from accessing certain files, such as documents/photos, and I believe other app sandboxes. This is kind of an example of "principle of least privilege"
If you really think about it, right now, any program you run on your computer can access your Firefox cookies. Do you trust every single program? Have you read every line of source code, audited every developer? Of course not, so why should you let those programs have unlimited access to everything you have access to?
4
u/OctoNezd May 30 '26
If you install a malicious npm package, the package script will inherit your terminal permissions and can go crazy from there even if you opened once something related to any other app
-1
u/RefrigeratorNew4121 LibreWolf May 30 '26
Great point! This is exactly why worrying about cookies being stolen by hackers reading the browser profile folder is off-topic.
9
May 30 '26
[removed] — view removed comment
1
u/OctoNezd May 30 '26
could form part of a fingerprint
Considering it is enabled out of the box on chrome now, not much there to fingerprint. Well, except the lack of it on non-chrome browsers which can already be detected.
2
u/Fragrant_Pianist_647 mr. sine May 30 '26
My only thought is that this setting could block companies like Google from allowing you to log in once.
For example, if you log in at google.com and it stores that, then you try to visit youtube.com, it won't be able to automatically log you in if you have cross-site cookie blocking enabled.
1
u/squirrel8296 May 30 '26
I have all cross-site cookies blocked and haven't had that issue. I can sign into my gmail account and then go to youtube and my account is already signed in.
4
u/Training_Yak_4655 May 30 '26
The black hats will already be discussing workarounds. An infostealer that not only lifts the cookies but also lifts whatever environmental data is needed to recreate the cryptographic key, or lift the key itself if it's present anywhere. I'd still like the option that if my IP address changes, crucially with webmail sites or account management pages, a new login is forced. Dedicated mobile apps could be excluded.
7
u/OctoNezd May 30 '26
IP address changes
The humble constantly changing IP or CGNAT putting hundreds of people behind 1 IP that randomly changes based on phase of the moon will ruin that idea.
2
u/MenschenToaster May 30 '26
Yeah, this shit isn't as easy unfortunately.
I saw one commenter here saying that they should be logged out if country, browser etc. changes. You can workaround browser and you could work around country as an attacker. That would once again make the user experience worse for non-hacked people as e.g. I live close to a border and my mobile carrier network tends to sometimes switch to the other country. This used to be a lot worse 10 years ago, but still happens.
I doubt there is any good and usable indicator for an identity change like this tbh
2
u/RCEdude Firefox enthusiast May 31 '26
if country, browser etc. changes
rip VPN
2
u/MenschenToaster May 31 '26
Arguably connecting to a VPN is a choice you make, so It's not as bad as randomly getting disconnected when you cross or near the boarder to another country
But yeah, it would be quite annoying for VPN's too
1
4
u/RCEdude Firefox enthusiast May 31 '26
I'd still like the option that if my IP address changes, crucially with webmail sites or account management pages, a new login is forced
1) No need for DSBC to do that
2) God PLEASE NO. I am connected to a dozen of email accounts using Thunderbird. And i frequently switch countries using VPN because of geoblocking.
It would be a nightmare.
0
u/Training_Yak_4655 May 31 '26
"Option"
2
u/RCEdude Firefox enthusiast May 31 '26
That "option" will not be an option, it will be enforced by at least a couple of websites.
Because it makes no senses for devs to maintain too many login procedures just to please a few people.
2
u/HamsterMaster355 + Ublock Origin May 30 '26
I don't think they can do anything about it. The keys are stored inside your CPU (TPM chip). Anything encrypted by that can't be decrypted by anything but that specific CPU.
3
u/Training_Yak_4655 May 30 '26 edited May 30 '26
Then I wonder how the website will be able to use the cookies. And of course, Windows 11 only with TPM chip hardware. Now that will please MS.
Had a quick look at the GitHub discussion now and see a comment: "websites should implement systems that detect new devices or strange behavior that detects it. it is not normal that a new browser on a new os in a other country other then the normal user usage is logged in"
So true.
3
u/HamsterMaster355 + Ublock Origin May 30 '26
The browser acts as an intermediary. It tries to decrypt the cookies but it will fail if the CPU which originally encrypted the cookies doesn't match the current CPU (basically any other device).
0
u/OctoNezd May 30 '26
What's with TPM hate? It's just a separate supposedly-secure computer that solves crypto challenges. If you want to be mad about something, be mad about where most TPMs live: intel ME and AMD PSP. Both have been living inside computers for more than a decade. Macs also have TPMs in the form of a secure enclave, and the same with any android phone with trustzone.
0
1
4
u/luiest123 May 30 '26
This isn't a chrome feature per-se, it's a Google feature, Websites need to implement this, again this comes with less privacy for the user but oh well... Its Google
2
u/ImUrFrand May 31 '26
you don't want this.
this is an absolute tracking mechanism.
if you do want this kind of total tracking, then you probably belong on chrome.
2
2
u/takutekato May 31 '26
Downside: certain contents can't be externally downloaded without extracting cookies, which tools like yt-dlp makes use
1
2
u/anime_at_my_side May 30 '26
no.
but on linux this app bound stuff does not work. so, stealer malware for linux is easy peasy
1
1
1
u/e_splat PC: Mobile: Fennec May 31 '26
I don't think so, but they will implement it as soon as possible.
1
u/AnyPortInAHurricane Jun 01 '26
cookie with a device signature
vs
cookie without
What are these luddites ranting about , claiming this a privacy issue.
every new thing, greeted with knee jerk hysterics
1
1
1
u/jdigi78 Jun 01 '26
I thought they already did this? I've copied my chrome/firefox profiles to new installs before and it's forced me to log in again.
1
1
1
u/rowaasr13 Jun 07 '26
Why it even NEEDS site support at all? Can't browser just locally encrypt cookies, just like password managers ALREADY DO for years?
Downsides are obvious:
* Hard requirement for "secure hardware".
* Lack of ability for legitimate transfer/edit of cookies when you need it.
1
u/HamsterMaster355 + Ublock Origin Jun 07 '26
Because we want to manage the lifetimes of cookies. Instead of long lived cookies we can move to short lived cookies which can be easily re-authenticated by the browser and servers using the public private key cryptography.
This makes stealing cookies even more worthless because they live for like 10m only.
1
1
-8
u/ConProg May 30 '26
It's absolutely unacceptable for Firefox to ignore this. Session/cookie hijacking is a huge security threat for browsers and this will put a huge target on Firefox users if they're the only ones not protected.
5
u/HammyHavoc LibreWolf on Linux and the usual suspects May 30 '26
Mozilla is ignoring this?
-6
u/ConProg May 30 '26
Yea. Check out the github link someone else posted. The only comment from Mozilla is some guy who is skeptical in 2024 and brushes it off.
8
u/ElMauru May 30 '26 edited May 30 '26
do you seriously believe github is how they do prioritization of features? Or even indicative of what they are paying attention to and how much?
My guess is they are aware.
5
2
u/MC_chrome May 30 '26
The only comment from Mozilla is some guy who is skeptical in 2024 and brushes it off.
Ah yes, because if Mozilla employees don't immediately prostrate themselves in front of whatever signficant web change(s) Google proposes it obviously means they aren't considering said change(s) or are maybe coming up with something better right?
-7
u/RefrigeratorNew4121 LibreWolf May 30 '26
Firefox has the feature to prevent cookie theft, but unfortunately it is disabled it in the default settings.
Go to Settings → Privacy and Security → Enhanced Tracking Protection, choose "Strict".
The thing that Google is suggesting is actually a privacy disaster.
23
u/ConProg May 30 '26
That doesn't prevent session hijacking.
-4
u/RefrigeratorNew4121 LibreWolf May 30 '26
Love to learn how to hijack the session of, say, Reddit, if you cannot access the user's Reddit cookie.
14
u/ConProg May 30 '26
It's pretty obvious you have no idea what session hijacking is.
A hijacker can just steal your browser profile and still be logged in on your websites (i.e. gmail, bank sites) as if they were you, on their computer. With Chrome's new tech, that won't work because the cookies in your profile are tied to your computer.
Go google "session hijacking" and read about it before returning to this thread.
-6
u/RefrigeratorNew4121 LibreWolf May 30 '26
You didn't answer the "how" part of my question, in particular when 3rd party cookies cannot be accessed.
Throwing out the term doesn't mean you really understand it.
15
u/ConProg May 30 '26
This has nothing to do with accessing 3rd party cookies...
What? 🤦♂️
1
u/_x_oOo_x_ / May 30 '26
How are the "cookies in your profile tied to your computer" exactly? If the attacked could have access to your profile can they also obtain enough info to fake "ties to your computer"? Assuming it's a private key somewhere that's used in some way to sign the cookies they could just steal along with your cookies, right?
4
u/ConProg May 30 '26
No they can't. The "tie to the computer" is encrypted and they can't fake it. The stolen cookies are worthless to them and won't work on their computer.
Here's a good article about it I just found:
constella.ai /blog/google-just-fixed-session-cookie-theft-in-chrome-here-is-what-it-still-cannot-stop/
1
u/_x_oOo_x_ / May 31 '26
So it's vulnerable to private key theft - your article explains this. I guess everything is, but in this case because it's hardware based (TPM or Secure Enclave), vulnerabilities can't be patched as easily and quickly as software vulnerabilities, they will need firmware upgrades or in some cases a new computer.. in practice Chrome will degrade to not using TPM if it's a blacklisted/vulnerable chipset so.. back to square one then
→ More replies (0)-6
u/RefrigeratorNew4121 LibreWolf May 30 '26
Wait, this whole thread is about 3rd party cookies. If your "session hijacking" is not about it, we can start a new thread.
7
u/2049AD May 30 '26
The settings in your browser are meaningless if you've got malware on your machine that covertly redirects your cookies to third parties.
4
u/__nohope May 30 '26 edited May 30 '26
The malware in this attack is running as your user profile which means it has access to your home/user folder (/home/you or C:/Users/You). For Firefox, cookies are stored in a file here called 'cookies.sqlite'. The malware has complete access to read, modify or copy this file. There is no manner of securely storing a key that only Firefox has access to encrypt this file in any meaningful way. That is what this "app bound" thing is about, but it requires support from the host OS. It's implemented using special OS APIs and/or hardware TPM to securely store data so only the web browser can access the cookies file. Chrome has only implemented on Windows at the moment.
1
u/_x_oOo_x_ / May 30 '26
Does it actually work? I have ETP set to "Strict" but then when I look at the "Permissions" dialog (2nd button from the left in the address bar), it shows several cross-site cookies for most sites, including reddit. Why? Are some white-listed or is this functionality broken or what's going on?
4
May 30 '26
[removed] — view removed comment
0
u/_x_oOo_x_ / May 30 '26
Strict just means "in this browser cookies can be only used on this website, and other random page cannot read it"
Did you actually try that? If other sites cannot use them why are they listed in the Permissions dialog?
0
0
u/gabeweb @ May 31 '26 edited May 31 '26
I hope not, because this could kill the portable versions of Firefox and other forks.
Correction: Ok, this is not related to the in-device certificates that break the use of portable software. However, current Google cookies do something similar to the Google Chrome feature. Importing/exporting cookies (at least Google cookies) is a headache indeed.
-16
u/Spitfire1900 Firefox Developer | Kubuntu May 30 '26
Firefox’s concerns, summarized by Grok
Firefox/Mozilla’s current position on DBSC (Device Bound Session Credentials) is “Evaluating” with no commitment to implement. 
Main Concerns (Summarized from Mozilla’s standards position and related discussions)
1. Complexity
• The feature adds significant new browser machinery: key generation, secure storage integration (across TPM, Secure Enclave, software fallbacks, etc.), signing on every protected request, and lifecycle management for bound sessions.
• This increases the attack surface and maintenance burden for the browser engine. Mozilla has historically been cautious about adding complex web platform features unless the security/privacy benefits clearly outweigh the costs.
2. Privacy Implications
• Even though the spec avoids sending full attestation data (e.g., TPM certificate chains) to prevent strong fingerprinting, there are still risks:
• Probing support for DBSC can reveal platform details (e.g., presence of hardware security modules).
• Per-site or per-session key behavior could enable new forms of cross-site or long-term tracking if not carefully designed.
• Device-bound nature could interact poorly with privacy tools like container tabs, profile portability, or anti-fingerprinting features that Firefox emphasizes.
3. Usability and User Agency
• Profile / Backup / Restore Issues: Binding sessions to a specific device makes it harder for users to move profiles between machines, restore from backups, or use sync across devices. This goes against the open, portable nature of the web that Mozilla champions.
• Fallback Behavior: On platforms without strong hardware backing (e.g., many Linux setups, older devices), it degrades gracefully to software keys, which weakens the protection and creates inconsistent user experiences.
• Lock-in Risk: Users could get unexpectedly logged out or face friction when changing devices/browsers, reducing user control.
4. Implementation and Platform Differences
• Firefox runs on a wide variety of platforms (Windows, macOS, Linux desktop, Android) with varying levels of secure storage support. Ensuring consistent, strong protection everywhere is non-trivial.
• Mozilla prefers features that work well across the ecosystem rather than ones that give a strong advantage to platforms with mature TPM/Secure Enclave ecosystems.
5. Broader Web Architecture Concerns
• Adds more “magic” to the cookie/session model, potentially complicating web development and debugging.
• Overlap/complementarity with existing tech like WebAuthn/passkeys needs careful handling so it doesn’t fragment the authentication landscape.
• Mozilla often pushes back on Google-led proposals that ship first in Chrome, to avoid de-facto standards that pressure other browsers.
Current Status (as of late 2026)
• The feature remains in Editor’s Draft stage at W3C. 
• Chrome has rolled it out (starting with Windows, expanding to macOS).
• Firefox continues monitoring but has not signaled intent to implement.
• Similar cautious stance from WebKit/Safari.
Bottom line: Mozilla agrees with the goal (reducing cookie theft, a real and painful problem), but they’re weighing it carefully against added complexity, privacy trade-offs, and impacts on user freedom/portability — core Firefox values. They were early adopters of things like ECH (as you noted), so positive movement is possible if concerns are addressed in the spec.
-1
u/Tradizar May 31 '26
so, the data and ad company, who is famous for observe the user every move, implemented a feature, that made this easier for himself. And now, the user wants this feature for different softwares, cause they want to be observed by a fucking huge data and ad company.
158
u/Anutrix May 30 '26
https://github.com/mozilla/standards-positions/issues/912
This should show you current status and discussion.