- tbb-dev - lists.torproject.org

Future Tor Browser for Android milestones
by Georg Koppen 12 Sep '18

12 Sep '18

Hi all! Our first alpha for Tor Browser for Android is about to go live and we could have a short meeting about the big picture for the things to come until we call it stable. I outlined my thoughts in https://pad.riseup.net/p/nlhgUPXcS8SK. Please add things I forgot or rearrange them. I think our MUST and SHOULD format went well for the first alpha which is why I kept it. Georg

1 2

Tor Browser 8.0 Retrospective
by Tom Ritter 11 Sep '18

11 Sep '18

<mozilla hat> Hey Tor, Can we have a retrospective on the 8.0 release and how things went from an uplift perspective? What was good (hopefully the windows build had few hiccups?), bad (reviewing networking code), unexpected bugs (permission+canvas patch interaction), etc? We can do it over irc if that's preferable, and I'd suggest doing it similar to the existing meetings where we add to the pad before-hand). Timing-wise, ideal time would probably be 8 AM PDT / 3 PM UTC. Any later than that and it will be too late for the Berlin folks; any earlier and it'll be too earlier for the Pacific folks. But if that time doesn't work, we could still push it later in the day. When doesn't matter much. Sometime in the next few weeks? Maybe it would be better to do it in Mexico City? (Only disadvantage is I won't be there (and I have the most context on the MinGW build stuff...) I want us to figure out how we can make subsequent releases of Tor Browser much easier. -tom

2 1

Next Tor Browser meeting is on Tuesday, 9/4 1800 UTC
by Georg Koppen 27 Aug '18

27 Aug '18

Hi! As next Monday, 9/3, is a national holiday in the US (Labor day) we'll move the weekly Tor Browser meeting by one day. The next meeting will then be at Tue, 9/4, 1800 UTC in #tor-meeting on irc.oftc.net. See you there, Georg

1 0

Fwd: Following FOSS communities: new icon for Fennec in F-Droid
by Matthew Finkel 27 Aug '18

27 Aug '18

It's only tangentially relevant - but interesting.

1 0

Tor Browser for Android Build Script
by Matthew Finkel 27 Aug '18

27 Aug '18

Hi everyone, I wrote a build script for TBA-alpha, while integration into tor-browser-build is still being worked on. It works well on Debian Stretch and Ubuntu Bionic (the only two systems on which I tested it). It creates a (configurable) build directory where it clones or downloads every component and then builds them as needed - checking file hashes, commits hashes, and tags when relevant. I don't expect many of you will care too much about this, but you can give it a try if you want. One suggestion I have is creating a new user for this (I create a user named tba_builder), simply so there is a clean build environment. The script, by default, runs `git clean` within the git repos before configuring them, so if you don't want your working directory destroyed you should comment those lines in the script before running it. When I run it, I don't provide any command line arguments: tba_builder@localhost:~$ time ./build_tba_alpha and it creates a directory called tba_build_dir, changes directory into that directory, and then sets HOME=`pwd`. Unfortunately, some of the Adnroid build system continue writing in /home/tba_builder instead of /home/tba_builder/tba_build_dir, but it wasn't worth spending time troubleshooting that. Almost all of the values are configurable, simply look at the variables at the top of the script and you can override them by setting environment variable before executing the script. Let me know if you have any questions. - Matt

1 0

Tor Browser for arm64/v8 on RPi3
by procmem 08 Aug '18

08 Aug '18

Hi. We (Whonix) are working on RPi3 support which opens a lot of usecases and allows cheaper access to anonymity than before. For regular cleint side non-onion usage we consider Tor Browser an essential basic application. Can you please consider making TBB builds for arm64? Is the current Tor Browser port for Android helpful for such a project?

2 1

Feedback on the embedding API in tor_api.h
by isabela 03 Aug '18

03 Aug '18

