Re: [tor-talk] Problems with setting up of hidden service

[cmeclax-sazri]

On Thursday 04 August 2011 23:53:12 Orionjur Tor-admin wrote:
> Sorry for the off-top, what soft do you use for torchat?

soft ki'a?
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Reason Firefox version in TBB is so far behind?

[Joe Btfsplk]

On 8/2/2011 7:41 PM, Joe Btfsplk wrote:

On 8/2/2011 7:10 PM, Andrew Lewman wrote:

On Tuesday, August 02, 2011 19:55:48 Joe Btfsplk wrote:

Are there specific reasons for not using latest (or late-er) Firefox
versions in Tor Browser Bundle?  Is it primarily because the latest
version doesn't always work w/ Tor&  fixes must be developed for Tor to
deal w/ that?
It's the latest udpated Firefox 3.6 branch.  FF4 branch has been 
killed and

replaced with 5.  We have FF5 testing bundles. See
https://blog.torproject.org/blog/new-tor-browser-bundles-3.
Thanks.  I realize the latest stable TBB has FF 3.6.  Is the reason 
for delay in updating to latest FF version always for testing - to see 
if Tor works properly?
Firefox versions used in stable TBB have always run behind the latest 
FF release - sometimes several versions.  This may well be unavoidable 
for TBB developers.  My original question - how does this affect the 
security of TBB users?

___

No comments on security implications of using a Firefox version in TBB, 
that isn't up to date with security fixes (sometimes not even close)?
I'm grateful for the work done to create TBB, but the mantra of security 
experts has always been, "ALWAYS keep your browser / OS updated w/ 
security patches."


As said, it may be unavoidable (currently) for TBB developers to 
integrate new FF versions quickly, but surely I'm not the 1st to wonder 
about security issues of using old browser versions.
The testing bundles Andrew mentioned are fine for, well... testing, but 
not for general users.  It's a long way & many fixes, from Firefox 3.6 
to 5.0 / 5.0.1.

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] [GSoC] Metadata Anonymisation Toolkit

[jvoisin]

Hello,
the end of the GSoC is near, and I think I have almost achieved my
objectives (except for zip files, but I'm working on a patch). My project is
also meant to run well on Tails; dependencies are python-core and
python-parser; optionals dependencies are python-mutagen for more audio
format support, and python-poppler and python-cairo for pdf support.

I need some testing/usability comments of my project.

documentation :
https://gitweb.torproject.org/user/jvoisin/mat.git/blob/HEAD:/README
blog : http://mat-tor.blogspot.com/
repo : https://gitweb.torproject.org/user/jvoisin/mat.git

Thank you, and have a nice day !
-- 

VOISIN Julien
| pgp key : C48815F2

| dustri.org
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] New Tool Keeps Censors in the Dark - mentions Tor.

[Martin Fick]

--- On Fri, 8/5/11, berta...@ptitcanardnoir.org  
wrote:

> >   http://www.technologyreview.com/communications/38207/?p1=A1
> > >>>It's worth reading the paper:

I think that simply getting high profile sites to run to r
nodes would be more likely and less invasive to the internet 
as a whole.  If google were to simply run a bunch of 
bridges, or even known tor entry nodes, that would likely
be more reliable and be less pie in the sky.

If you compare the advocacy it would take to get enough 
ISPs to implement this scheme versus the advocacy to get
a few high profile (can't live without them) sites to run
tor nodes, I suspect the latter would be much easier.

-Martin

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] New Tool Keeps Censors in the Dark - mentions Tor.

[Joe Btfsplk]

On 8/5/2011 3:37 PM, berta...@ptitcanardnoir.org wrote:

On Fri, Aug 05, 2011 at 03:13:07PM -0500, Joe Btfsplk wrote:
I think their concept is that the "friendly" ISPs will not know the 
true destination, therefore would not be complicit in allowing users 
to access forbidden sites. Apparently, after passing through the ISP 
to the "apparent" destination, Telex diverts the traffic to the 
"real" destination, based on tags inserted into the request on user's 
computer. In concept.

"We envision that friendly ISPs would deploy Telex stations on
paths between censors’ networks and popular, uncensored Internet
destinations. Telex stations would monitor seemingly innocuous
flows for a special “tag” and transparently divert them to a
forbidden website or service instead."

Yes, I'm aware of that, I was just saying that "friendly ISP" isn't an
easy and so obvious concept to me. :)

bert.
___
Nor for I.  I may be way off, but perhaps they should have used the term 
"unwitting ISPs," vs friendly.  Workable or not, their concept seems to 
be that friendly ISPs are any that would rout users' traffic to *any* 
allowed (non forbidden) site / service.  If I understood, a friendly ISP 
would think the Telex user was going to Disney.com, but after passing 
the ISP, on the way to Disney, Telex diverts the traffic to "Death To 
(your dictator's name here).com" - the Telex user's real destination.  
It is a variation on how Tor works.  The ISP only sees you're connecting 
to a Tor node.


I don't pretend to be an expert on Telex - just the opposite.  But, it 
seems their concept is similar, except w/ Telex, the ISP thinks you're 
going to an acceptable site, like "Long Live (your dictator's name 
here).com", but after leaving the ISP, the traffic is diverted to 
another site, of which the ISP is unaware.

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Pirate Linux]

[Peter Tonoli]

Hi There,

AK wrote:

Sorry forgot to answer your first question.

The sources are mostly taken from already quite trusted sources and 
can be verified by PGP signatures. You can also read the sources and 
since they get compiled on your computer, you know that what you read 
is what you get. Also, other people can read the sources and give 
reviews and you will know that those reviews actually correspond to 
what is running on your system.
Sorry - not trying to be too critical here, but them sounds like weasel 
words - 'mostly taken' and 'can be'. Without having *all* source 
verified by cryptographic signatures or otherwise, you're probably 
increasing the chances of rogue code running, rather than mitigating it 
with binaries.


Reviews take too long - by the time a 'negative' review is out - it's 
too late, there will be systems that are running compromised code.


My first suggestion - all source / binaries being cryptographically 
verified.


P.


___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk