Re: [Tails-dev] logancij / press page
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.
Re: [Tails-dev] Tails Hardware
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] Tail 2.2 Ugly as HELL
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] GNOME menu items
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.
[Tails-dev] Browser Bookmarks Persistence Bug
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] Tail 2.2 Ugly as HELL
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] IFF session about connecting to Tor in Tails
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] [RFC] Design of our freezable APT repository
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 rep
Re: [Tails-dev] Tail 2.2 Ugly as HELL
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.
[Tails-dev] [review] Updates in learn.mdwn, faq.mdwn and press appearances
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.
[Tails-dev] (review)[de] Shutdown notification; question to .desktop files
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.
Re: [Tails-dev] Proposal for Anti-Keystroke Fingerprinting Tool
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.
Re: [Tails-dev] Tail 2.2 Ugly as HELL
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] 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. 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] GNOME menu items
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.
[Tails-dev] Tail 2.2 Ugly as HELL
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] Porting Tails to Debian Stretch
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] Feature 11198 - shell scripts to python
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.
[Tails-dev] logancij / press page
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.
Re: [Tails-dev] GNOME menu items
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] Proposal for Anti-Keystroke Fingerprinting Tool
== 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] Tail 2.2 Ugly as HELL
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.
Re: [Tails-dev] [Secure Desktops] Proposal for Anti-Keystroke Fingerprinting Tool
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] GNOME menu items
Hi, sajolida: >> >>> and do we want to change this? >> >> IMO, in the general case (and in most such proposals I've seen so >> far), such proposed changes are not worth maintaining a Tails-specific >> delta (that comes with a cost both for our developers, and for users >> who are used to finding some app in some menu on other operating >> systems). I'm sure there are exceptions to this though! And if we had >> a menu maintainer who would commit to handle such things, to maintain >> consistency and the corresponding delta on the long term, keeping in >> mind our commitments to our upstreams, I personally would be very >> happy to see people polish these bits of Tails UX :) > > 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. 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.