Re: [tor-bugs] #7085 [Tor bundles/installation]: Integrate Cryptocat Browser Extension into Tor Browser Bundle

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#7085: Integrate Cryptocat Browser Extension into Tor Browser Bundle
--------------------------------------+-------------------------------------
 Reporter:  kaepora                   |          Owner:  erinn                        
     Type:  enhancement               |         Status:  new                          
 Priority:  normal                    |      Milestone:  TorBrowserBundle 2.2.x-stable
Component:  Tor bundles/installation  |        Version:  Tor: unspecified             
 Keywords:                            |         Parent:                               
   Points:                            |   Actualpoints:                               
--------------------------------------+-------------------------------------

Comment(by mikeperry):

 Replying to [comment:22 StrangeCharm]:
 > Replying to [comment:20 mikeperry]:
 > > > > Oh, also, I think this extension is something that might make more
 sense in Thunderbird. It's great that it could exist in the browser, but
 secure instant messaging is more like something you'd expect from a mail
 client than a web browser.
 > Mozilla's user-research indicates that people want to be able to chat
 in-browser (as with Google Talk or Facebook Messenger), *no matter what
 page* they are currently browsing. That's one of the (many) motivations
 behind the social API.

 Hrm.. This is depressing, but I suppose this indicates that Cryptocat
 could find a good home in the browser.

 However, I still think the convergence Mozilla sees is merely a function
 of popular websites already aggregating people's communication
 interactions all in one place rather than the browser being the best
 possible place for personal communications a-priori.

 > If this sounds like an argument for including CryptoCat when it's ready,
 I guess that it probably is. However, I suspect that it's also an argument
 for working out a safe way to use GPG with the gmail web interface, as
 well as a litany of other usability challenges integratingprivacy &
 security assurance into the online experience of a typical user.

 For a list of some of the failures+shortcomings of content-window GPG, see
 this page and the tor-talk thread it links to:
 https://tails.boum.org/doc/encryption_and_privacy/FireGPG_susceptible_to_devastating_attacks/

 I think that page only scratches the surface. Posts in that thread mention
 several additional general problems with content-window encryption.

 > Good privacy and security (of the sort to which I suspect almost
 everyone in this thread has easy access through carefully-configured
 standalone client software) shouldn't be as difficult as most users find
 it. As long as it continues to be, the best attacks against Tor users
 won't be the technical approaches which we have worked to hard to
 mitigate, but will emerge through the "normal" online workflows which we
 haven't yet provided for the safe use of, like relying on Gmail to keep
 messages private, or on a social network to safely IM.

 Unfortunately, this is the fundamental problem with instrumenting existing
 centralized webapps for security without explicit support from those
 websites themselves (I know, "keep dreaming", right?).

 Without also working in concert with the server-provided webapp code, I
 don't think we can successfully instrument the communications
 functionality of arbitrary or even specific target websites client-side.
 Code security issues aside, it's too easy for sites to change their code
 and cause us to fail open accidentally, or for their UI to inadvertently
 induce the user into entering what should be encrypted text or even key
 material into unprotected areas of the content window. And then, in all
 cases your website-based social network and communications frequency is
 plainly visible to the website and network infrastructure (which, if we
 play our cards right, is a very important problem that Tor can uniquely
 solve).

 If we're going to do secure communications in the browser WITHOUT the
 support of the websites themselves, I think it has to be in a totally
 separate part of the browser UI from the content window... But then, the
 question is: who will find it, and what makes them choose to use it as
 opposed to their existing webpage UI? Keeping the "secure communications"
 app entirely separate seems like it would make it much easier to keep
 people's mental models cleaner in the face of webapp change and even in
 general day to day use. But you're right, they would have to go through
 the trouble of finding and using that app, and their social circle must do
 so, too...

 > This comment ended up a lot longer than I was expecting. Sorry about
 that.

 Same. It's pretty important stuff though, even if it might be a little
 off-topic for this ticket (though not really).

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7085#comment:23>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs