Re: [Tails-dev] Tails: pcmcia / firewire / etc.

2012-10-12 Thread Maxim Kammerer 
On Sat, Oct 13, 2012 at 5:04 AM, Steve Weis  wrote:
> I think the kernel is working as expected. Debian and Ubuntu are both also
> vulnerable by default, since FireWire modules are loaded automatically.

>From Documentation/debugging-via-ohci1394.txt:
“The alternative firewire-ohci driver in drivers/firewire uses filtered physical
DMA by default, which is more secure but not suitable for remote debugging.”

Isn't this supposed to limit DMA?

> I can send some fix suggestions if you like.

Not being a kernel developer, I am not sure I will be able to act on them.

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails: pcmcia / firewire / etc.

2012-10-12 Thread Steve Weis 
I think the kernel is working as expected. Debian and Ubuntu are both also
vulnerable by default, since FireWire modules are loaded automatically.

I can send some fix suggestions if you like.
On Oct 12, 2012 7:35 PM, "Maxim Kammerer"  wrote:

> On Sat, Oct 13, 2012 at 3:15 AM, Steve Weis  wrote:
> > Hi. I booted Tails' latest release and was able to scrape memory contents
> > via FireWire. All the necessary firewire modules are enabled by default
> and
> > Inception worked out of the box. This would let someone root a machine
> > through, say, a daisy chained thunderbolt monitor.
>
> Thanks for testing! Shouldn't such behavior be classified as a kernel
> bug? I can't find anything related on the kernel bugtracker.
>
> --
> Maxim Kammerer
> Liberté Linux: http://dee.su/liberte
>
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails: pcmcia / firewire / etc.

2012-10-12 Thread Maxim Kammerer 
On Sat, Oct 13, 2012 at 3:15 AM, Steve Weis  wrote:
> Hi. I booted Tails' latest release and was able to scrape memory contents
> via FireWire. All the necessary firewire modules are enabled by default and
> Inception worked out of the box. This would let someone root a machine
> through, say, a daisy chained thunderbolt monitor.

Thanks for testing! Shouldn't such behavior be classified as a kernel
bug? I can't find anything related on the kernel bugtracker.

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails: pcmcia / firewire / etc.

2012-10-12 Thread Steve Weis 
Hi. I booted Tails' latest release and was able to scrape memory contents
via FireWire. All the necessary firewire modules are enabled by default and
Inception worked out of the box. This would let someone root a machine
through, say, a daisy chained thunderbolt monitor.

I'd either remove support from the kernel, blacklist the modules in
modprobe, or disable support with a boot param.

Iommu should be enabled as well for good measure, although it can be
circumvented.

Cheers.
On Oct 12, 2012 5:48 PM, "Jacob Appelbaum"  wrote:

> Maxim Kammerer:
> > On Sat, Oct 13, 2012 at 1:30 AM, Jacob Appelbaum
> >  wrote:
> >> I would add Thunderbolt to the list as well:
> >>
> http://www.breaknenter.org/2012/02/adventures-with-daisy-in-thunderbolt-dma-land-hacking-macs-through-the-thunderbolt-interface/
> >
> >>
> > As far as I can see, all these attacks (PCMCIA, ExpressCard,
> > Thunderbolt) rely on attaching to a FireWire interface one way or
> > another, and then accessing arbitrary memory via DMA. But such
> > ability is (or can be) disabled by default in the newer firewire-ohci
> > module, as described in "debugging-via-ohci1394.txt", and even
> > discussed on the relevant Tails TODO page. So why disable the
> > interfaces? Looks like an overkill to me.
> >
>
> My understanding is that this assumption doesn't actually pan out in
> practice. I've cc'ed Steve who may have some more information to
> contribute. As I understand things, he found that as predicted, the
> default "it is off" doesn't actually always turn DMA off.
>
> All the best,
> Jacob
>
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] from sdmem to memtest, and testing procedures

2012-10-12 Thread Maxim Kammerer 
On Thu, Dec 29, 2011 at 12:53 AM, intrigeri  wrote:
> Maxim Kammerer wrote (26 Dec 2011 17:59:44 GMT) :
>> But best option, of course, is if kernel developers fix the kernel
>
> Sure.

Ah, by the way, they won't fix memtest. Nobody cares [1].

[1] https://bugzilla.kernel.org/show_bug.cgi?id=42630

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails: pcmcia / firewire / etc.

