Patrick, The predictor may issue dns requests or start connections (including TLS negotiations, if necessary) entirely based on browsing history combined with a confidence calculation (the details of which are in the code, but intentionally left vague via email because they may change in order to improve performance/privacy/some other concern). To be clear, we aren't randomly guessing at what to do, and we won't do anything the user hasn't intentionally done at least once before.
Also, I will note that this feature went through privacy review when it first landed (details/results at https://wiki.mozilla.org/Privacy/Reviews/Necko), and "passed" (if that's the right word) with flying colors. This new landing doesn't change any of the results of that, it's purely an implementation detail to reduce jank and CPU usage caused by the feature. Beyond that, it's hard to address any perceived "privacy ramifications" without knowing people's particular concerns. (As you noted, for the truly privacy paranoid among us, the feature is easy to disable via about:config.) -Nick On Thu, Jan 15, 2015 at 7:48 PM, Patrick Cloke <clo...@gmail.com> wrote: > On 1/15/2015 12:26 PM, Nicholas Hurley wrote: > >> All, >> >> I just landed https://bugzilla.mozilla.org/show_bug.cgi?id=1009122 on >> mozilla-inbound, which re-enables necko's predictive actions capabilities. >> I won't go into the full explanation of it here, you can find the big >> information (very little of which has changed in this new iteration) in my >> original post, >> https://groups.google.com/d/msg/mozilla.dev.platform/ >> tAnuc-J0DbY/snrGsOVW1MAJ >> >> The big thing to note about this landing is that data is now stored in the >> disk cache instead of sqlite, which means the predictor (formerly "seer") >> should not be causing jank or excessive cpu usage any more (hooray!) This >> rewrite also keeps the improvements in page load time seen in the previous >> iteration (see previous message linked above for details). >> >> This is currently enabled on desktop and android, and disabled on b2g, as >> e10s support is not fully there in the predictor yet. To be clear - this >> will not break anywhere e10s is enabled, it's just a no-op for now if e10s >> is enabled. Work on e10s support is proceeding in >> https://bugzilla.mozilla.org/show_bug.cgi?id=959752 (feel free to follow >> along if you wish). >> >> Any bugs you encounter with this feature enabled, please file a followup >> blocking 1009122. >> >> -Nick >> >> > Nick, > > I just read through your previous post and I'm underwhelmed by the detail > in it. Can you go into more detail about how it "may" issue speculative DNS > lookups/SSL negotiations? It seems to have some privacy ramifications that > I think deserve a more thorough explanation. > > For anyone else who's curious, it seems you can disable this by setting > "network.predictor.enabled" to false in about:config (or by using e10s it > seems ;) ). > > Thanks, > Patrick > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
