Hey there,
As I've mentioned on IRC, I've this idea to create an extension for Tor Browser. Such a thing could really improve our relationship with end-users while helping us to collect the metrics we need for UX on an opt-in basis.
Initially I was thinking of this as a mechanism for users to give us feedback and report problems they might encounter while using the browser. But after some thoughts and specially after seeing dcf's notes from UX session at dev meeting[1], I realized we could even take this further. This could be even used by users who have problem connecting to Tor network to troubleshoot their connectivity issues or it could give us a hint on how and when a network starts blocking Tor connections.
To write a simple list of the things I think this extension could do:
- Have a message box to submit feedback + we could let them to attach img as well + or we could include a checkbox that would automatically take an screenshot of the Tor Browser window. I think chrome used to have such feature.
- Have an option to opt in for network tests. Test different protocols and see if vanilla tor or any of the Pluggable Transports are being blocked.
- Collect some information about their network and computers: such as operating system, version of tor browser, country code, maybe AS Number, etc.
There are some open questions to answer. eg how to safely submit collected data? I was thinking maybe over onion but that's only if user has gotten past tor-launcher and tor is running properly.
All of this obviously should be opt-in only and is a very good thing for the review-board to approve before going live.
What do you think? Is it worth to give it a shot at GSoC? sukhe and willscott have showed interest in mentoring. Can we have three mentors for GSoC?
[1] https://trac.torproject.org/projects/tor/wiki/org/meetings/2016WinterDevMeet...
Hi,
Nima Fatemi:
Hey there,
As I've mentioned on IRC, I've this idea to create an extension for Tor Browser. Such a thing could really improve our relationship with end-users while helping us to collect the metrics we need for UX on an opt-in basis.
Initially I was thinking of this as a mechanism for users to give us feedback and report problems they might encounter while using the browser. But after some thoughts and specially after seeing dcf's notes from UX session at dev meeting[1], I realized we could even take this further. This could be even used by users who have problem connecting to Tor network to troubleshoot their connectivity issues or it could give us a hint on how and when a network starts blocking Tor connections.
To write a simple list of the things I think this extension could do:
- Have a message box to submit feedback
- we could let them to attach img as well
- or we could include a checkbox that would automatically take an
screenshot of the Tor Browser window. I think chrome used to have such feature.
- Have an option to opt in for network tests. Test different protocols
and see if vanilla tor or any of the Pluggable Transports are being blocked.
- Collect some information about their network and computers: such as
operating system, version of tor browser, country code, maybe AS Number, etc.
There are some open questions to answer. eg how to safely submit collected data? I was thinking maybe over onion but that's only if user has gotten past tor-launcher and tor is running properly.
All of this obviously should be opt-in only and is a very good thing for the review-board to approve before going live.
What do you think? Is it worth to give it a shot at GSoC? sukhe and willscott have showed interest in mentoring. Can we have three mentors for GSoC?
I think this is not a good project for GSoC at least for two reasons:
1) It seems to me that it is underwhelming for three months of work given that students are supposed to code full-time on it.
2) I am not convinced we should develop yet another extension for all the things you listed. E.g. why should a way to give feedback not get implemented in Tor Browser directly instead of having it in a separate extension? Or why should those censorship related things not get implemented in Tor Launcher given that this is already the primary point for users to deal with bridges and pluggable transports? Keep in mind as well that we have the goal to suggest the user a pluggable transport/bridge that works for her/him anyway in the future in case it is needed. This would avoid having to try all the transports hoping to finally find one that works.
Georg
[1] https://trac.torproject.org/projects/tor/wiki/org/meetings/2016WinterDevMeet...
tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
Hi Georg,
Thanks for your feedback. Please find my response below:
I think this is not a good project for GSoC at least for two reasons:
- It seems to me that it is underwhelming for three months of work
given that students are supposed to code full-time on it.
I'd argue that given the importance of this project, the current paid staff and members of the community don't seem to have the capacity to do it.
Also, like I've mentioned before, this might seem like an easy project, but has lots of details and it takes a lot of time to do it right.
I suggest we add this to the idea list ASAP and make the final decision based on the quality of proposals we get. Rather than letting the whole thing to die off just because it seems too easy.
- I am not convinced we should develop yet another extension for all
the things you listed. E.g. why should a way to give feedback not get implemented in Tor Browser directly instead of having it in a separate extension? Or why should those censorship related things not get implemented in Tor Launcher given that this is already the primary point for users to deal with bridges and pluggable transports?
Right, this is even better. It totally can be directly implemented into Tor Browser and Tor Launcher. Not insisting on it to be an extension.
Keep in mind as well that we have the goal to suggest the user a pluggable transport/bridge that works for her/him anyway in the future in case it is needed. This would avoid having to try all the transports hoping to finally find one that works.
Wow that's news to me and kind of a radical approach. Wouldn't that make PTs a bigger bottleneck than what they already are? Plus PT users soon seem to be going over 4 hops instead of 3 and that dramatically affects the speed, specially for censored users whom are already battling with TLS throttling and DPI. But this is a whole separate conversation and I don't think it belongs to this thread.
PS: still waiting for sukhe and will to hear their thoughts.
Best,
Nima Fatemi:
Hi Georg,
Thanks for your feedback. Please find my response below:
[snip]
Keep in mind as well that we have the goal to suggest the user a pluggable transport/bridge that works for her/him anyway in the future in case it is needed. This would avoid having to try all the transports hoping to finally find one that works.
Wow that's news to me and kind of a radical approach. Wouldn't that make PTs a bigger bottleneck than what they already are? Plus PT users soon seem to be going over 4 hops instead of 3 and that dramatically affects the speed, specially for censored users whom are already battling with TLS throttling and DPI. But this is a whole separate conversation and I don't think it belongs to this thread.
Well, this point was only meant to illustrate that we at some point want to take the burden to deal with pluggable transport/bridge selection off of the user. Yes, it is orthogonal to the GSoC idea how and in which form we achieve this. But mentioning it was meant to drive the point home that the option for network tests should might fit better into Tor Launcher althought this idea has drawbacks, too. E.g. it makes Tor Launcher more complex enhancing the risk that users get lost on start-up etc.
Georg
Getting a UI and feedback pipeline in tor launcher certainly seems like it could be a full summers work. Figuring out what happens with the reports seems like the biggest unknown and potentially the most amount of work. (Are they fed into trac tickets? is there some new system to see them? who can see that data? how much PII is scrubbed / available to who?)
I'm happy to help mentor firefox extension side development and think about some of the reporting issues.
--Will
On Wed, Mar 16, 2016 at 12:16 PM, Georg Koppen gk@torproject.org wrote:
Nima Fatemi:
Hi Georg,
Thanks for your feedback. Please find my response below:
[snip]
Keep in mind as well that we have the goal to suggest the user a pluggable transport/bridge that works for her/him anyway in the future in case it is needed. This would avoid having to try all the transports hoping to finally find one that works.
Wow that's news to me and kind of a radical approach. Wouldn't that make PTs a bigger bottleneck than what they already are? Plus PT users soon seem to be going over 4 hops instead of 3 and that dramatically affects the speed, specially for censored users whom are already battling with TLS throttling and DPI. But this is a whole separate conversation and I don't think it belongs to this thread.
Well, this point was only meant to illustrate that we at some point want to take the burden to deal with pluggable transport/bridge selection off of the user. Yes, it is orthogonal to the GSoC idea how and in which form we achieve this. But mentioning it was meant to drive the point home that the option for network tests should might fit better into Tor Launcher althought this idea has drawbacks, too. E.g. it makes Tor Launcher more complex enhancing the risk that users get lost on start-up etc.
Georg
tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
On Sat, Mar 12, 2016 at 03:04:52AM +0000, Nima Fatemi wrote:
Hey there,
As I've mentioned on IRC, I've this idea to create an extension for Tor Browser. Such a thing could really improve our relationship with end-users while helping us to collect the metrics we need for UX on an opt-in basis.
Initially I was thinking of this as a mechanism for users to give us feedback and report problems they might encounter while using the browser. But after some thoughts and specially after seeing dcf's notes from UX session at dev meeting[1], I realized we could even take this further. This could be even used by users who have problem connecting to Tor network to troubleshoot their connectivity issues or it could give us a hint on how and when a network starts blocking Tor connections.
To write a simple list of the things I think this extension could do:
- Have a message box to submit feedback
- we could let them to attach img as well
- or we could include a checkbox that would automatically take an
screenshot of the Tor Browser window. I think chrome used to have such feature.
Food for thought, here is a screenshot of the Psiphon 3 feedback interface that I mentioned during the session Nima referred to. https://people.torproject.org/~dcf/circ-tool-ux-2016/images/image09.png
* Nima Fatemi:
Hey there,
As I've mentioned on IRC, I've this idea to create an extension for Tor Browser. Such a thing could really improve our relationship with end-users while helping us to collect the metrics we need for UX on an opt-in basis.
Initially I was thinking of this as a mechanism for users to give us feedback and report problems they might encounter while using the browser. But after some thoughts and specially after seeing dcf's notes from UX session at dev meeting[1], I realized we could even take this further. This could be even used by users who have problem connecting to Tor network to troubleshoot their connectivity issues or it could give us a hint on how and when a network starts blocking Tor connections.
To write a simple list of the things I think this extension could do:
- Have a message box to submit feedback
- we could let them to attach img as well
- or we could include a checkbox that would automatically take an
screenshot of the Tor Browser window. I think chrome used to have such feature.
- Have an option to opt in for network tests. Test different protocols
and see if vanilla tor or any of the Pluggable Transports are being blocked.
- Collect some information about their network and computers: such as
operating system, version of tor browser, country code, maybe AS Number, etc.
There are some open questions to answer. eg how to safely submit collected data? I was thinking maybe over onion but that's only if user has gotten past tor-launcher and tor is running properly.
All of this obviously should be opt-in only and is a very good thing for the review-board to approve before going live.
What do you think? Is it worth to give it a shot at GSoC? sukhe and willscott have showed interest in mentoring. Can we have three mentors for GSoC?
I think this is a fine idea but before we put up the proposal, we should work out a few details, say a fixed set of deliverables. Also as Georg mentioned, it would probably make sense for this to be a part of Tor Launcher, which means perhaps we should see what Mark and Kathy think about this.
So let's (quickly) discuss the deliverables so that we can put up the proposal and allow applicants to further develop the idea. (I am happy to mentor it with you and Will.)
tor-project@lists.torproject.org
-
David Fifield -
Georg Koppen -
Nima Fatemi -
Sukhbir Singh -
Will