Changes between Version 4 and Version 5 of doc/TorBOX/Dev/ArchivedDiscussion/MISC


Ignore:
Timestamp:
Apr 7, 2013, 5:49:33 PM (6 years ago)
Author:
proper
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • doc/TorBOX/Dev/ArchivedDiscussion/MISC

    v4 v5  
    4747 * (adrelanos) Currently the main page is way too geeky, scary and complicated. I appreciate being upfront about security and other issues but we should perhaps orientate more on front pages of successful projects, such as Tor and Tails. Successful in having lots of developers, users, supporters and progress. Without having users the most promising implementation is not very useful or secure. Users attract interest, more user, more reviewers, devs and so on. Of course, we will always be upfront with the interested ones about open issues, but that are the ones who click to a sub page and who read the full documentation. When you look at the torproject.org you also won't see a "Uh, we actually have no defense against traffic confirmation, internet exchange point spying, don't pin SSL certificates, have no deterministic builds, no apparmor and a huge amount of other critical issues". It's a fact that most users don't read documentation. I'll aim to make offer a project which provides them with as much as security then possible, at very least more security than the Tor Browser Bundle. The interested ones and those who really care will always be very welcome and they will be offered additional information on how they can get best safety. And when they learned everything they may help us to improve the project even further (use multiple vm's/snampshots, physical isolation, etc.).
    4848 * (adrelanos) I plan to make big changes, a rewrite to the aos front page. News and You Can Help will be moved to the Readme.
     49
     50== [SOURCE CODE] no longer hardcode user folder [FIXED] ==
     51 * (adrelanos) Currently Whonix build scripts assume to be build as user "user" and the Whonix source code being in /home/user/Whonix. This should no longer be hardcoded.
     52 * (adrelanos) fixed.
     53
     54== remove wpolipo [DONE] ==
     55 * (adrelanos) Remove [https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Polipo wpolipo]. Put wpolipo in it's own git repository. Not in use for anything. When discussing wpolipo, privoxy was rather recommend. So perhaps create wprivoxy? -> New ticket.
     56 * (adrelanos) Done. It's still inside but does not do anything because no ports are defined.
     57
     58== [FEATURE] Feedback collector [ANSWERED] ==
     59 * (adrelanos) We could add a small application on T-W where the user would only see a small text box and a send button. The feedback would be send to us. E-mail would make sense, but any other suitable method will do. There are open questions about user privacy. Should we encrypt that message? Should we normally send over the Tor network or should we add another layer of protection such as remailing? Or simply send over Tor and tell the user to switch circuit afterwards? How do we answer the users? Are there existing applications for this task or would we have to develop it ourselves? Does this make sense at all?
     60 * (anonymous) I really think that's overkill neither Tor nor Ubuntu has that, why should we - we just configure the two?
     61 * (adrelanos) Agreed. Update: Reopened. We have 173 download of Whonix 0.1.3 through sourceforge.org and barely any user feedback. Tails has [whisperback, you can see it in action if you get a recent Tails version. Unfortunately, whisperback requires a SMTP relay. Apart from that, they have a [http://git.immerda.ch/?p=whisperback.git git repository for whisperback] and after changing the messages, it could be used as a drop in replacement (still needs more research).
     62 * (trademarkdomain user disappeared) A feedback collector is a good idea. However, I think doing it over email is a bad idea. This increases chances of interception and it makes it very hard for all developers and/or community to receive & review the feedback. I think the best way to implement it would be via HTTP through the (trademarkdomain user disappeared) website, where it goes into the database. I assume that there would be an obmenu item to initiate the feedback form. Either we could have a form on the desktop submit to a (trademarkdomain user disappeared) processing script in the background (extra feature development & maintenance), or we could simply open up a standard feedback webpage on the (trademarkdomain user disappeared) website in the browser that everyone uses, whether coming from the desktop or web (simpler, one unified solution to maintain & pull from). Also, by launching a webpage in the browser, people can have more certainty about where the feedback is going, compared to an uncertain form overlayed on the desktop that goes out into the ether. So, I'd probably vote to simply open a standard (trademarkdomain user disappeared) feedback webpage like that. Could be done via SSL or Hidden Service in the TorBrowser.
     63 * (adrelanos) About interception: I was going to ask if we could host a hidden mail relay (only relaying to (trademarkdomain user disappeared), no outside targets). That way no interception is possible. I was only going to ask, if I would not have found an alternative to the mail relay. I was thinking about using remailers and encrypted posting to usenet. Whisperback from Tails looks very pretty, here is a https://tails.boum.org/doc/first_steps/bug_reporting/whisperback.png screenshot]. Thanks for joining this thread. Most features can be implemented over http and a hidden service. I think the Tails threat model for having an application for that is, that not even the server host can read the gpg encrypted reports. (The "add gpg key" field is allow the Tails developer to send back an encrypted answer.) Not sure we have such a threat model? If we had we could gpg encrypt inside the browser using a locally stored website. Most discussion should got into public areas anyway.
     64 * (trademarkdomain user disappeared) Hmmm... Interesting. I like the idea of initiating feedback from the desktop, even if just linking to the website. However, I don't like the idea of doubling the infrastructure of an issue tracker, both for the double maintenance as well as having similar types of postings end up in two separate systems/places. So, to me, it seems more ideal to somehow integrate this desktop feedback into the central issue tracker system. This would also likely allow for better inter-developer workflow for processing the feedback properly (every approved developer gets to see it, no overlapping responses, accountability for responses, etc). Beyond integration with existing issue tracker infrastructure, the challenge seems to be handling private non-public feedback/issues, and secure notification/transport of responses for private feedback/issues. So, overall, ideally looking for... Tracker Integration + Shared Developer Processing + Private & Public + Secure Transport. Does this sound accurate?
     65 * (trademarkdomain user disappeared) And, if so, is private feedback/issues that important, if we can offer anonymous public feedback/issues?
     66 * (adrelanos) Yes, having two systems sounds complicated and I am not sure we have the manpower yet. Let's make it easy but at least make it. One website, one issue tracker, one forum, one wiki, done so far. A website link can still be added, but it shouldn't encourage posting duplicates. If anyone really needs encrypted bug reports, they can mail be personally using my gpg key, I don't expect that to happen often.
     67   * (trademarkdomain user disappeared) Agreed.
     68 * (adrelanos) Tails reason to have the feedback collector as application is sending anonymized hardware data to Tails develoeprs and not to the open public. Since Whonix delegates hardware support to the host operating system and does not have so strong requirements to safe space and kernel modules, it might not be necessary to use their tool.
     69
     70== [BUG] uwt wrapper localhost connections broken [FIXED] ==
     71 * (adrelanos) I deactivated the wget uwt wrapper, because connections to localhost were broken. That may not be needed often, but if so, it leads to errors where the source is hard to find. The same goes probable also for the ssh wget wrapper and perhaps others.
     72 * (anonymous) can't we add an exception? "IF localhost use wget, ELSE use wrapper"?
     73 * (adrelanos) Good idea. I added an check not to use torsocks when 127.0.0.1 or localhost is inside the parameters.
     74 * (adrelanos) Not sure if anything else is still broken. uwt might still not be a generic solution for applications which internally decide to connect to localhost, not sure if git does this.
     75 * (adrelanos) Removed [0.2] tag until I or someone else finds a new issue.
     76