Hello tor browser mobile devs! I am writing to you because you are part of a group of mobile developers that we (Tor network team) are contacting to ask for feedback on work we have done to help mobile devs embed Tor in their apps. We did a survey with other mobile devs (back in mid 2017) and based on some of that feedback we created the 'tor_api.h' controller API - you can read more about this work at the ticket #23684 [1]. We would be very thankful if you could spend a bit of your time looking at what we built, and if possible testing it to give us feedback (or report bugs). This will help us fix what is broken and improve it! Please create a child ticket to our #25510 [2] master ticket for collecting feedback and/or bug reports. Thank you in advance! Isabela [1] https://trac.torproject.org/projects/tor/ticket/23684 [2] https://trac.torproject.org/projects/tor/ticket/25510

3 4

[Survey] Does your team uses github.com?
by isabela 30 Jul '18

30 Jul '18

Hi there, I am sending this to all vegas teams in order to collect information to make decisions on how we should configure github.com for Tor teams use. To be clear - we are not replacing hosting our own git repo for github.com. We are considering using it as a synced repo for other means (more information below). Please answer this as soon as you can so we can get things organized :) and projects that want to use it can move on to use it. thanks! isabela background: This history goes way back then I will do in the background I am providing here. If you want to know more ping (isa or maybe irc in general cuz isa doesn't know i tall either). To make things short, we have been investigating options to improve our workflow and volunteers workflow. Network team has being doing a lot of that and recently decided to use github.com as a solution for, between other things: * receive and review volunteers collaborations * review long pieces of code * use travis/CI testing from github.com infra When doing it we saw that OONI is also using github.com in their workflow. And after the network team migrated to it, stem also start using it. With that, an instance of gitlab that we had for tests (oniongit) was only being used by the UX/Services teams. To consolidate how we do things, UX/Services teams decided to move to github.com too (and we will kill oniongit). The idea here is to have github.com for volunteers patches and some of the stuff listed above that the network team is doing (if people want them) but we will: * keep trac as our issue tracker (so all teams will continue to use trac tickets to coordinate their work) * our real repo will always be our repo (so we can only push to master on our repo and only us can do it) There is more to what I am saying here, more configuration details and use cases you might want to talk about. That is why I am sending this survey, to learn more from all teams. The goal here is to organize how tor does things with github and have this option available for teams to use. If you think your team doesn't need this you can just let us know in the survey. note: some configuration discussion is going on in this other pad: https://pad.riseup.net/p/Organizing-GitHub-and-Tor survey: Do you currently use github for anything? If yes, could you describe a bit how? Things like: * What usernames your team members has on github? * What github projects is your team using? * What github repos? * Any special permissions configuration? * Do you sync what is there with tor's git? (gitweb) If so how? If you are not using it yet, and could see a reason to start using it, please let us know: * What would you answer for the above questions (for those who are already using it), you can write 'i would need a project named xxxx' for instance. * Is there anything else your team would need in order to be set up to use github?

2 1

Sandboxing Tor Browser - Next Step
by Matthew Finkel 30 Jul '18

30 Jul '18

Hi Everyone, We had a productive meeting yesterday about sandboxing Tor Browser. I sent a high-level summary on tor-dev@ [0]. We ended the meeting while we were discussing/considering the different criteria for how we decide which sandboxing implementation(s) we persue [1]. This is the continuation of that topic. Specifically, we currently have four sandboxing options under consideration (there may be more we aren't considering): a) one standard VM on all desktop OSes running Tor Browser on Linux b) Per-OS container/virtualization solution c) No container/vm, but sandboxing the parent and content processes using OS-specific mechanisms (dropping privs etc.) d) a mix of all options choosing the best per platform With each of these mechanisms, we enumerated some criteria for evaluating them and choosing the best option for Tor Browser: 1) (in the face of a browser exploit) tracking protection 2) (no browser exploit) tracking protection 3) (in the face of a browser exploit) proxy bypass protection 4) (no browser exploit) proxy bypass protection 5) user experience 6) development effort (including time to market with improved security) 7) maintainability 8) uplift possibilities 9) installation size? (part of user experience?) 10) ability to take advantage of expected future security improvements 11) Compatibility with future browser/app development plans at the Tor Project As mentioned during the meeting, there doesn't currently exist a common set of sandboxing mechanisms across all platforms. Maybe this will exist in some years when Docker is the de facto standard run-time. Until then, we have platform-specific implementations we must use. How should we document ranking each of the sandboxing options with the stated criteria? Would this be easier on another pad or using a spreadsheet (ethercalc)? Thanks, Matt [0] https://lists.torproject.org/pipermail/tor-dev/2018-July/013350.html [1] https://pad.riseup.net/p/sandbox-07-24

4 3

Fwd: Call for Participation: W3C Workshop on Permissions and User Consent
by Tom Ritter 24 Jul '18

24 Jul '18

For anyone west coast local perhaps... ---------- Forwarded message --------- From: Samuel Weiler <weiler(a)w3.org> Date: Fri, Jul 13, 2018, 2:14 PM Subject: Fwd: Call for Participation: W3C Workshop on Permissions and User Consent To: <public-device-apis(a)w3.org>, public-web-security(a)w3.org < public-web-security(a)w3.org>, <public-privacy(a)w3.org> W3C is holding a workshop on Permissions and User Consent, September 18-19 in San Diego. The full CFP is at: https://www.w3.org/Privacy/permissions-ws-2018/cfp.html I encourage your participation. -- Sam Weiler, W3C -------- Forwarded Message -------- Subject: Call for Participation: W3C Workshop on Permissions and User Consent Resent-Date: Thu, 12 Jul 2018 08:03:03 +0000 Resent-From: w3c-ac-members(a)w3.org Date: Thu, 12 Jul 2018 10:02:51 +0200 From: Coralie Mercier <coralie(a)w3.org> To: w3c-ac-forum(a)w3.org CC: chairs(a)w3.org Dear Advisory Committee Representative, Chairs, W3C is pleased to call for participation in: W3C Workshop on Permissions and User Consent September 18-19 2018, San Diego, CA https://www.w3.org/Privacy/permissions-ws-2018/cfp.html Thanks to Qualcomm for hosting the workshop. This workshop brings together security and privacy experts, UI/UX researchers, browser vendors, mobile OS developers, API authors, Web publishers and users to address the privacy, security and usability challenges presented by the complex and overlapping variety of permissions and consent systems that are currently presented for hardware sensors, device capabilities and applications on the Web. The scope includes: * user consent; * bundling of permissions; * lifetime/duration of permissions; * permission inheritance to iframes and other embedded elements; * relation to same origin policy; * UIs and controls; * interaction with private browsing modes; * implicit permission grants; * progressive permission grants; * cross-stack permissions: how OS, browser, and web app permissions interact; * permission transparency; * relation to regulatory requirements; * special considerations for systems that use the browser as a pass-through (e.g. EME and Web Authentication); and * permissions/transparency/UI as it relates to display-less devices that connect to the Internet. We aim to share experiences and user studies, leading to common understanding of when and how to seek user consent for use of various Web platform capabilities. We expect this workshop to lead to concrete and consistent guidance for API authors and implementers and to identify areas for further standardization or research. An important take-away from this workshop should be guidance on how Permissions APIs should be designed, both now and in the future, considering the rapid evolution of the web platform. For more information on the workshop, please see details and submission instructions: https://www.w3.org/Privacy/permissions-ws-2018/cfp.html If you have any questions, please contact organizer Samuel Weiler <weiler(a)w3.org>. W3C Members interested in sponsoring this workshop should contact Alan Bird <abird(a)w3.org>. This announcement follows section 8 of the W3C Process Document: https://www.w3.org/2018/Process-20180201/#GAEvents We look forward to seeing you there. Coralie Mercier, Head of W3C Marketing & Communications -- Coralie Mercier - W3C Marketing & Communications - https://www.w3.org mailto:coralie@w3.org +337 810 795 22 https://www.w3.org/People/CMercier/

1 0