How can I disable Passkeys over Bluetooth? Given the severity of vulnerability and the "fix" just plugging one hole of potentially many more, I'd rather have it permanently disabled.
Unlocked. It was a 2023 model I bought in 2024. There are some screaming good deals if you don't mind buying one model older at the right time. I cannot stress enough how much I don't care about OS updates as long as my apps continue to work (not many, mostly from F-Droid).
Is that what you think this bill is all about? I skimmed through it, and it seems to be a parody on controversial mental health issues like ADHD. Do you think the parody succeeded based on the fact that you think that an ADHD-like "illness" description sounds "bizzare" and unserious?
This idea is a clear violation of the first amendment, so, fortunately, will never fly. Any assumption that US will even look at it seriously is delusional.
Poor liars in Russian government will have to continue to rely on the slave mentality to keep their circus running, because it is impossible to plug holes in the ocean of information.
Whether you want to call it a “restriction”, “a lack of permission without being X type of activity”, or “it works because the app exhibits Y behavior”, it’s all functionally a restriction.
You can run some background activities that are not audio apps, but you’re at the mercy of iOS’s decision to keep your task active or not. If you’re off the charger, all bets are off. iOS’s dev docs make this very clear.
I said NOT(rule in "fundamental restrictions") AND (rule is XXX). You showed (XXX in "restrictions"). It would have been sufficient to prove my statement false if "fundamental restrictions" === "restrictions", but it is not.
I am not here to debate meaning of words. If LLaMA 3.1 8B can understand the difference between a fundamental restriction and a restriction in general on its own, so can you. If you feel like this topic is worth your time for intellectual pursuit, feel free to debate with it: https://huggingface.co/meta-llama/Llama-3.1-8B-Instruct I don't feel that it is worth mine. See if you can convince it the definition your are implying is more accepted than the one I am.
You say that, but then you dedicate a whole paragraph to my potentially (I’m not a native speaker, so it’s very possible) incorrect word usage :)
But also, I took your advice and had a chat with an LLM – seems like it's pretty much in agreement with my understanding of the meaning of "fundamental" as a plausible one.
In this context, fundamental just means something inherent to the system, like a thing that can’t happen because of the way the system was defined. A boat fundamentally can’t fly, because it wasn’t made in a way that would allow it to fly. This is different from a plane which is restricted from flying because of a no-fly order. There’s no fundamental restriction (the plane was designed to fly, after all) but there is something keeping it from flying. And maybe one plane get special permission to fly despite the no fly order—that’s a carve out.
So with iPhones, they are built in such a way as to allow background execution (there is no fundamental restriction) but Apple has made it so they cannot do so, with certain carve outs for things that people will want to be able to do while the app is in the background, like listening to audio or tracking the phone’s movements with gps. So there isn’t a fundamental restriction to background execution, it’s just a rule Apple makes (and then makes some exceptions to).
There are other ways you could use the word fundamental, as in something that is important because other things rely on it. But that’s not the way it was being used here.
Hope that helps!
Not sure what you mean with fundamental. As mentioned in the thread parent comment links to, the issue lies in enforced limits and lack* of general mechanism available to developers to allow background execution for any kind of app or/and purpose. No one said iOS itself lacks the functionality for background execution.
*In the same thread, it is noted that this lack is by choice and special-purpose mechanisms are preferred instead to prevent abuse.
As long as you subscribe to security advisories, it’s a lot more likely that new vulnerabilities are introduced than old undiscovered vulnerabilities are accidentally patched. In fact barring rewrites (which usually won’t be picked up by semver-respecting auto bumps anyway) I can hardly think of an example of the latter.
reply