Hi,
For years Tails has shipped with an Iceweasel with the (relevant) Tor Browser patches applied. It has worked ok, but it's been high maintenance, and keeping the preferences synced with TBB was a bit of a chore, among other issues. Since Tails 1.2 we've migrated to installing the Tor Browser from the actual (32-bit Linux) TBB tarballs you distribute. We're very much interested in your comments on how we do this, so please have look at our design page: [1]
[1] https://tails.boum.org/contribute/design/#index40h3
The main source of *potential* issues this has introduced is the added dependency on the timing of your TBB releases (rather, when the tarballs are made available). We aim at releasing Tails with a browser based on Firefox X.Y.Zesr on the same day as Mozilla officially releases it, i.e. every sixth Tuesday. Due to the time required for Tails' release process (including QA) that means that we need the final TBB tarballs based on that Firefox release *at the very latest* 24 hours before the planned Tails release.
Just to get an idea, let's have a look at TBB's release history. Below I'll list the last -buildX tag for a given TBB release that upgrades to a new Firefox ESR (but I'm skipping exceptions outside the 6-week cycle) and the timing of when the tag was made vs the "ideal" time of a Tails release, which we say is at 18:00:00 (UTC) on the Firefox ESR (official) release day. Just to be clear, a high timing value is good for Tails.
TBB release tag Tag date (UTC) Timing vs ideal Tails release tbb-4.0-build1 2014-10-13 17:34:22 +24 hours tbb-3.6.5-build1 2014-09-01 05:48:33 +36 hours tbb-3.6.3-build1 2014-07-24 08:58:10 -39 hours tbb-3.6.2-build6 2014-06-11 13:30:06 -19 hours tbb-3.6.1-build1 2014-05-06 12:19:26 -138 hours tbb-3.5.3-build1 2014-03-17 23:05:35 +19 hours tbb-3.5.2-build5 2014-02-07 18:14:41 -72 hours
So, now we assume that the "Tag date" above also is the time when the tarballs are made available for download (and preferable announced on tor-qa@). Given that we want at least a +24 hours, this history doesn't look super promising for our (Tails') plans. I'm not sure the above assumption is very sound, though; for instance, the initial 4.0 tarballs (before the rebuild for POODLE but we're ignoring such exceptions) was announced on tor-qa@ on 2014-10-13 10:19:08 (UTC), which was 7 hours before the tbb-4.0-build1 tag.
In any case it's true that if Tails had migrated to using the TBB in the beginning of 2014, we'd have trouble with several of our releases due to late TBB rebuilds. Of course, I'm not complaining that you have misbehaved. :) So far you haven't been working as an upstream for other projects so that they get a time window to include TBB and then do a same-day releases with you, e.g. like how Mozilla is an upstream to you, and was an upstream for Tails prior to our TBB-migration.
However, do you think you can become such an upstream for Tails by trying to provide the time window detailed above? If you believe that window is too narrow, I suppose Tails could drop the "same-day release" goal and adopt a "day-after release" goal or possible even later. What do you think is possible? How can we help?
To get a more concrete understanding of what exactly I'm proposing, let's use the next Tails release, 1.2.1, as an example: It's aimed to be released at 2014-11-25 18:00:00 (UTC), the same day as Firefox 31.3.0esr will be officially released. We'd need the (final) TBB (32-bit Linux) tarballs based on that Firefox version at the latest 24 hours before that, i.e. 2014-11-24 18:00:00 (UTC). Does that seem reasonable? I'm actually genuinely interested in an answer to this specific question, since I'm writing the Tails 1.2.1 release schedule as we speak and may have to adjust it if this turns out difficult for you to "promise".
Cheers!
Hi,
anonym:
Hi,
For years Tails has shipped with an Iceweasel with the (relevant) Tor Browser patches applied. It has worked ok, but it's been high maintenance, and keeping the preferences synced with TBB was a bit of a chore, among other issues. Since Tails 1.2 we've migrated to installing the Tor Browser from the actual (32-bit Linux) TBB tarballs you distribute. We're very much interested in your comments on how we do this, so please have look at our design page: [1]
what does adding Adblock plus have for a benefit wrt to tracking avoidance? To put it more precisely: In which cases are the defenses in the current Tor Browser not adequate yet Adblock plus fixes this situation (I could not find anything on the link you gave above about it)? (might be a separate discussion, though)
So, now we assume that the "Tag date" above also is the time when the tarballs are made available for download (and preferable announced on tor-qa@). Given that we want at least a +24 hours, this history doesn't look super promising for our (Tails') plans. I'm not sure the above assumption is very sound, though; for instance, the initial 4.0 tarballs (before the rebuild for POODLE but we're ignoring such exceptions) was announced on tor-qa@ on 2014-10-13 10:19:08 (UTC), which was 7 hours before the tbb-4.0-build1 tag.
Yes, this assumption may not hold in the current model we have, where we build first to see whether we get matching builds and tag later. I am not sure what would be a better model as not getting matching builds is a blocker for us. Would it be possible for you to take the builds announced on tor-qa instead of waiting for an official tag?
However, do you think you can become such an upstream for Tails by trying to provide the time window detailed above? If you believe that window is too narrow, I suppose Tails could drop the "same-day release" goal and adopt a "day-after release" goal or possible even later. What do you think is possible? How can we help?
We aim at the "same-day release" as well which means something like starting builds Thursday/Friday before Mozilla's release on Tuesday, getting builds to tor-qa by Monday and (given there are no serious issues popping up) releasing on Tuesday. Having them sent to tor-qa by 18:00:00 (UTC) should be doable.
To get a more concrete understanding of what exactly I'm proposing, let's use the next Tails release, 1.2.1, as an example: It's aimed to be released at 2014-11-25 18:00:00 (UTC), the same day as Firefox 31.3.0esr will be officially released. We'd need the (final) TBB (32-bit Linux) tarballs based on that Firefox version at the latest 24 hours before that, i.e. 2014-11-24 18:00:00 (UTC). Does that seem reasonable? I'm actually genuinely interested in an answer to this specific question, since I'm writing the Tails 1.2.1 release schedule as we speak and may have to adjust it if this turns out difficult for you to "promise".
We can try. How hard would it be for you to promise the day-after-release and while trying to get Tails released the same day, though? Does this buy you anything?
Georg
23/10/14 11:08, Georg Koppen wrote:
Hi,
anonym:
Hi,
For years Tails has shipped with an Iceweasel with the (relevant) Tor Browser patches applied. It has worked ok, but it's been high maintenance, and keeping the preferences synced with TBB was a bit of a chore, among other issues. Since Tails 1.2 we've migrated to installing the Tor Browser from the actual (32-bit Linux) TBB tarballs you distribute. We're very much interested in your comments on how we do this, so please have look at our design page: [1]
what does adding Adblock [...] (might be a separate discussion, though)
Indeed, so I'm splitting this into a separate thread.
So, now we assume that the "Tag date" above also is the time when the tarballs are made available for download (and preferable announced on tor-qa@). Given that we want at least a +24 hours, this history doesn't look super promising for our (Tails') plans. I'm not sure the above assumption is very sound, though; for instance, the initial 4.0 tarballs (before the rebuild for POODLE but we're ignoring such exceptions) was announced on tor-qa@ on 2014-10-13 10:19:08 (UTC), which was 7 hours before the tbb-4.0-build1 tag.
Yes, this assumption may not hold in the current model we have, where we build first to see whether we get matching builds and tag later. I am not sure what would be a better model as not getting matching builds is a blocker for us. Would it be possible for you to take the builds announced on tor-qa instead of waiting for an official tag?
Of course, that's also possible -- I wasn't sure *what* I was supposed to look at, so thanks for the clarification!
I re-recalculated the table and got this:
TBB release tor-qa@ (UTC) Timing vs ideal Tails release 4.0 2014-10-13 10:18:04 +31 hours 3.6.5 2014-09-01 06:45:46 +35 hours 3.6.3 2014-07-24 09:10:03 -39 hours 3.6.2 2014-06-09 06:49:20 +36 hours 3.5.3 2014-03-18 18:18:34 +0 hours 3.5.2 2014-02-07 18:14:41 -81 hours
So, it improves the situation slightly overall, but it still looks like half of the Tails releases would have been stalled.
3.6.1 is omitted from the table above since it wasn't announced at all. 3.6 was announced on 2014-04-27 14:18:00 (UTC), which would give a very good timing value, however. I'm not how we would have dealt with that situation. The corollary is, what will we do if it happens again? I'm not sure I have a good answer for that yet, but I suppose we either build the tarballs ourselves (at least if the delay is due to problems not affecting Tails), or postpone our release too, if possible (see below why this may be problematic). At least I'd like our communication to improve *when* such blockers appear for you, so we known that we are potentially blocked.
However, do you think you can become such an upstream for Tails by trying to provide the time window detailed above? If you believe that window is too narrow, I suppose Tails could drop the "same-day release" goal and adopt a "day-after release" goal or possible even later. What do you think is possible? How can we help?
We aim at the "same-day release" as well which means something like starting builds Thursday/Friday before Mozilla's release on Tuesday, getting builds to tor-qa by Monday and (given there are no serious issues popping up) releasing on Tuesday. Having them sent to tor-qa by 18:00:00 (UTC) should be doable.
Ok. The earlier the better, of course, but I assume you aim for that any way since it helps your QA. Still, if there's anything we can do to help this progress from "should be doable" to something more reliable, please let us know.
To get a more concrete understanding of what exactly I'm proposing, let's use the next Tails release, 1.2.1, as an example: It's aimed to be released at 2014-11-25 18:00:00 (UTC), the same day as Firefox 31.3.0esr will be officially released. We'd need the (final) TBB (32-bit Linux) tarballs based on that Firefox version at the latest 24 hours before that, i.e. 2014-11-24 18:00:00 (UTC). Does that seem reasonable? I'm actually genuinely interested in an answer to this specific question, since I'm writing the Tails 1.2.1 release schedule as we speak and may have to adjust it if this turns out difficult for you to "promise".
We can try. How hard would it be for you to promise the day-after-release and while trying to get Tails released the same day, though? Does this buy you anything?
It's not that easy, at least not now. Normally I prepare releases on my own, and I plan my time to be quite flexible around the release dates., but I'm not alone; the release has to be coordinated for the QA well in advance. To change that on short notice may not be compatible with the schedules of the other people involved in QA. Hence, we want a rigid schedule that we can set weeks before the actual date. If same-day releases seems like it will cause a lot of timing problems, we may end up trying day-after releases instead.
However, once our automated testing has replaced manual QA, then this may get more flexible.
Cheers!
23/10/14 11:08, Georg Koppen wrote:
what does adding Adblock plus have for a benefit wrt to tracking avoidance? To put it more precisely: In which cases are the defenses in the current Tor Browser not adequate yet Adblock plus fixes this situation (I could not find anything on the link you gave above about it)?
In all honesty, it's not very clear to me why we state this. We've been shipping AdBlock together with the browser since before there was a TBB, and even before Tails, the Incognito LiveCD did it. I added AdBlock to Incognito's browser primarily for performance reasons, I think.
Any way, we have a ticket about possibly removing AdBlock in Tails:
https://labs.riseup.net/code/issues/5649
As for tracking avoidance, I guess the basic issue is that if I (more or less) concurrently browse sites X and Y, and both serve ads from Z, then Z can correlate my presence on X and Y in various ways. The Tor Browser does stuff to prevent this, like disabling 3rd party cookies and probably more things I'm unaware of, but I suppose the ad fetches still may use the same Tor circuit, so AdBlock:ing seems to at least help with preventing that. Of course, it uses a blacklist approach, and the real solution is something like Tor bug #3455 [1] I guess.
Do you feel that the above is accurate? If not, please elaborate, so we can progress on Tails ticket #5649.
For me personally, however, the biggest benefit with AdBlock Plus is that I can enjoy my browsing experience as ad-free. This may not be a good argument for its inclusion, though, just a personal anecdote. :)
Cheers!
[1] Tor Browser should set SOCKS username for a request based on first party domain: https://trac.torproject.org/projects/tor/ticket/3455
-
anonym -
Georg Koppen