I'm not sure I follow, presumably if these are using the Keychain API they're doing so via the app, to which you must be logged in, so they are already tracking you and the keychain thing achieves... nothing?
The keychain data of an app on iOS is NEVER removed from your device, unless you completely wipe the device. This has been the behavior since the beginning.
Even if you delete and reinstall the app, it remembers your logins and who you are. Even after you wipe the iPhone/iPad and setup with the same Apple ID/iCloud account.
Discord automatically logged me in ON A NEW IPAD, because I signed into the same Apple ID/iCloud account.
and I assume all the other apps from a company can share that info, like Facebook ↔ WhatsApp
Funnily enough, Apple allowed users to delete that data when deleting an app, during an iOS beta, but removed that feature before release, heavily in favor of the spyware and against users.
Various services have existed, such as portmap(8), though NFS and similar services have often suffered from the "too complicated to debug" problem where devops (then sysadmins) would try turning the system off and then back on again in the hopes of resolving the issue du jour. You might get lucky and determine that node number three (of many) was cursed and leave it switched off for the Season of Mammon, more commonly known as Christmas, and to retire it quietly, later. Hypothetically.
Generally host and port mapping gets shoved somewhere into the configuration management layer and hopefully does not become too complicated (or have too many security holes) as this could vary from "configuration files and a few scripts" to database and services layers that few can debug, especially not a sysadmin at 3 AM in the morning running on an hour of bad sleep. Hypothetically.
I'm hoping that the success of the Neo and the RAM shortage makes people realise that 8GB should be enough for most tasks without constantly swapping.
That 32GB or even 64GB is considered a minimum to be able to run some word processing, chat app, fetch remote content, and display funny cat photos is preposterous. In terms of information storage, these are absolutely immense numbers.
The infinite treadmill
of chasing for more RAM and then immediately proceeding to carelessly fill all of it at the first line of code is part of a deeper, wasteful, and self-imposed obsolescence process.
We don't need more RAM, we need more frugal software.
> the old snapshot has security holes attackers know how to exploit.
So is running `docker build` and the `RUN apt update` line doing a cache hit, except the latter is silent.
The problem solved by pinning to the snapshot is not to magically be secure, it's knowing what a given image is made of so you can trivially assert which ones are safe and which ones aren't.
In both cases you have to rebuild an image anyway so updating the snapshot is just a step that makes it explicit in code instead of implicit.
where does the apt update connect to? If it is an up to date package repo you get fixes. Howerer there are lots of reasons it would not. You better know if this is your plan.
You get fixes that were current at docker build time, but I think GP is referring to fixes that appear in the apt repo after your docker container is deployed.
If you've pulled in a dependency from outside the base image, there will be no new base image version to alert you to an update of that external dependency. Unless your container regularly runs something like apt update && apt list --upgradable, you will be unaware of security fixes newly available from apt.
Don't worry it's no better on iOS, where I too have a English+French QWERTY setup, and where it too frequently decides to "helpfully" correct using an English dictionary several words into a unambiguously French sentence; or the other way around depending on wind direction and age of the captain.
Even more damning is that there seems to be three independent layers to the feature ("three suggestions" area above keyboard, autocorrect-as-you-type, correction popup as you touch a word) and neither agree with each other about which language it should be using.
- it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism.
- it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism whose permission survives the action context that triggered the file picker (e.g "pick a folder to do action A" also magically imbues similarly gated actions B C D and Z with access to that folder, possibly non-interactively even).
- it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism whose permission propagates to an action gated by the first mechanism, a first mechanism for which "Yes" means yes but "No" means "Maybe, depending on past unrelated actions that triggered an unrelated permission mechanism"
This is a result of trying to retrofit a series of tighter security measures on top of a system that was not originally designed for them, in a way that is both understandable to users but also doesn't break back-compat with APIs (and therefore a lot of existing third-party apps that are seldom updated) too badly. I'm not saying Apple did a perfect job here, but it's a hard problem.
Yes, the problem could probably be "solved" by adding more UI, but "more UI" is not always a good solution. The more UI that exists, the less likely the user is to successfully navigate it. On the other hand, adding additional complexity to an existing UI is also fraught with potential for new bugs and edge cases. Again, not defending the status quo, but I can see how it might have ended up like this.
This is worth spending more time on trying to improve, and perhaps it is reasonable to expect better from an almost-$4tn company. But at the same time, a potential solution is far from easy or obvious, and there is a risk of making things worse if not done with an extreme level of thought and consideration.
(Alternate pessimistic take: A large number of users don't care or read anything, they just click "allow" on anything that gets in their way. A smaller set of users are terrified and disgusted by repeated invasions of the privacy and click "deny" on everything. None of these implementations are doing any good for either group. The allow/deny design pattern is badly broken and in need of rethinking.)
Very personal counterpoint: I find Stross writing extremely bland, contrived, and badly paced.
I really really disliked Accelerando in particular, finding it completely vacuous, the sciencey namedrops is self-aggrandising and sound like attempts at reader flattery, the entire plot is telegraphed, characters are generic and perfectly forgettable.
It was several friends recommendation and I only got reading through the whole ordeal because whenever I asked "well I'm about there and it doesn't click" they answered "no spoiler, just a dozen pages and you'll see!"
Not a critic, again this is my personal experience of it. If people enjoyed it, more power to them.
I've had to explicitly direct the machine to read existing sibling code and follow the specific idioms and patterns in use.
reply