tbb-dev January 2015

tbb-dev@lists.torproject.org

7 participants
7 discussions

Quo Vadis, Private Browsing Mode?
by Georg Koppen 01 Feb '15

01 Feb '15

Hi all, the discussion about how to handle our fingerprinting patches in the Private Browsing Mode (PBM) space we had on 01/12 made me think a bit more about the topic in general. So, PBM currently is just meant to avoid saving information about the sites you visit. Nothing more and nothing less.[1] This basically maps to the disk avoidance requirement in the Tor Browser design document.[2] The question is now how to treat the other privacy relevant areas like cross-origin linkability or fingerprinting? Should we invent new modes and try to sell them to the user in addition to the Private Browsing Mode? And if so, how exactly do we relate all these things together given that there are now private windows and non-private windows coexisting in vanilla Firefox versions (thanks for bringing this complication up, Arthur)? Here is what I think we should aim at: We should have one mode we sell as private browsing mode, call it Private Browsing Mode+ (PBM+) for now, that contains the different areas I mentioned above as they are all related to "privacy" in one way. How should it work ------------------ If you look at the current privacy pane in your Firefox you see that there are already some foundations laid for that idea in that Mozilla seems to acknowledge that there are different angles to "privacy": there is the Tracking section that would roughly correspond to our cross-origin linkability area, then there is the History section which regulates the disk avoidance part and then there is the odd Location Bar section which is presumably there to optionally prevent people from looking over ones shoulder. No fingerprinting part. No proxy part (in case users are looking for location privacy). At the same time the privacy pane is highly confusing: What do third party cookie settings play for a role in the history section, for instance? And why are these settings deeply buried there and not visible in the Tracking section? I am not talking here about how the privacy pane should look like in non-PBM(+) but if PBM+ got enabled the pane could by quite clean and show by default five checkboxes and one button like [x] Enable Private Browsing Mode+ [x] Don't remember history [x] Prevent website tracking [x] Prevent browser fingerprinting [ ] Prevent location tracking (use a proxy) [Show site data] (We could think about checking the last checkbox, too, if a proxy is already configured) Users would then 1) easily see what kind of privacy related protections they have enabled without the need to dig down some obscure menus and fiddle with several settings. 2) be able to configure their mode according to their needs (yes, there are people that want their history being enabled (I am not of that sort btw) while all the other protections remain in place). 3) get a place where the improved privacy UI mentioned in our design document would have a good place (we might need to think about which relationship it has to the prevent-tracking-option above but that is just a detail): a "Show site data" button. Why should it work that way --------------------------- First if all, it is highly confusing for a user to have a bunch of modes to select from if she wants to get privacy on the web. "Enable Private Browsing Mode" somewhere in the menu or via a toolbar button should be enough. There is no need for her to know things about the different parts of the privacy concept. Second, there is still a big part of users that see more than one angle with respect to privacy and include the linkability and fingerprinting part in their concept of a private browsing mode.[3] We should take care of them and incorporate that into the UI I think. This is especially important, I think, as the usual things that hit the mainstream press and thus have a chance to get seen by and influence normal users are linkability/fingerprinting related.[4][5] What to do ---------- For the linkability related things we have a preference which makes it a) easier for Mozilla to merge our patches and b) makes it easier for the UI I outlined above. It might even make it easier for Mozilla to adapt such a UI as they could just flip a preference if they really think that cross-origin linkability has nothing to do with a Private Browsing Mode. It might make sense to have a preference for the fingerprinting patches, too, then given the model above. Something like "privacy.fingerprinting.disable" maybe. This would allow Mozilla then again to leave the checkbox unchecked in a UI like the one above if they think fingerprinting does not belong into the Private Browsing Mode. It might make upstreaming patches easier, too. And, as a last point, we should not let us distract here from people framing the fingerprinting issue as a security related one being orthogonal to privacy concerns.[6] Georg [1] https://support.mozilla.org/en-US/kb/private-browsing-browse-web-without-sa… [2] https://www.torproject.org/projects/torbrowser/design/#disk-avoidance [3] About 22% according to http://www.winlab.rutgers.edu/~janne/WPES14-privatebrowsing.pdf. But the data they collected is not as robust as I'd like to have it. [4] E.g.: http://www.mediapost.com/publications/article/155032/#axzz2JFJ5s8l1 [5] E.g.: https://www.propublica.org/article/meet-the-online-tracking-device-that-is-… [6] See the FPDetective paper: https://www.cosic.esat.kuleuven.be/publications/article-2334.pdf sections 7.1 and 7.3 for examples

