Re: [Tails-dev] Faking htpdate user agent worth it?

2012-10-02 Thread Jacob Appelbaum
adrelanos:
> Jacob Appelbaum:
>> adrelanos:
> Thus my suggestions:
> - Keep only header. Safe users traffic, Tor's traffic and website traffic.
> - Drop the user agent setting, it only gives a false sense of being in
> the same anonymity set as Tor Button.

 That is not the goal - the point is that you will say, drop that and no
 one else will do so - so you will entirely stick out.
>>>
>>> Well, don't drop it individually or right away. Drop it in a new release.
>>>
>>
>> And I am saying - TBB won't drop their user agent. So you won't look
>> like them - you will look like you.
> 
> What TBB does is not important for this case. You will look like wget,
> so or so. See below.

It is important to look like TBB or another case - if you use TBB to
fetch a single item - lets say an image like a favicon - I'd probably
want to match the headers it sends. Per request.

> 
>
> [1] Not exactly impossible. The curl devs would have to change too much,
> extremely unlikely.

 I don't use curl with tlsdate.
>>>
>>> Replace curl with a placeholder for any command line downloader.
>>>
>>
>> I think you are confused.
> 
> I don't want to deny the possibility.
> 
>> If I send a GET request with all the headers
>> sent by say, Tor Browser, that *single* GET request should look
>> identical. That is my goal.
> 
> A honorable goal.
> 
> I made a quick test with Wireshare visiting cnn.com as an example. With
> Tor Browser I had the page open for 1 minute. It connects to at least 6
> different IPs (just saying no criticism), downloads (temporary to show
> in browser) lots of pictures. The log grows much faster.
> 
> Then I issued "wget cnn.com". It only connects to two IPs (1
> redirection). The log is much smaller. Wget does not fetch pictures.
> 

wget -m would but that is rather beside the point, I think.

> It's trivial for the website owner, if he wants to, to find out if his
> website gets visited with Tor Browser by a real user or if it gets
> downloaded with a tool like wget.
> 

Not really. It is *possible* if someone using TBB to explicitly visit a
single page or fetch a single resource.

> If you use wget, you look like wget, no matter which user agent you
> choose. So what's the point for Tails to add extra identifying bits?
> (curl + Tor Button user agent)
> 

The point is that not every single request needs to stand out - in
aggregate, yes, some people may look differently. I'd rather stand out
only in aggregate.

> I think the the user agent switcher feature of command line downloaders
> is not supposed to be a privacy feature. They probable added it to fetch
> different versions of sites, one for firefox, one for mobile phones and
> so on. This does not apply here, since you just want the header for the
> time.

I think you're confused still - a single GET request can be constructed
without the use of a library or another program.

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


Re: [Tails-dev] Shipping a 686-pae kernel

2012-10-02 Thread Ague Mill
On Sat, Sep 29, 2012 at 05:50:05PM +0200, intrigeri wrote:
> > What's your opinion? Should I proceed in adding a custom
> > `python-dbus` to the multikernel branch?
> 
> Please proceed: at least so that we can verify that this hack
> workarounds the bug in various settings.

Done. Merged in experimental. My tests are still conclusive and I really
think the branch should be reviewed one more time and merged in devel
now.
 
> I'm fine with shipping a patched python-dbus in Tails (obviously, as
> long as we report the bug and forward the patch at least to Debian).

If the bug is still reproducible in Wheezy, it has to be done. But I am
really unsure on the best place to actually report the bug. Someone
would probably have to come up with a smaller test case, too.

-- 
Ague


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


Re: [Tails-dev] Shipping a 686-pae kernel

2012-10-02 Thread Ague Mill
On Sat, Sep 29, 2012 at 08:42:37PM +0200, intrigeri wrote:
> These Vagrant / memory tweaks made in the feature/multikernel branch
> should be re-done there, as they conflicted with those made in
> feature/vagrant and since then merged into devel, which I've just
> merged back into feature/multikernel.

I don't think they are neeeded anymore after the various improvements to
the build system that was made.

-- 
Ague


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


Re: [Tails-dev] Faking htpdate user agent worth it?

2012-10-02 Thread adrelanos
Jacob Appelbaum:
> adrelanos:
 Thus my suggestions:
 - Keep only header. Safe users traffic, Tor's traffic and website traffic.
 - Drop the user agent setting, it only gives a false sense of being in
 the same anonymity set as Tor Button.