2012-10-12 Thread Jacob Appelbaum 
Maxim Kammerer:
> On Sat, Oct 13, 2012 at 1:30 AM, Jacob Appelbaum
>  wrote:
>> I would add Thunderbolt to the list as well: 
>> http://www.breaknenter.org/2012/02/adventures-with-daisy-in-thunderbolt-dma-land-hacking-macs-through-the-thunderbolt-interface/
>
>> 
> As far as I can see, all these attacks (PCMCIA, ExpressCard, 
> Thunderbolt) rely on attaching to a FireWire interface one way or 
> another, and then accessing arbitrary memory via DMA. But such
> ability is (or can be) disabled by default in the newer firewire-ohci
> module, as described in "debugging-via-ohci1394.txt", and even
> discussed on the relevant Tails TODO page. So why disable the
> interfaces? Looks like an overkill to me.
> 

My understanding is that this assumption doesn't actually pan out in
practice. I've cc'ed Steve who may have some more information to
contribute. As I understand things, he found that as predicted, the
default "it is off" doesn't actually always turn DMA off.

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails: pcmcia / firewire / etc.

2012-10-12 Thread Maxim Kammerer 
On Sat, Oct 13, 2012 at 1:30 AM, Jacob Appelbaum  wrote:
> I would add Thunderbolt to the list as well:
> http://www.breaknenter.org/2012/02/adventures-with-daisy-in-thunderbolt-dma-land-hacking-macs-through-the-thunderbolt-interface/

As far as I can see, all these attacks (PCMCIA, ExpressCard,
Thunderbolt) rely on attaching to a FireWire interface one way or
another, and then accessing arbitrary memory via DMA. But such ability
is (or can be) disabled by default in the newer firewire-ohci module,
as described in "debugging-via-ohci1394.txt", and even discussed on
the relevant Tails TODO page. So why disable the interfaces? Looks
like an overkill to me.

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Download manager

2012-10-12 Thread Jacob Appelbaum 
Alan:
> Hi,
>> From: intrigeri 
>> Date: Fri, 28 Sep 2012 17:47:50 +0200
>>
>> Hi,
>>
>> a...@boum.org wrote (26 Sep 2012 17:44:20 GMT) :
>>> https://tails.boum.org/todo/include_download_manager/
>>> -
>>> [...] it might be useful to include a download managar in Tails.
>>> A usecase could be to try to download a big file across separate
>>> working sessions.
>>
>> I think this usecase is worth supporting, e.g. to make it easier to
>> download ISO images such as Tails' ones. I would consider it
>> relatively low-priority, though.
>>
> I do agree. Others?

I like the idea of a download manager and an upload manager. In both
cases we have the same issue - sometimes normal network issues that
would make a non-anonymous download fail will also cause Tor downloads
to fail. An example is bumping an ethernet cable on a laptop or a
microwave screwing up a wifi connection.

