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.
The cookie should always be minimal and arbitrary. If you want to fingerprint the device and have confidence in that correctness it's something you should store on the server (or at least store a hash of on the server).
Anything that is on a client device can be manipulated without your awareness.
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...
I recall chrome used to let you reveal passwords with a simple button press in the UI. I think their conclusion at the time was if an attacker had local access there was no point in pretending they were hidden.
I still found it insane to display passwords that easily. Sometimes I give brief access to my PC to friends, family, acquaintances, or even colleagues, and they shouldn't be able to see my passwords with a simple button. It's like leaving your bike out unlocked, because someone with the right tools can break the locks anyway.
> It's like leaving your bike out unlocked, because someone with the right tools can break the locks anyway.
Not to strain the analogy, but it's more like not locking your bike when it's in your locked apartment (the apartment being your computer). The thought being that if someone puts the time and effort into breaking into your apartment, a bike lock isn't going to do anything to stop them.
I think it makes perfect sense. I want to see my passwords without having to re-enter my system password every time.
Operating systems have had guest accounts for decades for the "handing your PC to friends/family/etc." use case. Even Android phones have temporary guest accounts (though many manufacturers disable that because it interferes with their own secondary user-based hacks).
Guest accounts are a nice theory that do not match the lived practice of scenarios such as "Yeah sure, go to the PC to add some songs to the playlist".
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. [...]
> Android 16 no longer provides device trees for Pixels as part of the Android Open Source Project. It's important to note it doesn't provide those for any other devices. There are no other OEMs providing similar AOSP support. [...]
Way back before I made the jump to a Nexus S, I was maintainer of a CyanogenMod port. Granted there were other challenges involved with that (bypassing locked bootloaders with kernel module exploits) but I am well aware of what's involved. What Google is doing is a fucking waste of people's time for no reason whatsoever. And it's not just on the AOSP front--it's clearly a strategic platform decision.
I'm done with Google. On every front they are being assholes. The DOJ should have exploded Microsoft into bits and pieces back in the day the way they handled AT&T so that Google would fear the same.
AFAIK the impact of that is overblown, because "device trees" are just files that can be extracted from the stock ROMs. Moreover drivers and kernels are still provided by google, albeit in code dump format (no git history).
The screen is a 16:10 screen with some extra pixels added next to the notch.
By default, the system uses a resolution of 1512x982 (14"), which you can change to 1512x945 (16:10) to move the menu bar below the notch and end up with black pixels next to the notch.
"If you go make weird contortions and workarounds you might just find a semi-working non-solution to a problem that didn't exist until Apple introduced it".
> a feature that can only be appreciated by a subculture of people (privacy advocates)
Just because it can’t be “appreciated” by all users doesn’t mean it’s only “for” a small sub-group.
It seems to me they’re just trying to minimise the data they have access to — similar to private cloud compute — while keeping up with the features competitors provide in a less privacy-respecting way. Them not asking for permission makes it even more obvious to me that it’s not built for any small super privacy-conscious group of people but the vast majority of their customers instead.
Google now wants to bind credentials to a device by storing the secret in the TPM: https://blog.google/security/protecting-cookies-with-device-...
reply