I know nothing about any of this and I am surprised to learn that something that is apparently considered to be permanent is stored in something as ephemeral as a browser cookie, and then causes problems if deleted. At least this is how I understand the exchange above.
Any web application really has access only to "ephemeral" storage like cookies or localStorage when used in this manner (you could be cleaning your localStorage for every session too).
Switching to localStorage would help things, but until they do, you can avoid the known failure case for Element Web by not doing that.
Obviously though, they need to figure out a way to reestablish encryption when the keys are gone, as long as you are willing to accept no access to history, or keeping keys encrypted server side.
On the other hand, there’s been a bug open to make a simple harmless change to fix this in Android for 9 months, with no response from Google other than asking for reproduction steps as far as I can tell.
Buganizer is not where you submit code to be reviewed and accepted into Android. And by the author's own admission that change is a hack and not a proper fix. Anyone is free to make a proper fix and upstream it if they wanted to.
No one has presented a remotely correct fix anywhere on that issue, or elsewhere to my knowledge.
You're welcome to write an actually correct patch for android if you want, one that isn't just commenting out code and probably breaking some spec-compliant bluetooth devices.
Make sure to test your patch against all the bluetooth devices in existence to make sure it doesn't regress.
Do that, make a PR, wait the average third-party-android-PR review time (approximately 5 years), and then if your PR isn't accepted at that point we can maybe say Google is intentionally ignoring this issue.
Nobody actually productively commenting in the thread thinks it's a conspiracy theory and everyone acknowledges that the Apple hardware is off-spec. It would be nice to see Android add this workaround.
You have linked me to what sounds like an AI generated comment. AI comments cannot be trusted. AI will make up believable sounding gunk and cannot be trusted.
"The bug", aka not implementing spec violating behavior, also exists in BlueZ, the Linux Bluetooth stack. Is the BlueZ team taking kickbacks to make sure earbuds don't work on Linux, too? They were Google Summer of Code partners, too, so this potentially goes pretty deep.
I was genuinely sure it’s not a problem, as I personally know quite a few people who do that. But I think they use either FaceTime or regular cellular. That’s sure weird a simple call does work in iPhone 4S (imagine a price for it in 2026), but doesn’t on modern Apple Watch Ultra, which is quite expensive.
Unfortunately, it doesn't work like that. Third-party app calls don't go to the Watch. It's so annoying, I have to tell people to call me using regular phone calls or FaceTime instead of using Signal or WhatsApp because I always miss the latter ones.
I think it’s misleading to imply hypocrisy considering the reasons listed in the article don’t apply to the scenario of a site being behind Cloudflare.
reply