> 
>> I think this download manager must have a simple GUI and as few
>> features as possible.
>>
>> I'm not sure what I think of Iceweasel integration.
>>
>> I don't intend to put much energy into that, but still, I searched
>> a bit the Debian packages database with that usecase in mind.
>>
>>> If so, [uget](http://urlget.sourceforge.net/) could be a good
>>> candidate.
>>
>> * uget - easy-to-use download manager written in GTK+: from
>>   the package long description, looks a bit too feature-full.
>>
>> I did not find any other candidate in Debian that integrates with the
>> web browser. Outside of it, there are:
>>
>> * steadyflow - Simple download manager for GNOME: in Wheezy, not in
>>   Squeeze; a quick look at the build-deps makes me think a backport
>>   is doable. Aims for minimalism and ease of use.
>> * multiget - graphical download manager: in Squeeze and Wheezy; from
>>   the package long description, looks a bit too feature-full.
>> * kget: depends on many parts of KDE, so that's a no.
> 
> I'll add this resaerch to the ticket once an agreement is reached.

We need this in Tor Browser in general - I wish there was an easy to use
download/upload manager (you know, like the browser itself should be...)
that was well integrated in general.

All the best,
Jacob

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails: pcmcia / firewire / etc.

2012-10-12 Thread Jacob Appelbaum 
Alan:
> Hi,
> 
>>> * de-activate PCMCIA and ExpressCard on systems that don't have any
>>>   PCMCIA or ExpressCard devices after running for 5 minutes. This is
>>>   going to byte some users, but probably only the first time.
>>
>> I am strongly inclined towards this one, for PCMCIA, ExpressCard
>> FireWire and even Bluetooth.
> 
> Seems this could be a consensus. Without disagremment before Oct 19 I
> consider this as agreed.
> 

I would add Thunderbolt to the list as well:
http://www.breaknenter.org/2012/02/adventures-with-daisy-in-thunderbolt-dma-land-hacking-macs-through-the-thunderbolt-interface/

All the best,
Jacob

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Pidgin Protocols Safe?

2012-10-12 Thread adrelanos 
intrigeri:
> adrelanos wrote (12 Oct 2012 13:02:35 GMT) :
>> Just created a wishlist item.
> 
> adrenalos,
> you created 4 such items in there since the beginning on the month.

You told me to create a wishlist item.

https://tails.boum.org/forum/Tails_without_Tor___40__behind_Transparent_Proxy__41__/

Well, long time ago, but I finally did. Perhaps I have read way to often
"create a wishlist item" in the forums and took you up on that.

Are my wishlist items a disturbance? Do you wish less wishlist items?

> This is great to see you care about that many aspects of Tails,
> but it's not clear to me what you expect to happen as a result.

Sharing ideas, feedback, someone popping up to do it, turning wishlist
into todo, turning into implementation, turning into patches welcome or no.

> I need to make sure you're aware that IIRC no item from this
> (long) wishlist has ever been turned into releasable code
> or documentation.

Wasn't aware of this.

> Risking to state the obvious, it seems to me that if you really care
> about a topic, the most realistic way to turn it into something real
> is to fix / implement it yourself, or find someone who wants to do so.

Glad, you took the risk. I didn't know. Thanks.

Cheers,
adrelanos
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Design doc update

2012-10-12 Thread Ague Mill 
On Fri, Oct 12, 2012 at 08:30:57PM +, Alan wrote:
> The following commit would require an update of the design doc, which
> I didn't find:
> 
> commit 4be2ee47b30f851a0006c894214e84c8c71ea146
> Author: Tails developers 
> Date:   Tue Oct 9 13:00:27 2012 +0200
> 
> Allow amnesia user to use Tor's TransPort.
> 
> If you are its author, please update it or point me to the commits I
> didn't found (or state you won't do it and somebody else should
> volonteer).

This is already documented in
:

The Tor software is currently configured as a client only (onion
proxy). The client listens [...] as a transparent proxy on port 9040
(only used for remapped hidden services) [...].

The aforementioned port is useless since 0.13 as no applications run by
the main user (amnesia) is able to acces it. This commit fix a
regression introduced when adding more restrictions for outgoing
packets.

-- 
Ague


pgpIHcZRKZMVp.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

[Tails-dev] Design doc update

2012-10-12 Thread Alan 
The following commit would require an update of the design doc, which
I didn't find:

commit 4be2ee47b30f851a0006c894214e84c8c71ea146
Author: Tails developers 
Date:   Tue Oct 9 13:00:27 2012 +0200

Allow amnesia user to use Tor's TransPort.

If you are its author, please update it or point me to the commits I
didn't found (or state you won't do it and somebody else should
volonteer).

Thanks by advance

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Download manager

2012-10-12 Thread Alan 
Hi,
> From: intrigeri 
> Date: Fri, 28 Sep 2012 17:47:50 +0200
>
> Hi,
> 
> a...@boum.org wrote (26 Sep 2012 17:44:20 GMT) :
> > https://tails.boum.org/todo/include_download_manager/
> > -
> > [...] it might be useful to include a download managar in Tails.
> > A usecase could be to try to download a big file across separate
> > working sessions.
> 
> I think this usecase is worth supporting, e.g. to make it easier to
> download ISO images such as Tails' ones. I would consider it
> relatively low-priority, though.
> 
I do agree. Others?