>>>
>>> That is not the goal - the point is that you will say, drop that and no
>>> one else will do so - so you will entirely stick out.
>>
>> Well, don't drop it individually or right away. Drop it in a new release.
>>
> 
> And I am saying - TBB won't drop their user agent. So you won't look
> like them - you will look like you.

What TBB does is not important for this case. You will look like wget,
so or so. See below.


 [1] Not exactly impossible. The curl devs would have to change too much,
 extremely unlikely.
>>>
>>> I don't use curl with tlsdate.
>>
>> Replace curl with a placeholder for any command line downloader.
>>
> 
> I think you are confused.

I don't want to deny the possibility.

> If I send a GET request with all the headers
> sent by say, Tor Browser, that *single* GET request should look
> identical. That is my goal.

A honorable goal.

I made a quick test with Wireshare visiting cnn.com as an example. With
Tor Browser I had the page open for 1 minute. It connects to at least 6
different IPs (just saying no criticism), downloads (temporary to show
in browser) lots of pictures. The log grows much faster.

Then I issued "wget cnn.com". It only connects to two IPs (1
redirection). The log is much smaller. Wget does not fetch pictures.

It's trivial for the website owner, if he wants to, to find out if his
website gets visited with Tor Browser by a real user or if it gets
downloaded with a tool like wget.

If you use wget, you look like wget, no matter which user agent you
choose. So what's the point for Tails to add extra identifying bits?
(curl + Tor Button user agent)

I think the the user agent switcher feature of command line downloaders
is not supposed to be a privacy feature. They probable added it to fetch
different versions of sites, one for firefox, one for mobile phones and
so on. This does not apply here, since you just want the header for the
time.

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


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

2012-10-02 Thread intrigeri
a...@boum.org wrote (02 Oct 2012 16:59:55 GMT) :
>> From: intrigeri 
>> Date: Fri, 28 Sep 2012 17:14:04 +0200
>> 
>> Alternatively, how about killing Bluetooth support with rfkill at boot
>> time iff. no (input?) device is connected this way?

> Do this discussion on details means that we agree on the main general
> idea?

Note that this has been proposed as a general solution, Bluetooth
included, in the "Tails: pcmcia / firewire / etc." discussion too.
We might want to make a decision on this topic as a whole there.

> If it is the case, who volonteers to create a ticked?

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


Re: [Tails-dev] Tails webbrowser homepage

2012-10-02 Thread intrigeri
> 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.

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


Re: [Tails-dev] Tails webbrowser homepage

2012-10-02 Thread alan

> From: intrigeri 
> Date: Fri, 28 Sep 2012 17:30:09 +0200
> 
> a...@boum.org wrote (26 Sep 2012 17:44:48 GMT) :
> > > We started to discuss this, and the most up-to-date proposal
> > > would be to point the homepage to our online website's "News"
> > > page, that would e.g. announce new release candidates to
> > > test etc.
> 
> I'm in favor of that one.
> 
> I think a prerequisite is to make the "news" section translatable:
> todo/make_the_news_translatable

So do we agree to set the homepage to "news" as soon as it is
translateable? May I update the ticket accordinately?


-- 


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


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

2012-10-02 Thread alan

> From: intrigeri 
> Date: Fri, 28 Sep 2012 17:14:04 +0200
> 
> Hi,
> 
> intrigeri wrote (25 Sep 2012 08:15:28 GMT) :
> > Ague Mill wrote (25 Sep 2012 07:53:02 GMT) :
> >> Bluetooth can be problematic. Some systems use Bluetooth to
> >> communicate with their keyboards and mouses.
> 
> > OK. Let's keep Bluetooth enabled, then :(
> 
> Alternatively, how about killing Bluetooth support with rfkill at boot
> time iff. no (input?) device is connected this way?

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?

Cheers


-- 


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


Re: [Tails-dev] Please review and merge feature/persistent_NM_connections [was: tails-persistence-setup releases vs. Tails 0.14]

2012-10-02 Thread alan

> From: anonym 
> Date: Tue, 2 Oct 2012 15:14:58 +0200
> 
[...]
> 
> If the rest of you agree that all is good now, please review and merge
> this branch into devel so it can be included in Tails 0.14.
> 
Please merge the new state of this branch to experimental.

And, by the way, is there a good reason this page is still tagged
'discuss' ?


-- 


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


Re: [Tails-dev] Faking htpdate user agent worth it?