4 4

Tor Launcher should use built-in bridges if it fails to connect to the public network.
by Sherief Alaa 31 Jan '15

31 Jan '15

Hi tbb-team, I intended for this to be a trac ticket but I wanted to ask here first before creating it. The help desk receives a lot of tickets from users who fail to connect to the network, their problem would be solved by just using the built-in bridges. Would it be better if we make Tor Launcher attempt connecting using the built-in bridges if it fails to connect for X minutes? My only concern here is that this behaviour might kill the bridges' VMs. -- Sherief Alaa pgp 0x8623B882

1 0

Continuous builds continue to build, continuously
by Linus Nordberg 20 Jan '15

20 Jan '15

Hi tb devs, My nightly [1] builds [2] have been failing for almost a week. I think the virtual machines were outdated so I've done a "make clean" and restarted todays build. I've fixed a couple of smaller things in the build script. If someone would be kind enough to merge branch build-tbb-tweaks [3] in my public repo that'd be swell. Today, log files from failed builds are sent to Georg and myself. Let me know if this should change. [1] called nightly because when they finish building, there should be night somewhere on the planet [2] https://people.torproject.org/~linus/builds/ [3] https://gitweb.torproject.org/user/linus/tor-browser-bundle.git/log/?h=buil…

2 1

Problems getting a nsIChannel reference
by tordevmuc＠encambio.com 15 Jan '15

15 Jan '15

Hello list, Regarding #9701, on Monday's meeting we talked about this method: DataStruct::SetData (nsISupports* aData, uint32_t aDataLen) { // Try to get a nsIChannel here } And a helpful comment was 'get the channel from the top level chrome window.' I tried a few things: nsCOMPtr<nsIDOMChromeWindow> aWin(do_QueryInterface(aData, &rv)); nsCOMPtr<nsILoadContext> aCtx(do_QueryInterface(aData, &rv)); These calls set rv == NS_NOINTERFACE in every case. Am I missing another way to get the top chrome window? Is there a global mTopwin? SetData gets called like this: nsCOMPtr<nsISupportsString> aString; SetData (aString, <some-number>) By the way, another suggestion to use the JavaScript module PrivateBrowsingUtils.jsm requires a nsILoadContext pointer, failing with rv == NS_NOINTERFACE in the same way. Looks like this is not going to make it in the 4.5 alpha 3 release. (No) Cheers, Michael

2 5

Notes from the help desk
by Matt Pagan 05 Jan '15

05 Jan '15

Hi-- I'm writing this mail since I can't attend the IRC meeting today. One thing to note from help desk requests is that the Vidalia Windows bundles-- the Vidalia Relay Bundle, the Vidalia Exit Bundle, and the Vidalia Bridge Bundle-- are still quite popular. And they really shouldn't be. Their Tor is one version number behind, I'm not sure what version of Firefox ESR it contains, and Vidalia crashes with errors pretty often. The recommended way to use Tor to browse the web is Tor Browser, and the low-bandwidth relays these bundles create are more drain on the network than help. I'd like to recommend that we remove the Vidalia Bundles (but not the Windows Expert Bundle which is Tor-only plus an installer) from our website. I also think we should make a blog post explaining that Vidalia is deprecated and should no longer be used. I'd be willing to help with either of these tasks with some guidance. All the best, Matt Pagan

1 0

Double keyed cookies agenda entry
by tordevmuc＠encambio.com 02 Jan '15

02 Jan '15

Hello list, Prelimary tests indicate that the double keyed cookie logic from #3246 [1] performs as intended, but there are open questions like: How close have we covered all requirements (session, persistent, RFC 6265, real world use, maybe CVEs?) Should we consider modifying 1st/3rd party contexts of DOM stuff to accommodate broader use cases (federated login?) Which assumptions should we make of ESR network.cookie.* combos ...or should we implement and test for all config combinations? What would Mozilla require for a backport to ESR? How should this be 'packaged' with other 3rd party isolation? ...so I'm hoping to clear this up at the next TBB meeting Monday 19:00 UTC. QUESTION If anyone has changed their network.cookie.cookiebehavior to 'allow all cookies', please state which website caused the frustration. [1] https://trac.torproject.org/projects/tor/ticket/3246/ Cheers, Michael -- Michael Schloh von Bennewitz Software Development Engineer

