Re: [Tails-dev] [tor-qa] Tor Browser 5.0 is ready for testing!
Georg Koppen: > Mike Perry: > > https://people.torproject.org/~mikeperry/builds/5.0-build2/ > > > > This release is our first stable release based on Firefox 38-ESR. We've > > done a lot of work to ensure that this release is minimally disruptive > > in terms of changes to the UI/UX, but some hacks were needed, especially > > to ensure the "Tiles" feature was disabled, and to clean up the NoScript > > whitelist. > > > > The current Firefox 31-ESR is end-of-life on Tuesday, August 11th, so we > > need to switch all users to 5.0 for them to pick up security updates. As > > such, extra testing would be appreciated! > > FWIW: One thing we already found and which unfortunately makes a build3 > necessary is the incompatibility with the localized language packs. I > was under the impression (wrongly as it turns out) that Mozilla fixed > their versioning scheme we get with the git checkouts starting with > their esr38 cycle and forgot to doublecheck that. If anyone was waiting for build3 before testing (which was a bad idea), it is now ready: https://people.torproject.org/~mikeperry/builds/5.0-build3/ Please test. -- Mike Perry signature.asc Description: Digital signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [tor-qa] Tor Browser 4.5 is ready for testing
We had to do a rebuild over the weekend for two bugs: * Bug 15794: Crash on some pages with SVG images if SVG is disabled * Bug 15795: Some security slider prefs do not trigger custom checkbox We also updated HTTPS-Everywhere to 5.0.3. New builds are at: https://people.torproject.org/~mikeperry/builds/4.5-build5/ Georg Koppen: > Hi, > > we are excited to announce the first stable version in the 4.5 series > being ready for testing. It will be the next alpha as well. Bundles can > be found on > > https://people.torproject.org/~mikeperry/builds/4.5-build4/ > > Compared to 4.5a5 we were able to put another couple of important > usability fixes into this release. We improved HTTP connection handling, > the HTTP authentication experience and fixed the TLS connection display, > to name a few. Moreover, we neutered Blob URIs to a great deal which can > get used to track users across domains and, finally, brought all Tor > Browser components up-to-date. > > The complete changelog since 4.5a5 is: > > Tor Browser 4.5 -- Apr 28 2015 > * All Platforms >* Update Tor to 0.2.6.7 with additional patches: > * Bug 15482: Reset timestamp_dirty each time a SOCKSAuth circuit is > used >* Update NoScript to 2.6.9.22 >* Update HTTPS-Everywhere to 5.0.2 > * Bug 15689: Resume building HTTPS-Everywhere from git tags >* Update meek to 0.17 >* Update obfs4proxy to 0.0.5 >* Update Tor Launcher to 0.2.7.4 > * Bug 15704: Do not enable network if wizard is opened > * Bug 11879: Stop bootstrap if Cancel or Open Settings is clicked > * Bug 13576: Don't strip "bridge" from the middle of bridge lines > * Bug 15657: Display the host:port of any connection faiures in > bootstrap >* Update Torbutton to 1.9.2.1 > * Bug 15562: Bind SharedWorkers to thirdparty pref > * Bug 15533: Restore default security level when restoring defaults > * Bug 15510: Close Tor Circuit UI control port connections on New > Identity > * Bug 15472: Make node text black in circuit status UI > * Bug 15502: Wipe blob URIs on New Identity > * Bug 14429: Disable automatic window resizing for now >* Bug 4100: Raise HTTP Keep-Alive back to 115 second default >* Bug 13875: Spoof window.devicePixelRatio to avoid DPI fingerprinting >* Bug 15411: Remove old (and unused) cacheDomain cache isolation > mechanism >* Bugs 14716+13254: Fix issues with HTTP Auth usage and TLS > connection info display >* Bug 15502: Isolate blob URI scope to URL domain; block WebWorker access >* Bug 15562: Disable Javascript SharedWorkers due to third party tracking >* Bug 15757: Disable Mozilla video statistics API extensions >* Bug 15758: Disable Device Sensor APIs > * Linux >* Bug 15747: Improve start-tor-browser argument handling >* Bug 15672: Provide desktop app registration+unregistration for Linux > * Windows >* Bug 15539: Make installer exe signatures reproducibly removable >* Bug 10761: Fix instances of shutdown crashes > > Georg > > ___ > tor-qa mailing list > tor...@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-qa -- Mike Perry signature.asc Description: Digital signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Make Tor Binary location configurable in Tor Launcher?
Hey Tails folks, hey Sukhbir, In our efforts to streamline and reorganize the Tor Browser directory structure for the Firefox updater, we have changed how Tor Launcher finds the Tor binary: https://trac.torproject.org/projects/tor/ticket/11641 https://gitweb.torproject.org/user/brade/tor-launcher.git/commitdiff/6599aca0c63944a4db7782fd47c0c6569d8dfdf0 We created a maint-0.2.5 Tor Launcher branch that preserves the old location and behavior for Tor Launcher 0.2.5.x releases in Tor Browser 3.6, while the master branch will house 0.2.6 and use this new directory structure for our upcoming 4.0-alpha series. While reviewing that patch, it occurred to me that it might be useful to make the path to the Tor binary configurable in a pref, rather than hardcoding the depth and pieces of the directory structure in the code and launching logic. However, it probably only makes sense to do this if it would also be useful to non-TBB consumers of Tor Launcher. Otherwise, we can keep using the hardcoded values just for us, if you guys already have an alternate way of launching Tor that you prefer. Let us know what you think! -- Mike Perry signature.asc Description: Digital signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails
Mark Smith: > >>Another small consideration is that we (TBB developers) will probably > >>not test Tor Launcher as a standalone XUL application because we will > >>not be using it that way... so it is possible we will accidentally break > >>something that is needed in that mode. Of course we will try not to do so. > > > >As long as Tor Launcher more or less sticks with its current design, and > >continues to keep away from stuff directly affecting Firefox (leaving > >that to Tor Button) and only do stuff related to > >starting/configuring/monitoring Tor processes, I expect very little > >problems due to your upstream changes. > > > >Does this look like your plan for the foreseeable future? > > Yes, although I leave it to Mike (in his role as TBB chief > architect) to comment as well. Requirements may dictate a future > change in direction, but for now the plan is for Torbutton and Tor > Launcher to work together but maintain their distinct roles. Yes, I think it is reasonable to assume that Tor Launcher should behave independently of Firefox (modulo minor oversights). In addition to XULRunner/Tails, we want it to continue to work with Thunderbird, and be easy to port to Instantbird, as well. To what degree does Tails have automated testing? Will you be able to keep an eye on 'master' and tell us if you run into problems? As far as the patches, they should have a Tor Launcher ticket to correspond to them. Perhaps attach them there? -- Mike Perry signature.asc Description: Digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tor Browser branding in Tails?
Oh, and for the record, you proabably want to build with the patches up to aa57efd7c1807b334a456d0a8e89bdc160eeb296 of tor-browser-24.1.1esr-1 in tor-browser.git (to pick up the commit that disables the mixed content blocker in Firefox, which enables considerably more HTTPS-Everywhere rules). Note that that branch still has not been rebased on top of FF24.2.0 yet. I will be making a new branch for that this weekend (which will also squash those fixup commits). intrigeri: > Hi Mike, > > intrigeri wrote (01 Dec 2013 16:05:08 GMT) : > > how annoying do you think it is if some of the Tor Browser branding > > (mainly: window title bar, some text in "About Tor Browser") is > > applied in Tails 0.22? > > > I guess we could change this by dropping the "Tor Browser's official > > .mozconfigs" patch. To be honest, I'm a bit reluctant to change this > > *now* for 0.22 (frozen, will be released in a bit more than a week), > > and I'm afraid we did not think of this earlier in this release cycle, > > but I would be happy to fix this for 0.23 if you think it's required. > > Thanks for your reply on #tor-dev wrt. which patches we should drop if > we wanted *not* to call our browser "Tor Browser": FTR you suggested > we only drop the Rebrand-Firefox-to-TorBrowser patch, and we keep > applying the mozconfig one. This is already what we do, and the result > is a browser that calls itself "Tor Browser", so I'm afraid this is > not an option. If you think we have to *not* call our browser this > way, I guess I'll have to try dropping the mozconfig patch too. > > More importantly, I've not seen any reply from you on the "how > annoying [...]" question above. I plan to build our browser based on > 24.2.0esr at some point during the week-end. Without any answer on > this topic, I'll assume it's fine that we call our browser "Tor > Browser", at least for one Tails release, and I will avoid fiddling > with the branding at the last minute. > > Cheers, > -- > intrigeri > | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc > | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- Mike Perry signature.asc Description: Digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tor Browser branding in Tails?
intrigeri: > Hi Mike, > > intrigeri wrote (01 Dec 2013 16:05:08 GMT) : > > how annoying do you think it is if some of the Tor Browser branding > > (mainly: window title bar, some text in "About Tor Browser") is > > applied in Tails 0.22? > > > I guess we could change this by dropping the "Tor Browser's official > > .mozconfigs" patch. To be honest, I'm a bit reluctant to change this > > *now* for 0.22 (frozen, will be released in a bit more than a week), > > and I'm afraid we did not think of this earlier in this release cycle, > > but I would be happy to fix this for 0.23 if you think it's required. > > Thanks for your reply on #tor-dev wrt. which patches we should drop if > we wanted *not* to call our browser "Tor Browser": FTR you suggested > we only drop the Rebrand-Firefox-to-TorBrowser patch, and we keep > applying the mozconfig one. This is already what we do, and the result > is a browser that calls itself "Tor Browser", so I'm afraid this is > not an option. If you think we have to *not* call our browser this > way, I guess I'll have to try dropping the mozconfig patch too. Oh, this may be due to the .mozconfig line: mk_add_options MOZ_APP_DISPLAYNAME=TorBrowser Without that, it should call itself Iceweasel/Firefox again in all places. > More importantly, I've not seen any reply from you on the "how > annoying [...]" question above. I plan to build our browser based on > 24.2.0esr at some point during the week-end. Without any answer on > this topic, I'll assume it's fine that we call our browser "Tor > Browser", at least for one Tails release, and I will avoid fiddling > with the branding at the last minute. I thought the "how annoying" question was addressed to the Tails development list, not me. I don't care what you call your browser :). I might suggest that your non-Debian users will find it more understandable to have an "Insecure Browser" and a "Tor Browser", rather than an "Insecure Browser" and an "Iceweasel" (wtf is an Iceweasel anyway?) but that is for you to decide. -- Mike Perry signature.asc Description: Digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] New Firefox 24.1.0esr branch (with full patch set)
Hey everyone, Just wanted to give you the heads up that I have created a new FF24esr branch based on Mozilla's FF24.1.0esr release tag. This should have all of our FF17 patches fully rebased and squashed back into 1 commit per patch. The branch is torbrowser-firefox24.1.0esr on my remote https://git.torproject.org/user/mikeperry/tor-browser.git. The head of that branch should have hash 0afe6cc436e994f176d71c340516f04074e91eeb It compiles on Linux, but I have not tried a full Gitian build with it yet, nor have I tested running it. It also requires a couple commits to Tor Launcher that have been merged to origin/master but have not been tagged with a release yet. There probably also will have to be new patches written once I finish with https://trac.torproject.org/projects/tor/ticket/9608 and with the networking code review. There's also this pile of already-known issues to contend with: https://trac.torproject.org/projects/tor/query?keywords=~ff24-esr -- Mike Perry signature.asc Description: Digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Timing of the move to FF24
Ugh. Python snuck into my C++. Should be fixed.
intrigeri:
> Hi Mike,
>
> Mike Perry wrote (25 Sep 2013 02:37:38 GMT) :
> > intrigeri:
> >> 1. When do you expect to have published preliminary Torbrowser
> >>patches, rebased on FF24?
>
> > Right now:
> > https://gitweb.torproject.org/user/mikeperry/tor-browser.git/shortlog/refs/heads/torbrowser-firefox24.0
>
> Thanks!
>
> It fails to build for me, apparently due to:
>
> + if (!spec.IsEmpty())
> +msg.AppendASCII(spec.get());
> + else:
> +msg.AppendASCII(NS_LITERAL_STRING("Unknown URI!"));
>
> ... in fixup-Isolate-the-Image-Cache-per-url-bar-domain.patch.
>
> That triggers:
>
> /tmp/buildd/iceweasel-24.0/image/src/imgLoader.cpp: In member function
> 'nsAutoCString imgLoader::GetCacheKey(nsIURI*, nsIURI*)':
> /tmp/buildd/iceweasel-24.0/image/src/imgLoader.cpp:1866:11: error: expected
> primary-expression before ':' token
> else:
>^
> /tmp/buildd/iceweasel-24.0/image/src/imgLoader.cpp:1866:11: error: expected
> ';' before ':' token
>
> I could presumably easily fix it locally, but it's way easier (patches
> management -wise) if I can just pile up another fixup commit from you
> on top of that one.
>
> Cheers,
> --
> intrigeri
> | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
> | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
--
Mike Perry
signature.asc
Description: Digital signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Timing of the move to FF24
intrigeri: > Hi Mike, > > we at Tails need to organize the schedule for our next releases wrt. > the move to FF24. > > If you already have a rough timeline in mind, I'd be happy to read it. > > Otherwise, having your answers to a few simple questions should be > enough, for now, so that we can get organized: > > 0. Will there be Torbutton changes that Tails should care about? >If yes, then when can we start to play with it? I think you mostly want to pick up the patch for Bug #8478. However, you should probably start investigating 1.6.x and see how bad it is for you to use. 1.5.x will probably be EOL as soon as TBB 3.0 is stable (which is blocked on just a couple bugs). Not sure if our branding additions to 1.6.x will conflict with yours or not. > 1. When do you expect to have published preliminary Torbrowser >patches, rebased on FF24? Right now: https://gitweb.torproject.org/user/mikeperry/tor-browser.git/shortlog/refs/heads/torbrowser-firefox24.0 Not all patches have been applied. Here's the ones that have lots of conflicts that I haven't done yet: https://gitweb.torproject.org/user/mikeperry/tor-browser.git/tree/refs/heads/torbrowser-firefox24.0:/BADPATCHES > 2. Does it sound reasonable that we do the bulk of our own migration >work, based on your updated Torbrowser patches and the Iceweasel >sources, on 2013-11-25? If not, when should we do it? > > 3. We plan to release a RC1 with FF24 on 2013-12-02, and the final ISO >on 2013-12-11, the same day as FF17 is EOL'd. Totally crazy, or >only half-crazy? Probably slightly less than half-crazy? The main things I'd be worried about if I were you is dealing with Tor Launcher and 1.6.x. Leaving Tor Launcher out but Torbutton 1.6.x in might cause some problems. You can also try including Tor Launcher in with extensions.torlauncher.start_tor set to false, but it still may complain if you don't set the TOR_CONTROL_PORT and TOR_CONTROL_PASSWD env vars anyway. Do you have a schedule link for the ESR release date btw? I can't find the release calendar I used to have. FWIW, I am hoping to have working Gitian builds with FF24 in a couple weeks. -- Mike Perry signature.asc Description: Digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Patches for next stable TBB / Tails
Thus spake intrigeri (intrig...@boum.org): > Hi, > > Mike Perry wrote (01 May 2013 20:50:03 GMT) : > > I say go for it. Onward and upward! :) > > Thanks! Is Torbutton 1.5.2 strictly needed by the updated patches, or > may we skip that one and save some time? You want 1.5.2 to reduce/eliminate hangs on New Identity: https://trac.torproject.org/projects/tor/ticket/8642 That bug *might* be exacerbated by the Optimistic Data patch (I noticed it way more frequently after making a debug build with the Optimistic Data patch, and that patch does change the behavior of nsISocketTransport in a general way), but it also might still be there without it. -- Mike Perry signature.asc Description: Digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Patches for next stable TBB / Tails
Thus spake intrigeri (intrig...@boum.org): > Hi Mike, > > will the April Torbrowser patch updates (especially the Optimistic > Data SOCKS handshake, and the numerous pipelining changes) be included > in TBB that will be released soon after FF 17.0.6esr? Yes. My plan is to include all patches in TBB-stable, unless we hear problems with the alphas. So far, all reports about the alphas have been positive (and people are running them, due to crash bugs in the current TBB-stable). In fact, we'll be doing a TBB-stable release in the next few days with these patches to fix the crash bugs for everyone. I've also been running these patches in my own build of TBB-stable (which I use for all Tor-related web browsing, as well as for reading the news). It's been fine for me - no new regressions at least. > The freeze for Tails 0.18 is in two days, so I wonder if I hurry to > prepare this stuff (and the according prefs changes), test it, have it > reviewed & merged in time, or if we should just postpone it for some > future release. Given the alpha bundles just came out, it seems a bit > early to me to decide. I say go for it. Onward and upward! :) > Thoughts, Mike or anyone? > > Cheers, > -- > intrigeri > | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc > | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- Mike Perry signature.asc Description: Digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Testing image cache and DOM storage isolation
Thus spake intrigeri (intrig...@boum.org): > I'm now taking time to apply to the Tails' web browser the last two > meaningful Torbrowser patches we were not using yet: > > - 0026-Isolate-DOM-storage-to-first-party-URI.patch > - 0024-Isolate-the-Image-Cache-per-url-bar-domain.patch > > I'm now trying to verify that applying these patches actually makes > a difference. How do you do it? First, note that I just fixed a bug in 0024 that caused an intermittent crash on New Identity and on exit: https://trac.torproject.org/projects/tor/ticket/8628 So you want to get the latest patch from origin/maint-2.4. There are also some other patch updates that I've made since the last TBB release, but I'm still working on them. > about:cache shows the same regardless of whether the image cache patch > is applied or not; this is explained, I guess, by the Torbrowser > design doc that reads "Additionally, because the image cache is > a separate entity from the content cache, we had to patch Firefox to > also isolate this cache per url bar domain." According to my notes in the original bug (https://trac.torproject.org/projects/tor/ticket/5742), the patch should cause additional domain= entries for each url bar to appear in about:cache. Otherwise I think only one entry appears for a given image, regardless of url bar domains used to load it... However, the patch was first written for Firefox 10. Things may have changed wrt about:cache display since then. You can manually verify that the Google logo image actually loads over the network for all three of these pages: https://encrypted.google.com/ https://anonym-surfen.de/ImageTest.html https://anonymous-proxy-servers.net/en/ImageTest.html If the patch is not working/not applied, the Google image will come from the cache for the second two, and the web developer console should say "304 not modified" in the "Net" logs. For DOM storage, you can try hosting this container page on an additional domain, and verify that the iframe can't retrieve any values set from the original container page from trial.pearlcrescent.com: http://trial.pearlcrescent.com/tor/storageContainer.html > Ideally, I'd like to add this to our automated test suite, but at > least a quick'n'dirty manual check would be much better than nothing > before we merge this branch. What do you use for automated testing of Firefox? I see some pages mentioning something called "Cucumber?" Are you able to inspect the browser state from that framework? -- Mike Perry signature.asc Description: Digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tor Launcher extension [Was: Mike's March 2013]
Thus spake intrigeri (intrig...@boum.org): > Hi Mike and fellow Tails developers, > > Mike Perry wrote (02 Apr 2013 02:55:20 GMT) : > > 5. I helped Pearl Crescent get a bunch of feedback on their Tor Launcher > > extension at the dev meeting and elsewhere. My current estimation is > > that shipping some running code in a TBB-alpha is still more important > > at this point than anything else, given the number of partially > > conflicting usability parameters involved. If you think otherwise, you > > should probably email me now before it's too late. > > We, at Tails, should evaluate if and how this project would fit our > needs. Assuming we replace Vidalia with this extension some day, we > most probably would not want it to launch Tor, but merely control it. > > Mike, > > 1. Any obvious showstopper, off the top of your head, regarding how >the Tor Launcher could be usable for Tails? I think you guys mostly won't use it. My guess is you'd probably just set the env vars $TOR_CONTROL_PORT and $TOR_CONTROL_PASSWD to allow New Identity and simply launch Firefox directly without any form of network configuration in the browser. #8511 might cause you problems if you use a $TOR_SOCKS_PORT env var with a value other than 9151, though. You may want to either add iptables redirect rule for 9151 or add an additional SocksPort line to your torrc rather than messing with TBB's socks port env vars for that reason. Changing the socks port at runtime will cause the issues mentioned in that bug. > 2. Will the "control a system-wide Tor instance, that possibly is >started or restarted after the Torbrowser" usecase be supported? Unlikely, unless you provide us with a $TOR_CONTROL_PASSWD env var (or a COOKIE/SAFECOOKIE auth implementation for Torbutton...) I also want to allow Vidalia to continue to exist as a standalone controller package via either COOKIE or SAFECOOKIE auth mechanisms. This probably means that $TOR_CONTROL_PASSWD will ultimately be deprecated from Tor Browser. If the privsep properties of SAFECOOKIE appeal to you, let me know. Otherwise initial versions will likely support only COOKIE auth at best. > Starting points to look into this: > > * ticket: https://trac.torproject.org/projects/tor/ticket/6009 > * source: https://gitweb.torproject.org/tor-launcher.git Yep, you're in the right place. See also the tor-launcher remotes. The plan for Tor Launcher in TBB-alpha is "maximumly minimalist". If everything works out, you should be able to use Tor Browser without Tor Launcher at all, but you may have to change/replace the start-tor-browser script slightly, and/or tweak some env vars before launching your patched Firefox. -- Mike Perry signature.asc Description: Digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Integration of Tor, Tor Browser, Tor IM, Tor Birdy, Vidalia, Tor Router, Tails, etc.
Thus spake adrelanos (adrela...@riseup.net): > The current [TBB launch] integration has a lot open issues and feature > requests. [2] Wow, even more than I thought! :) > Because there might come a proposal [1] to solve this cleanly, I created > an overview of all related open issues. [2] There are just so many > issues I though it makes sense to create an overview so nothing gets > forgotten. Feel free to edit/correct/expand the wiki site. Add your wishes. > > I cc'ed all effected people, if someone has been forgotten, feel free to > forward this mail. > > Can we have this discussion on tor-dev? I think so. Again, I think the path to max success for you here is to make your own package/collection/tar.gz of launch scripts for different scenarios. That way, you can experiment without getting bogged down by design proposals and formalities for making the TBB itself usable. It might be the case at first that it seems like you're being ignored. Once you have stuff that works, or at least have some kind of plan, I think people will listen/test stuff/make suggestions on tor-dev. Any earlier stages might want the wider input from the tor-talk crowd, though. It's quite possible that Jake's "Zygote-process named-pipe Tor coordinator" can just be an addition to all of this stuff at the end, as a helper process for finding the right Tor socks port. It's also likely that simple python (or even shell) prototypes will work just fine, even if they only just guess at defaults and test them. If you block on env var support in Torbutton, please let me know. Right now I think you can make a lot of progress even as-is. I think #5611 should help you do more, but isn't strickly needed yet? Am I correct there? > [1] https://trac.torproject.org/projects/tor/ticket/5611#comment:43 > [2] https://trac.torproject.org/projects/tor/wiki/doc/TB -- Mike Perry signature.asc Description: Digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [tor-talk] Please review Tails stream isolation plans
Thus spake Robert Ransom (rransom.8...@gmail.com): > On 8/28/12, adrelanos wrote: > > > I really think before you activate IsolateDestAddr/Port for web, Nick's > > or Roger's option is required. > > Nick or Roger would say no. But they are planning to specifically > leave those options disabled for the web browser. (That's what > “enabled by default (but for the web browser)” meant.) Here's the ticket for implementing Tor Browser's use of the circuit isolation feature: https://trac.torproject.org/projects/tor/ticket/3455 Summary: we plan on using some variation of the "url bar isolation" property from https://www.torproject.org/projects/torbrowser/design/#privacy to guide our circuit reuse implementation. So long as the url bar stays the same, we'll use the same circuit for sure. This shouldn't be *too* tricky to do using mozIThirdPartyUtil. I'm still debating if we should *also* try to track user click-nagivation, and use the same circuit so long as the user is clicking on links (as opposed to entering a fresh new value in the URL bar). This could be modeled by tracking the referer, or the last url bar domain to be entered. This will be trickier to implement, but will reduce client circuit creation. Either route will require a patch to Firefox, since it is not possible to set SOCKS usernames+passwords from a .xpi right now. Roger also wants to turn this into a research project of some kind to determine the optimal circuit isolation mechanism network-wide, but that seems like a waste of time to me, since what I'm proposing doesn't strike me as very resource-intensive in the common case. I'm open to suggestions on how to make it less painful, though. -- Mike Perry signature.asc Description: Digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