> I think this download manager must have a simple GUI and as few
> features as possible.
> 
> I'm not sure what I think of Iceweasel integration.
> 
> I don't intend to put much energy into that, but still, I searched
> a bit the Debian packages database with that usecase in mind.
> 
> > If so, [uget](http://urlget.sourceforge.net/) could be a good
> > candidate.
> 
> * uget - easy-to-use download manager written in GTK+: from
>   the package long description, looks a bit too feature-full.
> 
> I did not find any other candidate in Debian that integrates with the
> web browser. Outside of it, there are:
> 
> * steadyflow - Simple download manager for GNOME: in Wheezy, not in
>   Squeeze; a quick look at the build-deps makes me think a backport
>   is doable. Aims for minimalism and ease of use.
> * multiget - graphical download manager: in Squeeze and Wheezy; from
>   the package long description, looks a bit too feature-full.
> * kget: depends on many parts of KDE, so that's a no.

I'll add this resaerch to the ticket once an agreement is reached.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails: pcmcia / firewire / etc.

2012-10-12 Thread Alan 
Hi,

>> * de-activate PCMCIA and ExpressCard on systems that don't have any
>>   PCMCIA or ExpressCard devices after running for 5 minutes. This is
>>   going to byte some users, but probably only the first time.
>
> I am strongly inclined towards this one, for PCMCIA, ExpressCard
> FireWire and even Bluetooth.

Seems this could be a consensus. Without disagremment before Oct 19 I
consider this as agreed.

Cheers


___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Upstreaming yelp patch

2012-10-12 Thread Ague Mill 
On Fri, Oct 12, 2012 at 05:52:50PM +0200, intrigeri wrote:
> to anyone who pushed commit 64de544 ("Fix Yelp crashing on internal
> links"):
> 
> 1. Congrats!
> 2. Please open a ticket about upstreaming this fix.

I don't see the need:

 * GNOME documentation is not affected as far as I have seen,
 * Yelp has been heavily rewritten since Squeeze. I have not tested,
   but I doubt the bug is still in the version in Wheezy.

What we could do is to try to push a fix in the next Debian Squeeze
point release, but I don't think the bug is severe enough, as it does
not show up when browsing GNOME documentation.

I'd be happy to be convinced otherwise, though.

-- 
Ague


pgpjwC4XeDfuH.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Pidgin Protocols Safe?

2012-10-12 Thread intrigeri 
adrelanos wrote (12 Oct 2012 13:02:35 GMT) :
> Just created a wishlist item.

adrenalos,
you created 4 such items in there since the beginning on the month.
This is great to see you care about that many aspects of Tails,
but it's not clear to me what you expect to happen as a result.

I need to make sure you're aware that IIRC no item from this
(long) wishlist has ever been turned into releasable code
or documentation.

Risking to state the obvious, it seems to me that if you really care
about a topic, the most realistic way to turn it into something real
is to fix / implement it yourself, or find someone who wants to do so.

Cheers!
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

[Tails-dev] Upstreaming yelp patch

2012-10-12 Thread intrigeri 
hi,

to anyone who pushed commit 64de544 ("Fix Yelp crashing on internal
links"):

1. Congrats!
2. Please open a ticket about upstreaming this fix.

cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Pidgin Protocols Safe?

2012-10-12 Thread intrigeri 
anonym wrote (12 Oct 2012 13:06:51 GMT) :
> 12/10/12 09:47, intrigeri wrote:
>> 
>>> Pidgin also contains STUN [4], a nice feature for clearnet use, but is
>>> it safe in Tails?
>> 
>> I don't think we have researched this.
>> Is it enabled? Is it easy to disable?

> I disabled it in commit c2a541b, but it has never been an issue for as
> long the firewall has rejected outgoing UDP traffic.

Great! Care to add two lines to our design document about that?

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Pidgin Protocols Safe?

2012-10-12 Thread adrelanos 
antispa...@sent.at:
>>> I'm not sure what you mean here. Do you think people who want to
>>> create their first IM account would choose the first in the Pidgin
>>> protocols list?
>> Something like this.
> 
> Actually they are going to go for what their friends or contacts use.
> This is not some grand study. Just an observation from the people around
> me.

It's tempting to do that.

Off topic, but to show my point: Did you know, that Winny and Share are
the most used filesharing clients in Japan? They are closed source, use
weak crypto/design but actually "do work". I've never heard of those
applications before. (Recently discussed on tor-talk.)

Observing people around me, absolutely didn't lead to that conclusion.
We actually know very little about Tor users around the world. With all
due respect, I wouldn't conclude from personal observation.

Observing the number of starred / forked [2] repositories and downloads
[2], it looks like TorChat is quite popular among Tor users.

[1] https://github.com/prof7bit/TorChat
[2] https://github.com/prof7bit/TorChat/downloads
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Pidgin Protocols Safe?

2012-10-12 Thread antispam06 
On Fri, Oct 12, 2012, at 15:02, adrelanos wrote:
> intrigeri:
> > I doubt Tails should allow or filter access to remote content or
> > services depending on the remote side's privacy policies
> > and practices.
> Yes, privacy by design is stronger than privacy by policy. Just in this
> case I am using their privacy by policy to assume...

Hmm... actually, anything is better than privacy by policy. To make
things worse, the temptation to use the data is very high and, in
compensation, the punishment for ignoring the policy is NULL.

> > I'm not sure what you mean here. Do you think people who want to
> > create their first IM account would choose the first in the Pidgin
> > protocols list?
> Something like this.

Actually they are going to go for what their friends or contacts use.
This is not some grand study. Just an observation from the people around
me. And the intelectual work involved to have a second yahoo account is
never thought worthy. Forget the second protocol. Geeks do experiment as
they have a lot of time to waste. Normal people have only one. Even if
the geek perceives two: oh, but I haven't started Yahoo Messenger in
months because I use skype to call my in laws.

> > I believe most of them would choose what their
> > friends use.
> What about groups who want to switch their activities to Tor or people
> who want to create an anonymous contact address for whatever use case?

I think that would be far easier to obtain if people would get to move /
upgrade to the safer / newer open protocols. Myself I have zero success
in getting people to even try OTR. Sure, they would have all the time in
the Word to cry later on when the insurance company would crunch the
data and raise their rates. But, even than, it would be far easier to
point the finger at the corporation than do anything about it.

Cheers!
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Pidgin Protocols Safe?

2012-10-12 Thread anonym 
12/10/12 09:47, intrigeri wrote:
> 
>> Pidgin also contains STUN [4], a nice feature for clearnet use, but is
>> it safe in Tails?
> 
> I don't think we have researched this.
> Is it enabled? Is it easy to disable?

I disabled it in commit c2a541b, but it has never been an issue for as
long the firewall has rejected outgoing UDP traffic.

Cheers!

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Pidgin Protocols Safe?

2012-10-12 Thread adrelanos 
intrigeri:
>> Did you check, what kind of "innovative" features the other protocols
>> have? I didn't check, but could imagine they include something similar
>> like CTCP, dishonor proxy settings for file transfer, or send your IP
>> somewhere. (STUN)
> 
> I don't think we've checked. Help is welcome :)

Just created a wishlist item. I don't think I am skilled to review them
on a protocol or code base.

On the following wiki page I created an overview about the protocols.
Their default encryption settings. Often default is "if available".
Interestingly one protocol, Gadu-Gadu doesn't let you enforce encryption
and is subsequently vulnerable to encryption strip attacks.

One dangerous feature could be the file transfer proxy in some protocols.

I don't know either if accidentally activating or answering voice or
video is at risk. You have todo/done mute microphone, but what about
webcams?

https://tails.boum.org/todo/Pidgin_Protocol_Review/

>> Pidgin also contains STUN [4], a nice feature for clearnet use, but is
>> it safe in Tails?
> 
> I don't think we have researched this.
> Is it enabled? Is it easy to disable?

I don't know.

Use automatically detected IP address: 192.x.x.x is opt-in by default.

Stun server - default: empty
with a hint "Example: stunserver.org".

Haven't looked if stun also works without entering a server.

I could imagine if you google file transfer problems with Pidgin that
the suggestion will be given to enter the stunserver.org and it's also
obvious to try when you look through the settings. Hopefully people
using Tails users abstain from such experiments. I could be totally
wrong and it could allow flawless file transfers over Tor.

> (BTW, link [4] is missing in your email.)

Oops. It was just a link to the wiki article.
https://en.wikipedia.org/wiki/STUN By the way not because I am not sure
you figure out, just to ensure we are talking about the same thing.
Often those acronym have several meanings.

>> Many of the protocols are proprietary. I find their so called
>> "privacy policy" [2] and aup [3] highly questionable.
> 
> I doubt Tails should allow or filter access to remote content or
> services depending on the remote side's privacy policies
> and practices.

Yes, privacy by design is stronger than privacy by policy. Just in this
case I am using their privacy by policy to assume...

>> Is support for AIM/ICQ/MSN/[...] important? It's fine for circumvention,
>> if users want to chat with their existing list.
> 
> I think it's important to allow users to move part or all of their
> computer activities to Tails, while keeping their existing
> communication channels, at least to start with.

Agreed.

> I think it's important to educate Internet users to use better
> (privacy-wise) protocols, but it's not exactly part of the Tails
> mission. I'm happy that other projects do the education part of
> the work.

Sure, some thing are outside the scope.

>> But people looking for privacy, why should they sign up for
>> AIM/ICQ/MSN/[...]? It's sad, that AIM is on the top of the
>> protocol list.
> 
> I'm not sure what you mean here. Do you think people who want to
> create their first IM account would choose the first in the Pidgin
> protocols list?

Something like this.

> I believe most of them would choose what their
> friends use.

What about groups who want to switch their activities to Tor or people
who want to create an anonymous contact address for whatever use case?
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

[Tails-dev] Call for testing 0.14~rc1

2012-10-12 Thread anonym 
Hi!

This is the 'official' call for testing the first release candidate of
the upcoming version 0.14 of Tails. Please test it and see if all works
for you. All information you need for this can be found here:



Happy testing!

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Block/unblock wireless devices?

2012-10-12 Thread intrigeri 
hi,

a...@boum.org wrote (02 Oct 2012 16:59:55 GMT) :
> Do this discussion on details means that we agree on the main general
> idea? If it is the case, who volonteers to create a ticked?

Bluetooth is handled separately, and there was some confusion in this
thread, so here's an updated proposal.

At boot time:

 * unblock Wi-Fi, WWAN and WiMAX
 * ignore Bluetooth (see other proposal)
 * soft-block all other kind of wireless devices (UWB, GPS, FM)

+ write a short documentation page about how to manually unblock
a blocked device (e.g. GPS).

Deadline: Friday, October 19th.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails webbrowser homepage

2012-10-12 Thread intrigeri 
intrigeri wrote (02 Oct 2012 17:10:39 GMT) :
>> So do we agree to set the homepage to "news" as soon as it is
>> translateable? May I update the ticket accordinately?

> Deadline: Friday at noon CEST.

Created todo/set_iceweasel_homepage_to_Tails_news,
closed todo/decide_what_web_homepage_to_use.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails: pcmcia / firewire / etc.

2012-10-12 Thread intrigeri 
Hi,

intrigeri wrote (28 Sep 2012 15:27:50 GMT) :
>> * de-activate PCMCIA and ExpressCard on systems that don't have any
>>   PCMCIA or ExpressCard devices after running for 5 minutes. This is
>>   going to byte some users, but probably only the first time.

> I am strongly inclined towards this one, for PCMCIA, ExpressCard
> FireWire and even Bluetooth.

That was two weeks ago, and the only other expressed opinion (Ague's)
was in favor of the same. Looks like we've got a consensus, right?

Deadline: Friday, October 19th.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] live-boot_3.0~b4-1_i386.changes ACCEPTED into unstable

2012-10-12 Thread intrigeri 
intrigeri wrote (27 Sep 2012 12:13:41 GMT) :
> Hi,

> Debian FTP Masters wrote (27 Sep 2012 11:32:32 GMT) :
>> Changes:
>>  live-boot (3.0~b4-1) unstable; urgency=low
>>  .
>>* Switching to final name for the persistence configuration file
>>  'persistence.conf' in line with boot parameter.
>> [...]

> Is this change really meant for the 3.x series,
> or is this the result of some unfortunate mistake?

Apparently, this is meant to stay.

I created todo/newer_live-boot to track this and other issues that we
should be aware of when we upgrade.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Pidgin Protocols Safe?

2012-10-12 Thread intrigeri 
Hi,

adrelanos wrote (11 Oct 2012 17:16:44 GMT) :
> I am concerned about the many [1] protocols Pidgin supports.

Thanks for caring about this.

> Did you check, what kind of "innovative" features the other protocols
> have? I didn't check, but could imagine they include something similar
> like CTCP, dishonor proxy settings for file transfer, or send your IP
> somewhere. (STUN)

I don't think we've checked. Help is welcome :)

> Pidgin also contains STUN [4], a nice feature for clearnet use, but is
> it safe in Tails?

I don't think we have researched this.
Is it enabled? Is it easy to disable?

(BTW, link [4] is missing in your email.)

> Many of the protocols are proprietary. I find their so called
> "privacy policy" [2] and aup [3] highly questionable.

I doubt Tails should allow or filter access to remote content or
services depending on the remote side's privacy policies
and practices.

> Is support for AIM/ICQ/MSN/[...] important? It's fine for circumvention,
> if users want to chat with their existing list.

I think it's important to allow users to move part or all of their
computer activities to Tails, while keeping their existing
communication channels, at least to start with.

I think it's important to educate Internet users to use better
(privacy-wise) protocols, but it's not exactly part of the Tails
mission. I'm happy that other projects do the education part of
the work.

> But people looking for privacy, why should they sign up for
> AIM/ICQ/MSN/[...]? It's sad, that AIM is on the top of the
> protocol list.

I'm not sure what you mean here. Do you think people who want to
create their first IM account would choose the first in the Pidgin
protocols list? I believe most of them would choose what their
friends use.

Cheers!
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev