Re: [tor-dev] [HTTPS-Everywhere] [GSoC] HTTPS Everywhere secure ruleset update mechanism update
(resending to tor-dev with tp.o email address) On 07/08/2014 03:42 AM, Yan Zhu wrote:
On 07/08/2014 12:07 AM, Jeroen Massar wrote:
On 2014-07-07 20:40, Red wrote: [.. lots of cool work being worked on ..]
Hi Zack,
Seems you are doing lots of cool stuff ;)
But I am one of those strange people who really hate it that every separate tool has their own updater (which can be used for tracking a user, as the set of updater tools polling servers makes a fingerprint in the same way other flows make a fingerprint).
Hi Jeroen,
This makes a lot of sense. I'm aware of the fingerprintability concern, and EFF tech projects generally try to mitigate it by polling the update servers at randomized intervals over fresh Tor circuits if possible. For this project, we initially proposed polling for an update when the browser starts and every 3 hours plus some random, evenly-distributed number of milliseconds between 0 and 300000. I'm curious if others have more refined suggestions!
And thus I run Little Snitch and block those updates. Till I deem it a good time for the update to be done and trigger it manually.
As such, when you get to the stage of adding features, it would be good if there was: - an option to disable the auto fetching
Yes, this would be fairly easy to add.
- an option to trigger the fetching
Probably also easy.
- to feed the update mechanism with a pre-fetched file (eg provided through a different update mechanism)
Since the update mechanism is just an XHR that downloads a new ruleset library from a hardcoded static URL and replaces the existing one in the Firefox profile directory, you could fetch-and-replace this manually via any number of mechanisms. :)
Also, the ruleset libraries will still ship with extension updates, so you could disable ruleset updates and just wait for the next HTTPS Everywhere release.
-Yan
Greets, Jeroen
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ HTTPS-Everywhere mailing list HTTPS-Everywhere@lists.eff.org https://lists.eff.org/mailman/listinfo/https-everywhere
-- Yan Zhu <yan@eff.org>, <yan@torproject.org> Staff Technologist Electronic Frontier Foundation https://www.eff.org 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x134
On 2014-07-08 12:47, Yan Zhu wrote:
(resending to tor-dev with tp.o email address)
On 07/08/2014 03:42 AM, Yan Zhu wrote:
On 07/08/2014 12:07 AM, Jeroen Massar wrote:
On 2014-07-07 20:40, Red wrote: [.. lots of cool work being worked on ..]
Hi Zack,
Seems you are doing lots of cool stuff ;)
But I am one of those strange people who really hate it that every separate tool has their own updater (which can be used for tracking a user, as the set of updater tools polling servers makes a fingerprint in the same way other flows make a fingerprint).
Hi Jeroen,
This makes a lot of sense. I'm aware of the fingerprintability concern, and EFF tech projects generally try to mitigate it by polling the update servers at randomized intervals over fresh Tor circuits if possible. For this project, we initially proposed polling for an update when the browser starts and every 3 hours plus some random, evenly-distributed number of milliseconds between 0 and 300000. I'm curious if others have more refined suggestions!
When the update happens over Tor you are mostly fine. But then you have to make sure that the update happens over Tor. That is fine for Tails, but not guaranteed for TBB. Hence, my concern is for leaked connections outside of Tor. Eg, when connecting to a wireless network at Starbucks. The moment one has a forced VPN/Tor setup that one trusts, it is less of an issue. If somebody can fingerprint timing info in Tor, then well, we have bigger problems there ;) (and indeed, having the updates come in through either Apple App Store, Debian's APT repos etc, is an advantage as that only tells an adversary "hey another OSX/Debian user" and not much else; oh and yes, app store updating is disabled too on my hosts ;)
And thus I run Little Snitch and block those updates. Till I deem it a good time for the update to be done and trigger it manually.
As such, when you get to the stage of adding features, it would be good if there was: - an option to disable the auto fetching
Yes, this would be fairly easy to add.
- an option to trigger the fetching
Probably also easy.
- to feed the update mechanism with a pre-fetched file (eg provided through a different update mechanism)
Since the update mechanism is just an XHR that downloads a new ruleset library from a hardcoded static URL and replaces the existing one in the Firefox profile directory, you could fetch-and-replace this manually via any number of mechanisms. :)
Indeed. Thus it would be good if the system allows that.
Also, the ruleset libraries will still ship with extension updates, so you could disable ruleset updates and just wait for the next HTTPS Everywhere release.
Yes, that might not be the best method. Especiallly when you get it from a 'stable' source (eg TBB) that one does not update every once in a while. Note that I see HTTPS Everywhere being used for other purposes than just the standard checks it performs today, and then the updates might have to be a lot more frequent than the software update happens. Greets, Jeroen
participants (2)
-
Jeroen Massar -
Yan Zhu