[mncharity]

Indeed. There does seem an issue of what baseline to use. Elsevier isn't usually thought of as a useful ethical baseline, but here it's a displaced competitor. Companies embed a variety of telemetry. And while much open source doesn't, some does, and this is perhaps increasing. And yet, if say Firefox always maintained an open but empty connection to mozilla, would it be adequate to suggest "well, no, that's not under privacy preferences, but it's documented on our privacy web page, and can be disabled by editing about.config.mumble"? Perhaps with the shift from desktop to phone, expectations of what it means to be local are changing? "Your core data is local, not hostage", but now "of course the app chats on the web... doesn't everything?"?

[jmiserez]

Well Firefox actually does (Web Push API): https://support.mozilla.org/en-US/kb/push-notifications-fire...

>Firefox maintains an active connection to a push service in order to receive push messages as long as it is open. The connection ends when Firefox is closed.

I see what you're getting at, but I think the harshest criticism should be reserved for the worst services: those that actually hold your data hostage, don't provide an export functionality and use your data in all sorts of unethical ways.

Organisations that actually honestly do value privacy and try to make an effort to get it "right" should be given the benefit of the doubt and constructive criticism, as they might actually listen. In many cases the feature may simply be driven by convenience and the competition (e.g. cloud storage, accounts, sync), and having a toggle for those is the best you can do if they want to stay relevant. In other cases the privacy issue may have simply been overlooked and the feature is improved (IIRC Mozilla has had a few of these).

Maybe a big red "offline-only" toggle would be great, but the absence of that button does not in my eyes disqualify Zotero from being a great offline solution.

[mncharity]

Wow. And agreed. One question, re "being a great offline solution", in what sense offline? Able to work without net?

Thinking about dstillman's reply, I was thought-crawling towards a "local/remote vs online/offline" distinction. So Zotero would be local but always online (if net is available). Versus my expectation that when using only local resources, a local tool will be offline.

[jmiserez]

I think dstillman put it best, the features that make Zotero actually useful need to connect to the internet, like fetching metadata. You wouldn't want to enter everything by hand (but you can).

I think your expectation is reasonable (a local tool will be offline when using only local resources), and it's definitely possible with Zotero (disable the automatic translator/style updates) but just not the default setting.

On a technical level, I don't think there is a huge difference between polling and maintaining a persistent connection, if the polling interval is short or the keepalives are long. The real question that I'd find interesting is why the translator/style updates must be "instant". For my use, once a day or once every few hours would probably be more than sufficient.

[dstillman]

> The real question that I'd find interesting is why the translator/style updates must be "instant". For my use, once a day or once every few hours would probably be more than sufficient.

Before Zotero had push-based auto-sync, translator/style updates were indeed once a day, but that meant that, if a high-profile site changed and we pushed out an updated translator, we'd continue to get reports of the site being broken for 24 hours. We could say to update translators manually, but that would only help the people who made it to the forums.

When we added WebSocket support for syncing, we decided to send translator/style update notifications over the same connection. For anyone using auto-sync anyway (many/most users), there's no difference. If you don't use syncing/auto-sync, it's more debatable, but it's a choice between trying not to expose IP addresses that are likely already making at least some other anonymous requests (app updates, retraction checks, OA PDF checks) and decreasing the amount of breakage that users encounter after we've already fixed something.

[jmiserez]

Very interesting insights! Makes sense with the WebSocket reuse and the support requests.

[mncharity]

Nod. One way to address conflicting desires for both opt-in and defaults, is having an onboarding step "want to use net for features... can customize under Preferences/Privacy... [ok]". Informed and consent is somewhat spread in time, and between the step and preferences, but... it seems current best practice.