[threeseed]

> the competent design would have been to store them locally (and per user) in a central location on the machine doing the browsing

Not sure but it could be the case that when you mount a network drive there isn't a stable identifier that can be used to track it.

[organsnyder]

Sure, that wouldn't work if the network volume was accessed by different URIs. But it would work in 95% of cases, which is good enough.

[DidYaWipe]

Exactly. And if the same machine used two URIs, there'd simply be two entries for settings. And the settings cache could flush old entries periodically.

[nullindividual]

Like two websites that look the same, except one captures your creds?

You don't want user prefs to apply to multiple locations solely based on URI.

[organsnyder]

Just because two URIs might appear to be similar doesn't mean they are identical. Using the URI string as a hash key wouldn't be vulnerable to this.

[Wingy]

Store a single .DS_Store in the root of the disk that stores either the reference or all of the data for that filesystem?

[threeseed]

Users rarely mount network drives as root so not sure how this would work.

Also the conflict resolution to support concurrent updates would be crazy.

[DidYaWipe]

I think it's likely that there is a reasonably stable path for any kind of mount, but I don't know a ton about networks so I'll leave it to someone else to weigh in.

But the stakes are very low here, so settings can be invalidated and discarded if they can't be resolved or they age out of the local cache. And if the mount is of a type that can't be reliably identified later, the default should have been to do nothing. Spewing junk all over every computer visited, especially junk that won't even survive the next Mac user's visit... is amateur-hour and obnoxious at best.