1 0

New Guy Wants To Help With The TorBrowser Experience
by spencerone＠openmailbox.org 02 Jan '15

02 Jan '15

Hey y'all, here are some of my thoughts, which are also posted on the ticket [#9387] . I used my own terms here, made up on the spot, but please make me use yours if mine complicate the discussion. After reading the ongoing discussion, here are my two Satoshi: Splitting the JavaScript allowances between allowance setting positions on the slider could be confusing for people. It requires explaining what JavaScript is and what it does in detail, that is, presuming that explaining the settings in detail is necessary, and I think we are on the same page in thinking that it is. Alternatively, we can not explain the settings in detail, though that leaves people unclear as to what is actually happening, e.g., some JS is disabled/all JS is disabled, doesn't explain much. However, whatever the number of allowance settings, and four seems to be the path forward from here, the details [what people see] should be written in human, not computer. Though maybe that could be toggled for those who prefer one or the other. Regarding a 'Custom' allowance setting on the slider itself, that makes things a bit confusing. The slider could be the foremost front-end allowance settings option, inherently likening 'Custom' to 'Advanced'. I agree that the allowance settings interface just after install should be the allowance settings interface in 'Preferences', as an attempt to lessen visual and mental fragmentation. The tool tips for allowance setting positions are cool, but are hidden for most people. The always-on text for descriptions is better for full understanding of options/decisions, but takes up space. The always-on text for descriptions that is only visible at each allowance setting position fits in the middle of these two options but requires work, clicking and whatnot. Maybe, in addition to this middle option, the other unselected allowance setting position descriptions appear on hover, or in place, of the always-on text, as an alternative to grayed-out. After reviewing TB 4.5 Alpha 2 [Mac]: Setting security preferences could be a prompt in the second dialog, considering the first is the drag-to install dialog. I see benefit in not forcing people to make such decisions right away, but people are using TB for a reason, so maybe it can be expected. 'Cookie Protections' seems like a preference. What is cookie protection, IDK, so maybe this is an advanced setting. 'Proxy Settings' could be second after 'Privacy and Security Settings', however, 'Proxy Settings' seems like an advanced setting, maybe simplifying the experience for many people. 'Privacy Settings' and 'Security Level' could use some explaining. I would like to think that I am securing my data with the security settings, or, in other words, securing my privacy. Semantics could be important here. Are we only securing our anonymity? I am all for the vertical slider, given the varying lengths in allowance setting position labels. We could move allowance setting position labels to the left of the slider with descriptions to the right. If we're only showing the current/selected allowance setting position description, this provides plenty of space for a more detailed explanation. Questions: Is there a visual flow of the dialogs and what they contain, or is it all in development text archives? Is there an outlet for visuals, like wireframes? Does there have to be a "tradeoff between features and security"? It is a big bite to take, but, can alternatives be written as stand-ins to replace the vulnerable features? Awesome, SpencerOne > spencerone at openmailbox.org spencerone at openmailbox.org wrote: > > Hey Georg! > > > Thanks! I jumped in on the discussion with some thoughts; I hope they > provide some value. > > Awesome, > SpencerOne > > > > > > > >> Georg Koppen gk at torproject.org wrote: >> >> Hi SpencerOne, >> >> that fits perfectly. We are currently in the process of incorporating >> a >> security slider into Tor Browser which lets users choose between four >> different security levels: on the one end the slider allows the most >> features while on the other end promises you high security and is >> therefore restricting a bunch of browser features which are known to >> be >> risky security-wise. The big question now is: how do we get that idea >> transported to the user in the best possible way? >> >> Ongoing discussion is happening in https://bugs.torproject.org/9387. >> For >> the current solution which still lacks some features (see the above >> mentioned ticket in our bugtracker for details) see our recently >> released 4.5-alpha-2: >> https://www.torproject.org/projects/torbrowser.html.en#downloads-alpha. >> You'll find our work-of-progress clicking on the green onion -> >> Preferences... -> Privacy and Security Settings. >> >> Feedback and help is very much appreciated be it on this mailing list >> on >> the security slider ticket directly or on IRC in #tor-dev (I saw we >> missed us there). Oh, and if you are not interested in this particular >> issue, no worries we have plenty of other UX improvements we need. >> Just >> ask. >> >> Georg

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev January 2015