2012-10-02 Thread Jacob Appelbaum
adrelanos:
>>> Thus my suggestions:
>>> - Keep only header. Safe users traffic, Tor's traffic and website traffic.
>>> - Drop the user agent setting, it only gives a false sense of being in
>>> the same anonymity set as Tor Button.
>>
>> That is not the goal - the point is that you will say, drop that and no
>> one else will do so - so you will entirely stick out.
> 
> Well, don't drop it individually or right away. Drop it in a new release.
> 

And I am saying - TBB won't drop their user agent. So you won't look
like them - you will look like you.

>>>
>>> [1] Not exactly impossible. The curl devs would have to change too much,
>>> extremely unlikely.
>>
>> I don't use curl with tlsdate.
> 
> Replace curl with a placeholder for any command line downloader.
> 

I think you are confused. If I send a GET request with all the headers
sent by say, Tor Browser, that *single* GET request should look
identical. That is my goal.

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


Re: [Tails-dev] Faking htpdate user agent worth it?

2012-10-02 Thread adrelanos
Jacob Appelbaum:
> adrelanos:
>> Jacob Appelbaum:
>>> intrigeri:
 Hi,

 adrelanos wrote (30 Sep 2012 22:25:31 GMT) :
> I am wondering about this line in /etc/default/htpdate:
> HTTP_USER_AGENT="$(/usr/local/bin/getTorbuttonUserAgent)"

 FTR, this is left from the times when htpdate did run wget in the
 clear (without going through Tor).

> Since you are also using curl and only download the header, does
> faking the Tor Button user agent provide any additional benefit?
> Couldn't the server quite easily distinguish from real Tor Button
> users and tails_htp curl users?

 It may be worse than what you are suggesting.

 If iceweasel + Torbutton rarely, if ever, sends HTTP HEAD requests,
 then we should probably not pretend to be Torbutton. Does it?
>>>
>>> The more software that pretends to be TorButton - the better, I think.
>>
>> As a political statement?
> 
> No. As a feature for feature match - it is true that there are other
> protocol distinguishers and ... so what?
> 
>>
>> >From technical view it's impossible [1] to imitate Tor Button with curl.
>> The user agent is just one bit, there are loads of other bits to find
>> out if someone is actually running Tor Browser and curl.
>>
> 
> I don't care about curl at all.

Same goes for all command line downloader.

>> Just download for testing cnn.com with curl and look how much traffic
>> has been transfered and how quick it goes, even if fetching the whole
>> page, not just the header. Then watch the same thing in Tor Browser. It
>> fetches loads of pictures and also connects to doubleclick and other
>> third party sites.
> 
> Indeed.
> 
>>
>> Thus my suggestions:
>> - Keep only header. Safe users traffic, Tor's traffic and website traffic.
>> - Drop the user agent setting, it only gives a false sense of being in
>> the same anonymity set as Tor Button.
> 
> That is not the goal - the point is that you will say, drop that and no
> one else will do so - so you will entirely stick out.

Well, don't drop it individually or right away. Drop it in a new release.

>>
>> [1] Not exactly impossible. The curl devs would have to change too much,
>> extremely unlikely.
> 
> I don't use curl with tlsdate.

Replace curl with a placeholder for any command line downloader.

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

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


Re: [Tails-dev] Please review and merge feature/persistent_NM_connections [was: tails-persistence-setup releases vs. Tails 0.14]

2012-10-02 Thread intrigeri
Hi,

Ague Mill wrote (02 Oct 2012 14:08:05 GMT) :
>> * "Connect automatically" checkbox gets unchecked on each boot: IMHO
>>   this bug is good :). Hence we can ignore this for now and just
>>   mention it as a known issue (commit 0f7f652).

> We have to rule this as either a bug or a feature. In my views, it
> is a feature and we just have to state it that way: Tails do not
> connect automatically to networks it was previously connected to.

> So I'd rather remove the addition to known issues, and document that
> behaviour better on `doc/first_steps/persistence/configure`.

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


Re: [Tails-dev] Please review and merge feature/persistent_NM_connections [was: tails-persistence-setup releases vs. Tails 0.14]

2012-10-02 Thread intrigeri
Hi,

anonym wrote (02 Oct 2012 13:14:58 GMT) :
> 30/09/12 21:01, intrigeri wrote:
>> please, anyone who did the 0.18 release of tails-persistence-setup,
>> push your pristine-tar branch.

