Re: [Tails-dev] [Secure Desktops] Proposal for Anti-Keystroke Fingerprinting Tool

[★ STMAN ★]

Hello.

Mouse Fingerprinting, Keyboard Fingerprinting, Device Fingerprinting (Active 
collection modes, using hidden channel in the legit TCP/IP trafic going through 
TOR) are specialities that have NO SOLUTION with "software only » approaches.
These problems cannot be solved by software only. The can be fixed definitely 
through 100% Free Integrated Circuits based computers that solve these issue 
through hardware changes.

To me, any attempt to « solve » these issues by software can only be a fraud.

I’m open to debate.

Le 17 mars 2016 à 18:31, ban...@openmailbox.org a écrit :

> == Attack Description ==
> 
> Keystroke fingerprinting works by measuring how long keys are pressed and the 
> time between presses. Its very high accuracy poses a serious threat to 
> anonymous users.[1]
> 
> This tracking technology has been deployed by major advertisers (Google, 
> Facebook), banks and massive online courses. Its also happening at a massive 
> scale because just using a JS application (or SSH in interactive mode) in 
> presence of a network adversary that records all traffic allows them to 
> construct biometric models for virtually everyone (think Google suggestions) 
> even if the website does not record these biometric stats itself.[2] They 
> have this data from everyone's clearnet browsing and by comparing this to 
> data exiting the Tor network they will unmask users.
> 
> == Current Measures and Threat Model ==
> 
> While the Tor Browser team is aware of the problem and working on a solution, 
> current measures [6] are not enough. [4][5]
> 
> Security distros are designed to protect the user even if an end user 
> application is compromised and provide desfense in depth.
> 
> The goal is to protect users even in the event of an attacker taking over an 
> application running ina VM/Container.
> 
> This is valid for systems running in VMs or on bare metal.
> 
> 
> == Existing Work on Countermeasures ==
> 
> As a countermeasure security researcher Paul Moore created a prototype Chrome 
> plugin known as KeyboardPrivacy. It works by caching keystrokes and 
> introducing a random delay before passing them on to a webpage.[3] 
> Unfortunately there is no source code available for the add-on and the 
> planned Firefox version has not surfaced so far. There are hints that the 
> author wants to create a closed hardware soltuion that implements this which 
> does not help our cause.
> 
> 
> == Proposal for a System-wide Solution ==
> 
> A very much needed project would be to write a program that mimics the 
> functionality of the this add-on but on the display server / OS level. 
> Ideally the solution would be compatible with Wayland for the upcoming 
> transition in the near future.
> 
> 
> 
> 
> [1] 
> http://arstechnica.com/security/2015/07/how-the-way-you-type-can-shatter-anonymity-even-on-tor/
> 
> [2] http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=7358795
> 
> [3] https://archive.is/vCvWb
> 
> [4] 
> https://www.lightbluetouchpaper.org/2015/07/30/double-bill-password-hashing-competition-keyboardprivacy/#comment-1288166
> 
> [5] https://trac.torproject.org/projects/tor/ticket/16110
> 
> [6] https://trac.torproject.org/projects/tor/ticket/1517
> 
> 
> 
> ***
> 
> This feature request has been mirrored on each project's bugtrackers 
> respectively:
> 
> https://github.com/subgraph/subgraph-os-issues/issues/103
> https://labs.riseup.net/code/issues/11257
> https://github.com/QubesOS/qubes-issues/issues/1850
> 
> ___
> Desktops mailing list
> deskt...@secure-os.org
> https://secure-os.org/cgi-bin/mailman/listinfo/desktops



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tail 2.2 Ugly as HELL

[Fred Schiff]

what these extensions?

On Thu, Mar 17, 2016 at 7:36 AM, sajolida  wrote:

