There are (illegal) marketplaces initial access brokers sell session cookies on. Some companies try to defend against that by e.g. checking whether it's even possible that you travelled from place A to place B within a certain timeframe and, based on that, might invalidate your cookie. But then again attackers, depending on their sophistication, find their ways around it by ensuring they proxy their traffic via geographically close residential proxies, use the same OS and browser versions, etc.
For reference, this is how Google says Chrome stores passwords encrypted in memory and uses an elevated service to prevent other processes from impersonating Chrome and gaining access to the plain text passwords: https://security.googleblog.com/2024/07/improving-security-o...
This is not how CVEs work at all. You can be pretty vague when registering it. In fact they’re usually annoyingly so and some companies are known for copy and pasting random text into the fields that completely lead you astray when trying to patch diff.
Additionally, MITRE doesn’t coordinate a release date with you. They can be slow to respond sometimes but in the end you just tell them to set the CVE to public at some date and they’ll do it. You’re also free to publish information on the vulnerability before MITRE assigned a CVE.
> Is the baseband isolated?
> Yes, the baseband is isolated on all of the officially supported devices. Memory access is partitioned by the IOMMU and limited to internal memory and memory shared by the driver implementations. [...]
Are you intentionally ignoring the part where I provided reasons for why alternatives to the use of password managers by vendors that (supposedly) cause lock-in won’t go away?
It turns your fear into a hypothetical that you’re more than welcome to discuss but imo it’s disingenuous to frame it as the incredibly big problem you’re framing it as.
> What if I don't want to pay for Bitwarden, or buy a smartphone, or tie my log-ins to my computer?
Then you and the people you influence can continue to enjoy getting phished.
> What happens when the WebAuthn standard evolves and only the big-tech companies have solutions for storing passkeys because little software vendors or open-source vendors don't support the standard as well?
For a bunch of companies/gov entities syncable passkeys aren’t secure enough. So they still need to use hardware-bound passkeys on e.g. yubikeys.
Try to read up about a subject next time before you let your imagination go wild and scare equally ignorant people away from more secure alternatives.
Your conspiracy theories even seem to push you to be against using password managers in general. I guess googling around for an offline one like KeePass that’s heavily recommended all around the internet was too hard?
KeePassXC even supports passkeys.
> Since communication is done via TLS all the way to GIPHY, the Signal service never sees the plaintext contents of what is transmitted or received. Since the TCP connection is proxied through the Signal service, GIPHY doesn’t know who issued the request.
> While this does hide your IP address from GIPHY and your search terms from Signal, there are some caveats. The GIPHY service could use subtleties like TLS session resume or cache hits to try to correlate multiple requests as having come from the same client, even if they don’t know the origin.