Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#10935 closed project (fixed)

Make bundles featuring meek

Reported by: dcf Owned by: dcf
Priority: Medium Milestone:
Component: Obfuscation/meek Version:
Severity: Keywords: meek MikePerry201406R TorBrowserTeam201406
Cc: mcs, brade Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Let's try out some bundles with meek.

Child Tickets

TicketSummaryOwner
#11183Make an HTTP requestor Firefox extension for meek-clientdcf
#12146Firefox meek-http-helper leaks Host header in CONNECT requestsdcf

Attachments (1)

meek-latency-test-a201ed6e-graphonly.png (13.3 KB) - added by dcf 3 years ago.

Download all attachments as: .zip

Change History (35)

comment:1 Changed 3 years ago by dcf

  • Owner changed from asn to dcf
  • Status changed from new to assigned

comment:3 follow-ups: Changed 3 years ago by asn

Bundles were made. As discussed with dcf, a few things remain before we deploy meek to real users:

a) Get some people to review its code
b) Get someone to run a stable/fast meek bridge.
c) Figure out if Tor can pay the Appengine bills.
d) Make its TLS layer less easily fingerpintable.

comment:4 in reply to: ↑ 3 ; follow-up: Changed 3 years ago by dcf

Replying to asn:

d) Make its TLS layer less easily fingerpintable.

This is my thinking on HTTPS fingerprintability and deployment. We should first take care of the trivial fingerprinting issues, namely client ciphersuites and TLS extensions, and then make the first deployment. Those two are the things for which a firewall rule can be written in five minutes. The other issues are things like traffic statistics, which are important but not immediately important in that it takes time to make a classifier and even then it's not 100%.

I'm working on a TBB browser extension to make HTTPS requests on behalf of meek-client. That will get us Firefox's ciphersuites and TLS extensions, and I think is more realistically deployable than, say, packaging another browser in the TBB, and more future-proof than writing a custom OpenSSL or NSS program that closely tries to imitate browser TLS.

Last edited 3 years ago by dcf (previous) (diff)

comment:5 in reply to: ↑ 4 Changed 3 years ago by dcf

Replying to dcf:

I'm working on a TBB browser extension to make HTTPS requests on behalf of meek-client. That will get us Firefox's ciphersuites and TLS extensions, and I think is more realistically deployable than, say, packaging another browser in the TBB, and more future-proof than writing a custom OpenSSL or NSS program that closely tries to imitate browser TLS.

#11183 is the ticket for a browser extension.

comment:6 in reply to: ↑ 3 ; follow-up: Changed 3 years ago by dcf

Replying to asn:

b) Get someone to run a stable/fast meek bridge.

A big consideration here is latency; i.e., proximity to App Engine servers. We're adding an extra roundtrip hop to every communication:

meek-client → App Engine → meek-server

We have no control over the meek-client→App Engine link, but we can try to make the App Engine→meek-server link fast.

Here are sample roundtrip times for a few servers. The test is running live at http://meek-latency-test.appspot.com/. Source code for the test is in the repo here. The horizontal axis is milliseconds.


The measured servers are in order:

  1. my bridge in California (the same one used for flash proxy)
  2. my bridge with HTTPS turned on
  3. a bridge in Greece
  4. a Google server very close to App Engine (lower bound on roundtrip time)
  5. an HTTPS Google server very close to App Engine (lower bound on HTTPS roundtrip time)

I can add other servers if someone wants to test their own.

It appears that the App Engine requests are coming from 8.35.201.0/24 in the U.S. This link seems to confirm that the servers are in the U.S. Ideally we minimize latency with that netblock.

All that said, I've been using the Greek bridge for a while, and it doesn't feel that slow, but maybe I'm just used to it.

Last edited 3 years ago by dcf (previous) (diff)

comment:7 in reply to: ↑ 3 Changed 3 years ago by dcf

Replying to asn:

c) Figure out if Tor can pay the Appengine bills.

Google is currently offering $500 in Cloud Platform credit. (Cloud Platform includes App Engine.) I applied, describing meek, and received a code for $500.

It says the credit expires three months after it is redeemed. My guess is that we'll use up the three months before we use up the $500. So I think to activate the credit just before public deployment. That should keep us running for three months anyway.

comment:8 Changed 3 years ago by dcf

  • Component changed from Pluggable transport to meek

comment:9 Changed 3 years ago by dcf

These bundles use a browser extension for TLS camouflage. We're now very close to where we want to be for a test release. I need to make a rebased merge branch of https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/shortlog/refs/heads/meek and add meek to the tor launcher config (#11488). George said he'd try the bundles and look at the source code.

comment:10 follow-up: Changed 3 years ago by asn

I still have not read the source code.

I tested the linux64 bundle yesterday night. It worked great. I wouldn't even notice the second browser, if I hadn't done a pstree, that looks like this:

     ├─sh───rxvt-unicode─┬─bash───start-tor-brows───firefox─┬─tor───meek-client-tor─┬─firefox─┬─firefox
     │                   │                                  │                       │         ├─{Cache I/O}
     │                   │                                  │                       │         ├─{Cert Verify}
     │                   │                                  │                       │         ├─{DOM Worker}
     │                   │                                  │                       │         ├─{Gecko_IOThread}
     │                   │                                  │                       │         ├─{Hang Monitor}
     │                   │                                  │                       │         ├─{JS GC Helper}
     │                   │                                  │                       │         ├─{JS Sour~ Thread}
     │                   │                                  │                       │         ├─{JS Watchdog}
     │                   │                                  │                       │         ├─{Proxy R~olution}
     │                   │                                  │                       │         ├─{Socket Thread}
     │                   │                                  │                       │         ├─{Timer}
     │                   │                                  │                       │         └─{mozStorage #1}
     │                   │                                  │                       ├─meek-client───5*[{meek-client}]
     │                   │                                  │                       └─4*[{meek-client-tor}]
     │                   │                                  ├─3*[{Analysis Helper}]
     │                   │                                  ├─{Cache I/O}
     │                   │                                  ├─{Cert Verify}
     │                   │                                  ├─2*[{DOM Worker}]
     │                   │                                  ├─{Gecko_IOThread}
     │                   │                                  ├─{HTML5 Parser}
     │                   │                                  ├─{Hang Monitor}
     │                   │                                  ├─{JS GC Helper}
     │                   │                                  ├─{JS Sour~ Thread}
     │                   │                                  ├─{JS Watchdog}
     │                   │                                  ├─{MediaManager}
     │                   │                                  ├─{Proxy R~olution}
     │                   │                                  ├─{RunProcess}
     │                   │                                  ├─{Socket Thread}
     │                   │                                  ├─{Timer}
...

I didn't test with wireshark to see if the SSL looks firefoxy. I need to do that next.

Also, with the meek bundles, on Tor bootstrap I always get the following error:

Apr 12 14:26:46.000 [warn] Received http status code 404 ("Not found") from server '0.0.2.0:1' while fetching "/tor/keys/fp-sk/27B6B5996C426270A5C95488AA5BCEB6BCC86956-510628E039BC57EB78FD5A324E995690C1BDF1CE".

I'm not sure why I would get this error.

comment:11 in reply to: ↑ 10 Changed 3 years ago by asn

I also started reading meek code. meek-server looks good so far (yawning pointed out an interesting behavior wrt timeout in IRC)

comment:12 follow-up: Changed 3 years ago by gk

https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/commitdiff/tbb-3.5.4-meek-1?hp=tbb-3.5.4-build3 looks good. Just one thing: you write

# A PIE build fails on amd64 in cgo tests.

If that is really only an amd64 issue could you then disable the hardening just on that architecture? GBUILD_BITS is your friend here.

comment:13 in reply to: ↑ 12 Changed 3 years ago by dcf

Replying to gk:

https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/commitdiff/tbb-3.5.4-meek-1?hp=tbb-3.5.4-build3 looks good. Just one thing: you write

# A PIE build fails on amd64 in cgo tests.

If that is really only an amd64 issue could you then disable the hardening just on that architecture? GBUILD_BITS is your friend here.

I tried it again without disabling DEB_BUILD_HARDENING_PIE, and didn't get an error. I'm going to test some bundles that don't touch DEB_BUILD_HARDENING_PIE at all.

In any case, I don't think PIE is going to buy us anything with golang executables.
https://code.google.com/p/go/issues/detail?id=6940#c6: "The Go linker does not currently support building objects that may be linked into a PIE."

comment:14 follow-up: Changed 3 years ago by dcf

  • Status changed from assigned to needs_review

3.6.1-meek-1 bundles:

The big change in this version is that meek is no longer activated by default; you have to configure it like any other transport (as shown at doc/meek#Quickstart).

I also prepared a parallel rebased merge candidate branch. It has just 8 commits on top of tbb-3.6.1-build1. The second link shows all the changes made in the branch.

comment:15 Changed 3 years ago by dcf

The question came up of how much meek increases the size of the bundles. I compared 3.6.1-meek-1 with 3.6.1 and the summary is:

  • 1.7 MB increase in linux xz (29 MB to 31 MB)
  • 1.9 MB increase in windows exe (26 MB to 28 MB)
  • 2.4 MB increase in mac dmg (31 MB to 33 MB)

The increase is almost entirely caused by new executables: the size of the extra Firefox profile and extension, documentation, etc. is negligible.

Here's a list of all the added files in the linux bundle with their sizes:

967  ./Data/Browser/profile.meek-http-helper/user.js
2.9K ./Docs/meek/README
3.0K ./Docs/meek/meek-server.1
4.1K ./Docs/meek/meek-client.1
5.5K ./Data/Browser/profile.meek-http-helper/extensions/meek-http-helper@bamsoftware.com.xpi
6.9K ./Docs/PluggableTransports/LICENSE.CC0
3.5M ./Tor/PluggableTransports/meek-client-torbrowser
7.6M ./Tor/PluggableTransports/meek-client

Clearly the two programs meek-client-torbrowser and meek-client are the only files that matter. On disk they are 11.2 MB together. When I compress them with xz, they take up 1.7 MB.

1.7M t.tar.xz

The large size of the binaries is caused by static linking by the golang compiler. I don't think we want to try to circumvent Go's preference for static linking (see e.g. http://harmful.cat-v.org/software/dynamic-linking/); compression seems to get rid of most of the redundancy anyway. The large executable sizes are a known problem; see issue 6853: binaries too big and growing and Go Binary Sizes Are Growing out of Control. It's supposed to be better in the upcoming Go 1.3 (we're using Go 1.2). I tried compiling with a 1.3 beta and it does save some bytes, though compression makes it not matter much:
With Go 1.2:

3.5M ./Tor/PluggableTransports/meek-client-torbrowser
7.6M ./Tor/PluggableTransports/meek-client
----
1.7M t.tar.xz

With Go 1.3:

2.8M ./Tor/PluggableTransports/meek-client-torbrowser
6.0M ./Tor/PluggableTransports/meek-client
----
1.6M t.tar.xz

Appendix

For the record, here are the exact bundle sizes of 3.6.1 and 3.6.1-meek-1:

30021204 tor-browser-linux64-3.6.1_en-US.tar.xz
31790408 tor-browser-linux64-3.6.1-meek-1_en-US.tar.xz
26949533 torbrowser-install-3.6.1_en-US.exe
28954030 torbrowser-install-3.6.1-meek-1_en-US.exe
31522646 TorBrowser-3.6.1-osx32_en-US.dmg
34053808 TorBrowser-3.6.1-meek-1-osx32_en-US.dmg

Here are the added files and their sizes for windows (missing doc files are #11834). The extra terminateprocess-buffer.exe program is a special program required only on windows. I derived this output from diff -u <(cd 3.6.1/windows && find . -type f -print0 | xargs -0 ls -lh) <(cd 3.6.1-meek-1/windows && find . -type f -print0 | xargs -0 ls -lh).

967  ./$_OUTDIR/Data/Browser/profile.meek-http-helper/user.js
5.5K ./$_OUTDIR/Data/Browser/profile.meek-http-helper/extensions/meek-http-helper@bamsoftware.com.xpi
6.9K ./$_OUTDIR/Docs/PluggableTransports/LICENSE.CC0
2.2M ./$_OUTDIR/Tor/PluggableTransports/terminateprocess-buffer.exe
2.7M ./$_OUTDIR/Tor/PluggableTransports/meek-client-torbrowser.exe
5.8M ./$_OUTDIR/Tor/PluggableTransports/meek-client.exe

Again compression of the executables accounts for essentially all the difference in bundle sizes.

2.2M ./$_OUTDIR/Tor/PluggableTransports/terminateprocess-buffer.exe
2.7M ./$_OUTDIR/Tor/PluggableTransports/meek-client-torbrowser.exe
5.8M ./$_OUTDIR/Tor/PluggableTransports/meek-client.exe
----
1.8M t.7z

Here are the added files and their sizes for mac (missing doc files are 9d611fde).

967  ./TorBrowser.app/Data/Browser/profile.meek-http-helper/user.js
5.5K ./TorBrowser.app/Data/Browser/profile.meek-http-helper/extensions/meek-http-helper@bamsoftware.com.xpi
6.9K ./TorBrowser.app/Docs/PluggableTransports/LICENSE.CC0
2.8M ./TorBrowser.app/Tor/PluggableTransports/meek-client-torbrowser
6.2M ./TorBrowser.app/Tor/PluggableTransports/meek-client

The bz2 compression of the dmg container doesn't save as much in this case.

2.8M ./TorBrowser.app/Tor/PluggableTransports/meek-client-torbrowser
6.2M ./TorBrowser.app/Tor/PluggableTransports/meek-client
----
2.5M t.tar.bz2

comment:16 in reply to: ↑ 14 ; follow-up: Changed 3 years ago by gk

Replying to dcf:

I also prepared a parallel rebased merge candidate branch. It has just 8 commits on top of tbb-3.6.1-build1. The second link shows all the changes made in the branch.

This looks good to me. Bonus points if you could get rid of these sudo calls (might be a matter of setting $PATH properly). I am currently refactoring the descriptors and getting everything to work without the need for special privileges while building is one (albeit very minor) goal.

comment:17 Changed 3 years ago by dcf

3.6.1-meek-2 bundles:

The only change is a fix for #11429, so you no longer get a second dock icon on mac.

I'll do another rebase on 3.6.2 when that's released, hopefully also including the proxy stuff from #12120.

comment:18 in reply to: ↑ 16 Changed 3 years ago by dcf

Replying to gk:

Replying to dcf:

I also prepared a parallel rebased merge candidate branch. It has just 8 commits on top of tbb-3.6.1-build1. The second link shows all the changes made in the branch.

This looks good to me. Bonus points if you could get rid of these sudo calls (might be a matter of setting $PATH properly). I am currently refactoring the descriptors and getting everything to work without the need for special privileges while building is one (albeit very minor) goal.

I got rid of sudo in cc40318a2268e3d8b4ad80002445465e76472a5c.

comment:19 follow-up: Changed 3 years ago by dcf

  • Keywords MikePerry201406R added

3.6.2-meek-1:

They are built not exactly on top of the 3.6.2 bundles, because I merged with the tag tbb-3.6.2-build5 and the 3.6.2 bundles were apparently built with what is now the head of maint-3.6.

I also have a rebased branch, which I propose for merge:

The main noteworthy change since the last rebase branch is the addition of a shallow copy of TorBrowser.app with a modified Info.plist file. The reason for it is in #11429; it's to prevent two icons from appearing on OS X. I tried an alternative idea, hiding the icons with js-ctypes from the extension itself, but it creates a race between the dock trying to show the icon and the extension trying to hide it.

I know that #11641 changes the directory structure, which will probably affect the Info.plist thing. Would you like me to rebase somewhere onto master, rather than the maint-3.6 branch?

comment:20 follow-up: Changed 3 years ago by gk

You want to add the verification of GO as well in the verify-tags.sh script (as you did in the fetch-inputs.sh script).

Did you test with a different Gitian setup to check whether building meek is still reproducible?

comment:21 in reply to: ↑ 20 Changed 3 years ago by dcf

Replying to gk:

You want to add the verification of GO as well in the verify-tags.sh script (as you did in the fetch-inputs.sh script).

Thanks, I missed that. Done in 23085a6b37bb0c1887223e7f5ddef458a18ba613.

Did you test with a different Gitian setup to check whether building meek is still reproducible?

I tried building it again, and ran into the trouble in #12382. However the packages are the same except for the changed langpack files. The en-US packages are identical.

comment:22 in reply to: ↑ 19 ; follow-up: Changed 3 years ago by gk

Replying to dcf:

I know that #11641 changes the directory structure, which will probably affect the Info.plist thing. Would you like me to rebase somewhere onto master, rather than the maint-3.6 branch?

Yes, please. We plan to release a 4.0 alpha which could contain meek to give it a wider testing (and test its reproducibility under release conditions).

comment:23 in reply to: ↑ 22 Changed 3 years ago by dcf

Replying to gk:

Replying to dcf:

I know that #11641 changes the directory structure, which will probably affect the Info.plist thing. Would you like me to rebase somewhere onto master, rather than the maint-3.6 branch?

Yes, please. We plan to release a 4.0 alpha which could contain meek to give it a wider testing (and test its reproducibility under release conditions).

I started the rebase, but the build hasn't finished, and now I won't be able to finish it until June 19. Please stand by.

comment:24 Changed 3 years ago by dcf

Replying to gk:

Yes, please. We plan to release a 4.0 alpha which could contain meek to give it a wider testing (and test its reproducibility under release conditions).

I tested it and made sure it would bootstrap with meek on all platforms.

I put the second headless app (#11429) under TorBrowser/Data/TorBrowser.app.meek-http-helper. It has symlinks to the top-level Contents files, and modified Info.plist.

Here's a summary of added files on every platform.

linux32/64:

+Browser/TorBrowser/Data/Browser/profile.meek-http-helper/extensions/meek-http-helper@bamsoftware.com.xpi
+Browser/TorBrowser/Data/Browser/profile.meek-http-helper/user.js
+Browser/TorBrowser/Docs/Licenses/PluggableTransports/LICENSE.CC0
+Browser/TorBrowser/Docs/meek/meek-client.1
+Browser/TorBrowser/Docs/meek/meek-server.1
+Browser/TorBrowser/Docs/meek/README
+Browser/TorBrowser/Tor/PluggableTransports/meek-client
+Browser/TorBrowser/Tor/PluggableTransports/meek-client-torbrowser

windows:

+Browser/TorBrowser/Data/Browser/profile.meek-http-helper/extensions/meek-http-helper@bamsoftware.com.xpi
+Browser/TorBrowser/Data/Browser/profile.meek-http-helper/user.js
+Browser/TorBrowser/Docs/Licenses/PluggableTransports/LICENSE.CC0
+Browser/TorBrowser/Docs/meek/meek-client.1.txt
+Browser/TorBrowser/Docs/meek/meek-server.1.txt
+Browser/TorBrowser/Docs/meek/README
+Browser/TorBrowser/Tor/PluggableTransports/meek-client.exe
+Browser/TorBrowser/Tor/PluggableTransports/meek-client-torbrowser.exe
+Browser/TorBrowser/Tor/PluggableTransports/terminateprocess-buffer.exe

mac:

+Docs/meek
+Docs/meek/meek-client.1
+Docs/meek/meek-server.1
+Docs/meek/README
+TorBrowser/Data/Browser/profile.meek-http-helper/extensions/meek-http-helper@bamsoftware.com.xpi
+TorBrowser/Data/Browser/profile.meek-http-helper/user.js
+TorBrowser/Data/TorBrowser.app.meek-http-helper/Contents/Info.plist
+TorBrowser/Data/TorBrowser.app.meek-http-helper/Contents/MacOS
+TorBrowser/Data/TorBrowser.app.meek-http-helper/Contents/PkgInfo
+TorBrowser/Data/TorBrowser.app.meek-http-helper/Contents/Resources
+TorBrowser/Data/TorBrowser.app.meek-http-helper/README
+TorBrowser/Docs/Licenses/PluggableTransports/LICENSE.CC0
+TorBrowser/Tor/PluggableTransports/meek-client
+TorBrowser/Tor/PluggableTransports/meek-client-torbrowser

comment:25 follow-ups: Changed 3 years ago by gk

  • Cc mcs brade added

This looks good to me. The only thing I am not sure is wrt the location for the headless app and the placement of Docs/meek in the OS X case. Let's see what Kathy/Mark are saying. Kathy/Mark: Could you comment on those things? Does there something speak against the current idea? If so, what would be a better place?

comment:26 in reply to: ↑ 25 Changed 3 years ago by dcf

Replying to gk:

This looks good to me. The only thing I am not sure is wrt the location for the headless app and the placement of Docs/meek in the OS X case. Let's see what Kathy/Mark are saying. Kathy/Mark: Could you comment on those things? Does there something speak against the current idea? If so, what would be a better place?

I didn't even notice the wrong placement of the meek docs. That's a bug. I'll put it under TorBrowser/Docs like in the other cases.

comment:27 Changed 3 years ago by dcf

Take 2, with mac docs in the right place.

Difference from previous branch:

The mac file diff is now

+TorBrowser/Data/Browser/profile.meek-http-helper/extensions/meek-http-helper@bamsoftware.com.xpi
+TorBrowser/Data/Browser/profile.meek-http-helper/user.js
+TorBrowser/Data/TorBrowser.app.meek-http-helper/Contents/Info.plist
+TorBrowser/Data/TorBrowser.app.meek-http-helper/Contents/MacOS
+TorBrowser/Data/TorBrowser.app.meek-http-helper/Contents/PkgInfo
+TorBrowser/Data/TorBrowser.app.meek-http-helper/Contents/Resources
+TorBrowser/Data/TorBrowser.app.meek-http-helper/README
+TorBrowser/Docs/Licenses/PluggableTransports/LICENSE.CC0
+TorBrowser/Docs/meek
+TorBrowser/Docs/meek/meek-client.1
+TorBrowser/Docs/meek/meek-server.1
+TorBrowser/Docs/meek/README
+TorBrowser/Tor/PluggableTransports/meek-client
+TorBrowser/Tor/PluggableTransports/meek-client-torbrowser

comment:28 in reply to: ↑ 25 ; follow-up: Changed 3 years ago by mcs

Replying to gk:

This looks good to me. The only thing I am not sure is wrt the location for the headless app and the placement of Docs/meek in the OS X case. Let's see what Kathy/Mark are saying. Kathy/Mark: Could you comment on those things? Does there something speak against the current idea? If so, what would be a better place?

I discussed this with Kathy. It seems a little odd to place an application bundle (even a symlink'd one) under TorBrowser/Data. Maybe move it under TorBrowser/Tor/PluggableTransports/ ?

Also, maybe it is intentional or maybe not that the bundle does not end in .app, but we would have expected to see a name like TorBrowser-meek-http-helper.app. Apparently things work either way though.

The other issue that we will need to research is whether the Firefox updater (#4234) can handle symlinks. My guess is that it cannot but maybe we will be pleasantly surprised ;) I think we have to proceed with the symlinks for now in the interest of getting the alpha out.

comment:29 in reply to: ↑ 28 ; follow-up: Changed 3 years ago by dcf

Replying to mcs:

Replying to gk:

This looks good to me. The only thing I am not sure is wrt the location for the headless app and the placement of Docs/meek in the OS X case. Let's see what Kathy/Mark are saying. Kathy/Mark: Could you comment on those things? Does there something speak against the current idea? If so, what would be a better place?

I discussed this with Kathy. It seems a little odd to place an application bundle (even a symlink'd one) under TorBrowser/Data. Maybe move it under TorBrowser/Tor/PluggableTransports/ ?

Also, maybe it is intentional or maybe not that the bundle does not end in .app, but we would have expected to see a name like TorBrowser-meek-http-helper.app. Apparently things work either way though.

I avoided ending the file name with ".app" to reduce the likelihood that a curious user would launch the internal bundle by double-clicking. The internal bundle is necessarily configured to bypass the Tor proxy, so it's dangerous if it's confused with the actual Tor Browser. The naming trick worked when it was under TorBrowser/Data (the app appeared as a normal folder), but for some reason it doesn't work under TorBrowser/Tor/PluggableTransports :/ When you double-click the icon, first you get a dialog offering to import your bookmarks, then you get a browser window with the normal Firefox branding. You can't type into it, nor does it appear in the dock, probably because of the LSBackgroundOnly setting.

comment:30 in reply to: ↑ 29 Changed 3 years ago by mcs

Replying to dcf:

I avoided ending the file name with ".app" to reduce the likelihood that a curious user would launch the internal bundle by double-clicking. The internal bundle is necessarily configured to bypass the Tor proxy, so it's dangerous if it's confused with the actual Tor Browser. The naming trick worked when it was under TorBrowser/Data (the app appeared as a normal folder), but for some reason it doesn't work under TorBrowser/Tor/PluggableTransports :/ When you double-click the icon, first you get a dialog offering to import your bookmarks, then you get a browser window with the normal Firefox branding. You can't type into it, nor does it appear in the dock, probably because of the LSBackgroundOnly setting.

Almost certainly the app copy does not know where to find its browser profile. I think you have a reasonable point about not wanting users to be tempted to open the app, so not ending in .app makes sense.

comment:31 Changed 3 years ago by mikeperry

  • Keywords TorBrowserTeam201406 added

comment:32 Changed 3 years ago by gk

  • Resolution set to fixed
  • Status changed from needs_review to closed

Squashed and merged in commit d97e4bf2c0711bcd9683c1c0f89dd22ffa89b8ad. We should get alpha bundles out this week including meek.

comment:33 in reply to: ↑ 6 Changed 3 years ago by dcf

Replying to dcf:

It appears that the App Engine requests are coming from 8.35.201.0/24 in the U.S. This link seems to confirm that the servers are in the U.S. Ideally we minimize latency with that netblock.

Here's the official way to get the App Engine IPs:

Currently:

$ nslookup -q=TXT _cloud-netblocks.googleusercontent.com 8.8.8.8
_cloud-netblocks.googleusercontent.com  text = "v=spf1 include:_cloud-netblocks1.googleusercontent.com include:_cloud-netblocks2.googleusercontent.com include:_cloud-netblocks3.googleusercontent.com ?all"
$ nslookup -q=TXT _cloud-netblocks1.googleusercontent.com 8.8.8.8
_cloud-netblocks1.googleusercontent.com text = "v=spf1 ip4:8.34.208.0/20 ip4:8.35.192.0/21 ip4:8.35.200.0/23 ip4:108.59.80.0/20 ip4:108.170.192.0/20 ip4:108.170.208.0/21 ip4:108.170.216.0/22 ip4:108.170.220.0/23 ip4:108.170.222.0/24 ?all"
$ nslookup -q=TXT _cloud-netblocks2.googleusercontent.com 8.8.8.8
_cloud-netblocks2.googleusercontent.com text = "v=spf1 ip4:162.216.148.0/22 ip4:162.222.176.0/21 ip4:173.255.112.0/20 ip4:192.158.28.0/22 ip4:199.192.112.0/22 ip4:199.223.232.0/22 ip4:199.223.236.0/23 ip4:23.236.48.0/20 ip4:23.251.128.0/19 ?all"
$ nslookup -q=TXT _cloud-netblocks3.googleusercontent.com 8.8.8.8
_cloud-netblocks3.googleusercontent.com text = "v=spf1 ip4:107.167.160.0/19 ip4:107.178.192.0/18 ip4:146.148.2.0/23 ip4:146.148.4.0/22 ip4:146.148.8.0/21 ip4:146.148.16.0/20 ip4:146.148.32.0/19 ip4:146.148.64.0/18 ip4:130.211.4.0/22 ?all"
  • 8.34.208.0/20
  • 8.35.192.0/21
  • 8.35.200.0/23
  • 108.59.80.0/20
  • 108.170.192.0/20
  • 108.170.208.0/21
  • 108.170.216.0/22
  • 108.170.220.0/23
  • 108.170.222.0/24
  • 162.216.148.0/22
  • 162.222.176.0/21
  • 173.255.112.0/20
  • 192.158.28.0/22
  • 199.192.112.0/22
  • 199.223.232.0/22
  • 199.223.236.0/23
  • 23.236.48.0/20
  • 23.251.128.0/19
  • 107.167.160.0/19
  • 107.178.192.0/18
  • 146.148.2.0/23
  • 146.148.4.0/22
  • 146.148.8.0/21
  • 146.148.16.0/20
  • 146.148.32.0/19
  • 146.148.64.0/18
  • 130.211.4.0/22
Note: See TracTickets for help on using tickets.