> freedom-m...@sigaint.org:
> > There is any chance of Tails OS see other version that looks like the
> 1.6?
> > The 2.2 version is UGLY AS HELL.
>
> I agree :)
>
> We switched to GNOME Shell in Classic mode (with the grey menus) because
> we wanted to continue providing the top-left Applications and Places
> menus and the bottom windows list. But this can be achieve equally in
> GNOME Shell without the Classic mode by enabling these extensions.
>
> The thing is that changing the appearance of the desktop implies
> updating many things in our automated test suite which is based on
> screenshots of the desktop. So I understand that our test suite
> engineers are not really happy to do additional work just for aesthetic
> (not that aesthetic is not important but they are overloaded already).
>
> But I hope that one day we find a strong enough technical reason to do
> the shift!
> ___
> Tails-dev mailing list
> Tails-dev@boum.org
> https://mailman.boum.org/listinfo/tails-dev
> To unsubscribe from this list, send an empty email to
> tails-dev-unsubscr...@boum.org.
>



-- 
Fred Schiff (fsch...@yahoo.com)
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Proposal for Anti-Keystroke Fingerprinting Tool

[bancfc]

== Attack Description ==

Keystroke fingerprinting works by measuring how long keys are pressed 
and the time between presses. Its very high accuracy poses a serious 
threat to anonymous users.[1]


This tracking technology has been deployed by major advertisers (Google, 
Facebook), banks and massive online courses. Its also happening at a 
massive scale because just using a JS application (or SSH in interactive 
mode) in presence of a network adversary that records all traffic allows 
them to construct biometric models for virtually everyone (think Google 
suggestions) even if the website does not record these biometric stats 
itself.[2] They have this data from everyone's clearnet browsing and by 
comparing this to data exiting the Tor network they will unmask users.


== Current Measures and Threat Model ==

While the Tor Browser team is aware of the problem and working on a 
solution, current measures [6] are not enough. [4][5]


Security distros are designed to protect the user even if an end user 
application is compromised and provide desfense in depth.


The goal is to protect users even in the event of an attacker taking 
over an application running ina VM/Container.


This is valid for systems running in VMs or on bare metal.


== Existing Work on Countermeasures ==

As a countermeasure security researcher Paul Moore created a prototype 
Chrome plugin known as KeyboardPrivacy. It works by caching keystrokes 
and introducing a random delay before passing them on to a webpage.[3] 
Unfortunately there is no source code available for the add-on and the 
planned Firefox version has not surfaced so far. There are hints that 
the author wants to create a closed hardware soltuion that implements 
this which does not help our cause.



== Proposal for a System-wide Solution ==

A very much needed project would be to write a program that mimics the 
functionality of the this add-on but on the display server / OS level. 
Ideally the solution would be compatible with Wayland for the upcoming 
transition in the near future.





[1] 
http://arstechnica.com/security/2015/07/how-the-way-you-type-can-shatter-anonymity-even-on-tor/


[2] http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=7358795

[3] https://archive.is/vCvWb

[4] 
https://www.lightbluetouchpaper.org/2015/07/30/double-bill-password-hashing-competition-keyboardprivacy/#comment-1288166


[5] https://trac.torproject.org/projects/tor/ticket/16110

[6] https://trac.torproject.org/projects/tor/ticket/1517



***

This feature request has been mirrored on each project's bugtrackers 
respectively:


https://github.com/subgraph/subgraph-os-issues/issues/103
https://labs.riseup.net/code/issues/11257
https://github.com/QubesOS/qubes-issues/issues/1850
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] GNOME menu items

[u]

spriver:
> Hi,
> 
> sajolida:
>>>
 and do we want to change this?

>> In this particular case I think this should be proposed and changed
>> upstream. It's a cool dude :)
> 
> so maybe we should open a ticket to address this topic? (especially for
> finding the appropriate section(s)). I can work a bit on this issue, if
> desired.

go ahead! :)
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] logancij / press page

[Muri Nicanor]

attached a patch that adds the logancij to the press page

cheers,
-- 
muri
From 6f0d0ae12e28fc18713c4de0a5b76bb70707461e Mon Sep 17 00:00:00 2001
From: Muri Nicanor 
Date: Fri, 18 Mar 2016 10:39:03 +0100
Subject: [PATCH] added the logan cij talk and the recording to the press page

---
 wiki/src/press/media_appearances_2016.mdwn | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/wiki/src/press/media_appearances_2016.mdwn b/wiki/src/press/media_appearances_2016.mdwn