> I followed the instructions in
> contribute/release_process/persistence-setup, and that branch wasn't
> modified (i.e. it's still at commit 0bc2057).

Looks like you have pristine-tar disabled in your gbp configuration.
That's probably the default. I've just added "pristine-tar = True" to
debian/gbp.conf in the debian branch, so that won't happen anymore,
regardless of individual's configuration.

> How can I fix this?

I would try re-doing the git-import-orig, with the --no-merge option.
Some steps are likely to fail, because they were run already. Then,
I would reset --hard the upstream and debian branches to their
previous state (the current one, as of when I'm writing), and then
push the pristine-tar branch updated with the missing orig
tarball delta.

> todo/persistence_preset_-_NM_connections has been implemented in
> feature/persistent_NM_connections. IMHO it's now in a good enough
> shape to be shipped in Tails 0.14, but there are some issues (see
> todo page):

Great! I hope it makes it into 0.14.

> If the rest of you agree that all is good now, please review and merge
> this branch into devel so it can be included in Tails 0.14.

Some notes from a (too quick) static review follow.
I'll test that code once it is merged into experimental.

> +name=> $self->encoding->decode(gettext(q{NetworkManager 
> connections})),
> +description => $self->encoding->decode(gettext(
> +q{Network connections}
> +)),

I'm not sure end-users know what NetworkManager is, and/or want to
learn about its name. I suggest:

  * name = "Network Connections"
(Which uses title capitalization, like other existing presets.)
  * description = "Configuration of network devices and connections"
(All credits due to the NM applet About dialog text.)

What do you think?

Also, any thoughts about how we'll handle the migration to dconf when
Tails is based on Wheezy? (Not a blocker, I think, but still.)

To end with, I've pushed a minor doc rephrasing to that branch.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev


Re: [Tails-dev] Please review and merge feature/persistent_NM_connections [was: tails-persistence-setup releases vs. Tails 0.14]

2012-10-02 Thread Ague Mill
>   Since live-persist is the glue that fixes all the quirks we have
>   with live-boot's vanilla persistence, this seems like a perfect fit.
>   This is done in commits 77c3261 and 4db38e9.

Looks nicer this way.

The function `fix_gconf_dirs` might benefit from some more quoting of
the variables. Maybe filesystem corruption could put a space
somewhere bad...

> * "Connect automatically" checkbox gets unchecked on each boot: IMHO
>   this bug is good :). Hence we can ignore this for now and just
>   mention it as a known issue (commit 0f7f652).

We have to rule this as either a bug or a feature. In my views, it is a
feature and we just have to state it that way: Tails do not connect
automatically to networks it was previously connected to.

So I'd rather remove the addition to known issues, and document that
behaviour better on `doc/first_steps/persistence/configure`.
 
No tests done yet, but it looks good so far! :)

-- 
Ague


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


Re: [Tails-dev] Faking htpdate user agent worth it?

2012-10-02 Thread Jacob Appelbaum
adrelanos:
> Jacob Appelbaum:
>> intrigeri:
>>> Hi,
>>>
>>> adrelanos wrote (30 Sep 2012 22:25:31 GMT) :
 I am wondering about this line in /etc/default/htpdate:
 HTTP_USER_AGENT="$(/usr/local/bin/getTorbuttonUserAgent)"
>>>
>>> FTR, this is left from the times when htpdate did run wget in the
>>> clear (without going through Tor).
>>>
 Since you are also using curl and only download the header, does
 faking the Tor Button user agent provide any additional benefit?
 Couldn't the server quite easily distinguish from real Tor Button
 users and tails_htp curl users?
>>>
>>> It may be worse than what you are suggesting.
>>>
>>> If iceweasel + Torbutton rarely, if ever, sends HTTP HEAD requests,
>>> then we should probably not pretend to be Torbutton. Does it?
>>
>> The more software that pretends to be TorButton - the better, I think.
> 
> As a political statement?

No. As a feature for feature match - it is true that there are other
protocol distinguishers and ... so what?

> 
>>From technical view it's impossible [1] to imitate Tor Button with curl.
> The user agent is just one bit, there are loads of other bits to find
> out if someone is actually running Tor Browser and curl.
> 

I don't care about curl at all.

> Just download for testing cnn.com with curl and look how much traffic
> has been transfered and how quick it goes, even if fetching the whole
> page, not just the header. Then watch the same thing in Tor Browser. It
> fetches loads of pictures and also connects to doubleclick and other
> third party sites.

Indeed.

> 
> Thus my suggestions:
> - Keep only header. Safe users traffic, Tor's traffic and website traffic.
> - Drop the user agent setting, it only gives a false sense of being in
> the same anonymity set as Tor Button.

