The problem is all of these use localstorage, and since they're on different domains, they'll get different localstorages. This means if you change a setting on one, it will still be set to the default value on all the others.
One option to fix this would be to use an invisible iframe that always points to the same site along with window.sendMessage. This would also fix the issue of localstorage not being available for file:/// urls.
The iframe would contain a small script that listens for messages and reads/writes its localstorage accordingly. The script would contain a small list of whitelisted domains, and any domains besides those would prompt the user if they should be allowed through window.confirm. This would prevent malitious sites from wiping your settings.
Wouldn't this break offline usage of file://, since the domain wouldn't be available? The most common usage of local docs for me is when my Internet is down. For those who regularly travel I can also see this being important.
Also, is this really a huge issue? Presumably you can set this once for each site you use. Caveat: I don't change default settings. The default dark theme works for me.
The privacy concern is also a massive issue as pitaj mentioned.
All forms of storage are getting partitioned by top-level origin, not just cookies. I used cookies as shorthand for all forms of storage, including the localstorage you proposed.
it would be possible to reparent it to rust-lang and add it as a submodule so it can be tested alongside everything else, but it would probably be easier to just integrate it into rustdoc (all it does is patch rustdoc's code to use the method i proposed).
they would have to partition window.postMessage, which would be equivalent to just removing the feature, since its entire point is to safely allow cross-origin communication.
I'm really confused about what the privacy concerns are. the postMessage interface allows the recipient site to verify the origin of the sender, so we can use an access control list, and the only data that could possibly be exposed is the rustdoc settings, which are far from personally identifyable.
additionally, unless the user grants access to a malicious site, the settings are all stored locally and not sent to a server.
The storage the iframe content sees depends on the top-level origin. This way postMessage still works cross-origin, without leaking any information between top-level origins.
The concern is that every rustdoc access, even from local file://s, now results in some_website being loaded into an iframe.
Even if it doesn't have access to anything but rustdoc settings, it can still store its own cookies, get your IP address, and do whatever other fingerprinting that any other website you go to can.
And since it's just a website, it could change at any moment. Even if you trust the Rust project completely, there's the possibility of it being hacked.
If rust-lang infrastructure is hacked, rustdoc fingerprinting what docs you're looking at should be by far the least of your worries. Such a hack would likely allow an attacker to push arbitrary code onto developer machines via rustup or cargo.
I wonder: would the feature still bring significant benefit if you have the iframe logic be opt-in? (storing the opt-in in the same origin-specific local storage as the preferences today)
I can imagine it might still be helpful to (one-time per origin) allow it to read/write your preferences from that point forward. So you don't have to remember "what's the name of the theme" just "I approve loading from an additional origin, for this origin".
From the discussion above, it seems like that wouldn't help with file:// URLs (if they don't get local storage permission). But file:// seems possible (more likely) to be focused on offline mode.
This is not really about Rust project getting hacked, or even about trusting the rust project.
You also have to trust the hosting provider and intermediate hops to not record data.
The Rust project needs to maintain extra infrastructure for relatively small gain.
The rust project needs to deal with the potential regulatory headaches of this (GDPR etc). Now with the additional complication of cross site requests.
Many people likely don't want this and will have a kneejerk reaction to it. We have gone without a major controversy for about a year now, and I'd like it to be longer.
It won't even work in most cases, since third party local storage gets siloed (or is about to get siloed) by the top frame domain these days (except in Chrome). So you would need server side storage with an account to work around that.
It won't even work if the site you are using properly configured Access-Control-Allow-Origin - HTTP | MDN (you should deny everything you don't explicitly need). If I hosted docs and started getting CORS errors I would absolutely file a bug against Rustdoc. Loading anything external should be opt-in.
Not really. Even if it would work, I consider the other strong as well. And it is also common in rethorics to end on your strongest argument(s), for two reasons: it is what your audience will remember, and presenting a weaker argument after a strong argument can give a weak impression.