index 0ab0c19..8a74bb5 100644
--- a/wiki/src/press/media_appearances_2016.mdwn
+++ b/wiki/src/press/media_appearances_2016.mdwn
@@ -4,6 +4,8 @@
 
 * 2016-03-14: [Logan CIJ Symposium 2016: Technik, die entgeistert](http://www.linux-magazin.de/NEWS/Logan-CIJ-Symposium-2016-Technik-die-entgeistert) by Kristian Kißling in Linux-Magazin covers the panel we were participated in at the [Logan CIJ Symposium](https://logancij.com/) on March 12 (in German).
 
+* 2016-03-12: [Logan CIJ Symposium 2016: Panel 'Future of OS'](https://logancij.com/schedule/), ([recording](https://www.youtube.com/watch?v=Nol8kKoB-co)) with David Mirza Ahmad, Joanna Rutkowska and Tails
+
 * 2016-02-25: [Tails official mysterious during interview](http://www.networkworld.com/article/3038059/open-source-tools/tails-official-mysterious-during-interview.html) by Bryan Lunduke in Network World.
 
 * 2016-02-11: [Tails installer is now in Debian] in bits.debian.org.
-- 
2.7.0



signature.asc
Description: OpenPGP digital signature
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Feature 11198 - shell scripts to python

[Llama Tail]

Hello,
I would like to work on migrating the shell scripts to python and I would 
like your input on how to best proceed.
Since there are quite a bunch of shell scrips to convert, I would like to 
avoid working on the same things as someone else so we don't step on each 
other's toes.
I know someone else here said that they will  work on the script migration as 
well. How do you usually handle task distribution?
Cheers!___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Porting Tails to Debian Stretch

[sajolida]

intrigeri:
> sajolida wrote (09 Mar 2016 12:19:48 GMT) :
>>> We are in particular looking for one person to be
>>> responsible for the documentation-side of things, since we feel
>>> keeping it sort-of up-to-date will help us identify regressions
>>> early.
> 
>> I can be this person.
> 
> Excellent! I've updated the blueprint accordingly.
> 
>>> Regarding timelines, the freeze for Debian Stretch will be in
>>> early December, so the work has to start early enough so issues
>>> can be identified and fixed before that (post-freeze fixes are
>>> generally much harder). Due to other committments me and
>>> intrigeri will not be able to start this until some time early
>>> August, which will give us almost four months for this work
>>> before the Stretch freeze. We intend to kickstart this effort
>>> with a sprint where we meet face to face, and other participants
>>> will of course be welcome.
> 
>> Now the Stretch freeze has been postponed to 2017-02-05.
> 
>> I don't know what my calendar for the summer and fall will be but I
>> can't guarantee right now that I can also jump from "intrigeri will not
>> be able to start this until some time early August" to "kickstart this
>> effort with a sprint [in August]" (implicit in your email).
> 
> Please let us know when you know more when you can start, then :)

I'd prefer setting the dates of the summit first.

> Note that the very first sprint (that we would like to have in August
> 2016) might not be very exciting to doc people, given what we expect
> to be the goals there. Quoting the blueprint:
> 
> * August 2016 — start working on Tails 3.0 (1 week sprint with
>   all involved people) :intrigeri:anonym:kytv:
>   - get feature/stretch to build and boot
>   - update the automated test suite to test Tails/Stretch ISO images
> 
> … so it's no big deal if you join us for the 2nd sprint only.

Right. Then it might be better for me if I can skip this one :)
And until there's an ISO image it might be hard for me to be helpful.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Tail 2.2 Ugly as HELL

[freedom-mail]

There is any chance of Tails OS see other version that looks like the 1.6?
The 2.2 version is UGLY AS HELL.


___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] GNOME menu items

[sajolida]

u:
> spriver:
>> sajolida:
> and do we want to change this?
> 
>>> In this particular case I think this should be proposed and changed
>>> upstream. It's a cool dude :)
>>
>> so maybe we should open a ticket to address this topic? (especially for
>> finding the appropriate section(s)). I can work a bit on this issue, if
>> desired.
> 
> go ahead! :)

But on the MAT bug tracker:

https://labs.riseup.net/code/projects/mat
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Browser Bookmarks Persistence Bug

[u]

Michael English:
> When saving bookmarks to the “Unsorted bookmarks” category, occasionally
> a bookmark moves from “Unsorted bookmarks” to “Bookmarks menu” when I
> reboot. I think that this has been a bug in Tails for a long time and I
> can reproduce the problem on a consistent basis.

created https://labs.riseup.net/code/issues/11247 for tracking this.

cheers!
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tail 2.2 Ugly as HELL

[sajolida]

Fred Schiff:
> On Thu, Mar 17, 2016 at 7:36 AM, sajolida  wrote:
>> freedom-m...@sigaint.org:
>>> There is any chance of Tails OS see other version that looks like the
>>> 1.6?
>>> The 2.2 version is UGLY AS HELL.
>>
>> I agree :)
>>
>> We switched to GNOME Shell in Classic mode (with the grey menus) because
>> we wanted to continue providing the top-left Applications and Places
>> menus and the bottom windows list. But this can be achieve equally in
>> GNOME Shell without the Classic mode by enabling these extensions.
>
> what these extensions?

  - 'apps-m...@gnome-shell-extensions.gcampax.github.com'
  - 'window-l...@gnome-shell-extensions.gcampax.github.com'
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Proposal for Anti-Keystroke Fingerprinting Tool

[flapflap]

ban...@openmailbox.org:
> == Attack Description ==
> 
> Keystroke fingerprinting works by measuring how long keys are pressed
> and the time between presses. Its very high accuracy poses a serious
> threat to anonymous users.[1]

A while ago, I asked about that on tor-talk:
https://lists.torproject.org/pipermail/tor-talk/2015-July/038624.html

A suggestion back then was

> A keystroke reclocker / normalizer might be better integrated
> as part of the keyboard driver in your OS. You'd only need to
> code it once, and could tune it to suit you however you want.
> Try checking with your OS.

which I'd also prefer instead of replicating that feature into every
program that communicates with the outside world...

Cheers,
~flapflap



signature.asc
Description: OpenPGP digital signature
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] (review)[de] Shutdown notification; question to .desktop files

[spriver]

Hi,
(posted on Tails dev since this concerns the .iso's itself and my
question concerns the dev's).
I've added a translation in German of the shutdown message regarding the
wiping of the memory. I also built the image with the applied changes,
everything went fine and while shutting down the message is displayed
properly when German was selected as language in the Greeter.

(@German translators: if you don't want to build the whole .iso just
change the file and I'll do it then  )

Please review:
https://gitlab.com/spriver/tails.git
branch: de_kexec
HEAD commit: 47afb26 Added German translation

Affected files:
config/chroot_local-includes/lib/systemd/system-shutdown/tails-kexec



@tails-dev itself:
How are the .desktop files of things like the Installation Assistant,
Persistence setup etc. being translated? I only know how to configure
.desktop files itself, but I never translated those before. Can someone
give me some information (where and how to do so)? (since I'd love to
see those menu entries in German language  )

Cheers!
spriver



signature.asc
Description: OpenPGP digital signature
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] [review] Updates in learn.mdwn, faq.mdwn and press appearances

[elouann]

Hi,

please review in elouann/documentation the following commits:

91399b4 - add press appearances
0da8f9e - Update on learn.mdwn / Access Now
8561895 - Tails is now based on Jessie

Thank you,
cheers



signature.asc
Description: OpenPGP digital signature
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tail 2.2 Ugly as HELL

[sajolida]

anonym:
> sajolida:
>> freedom-m...@sigaint.org:
>>> There is any chance of Tails OS see other version that looks like the 1.6?
>>> The 2.2 version is UGLY AS HELL.
>>
>> I agree :)
>>
>> We switched to GNOME Shell in Classic mode (with the grey menus) because
>> we wanted to continue providing the top-left Applications and Places
>> menus and the bottom windows list. But this can be achieve equally in
>> GNOME Shell without the Classic mode by enabling these extensions.
>>
>> The thing is that changing the appearance of the desktop implies
>> updating many things in our automated test suite which is based on
>> screenshots of the desktop. So I understand that our test suite
>> engineers are not really happy to do additional work just for aesthetic
>> (not that aesthetic is not important but they are overloaded already).
> 
> If the automated test suite's images is the only "blocker", I think we
> could do the switch. Feel free to prepare a branch, and we'll see.

Thanks for the offer!

> Are you sure there would be no other changes? IIRC pure GNOME Shell deal
> with switching between applications (think: alt+tab) in a "novel" way.

You're right. Alt+Tab in the default Shell switches between applications
and not between windows. I think that can be configured as well...

Anyway, I don't feel this should be a priority for us but it good to
know that you're ready to do the switch. Maybe for Tails 3.0...
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [RFC] Design of our freezable APT repository

[anonym]

intrigeri:
> Hi,
> 
> anonym wrote (10 Mar 2016 20:06:31 GMT) :
>>> Upgrading to a new snapshot
> 
>> I expect it to be quite rare that we need to encode a particular
>> snapshot in a topic branch, which is both good and bad. Good, because we
>> then do not have to deal with the problems it may cause very often; bad,
>> because it happens rarely enough that one might not look for the
>> problems all the time, and hence let them slip through. :)
> 
>> Specifically, I fear that we may have problems with merging topic
>> branches that encode some snapshot into a base branch, and then forget
>> to remove the encoding (or otherwise deal with it in a sane way) so it
>> messes up the base branch.
> 
>> Have I missed/misunderstood something?
> 
> First of all, such encoding of snapshots is an integral part of
> proposed changes in such a topic branch; it's something one needs to
> carefully review when merging, just like any other code change. In the
> general case, merging a topic branch that encodes some snapshot into
> a base branch means "I want that base branch to use that snapshot",
> and most of the time the purpose of such a topic branch will precisely
> be to bump snapshot references to newer versions, so in general
> we should be good.

Ack, fair enough.

> Let's look at the scope of potential problems though:
> 
> * The devel branch is not affected since it "always uses the freshest
>   set of APT repository snapshots available" (I'm not 100% sure yet
>   but I think this will simply be fully automatic so one can't mess up
>   with it by mistake).

In the future, if we become a rolling distro based on Debian Testing,
we'll have to reconsider this, but the design indeed allows us to change
this behaviour easily, so let's forget about it for now.

> * The testing branch can be affected by this problem, between the time
>   the faulty merge is done, and the time we release something based on
>   testing (since "the RM encodes in the `testing` Git branch the fact
>   that it is not frozen anymore"), that is our code freeze period.
>   That's the time during which the snapshot references encoded in Git
>   are most important, and we'll be frozen, so I expect we'll be
>   careful about how we deal with such information on the
>   testing branch.
> 
> * The handling of the stable branch in this respect is less clearly
>   specified, but I suspect it'll be quite close to the
>   testing branch's.

Agreed. And for the stable branch we also need to be extra careful since
this is the type of issue one does not have to spend brain power on
resolving in case of an emergency release.

> ⇒ I'm not too concerned about this problem :)

Now I'm not either any more, thanks!

>>> Freeze exceptions
[...]
>> BTW, it would be great to have a linting tool that compared the current
>> APT pinnings vs what is available in the current Debian branches used
>> given some Tails source checkout.
> 
> I'm open to adding ideas of helpful tools to the blueprint.
> 
> I'll need help to specify more clearly what problem we want desired
> tools to solve, and how.
> 
> If I got it right, you want to know something like "what would happen
> if we dropped our APT pinning", right? Do we want to know that for the
> case when we remove APT pinning we have set up to grant freeze
> exceptions only, or all APT pinning? The former, I guess, right?

Well, I'm not sure how it would be determined if a pinning was added for
a freeze exception exactly, and not some other purpose. Any way, this
tool seems to be useful in the latter case you talk about too, to keep
our pinnings trimmed, especially if we become a rolling distro, and may
have to frequently pin stuff (security updates) from Debian Unstable.
Furthermore, I expect this latter case to be easier to solve, and I
think I'd be happy enough with that one solved -- with informative
enough output it will be easy enough to use it for the first case too.

>>> Another option, instead of adding/removing temporary APT pinning,
>>> would be to backport the package we want to upgrade, and make it so it
>>> has a version greater than the one in the time-based snapshot used by
>>> the frozen release branch, and lower than the one in more recent
>>> time-based snapshots.
> 
>> This makes me really unenthusiastic. Please do not underestimate the
>> added overhead of having to rebuild packages for trivialities like this.
>> I stronly object to this approach.
> 
> Agreed ⇒ made it clear on the blueprint that this approach is NACK'ed.

\o/

>>> Number of distributions
>>>
>>> ... in reprepro's conf/distributions, for the reprepro instance(s)
>>> dedicated to taking snapshots of the regular Debian archive, assuming
>>> other mirrored archives such as security.d.o, deb.tpo, etc. each go to
>>> their own reprepro instance.
> 
>> This make it sound like the design itself fixes which APT sources are
>> possible to use, and that it will be a pain to add new ones. Or will
>> some puppet magic automatically set up a new 

[Tails-dev] IFF session about connecting to Tor in Tails

[sajolida]

Hi everybody,

[Putting tails-dev in copy once so they know this info is available.]

So we had a session at the IFF about the UX of connecting to Tor in
Tails. Despite being scheduled on the last day of the festival, many
people attended: Tails contributors, Tor developers, UX experts, people
from Subgraph, SecondMuse, etc.

I showed 15 mockups of screenshots that I prepared during the week and I
asked everybody to write down comments on post-it notes (doubts, UX
issues, technical issues, privacy issues, suggestions, etc.) to gather
as much feedback as possible while avoiding bias from group dynamics.

The mockups build on the work done at Tor dev in Berlin and over this
list. They also introduce a bunch of crazy new ideas that I know my
engineering friends will freak out about (like spoofing MAC spoofing in
the session or autoconfiguration of Tor).

The idea here was not to come up with a pragmatic implementation program
but to explore what an ideal UX could be so we can later on discuss how
to correlate this with the resources we have and probably have to find
some middle ground.

You can find the material about the session here:

https://tails.boum.org/blueprint/network_connection#iff

The next steps for me would be to:

  - Show this to my engineering friends (early April)
  - Further process the feedback from the notes (no ETA)

Between the preparatory work and the session itself, I think we did a
huge amount of work but honestly, I don't know when I will have time to
really follow up on this (as I'm super busy with tons of other things).
So feel free to have a look and mature all this in your head but don't
count of me to follow up on lengthy threads and heated debates right now.

And a huge thanks to Ame Elliott and Susan Farrell who helped me frame
the session. I had nothing prepared when I arrived in Valencia :/
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tail 2.2 Ugly as HELL

[Daniel Kahn Gillmor]

On Thu 2016-03-17 14:59:15 -0400, intrigeri wrote:
> Daniel Kahn Gillmor wrote (17 Mar 2016 16:20:31 GMT) :
>> It's also possible that some default GNOME shell stuff requires fancier
>> graphics capabilities than some hardware provides.  i believe gnome
>> classic doesn't have as many requirements
>
> I think you're confusing GNOME Classic with GNOME Flashback (that used
> to be call GNOME Fallback).
>
> GNOME Classic _is_ GNOME Shell, plus a few extensions, and it has
> exactly the same hardware requirements.

Ah, thanks for the clarification, and sorry if i made things more
confusing.  I retract my concerns :)

Carry on,

  --dkg
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Browser Bookmarks Persistence Bug

[Michael English]

When saving bookmarks to the “Unsorted bookmarks” category, occasionally
a bookmark moves from “Unsorted bookmarks” to “Bookmarks menu” when I
reboot. I think that this has been a bug in Tails for a long time and I
can reproduce the problem on a consistent basis.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] GNOME menu items

[spriver]

Hi,


sajolida:
> u:
>> spriver:
>>> sajolida:
>> and do we want to change this?
>>
 In this particular case I think this should be proposed and changed
 upstream. It's a cool dude :)
>>>
>>> so maybe we should open a ticket to address this topic? (especially for
>>> finding the appropriate section(s)). I can work a bit on this issue, if
>>> desired.
>>
>> go ahead! :)
> 
> But on the MAT bug tracker:
> 
> https://labs.riseup.net/code/projects/mat


I've created #11248 as general ticket in the Tails bug tracker (because
I think this can be also done for other applications) and linked #11260
from the MAT bug tracker to it. I hope this is okay with you all (:

Cheers!
spriver
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tail 2.2 Ugly as HELL

[sajolida]

freedom-m...@sigaint.org:
> There is any chance of Tails OS see other version that looks like the 1.6?
> The 2.2 version is UGLY AS HELL.

I agree :)

