Commit 33a5c33e authored by Tails developers's avatar Tails developers
Browse files

Discussion => big todo list update.

parent 0fb0deef
......@@ -37,6 +37,11 @@ Check the output for:
* does the exposed User-Agent match the generic Torbutton's one?
(connect to a website you can check the access logs for)
* firegpg: test symmetric encryption/decryption, same for asymmetric
* `about:plugins` should say no plugin is installed in every one of
the following cases:
1. Torbutton add-on enabled in *Tor enabled* status
2. Torbutton add-on enabled in *Tor Disabled* status
3. Torbutton add-on disabled
# Pidgin
......
[[!tag todo/discuss]]
I think adding DuckDuckGo to Iceweasel's search engine list (or better yet, as default) would be great for Tails.
> What would be the advantages of DuckDuckGo over Scroogle in the
......@@ -9,3 +7,4 @@ I think adding DuckDuckGo to Iceweasel's search engine list (or better yet, as d
DuckDuckGo does not get its results directly from Google like Scroogle does, they use more than one source for their results, but the biggest advantadge over Scroogle IMO it is that they have lots of shortcuts to perform a search and it seems to be actively developed and improved.
> We decided to add DuckDuckGo to the search engines list. [[!tag todo/code]]
The [[security/IP_address_leak_with_icedove]] can be fixed by setting mail.smtpserver.default.hello_argument to "localhost". See [this Tor wiki entry](https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorifyHOWTO/EMail#ExperimentalSuggestionsforpossiblymakingthunderbirdandorclawsstopleakinginfoExperimental) for other goodies. By applying those configurations I think both claws and icedove comes to an equal level security-wise.
The [[security/IP_address_leak_with_icedove]] can be fixed by setting
mail.smtpserver.default.hello_argument to "localhost". See [this Tor
wiki
entry](https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorifyHOWTO/EMail#ExperimentalSuggestionsforpossiblymakingthunderbirdandorclawsstopleakinginfoExperimental)
for other goodies. By applying those configurations I think both claws
and icedove comes to an equal level security-wise.
The question is, though, why we would want to migrate back to Icedove from claws.
The question is, though, why we would want to migrate back to Icedove
from claws.
####Pros:
[[!toc levels=2]]
Pros
====
* Icedove has a *much* easier guide for setting up an email account -- just enter a name, email address and password, and Icedove will check if the domain of it has IMAP (preferred) or POP, and SMPT, and set up an account correctly and automatically, beginning with trying SSL/STARTTLS so no login credentials are unnecessarily leaked. claws is pretty much impossible to setup for normal people, but seeding the config could make that easier, but will it be as easy?
* Enigmail has a *much* easier guide for generating a key and setting up GnuPG. The guide starts pretty much automatically and is very informative.
* Icedove is more widely used, so it's less fingerprintable and perhaps familiar to more users. This (and its larger development team) also likely results in earlier bug fixes.
####Cons:
Cons
====
* It will be somewhat harder to implement the [[todo/easy_MUA_configuration]] with Icedove compared to claws. That would allow us some flexibility for our use case, e.g. specific recommendations w.r.t. anonymity.
* Icedove's automatic account creation process will fallback to plaintext POP/IMAP/SMTP if SSL/STARTTLS fails. That could result in leaks of login/password in many circumstances, like if the user types the wrong domain in the email address. I can't seem to find any options to disallow plaintext, although mail.smtp.ssl=2 (must use SSL) seems interesting (haven't found anything for POP/IMAP though).
......@@ -17,8 +27,28 @@ The question is, though, why we would want to migrate back to Icedove from claws
I think implementing the [[todo/easy_MUA_configuration]] is pretty far from trivial, at least if we want it to be as easy as Icedove's account creation guide, which brings that whole idea into question. Maybe a better approach would be to write an addon for Icedove that alters the account creation process (if that is possible -- I have no insight in how much addons can do)? It'd give the user some use case specific information, e.g. to not use a non-anonymous email account, and also implement the other ideas from [[todo/easy_MUA_configuration]]. And it would disallow plaintext plaintext POP/IMAP/SMTP.
> I'm not against moving back to Icedove and using the existing
> Icedove 3.x account creation guide as a basis to implement
> [[todo/easy_MUA_configuration]]. --intrigeri
Things to implement
===================
[[!tag todo/code]]
Spoof User-Agent
----------------
1. pretend to be Thunderbird
2. pretend to be running on the same OS as Firefox Torbutton does
3. pretend to be the Thunderbird version that was current when the
Firefox version advertised by Torbutton itself was
Things to be checked / researched
=================================
[[!tag todo/research]]
* how much size does Icedove + Enigmail + l10n packages add to the
SquashFS compared to Claws Mail?
* how well are Enigmail, Icedove and l10n packages maintained in
Debian?
* if how Icedove's "autoconfiguration file" is fetched (authenticated
SSL? any information leak?)
[[!tag todo/discuss todo/research]]
......@@ -46,9 +46,10 @@ environment: init script/upstart, log rotation, etc.
lacks some useful information.
2. Ask a mailing list to have buildbot sending it's build error
reports there.
3. [[!taglink todo/discuss]] whether we want buildbot to send the
build report to the specified email address when someone hits the
"Build" button on its webpage, rather to bug everyone on the list.
3. Make it so that the buildbot sends the build report to the
specified email address when someone hits the "Build" button on its
webpage, rather to bug everyone on the list. If too painful, just
give up :)
2. Allow developers to have their personal branch(es?) autobuilt as
well => help developers test their code *before* pushing it to the
`devel` branch.
......
......@@ -62,4 +62,5 @@ FireGPG's inline PGP content autodetection feature is not compatible
with Torbutton. Either we close this todo item or we fix this in
FireGPG or Torbutton.
[[!tag todo/discuss]]
> FireGPG was orphaned upstream and seem a pain to patch and maintain
> => wont fix that until some better alternative comes up => [[!tag todo/done]]. :/
......@@ -29,6 +29,11 @@ To be implemented:
default;
* there is an opt-in to make these device writeable.
[[!tag todo/code]]
About implementation: live-boot's `readonly` option does the read-only
part, but it does that for every device, including removable ones,
which is painful when using [[todo/persistence]] stored on the USB
stick Tails is running from => we need to add a `readonly=fixed`
option to live-boot that would do that only for fixed (internal)
disks.
For the implementation, there might be a live-something option to do so.
[[!tag todo/code]]
......@@ -38,6 +38,13 @@ and when to update them? Whith such a general solution the above
things would not have to be implemented individually and could
be present as default suggestions in the tool.
Stuff we don't want to actively support making persistent:
- web browser addons (while we don't want to make it impossible to
install addons, we think it's a really bad idea, and won't actively
support it, since it partitions the Tails users anonymity set, thus
having bad consequences both on people who do it *and* on others)
#### Persistent user data store
A persistent non-home data store for whatever random files the user
......
......@@ -2,4 +2,4 @@ Tails ships i2p 0.80 while 0.84 is released.
See [[Tails I2P design page|contribute/design/I2P]] for details about
how it shall be reviewed and upgrade steps.
[[!tag todo/research]]
[[!tag todo/code]]
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment