Why disable Reader view?

[RoxKilly]

I notice that reader.parse-on-load.enabled = false to disable Reader View. What is the reasoning behind this choice? I'm having a hard time understanding what privacy downside there is since switching to this view does not result in any more network request (according to the Network log).

[ghost]

One of the very few (recommended) setting I've never followed. I see no privacy issue with leaving Reader view enabled. I may be wrong. Good opportunity to get this point clarified. Maybe had the setting been established some time ago when it appeared to be tied to the Pocket feature which then was native and now is proposed as a service add-on (native in fact as well unless you disable (that) service add-on). The fact is Reader View has always operated independently of Pocket. I use it very often.

[earthlng]

Just toggling between reader and non-reader view doesn't seem to cause a site refresh, but maybe that's just with my setup (cache etc). I also never disabled the Reader View for what it's worth. I'm okay with moving it to Personal and commenting it out.

[ghost]

As long as it con be confirmed that zero online connections are made, then I see no reason to move to it to personal and comment it out

I would have imagined the opposite more pertinent : comment out any setting for which there is no evidence of a privacy/security issue. You need evidence to dare propose modifying a setting. My approach is that I modify settings on the ground of facts and never on the basis of suspicion.

[ghost]

OK @Thorin-Oakenpants , then I presume you'll consider commenting out the setting in next user.js?

/* 0375: disable "Reader View" [SETUP] ***/
user_pref("reader.parse-on-load.enabled", false);

Considering there is no evidence at this time of a privacy issue.

Users should never consider adopting a whatever recommended user.js blindly but we know many do and then get surprised this or that breaks that or this. if the setting is legitimate, hence if it blocks what has proven to be a privacy/security issue then at least there is a valid answer to their surprise, otherwise it would be a pity (for a user) to discredit a whole user.js on the ground one setting or another lacked evidence to legitimate the blocking.

[earthlng]

then I presume you'll consider commenting out the setting in next user.js?

already done

If you scroll up a bit you can see:

Thorin-Oakenpants added a commit that referenced this issue 14 hours ago "reader view" -> personal section -> inactive mozilla/addons-frontend#84 2d0e27c

[RoxKilly]

@Thorin-Oakenpants actually I just stumbled into evidence that in some cases, the browser actually downloads static content when switching to Reader View. Since this conflicts with my OP statement, I thought I should bring it to everyone's attention.

This occurs for instance when an extension previously blocked an image from downloading. When the browser switches to Reader View, static images are in fact fetched. To reproduce, please look at the issue I opened on the uBlock Origin board.

These new connections don't seem to occur to fetch scripts (tested by switching to reader view while watching the network tool on this page).

Because only images are fetched (it seems), and because the connection to the image server is made even with uBlock Origin when in regular view (only difference is image is not downloaded when blocked), I see no additional privacy exposure and would still use Reader View.

[RoxKilly]

What is gorhill's instruction?

Removing about-scheme (or commenting it out with #) from the Whitelist tab of uBlock Origin settings makes uBO work even in Reader View. I don't know what other effects come with that though.

[earthlng]

about:addons used to load a page that had google-analytics embedded and because of the whitelist it didn't block those requests. I've since removed all entries from the whitelist and now my * * * noop rule blocks all items on filterlists no matter where they occur. I once tested a firefox fork of a chrome extension and it also had google-analytics in it to make the author some money and spy on me, and that's why I removed all entries including all the extension schemes. In uMatrix I have the following rules and that's why I didn't see any additional requests when switching to reader view:

matrix-off: about-scheme false
about-scheme * * allow
reader.about-scheme * * block

edit: I've now added a new rule to allow images: reader.about-scheme * image allow

[earthlng]

Any drawbacks?

None that I noticed. But I only have 2 rules in uBO and the noop rule covers everything. Since you run uBO and uM in another way than I am, you may need more or different rules, idk

behind-the-scene are requests that can't be attributed to a source afaik. Mostly favicons and OCSP requests.

[earthlng]

Thanks for the heads up. The TBB ticket about Reader view is pretty vague about the "potential" fingerprinting issue:

I did not disable the whole feature but made sure that the fingerprinting risks that might be associated with it are neutered.

I don't see how that makes any sense. They only remove the easy access to it but didn't remove it completely.

Having it set to true would discriminate between users with low memory computers (probably only some mobile ones) and those who have Reader View capable ones.

Is that the only reason? So that means there aren't any FP risks apart from "maybe" knowing if someone is a mobile user? Does a site even know when I click on the Reader view icon, if so how? Is TBB on mobile even a thing? Seems a bit ridiculous with all the built-in tracking stuff in mobile phones.

Anyway, if they want to include Reader View in RFP there's not much we can do about it. Contrary to what I believed the change would be, upon reading it again in detail it seems they want to lock prefs and therefore it won't be possible to opt-out of certain features bundled in resistFingerprinting.

[RoxKilly]

Sidenote: after the switch to WebExtensions exclusively, would uBO/uMatrix still be able to police connections made from schemes such as these?

behind-the-scene
chrome-extension-scheme
chrome-scheme
loopconversation.about-scheme
metrics.mozilla.com
opera-scheme

[earthlng]

If you want to opt out of one of them, use a config file and lock_pref

Thx, I didn't think about that. But it's still not great because lock_pref applies to all profiles.

[Atavic]

@RoxKilly Gorhill is going fine.

loopconversation.about-scheme

[RoxKilly]

Thanks @Atavic. I'm basically trying to find out whether the Firefox WebExtension API will allow addons to limit these behind-the-scenes connections.

[RoxKilly]

hopefully they drop disabling reader view

I completely agree I hope they keep reader view enabled under resistFingerprinting unless it has privacy/security implications we haven't come across. I find it very useful and use it daily

[earthlng]

WE definitely cannot access about-scheme

not just that but any privileged scheme (fe addons!) and also some mozilla domains as well! I can understand why redirects on AMO for example are prohibited but blocking a request, any request, should still be possible and allowed. The current limitations on the webRequest API are quite frankly unacceptable to me. If they don't change that I'll probably have to start looking for FF alternatives.

[Atavic]

What about staying on a working ESR for the time being?

[earthlng]

Yes, for now I'm okay with my non-webextension versions of noscript, uBO and uMatrix etc. What I meant was once the time comes when no version of FF allows non-webextension addons anymore AND if by then the limitations haven't changed, I'll probably have to ditch FF.

[ghost]

Same here : if a privacy/security related add-on looses its power, efficiency in its WebExtension format then I systematically keep the so called legacy version. That's for now on Firefox 52+ESR. Once 52ESR's EOL if the Webextension equivalent of those add-ons have not made their way to be as powerful as they were before, I quit Firefox, for 'Pale Moon' most likely. For my concern it's all in how will things be by Q1/2018. I read that new APIs are coming in, we'll see.

Also I have to say that Firefox pages and Mozilla sites being an exception to whatever WebExtension is really not satisfactory as far as I'm concerned. "You mean the murderer cannot be the judge? And why not? We know firemen who start fires"