We switched to GNOME Shell in Classic mode (with the grey menus) because
we wanted to continue providing the top-left Applications and Places
menus and the bottom windows list. But this can be achieve equally in
GNOME Shell without the Classic mode by enabling these extensions.

The thing is that changing the appearance of the desktop implies
updating many things in our automated test suite which is based on
screenshots of the desktop. So I understand that our test suite
engineers are not really happy to do additional work just for aesthetic
(not that aesthetic is not important but they are overloaded already).

But I hope that one day we find a strong enough technical reason to do
the shift!
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Tails Hardware

[Michael English]

Sorry, I just noticed that the link to installing Libreboot on the X200
is incorrect. Here is the correct link:
https://libreboot.org/docs/install/x200_external.html .

Michael English:
> Intrigeri,
> 
> First, we should identify the problem. Tails does not replace all of the
> software on one's computer. There is additional storage on the SPI flash
> chip which carries the BIOS and ME, and there is the USB stick which has
> its own firmware. As shown by LegbaCore, this software outside of Tails
> can be easily infected. “Since almost no organizations in the world
> provide BIOS patch management, it is almost guaranteed that any given
> system has at least one exploitable BIOS vulnerability that has
> previously been publicly disclosed. Also, the high amount of code reuse
> across UEFI BIOSes means that BIOS infection is automatable and
> reliable.” Once the firmware is infected, the malware is more privileged
> than all applications and operating systems. Basically, Tails is
> completely useless on insecure hardware.
> 
> Your question about the audience is a bit of a leading question. All
> Tails users should be the audience. Currently, Tails only has
> documentation about warnings of firmware vulnerabilities. However,
> readers have no course of action to take against this serious problem.
> Anyone who cares about their privacy/security/freedom enough to run
> Tails should purchase or configure secure hardware.
> 
> One solution to the vulnerable SPI flash chip that we can document is
> Libreboot. Unlike Coreboot, Libreboot is completely open-source without
> the Intel FSP and provides easy to understand documentation. There are
> two options to get a Libreboot X200. First, one can buy a refurbished
> Lenovo ThinkPad X200 from a electronics store like Newegg in the United
> States. (I assume that there is a European equivalent.) Then, he or she
> can follow the relatively easy-to-understand instructions on the
> Libreboot website for installing the BIOS
> https://libreboot.org/docs/hcl/x200.html and removing the ME
> https://libreboot.org/docs/hcl/gm45_remove_me.html . Second, one can buy
> a laptop with Libreboot pre-installed. The Free Software Foundation has
> a list of hardware that respects your freedom and currently includes two
> companies that sell Libreboot laptops:
> https://www.fsf.org/resources/hw/endorsement/respects-your-freedom . I
> personally recommend Minifree which is run by the same person who
> founded Libreboot. When buying a laptop with Libreboot pre-installed,
> one does not have to worry about making a mistake in the installation
> process, financially supports Libreboot, and gets a longer warranty in
> the case of Minifree which offers a whole two year warranty. I do not
> recommend that we specifically promote one company on the Tails website,
> but we should link to the Respects Your Freedom page as an option
> instead of the manual install.
> 
> Another small note about the X200 is that it has a wireless kill switch
> to prevent the leaking of sensitive information over the network without
> the user noticing.
> 
> I am unsure what to do about the vulnerable firmware on the USB stick
> that runs Tails. As far as I know, there is no open-source USB
> drives/firmware. Though, USB drive malware could be almost as damaging
> as the BIOS/ME because it can perform MITM attacks between the OS and
> flash memory. Here are a couple videos which explain USB stick/SD card
> firmware vulnerabilities: https://www.youtube.com/watch?v=nuruzFqMgIw
> https://www.youtube.com/watch?v=CPEzLNh5YIo . Please let me know if
> there is a solution to vulnerable USB stick firmware and if some USB
> sticks more secure than others.
> 
> Cheers,
> Michael English
> 
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] logancij / press page

[sajolida]

Muri Nicanor:
> attached a patch that adds the logancij to the press page

Thanks for thinking about that. I moved your snippet to the "Conference"
section and duplicated it in the monthly report for March.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.