That is not the goal - the point is that you will say, drop that and no
one else will do so - so you will entirely stick out.

> 
> [1] Not exactly impossible. The curl devs would have to change too much,
> extremely unlikely.

I don't use curl with tlsdate.

All the best,
Jacob

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


Re: [Tails-dev] Faking htpdate user agent worth it?

2012-10-02 Thread adrelanos
Jacob Appelbaum:
> intrigeri:
>> Hi,
>>
>> adrelanos wrote (30 Sep 2012 22:25:31 GMT) :
>>> I am wondering about this line in /etc/default/htpdate:
>>> HTTP_USER_AGENT="$(/usr/local/bin/getTorbuttonUserAgent)"
>>
>> FTR, this is left from the times when htpdate did run wget in the
>> clear (without going through Tor).
>>
>>> Since you are also using curl and only download the header, does
>>> faking the Tor Button user agent provide any additional benefit?
>>> Couldn't the server quite easily distinguish from real Tor Button
>>> users and tails_htp curl users?
>>
>> It may be worse than what you are suggesting.
>>
>> If iceweasel + Torbutton rarely, if ever, sends HTTP HEAD requests,
>> then we should probably not pretend to be Torbutton. Does it?
> 
> The more software that pretends to be TorButton - the better, I think.

As a political statement?

>From technical view it's impossible [1] to imitate Tor Button with curl.
The user agent is just one bit, there are loads of other bits to find
out if someone is actually running Tor Browser and curl.

Just download for testing cnn.com with curl and look how much traffic
has been transfered and how quick it goes, even if fetching the whole
page, not just the header. Then watch the same thing in Tor Browser. It
fetches loads of pictures and also connects to doubleclick and other
third party sites.

Thus my suggestions:
- Keep only header. Safe users traffic, Tor's traffic and website traffic.
- Drop the user agent setting, it only gives a false sense of being in
the same anonymity set as Tor Button.

[1] Not exactly impossible. The curl devs would have to change too much,
extremely unlikely.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev


[Tails-dev] Please review and merge feature/persistent_NM_connections [was: tails-persistence-setup releases vs. Tails 0.14]

2012-10-02 Thread anonym
30/09/12 21:01, intrigeri wrote:
> Hi,
> 
> please, anyone who did the 0.18 release of tails-persistence-setup,
> push your pristine-tar branch.

I followed the instructions in
contribute/release_process/persistence-setup, and that branch wasn't
modified (i.e. it's still at commit 0bc2057). How can I fix this?

> Other than that, a 0.18 release was made from the usual branches in
> there, with stuff that is not be ready yet for merging into devel.
> One drawback is that it has apparently blocked an improved t-p-s (with
> bigger timeout) from entering Tails 0.13. I'd like to avoid this
> happening again. I think we now have two possibilities:
> 
> A. the NM presets persistence is finished and merged in time
>=> t-p-s 0.18 or greater is shipped into Tails 0.14,
>   with a (possibly much) bigger timeout. Great.
> 
> B. the NM presets persistence is not finished and merged in time
>=> I'd rather not fork a branch off t-p-s 0.17 and prepare
>   0.17.1 from there (overkill), so I think we should go for
>   a chroot_local-patches.
> 
> So, I think I'll wait a few days (say, until next Thursday), and go
> with #B if #A has not happened yet. Thoughts, better ideas?

I'm gonna try for #A now:

todo/persistence_preset_-_NM_connections has been implemented in
feature/persistent_NM_connections. IMHO it's now in a good enough shape
to be shipped in Tails 0.14, but there are some issues (see todo page):

* violation of Single Responsibility Principle: Adding a 'gconf'
  persistence option would have to go into upstream live-boot,
  and IMHO this is way too Tails-specific for such inclusion. An
  alternative would be to put the code from commit 1d3cae2 in
  tails-greeter into our custom live-persist script. Since
  live-persist is the glue that fixes all the quirks we have with
  live-boot's vanilla persistence, this seems like a perfect fit.
  This is done in commits 77c3261 and 4db38e9.

* "Connect automatically" checkbox gets unchecked on each boot: IMHO
  this bug is good :). Hence we can ignore this for now and just
  mention it as a known issue (commit 0f7f652).

I also wrote the user documentation (commit 269b672).

If the rest of you agree that all is good now, please review and merge
this branch into devel so it can be included in Tails 0.14.

Cheers!



signature.asc
Description: OpenPGP digital signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev