Re: [tor-talk] "recently-used.xbel" file in TBB directory, stores data on accessed, downloaded files
On Mon, Sep 18, 2017 at 01:34:49PM -0500, Joe Btfsplk wrote: > Why is there a *"recently-used.xbel"*, file in my Tor Browser installation > directory - in path shown and labeled as file TYPE: "XBEL bookmarks" > recording ACTUAL local file names, dates, times - they were accessed AND > some DOWNLOADED files (like *.pdf) with dates and times? > ~/.torbrowser/torbrowser-7.0/tor-browser_en-US/Browser/.local/share/recently-used.xbel. > *TBB is installed in home directory: ~/.torbrowser.* I asked Georg about this, and he pointed to this ticket: https://bugs.torproject.org/8706 So yes, it looks like it's a real issue, and people should probably help make progress on the ticket. Thanks, --Roger -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] "recently-used.xbel" file in TBB directory, stores data on accessed, downloaded files
This involves *at least* Linux (Mint 18.1) Tor Browser 7.04 and 7.05, over at least a couple months. This seems like a huge privacy / anonymity issue. Why is there a *"recently-used.xbel"*, file in my Tor Browser installation directory - in path shown and labeled as file TYPE: "XBEL bookmarks" recording ACTUAL local file names, dates, times - they were accessed AND some DOWNLOADED files (like *.pdf) with dates and times? ~/.torbrowser/torbrowser-7.0/tor-browser_en-US/Browser/.local/share/recently-used.xbel. *TBB is installed in home directory: ~/.torbrowser.* For instance, Listed is a downloaded *pdf file, about health issues* and many others. All dates shown in THIS instance of recently-used.xbel seem to be in July and Aug, 2017, but I used the same TBB installation before and after the dates shown in recently-used.xbel . In Linux, there's also a ~/.local/share/recently-used.xbel file - by default, but it is set asimmutable, so nothing written to it. The TBB recently-used.xbel file even shows date and time I downloaded TBB 7.0.4, and a random 6 digit string added after the "visited" time, with 'Z" at the end, such as (I removed actual times & 6 digit string: href="~/Downloads/security/tor/tbb7.0.4/tor-browser-linux64-7.0.4_en-US.tar.xz" added="2017-08-ddThh:mm:ssZ" modified="2017-08-ddThh:mm:ssZ" visited="2017-08-ddThh:mm:ss.123456Z"> Each file record shown in "recently-used.xbel" show this: modified="Z" visited="Z"> http://freedesktop.org;> Also, are files in the path below, with .bin or .toc extensions: ~/.torbrowser/torbrowser-7.0/tor-browser_en-US/Browser/.nv/GLCache//***1af.bin (very long, random strings, I removed) ~/.torbrowser/torbrowser-7.0/tor-browser_en-US/Browser/.nv/GLCache///***1af.toc These .bin and .toc files seem ? related to my Nvidia GPU or drivers? Not sure what's in them. The same type files are written to the ~/.nv folder, but I don't see why they're written to a Tor Browser folder. I don't know the meaning of "bookmark" in this context - in the TBB recently-used.xbel file. Tor Browser is supposed to delete / not store any data to disk after it's closed (or not write to disk at all). -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] New alpha release: 0.3.2.1-alpha (and new release series too!)
Hi, everybody!
After lots of work, we've got a tasty new alpha ready for you to find
bugs in! Because it's an alpha, you should only run it if you're
ready to find more bugs than usual, and report them on
trac.torproject.org.
The source code is available from the usual place on
www.torproject.org ; if you build Tor from source, why not give it a
try? And if you don't build Tor from source, packages should be ready
over the coming days, with a Tor Browser alpha release likely by the
end of the month.
(There were also new stable releases today, but they get announced on
the nice low-volume tor-announcements mailing list.)
If everything goes well, we're hoping to get this release series
stabilized by mid-December.
Here's what's new!
Changes in version 0.3.2.1-alpha - 2017-09-18
Tor 0.3.2.1-alpha is the first release in the 0.3.2.x series. It
includes support for our next-generation ("v3") onion service
protocol, and adds a new circuit scheduler for more responsive
forwarding decisions from relays. There are also numerous other small
features and bugfixes here.
Below are the changes since Tor 0.3.1.7.
o Major feature (scheduler, channel):
- Tor now uses new schedulers to decide which circuits should
deliver cells first, in order to improve congestion at relays. The
first type is called "KIST" ("Kernel Informed Socket Transport"),
and is only available on Linux-like systems: it uses feedback from
the kernel to prevent the kernel's TCP buffers from growing too
full. The second new scheduler type is called "KISTLite": it
behaves the same as KIST, but runs on systems without kernel
support for inspecting TCP implementation details. The old
scheduler is still available, under the name "Vanilla". To change
the default scheduler preference order, use the new "Schedulers"
option. (The default preference order is "KIST,KISTLite,Vanilla".)
Matt Traudt implemented KIST, based on research by Rob Jansen,
John Geddes, Christ Wacek, Micah Sherr, and Paul Syverson. For
more information, see the design paper at
http://www.robgjansen.com/publications/kist-sec2014.pdf and the
followup implementation paper at https://arxiv.org/abs/1709.01044.
Closes ticket 12541.
o Major features (next-generation onion services):
- Tor now supports the next-generation onion services protocol for
clients and services! As part of this release, the core of
proposal 224 has been implemented and is available for
experimentation and testing by our users. This newer version of
onion services ("v3") features many improvements over the legacy
system, including:
a) Better crypto (replaced SHA1/DH/RSA1024
with SHA3/ed25519/curve25519)
b) Improved directory protocol, leaking much less information to
directory servers.
c) Improved directory protocol, with smaller surface for
targeted attacks.
d) Better onion address security against impersonation.
e) More extensible introduction/rendezvous protocol.
f) A cleaner and more modular codebase.
You can identify a next-generation onion address by its length:
they are 56 characters long, as in
"4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad.onion".
In the future, we will release more options and features for v3
onion services, but we first need a testing period, so that the
current codebase matures and becomes more robust. Planned features
include: offline keys, advanced client authorization, improved
guard algorithms, and statistics. For full details, see
proposal 224.
Legacy ("v2") onion services will still work for the foreseeable
future, and will remain the default until this new codebase gets
tested and hardened. Service operators who want to experiment with
the new system can use the 'HiddenServiceVersion 3' torrc
directive along with the regular onion service configuration
options. We will publish a blog post about this new feature
soon! Enjoy!
o Major bugfixes (usability, control port):
- Report trusted clock skew indications as bootstrap errors, so
controllers can more easily alert users when their clocks are
wrong. Fixes bug 23506; bugfix on 0.1.2.6-alpha.
o Minor features (bug detection):
- Log a warning message with a stack trace for any attempt to call
get_options() during option validation. This pattern has caused
subtle bugs in the past. Closes ticket 22281.
o Minor features (client):
- You can now use Tor as a tunneled HTTP proxy: use the new
HTTPTunnelPort option to open a port that accepts HTTP CONNECT
requests. Closes ticket 22407.
- Add an extra check to make sure that we always use the newer guard
selection code for picking our guards. Closes ticket 22779.
- When downloading (micro)descriptors, don't
Re: [tor-talk] can't connect data bases and scientific journals
On Fri, 2017-09-15 at 16:24 -0400, Benjamin Sullivan wrote: > I have breaking news that involves years of torture, abuse, cohercion, multiple attempts at my life by the CIA, CSIS, and the intelligence community. It involves a botched CIA operation in Russia, the theft of trillions of dollars of intellectual property, and the prevention of recognition for my discoveries (world changing Physics) and said intellectual property. I am in fear for my life and have been for years and an incompetent FBI has done nothing. All legitimate facets of democracy have been reached repeatedly without success (complete manipulation). > > I need your help! I need this published and reported immediately. My life and my families lives depend on it. I have attached the keystone document and I have put all of the substantiating information on a website (a former business website that I have abolished): www.reculuxury.com > > Help my Family and Me! > > Benjamin Allen Sullivan > c...@basrc.biz > WWW.BASRC.Biz > > Hmm. So, you single-handedly solved that pesky Unification problem! Usually, people submit that sort of thing to a good science journal, and it's peer reviewed, and if it's sensible in the perspective of the reviewers (who are accredited in the applicable fields), things move forward from there. I did not see anything like that, but did see this - http://christianchat.com/new-christian-chat-members-introduce-yourselves/156555-csis-murdering-ring-cia-operation-russia.html (banned user) http://www.scienceforums.net/topic/94483-unification-theory-postulates-and-thought-experiments/ (thread closed by moderator) Tor-talk is a mailing list specific to Tor. Maybe this is not the best mailing list for what you need. I found some forums that might be useful, I could send them to you off-list if you like. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Advisory: Stack disclosure in hidden services logs when SafeLogging disabled
[TROVE-2017-008. CVE-2017-0380. Severity: medium] Hello! We have found a possible problem with the code that reports an error during the construction of an introduction point circuit. Because of this bug, it is possible that some hidden services will sometimes write sensitive information into their logs. This bug can only happen when the SafeLogging option is disabled, and SafeLogging is enabled by default. If you have not disabled SafeLogging, then you should be fine. We are tracking this bug as TROVE-2017-008 and as ticket #23490. It is also CVE-2017-0380. MITIGATION: 1. If you are not running a hidden service, then you don't need to do anything. This bug does not affect you. 2. If you are running 0.2.5.x, this bug does not affect you: it first appeared in 0.2.7.2-alpha. Other bugs do affect you, though: 0.2.5.x is pretty old! (If you are running 0.2.4, or 0.2.6, or 0.2.7, you should just upgrade. We aren't supporting those releases.) 3. Make sure that you did not change the value of the SafeLogging option in your configuration -- or if you did, that you set it to "1". SafeLogging needs to be turned to "0" or "relay" for this bug to occur. 4. If you did disable SafeLogging, re-enable it: Set it to 1, and use a HUP signal to tell Tor to reload its configuration. 5. If you did disable SafeLogging, you should delete any old logs that were generated with SafeLogging disabled. (You should be regularly removing old logs anyway, as a best security practice.) ACKNOWLEDGMENTS: We found this when we re-added scan-build's dead assignment checker into the checkers that we run on Tor. Obviously, it's time to make sure that scan-build gets run more frequently. FIX: There are patches for this issue linked from ticket #23490 on our bugtracker. I will be putting out updated releases today. This bug will be fixed in 0.2.8.15, 0.2.9.12, 0.3.0.11, 0.3.1.7, and 0.3.2.1-alpha. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
