[Tails-dev] Option to disable mouse clicks with touchpad in Tails Greeter
Hi, Copying -ux for historical reasons. And maybe moving there, too. Michael English: with Tails ... mouse clicks with touchpad are enabled by default and there is no easy way to turn it off before starting the OS. Hardware Controls are important :) u: Mouse clicks with the touchpad are not disabled in Debian by default afaik. I am in favour of having mouseclicks with the touchpad enabled, as the contrary seems even more confusing. Disabled or not, having more control before starting Tails is a good experience. We will keep this in mind when working through the startup flow [0]. Wordlife, Spencer [0]: https://tails.boum.org/blueprint/network_connection ___ 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] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/24/2015 9:00 PM, Michael English wrote: > Sajolida: > > “If I understand correctly, the main issue here is about the > *change* (and not about the behavior itself), then this should be > mentioned most of all in the release notes. If you think that the > behavior itself might be confusing, then I guess that this should > be solved upstream (in their documentation or the software > directly).” S7r and I disagree. Simply noting the change of default > base unit could have a big impact in avoiding confusion. > > “If they have to perform a specific action, then this should be > documented. If they don't have to perform a specific action, then > maybe we need to adapt the current warning about 'Do not blindly > trust the bitcoin balance'.” Yes, they do have to perform a > specific action to select the onion Electrum server at the moment. > Why do you think it's mandatory to use an .onion server with Electrum in Tails? All these were not a problem until now in 1.9.8 and it worked in Tails very good. 2.5.4 is not that different. > s7r: > > The mistake that you are making is being too specific with your > documentation proposal. Please see the Tails documentation > contributors page: > https://tails.boum.org/contribute/how/documentation/ . I also > proposed specific documentation like yours here: > https://mailman.boum.org/pipermail/tails-dev/2015-March/008302.html > and found out that it belonged in the Electrum wiki instead of > Tails. > Ok sorry my mistake - I wasn't aware of the Tails documentation guidelines. I basically included as much as I could so you can select only what's necessary and knife the rest. > The main debate is over the DoS documentation. This is a good > summary by anonym of a worst case scenario: “Thanks to SPV, the > server can spoof the wallet balance. Hence the server operator can > scam Tails users, e.g. s/he can buy stuff from a Tails user, and > then bump their balance with that exact amount so it looks like > they've received payment.” > I don't exactly understand what you mean when you say DoS and not sure what would you like to include in the documentation. Obviously an user shouldn't trust an unconfirmed transaction, but this recommendation usually goes for full wallets as well not only SPV. This is already written everywhere and that's why Electrum shows the unconfirmed balance separately. > The DoS problem is difficult to solve. The best solution would be > for Tails to sponsor its own onion Electrum server. > I don't like this too much, making a decentralized service partially centralized, but I also don't oppose it until we fix upstream the auto-connect synchronization issue reported by anonym. I am already on it but don't know how much time it'll take - hopefully not too much. > Documenting what an Electrum server is is completely off topic for > the Tails documentation. OK. Thought it's important for user to know what an Electrum server can or cannot do. > I strongly disagree. DoS should be mentioned as it has a > possibility (although unlikely) to have a devastating effect on > Tails users. How exactly? Can you explain me detailed where you think the DoS risk is? Again, the linked research paper has nothing to do with Electrum. The fact that an electrum server runs on top of bitcoin core which is mentioned in that research paper cannot be taken into consideration (how do we even know if the bitcoin core running on the electrum server we are connected to uses Tor for its peer to peer connections with other nodes). The problem here is that I don't know how you define DoS in this context. From my point of view an Electrum Server lying about an unconfirmed balance until first block is mined cannot be called DoS. (Also, in this case, the server has to OWN the coins apparently spent and target a certain user which is behind Tor (so anonymous) which is highly unlikely.). >> There's no current setting for this, but I made a note for this. >> Some option like prefernet=tor. > Good idea. You should propose this feature to Github > https://github.com/spesmilo/electrum so that it can be included in > Tails in the future. Will do. Noted it down. > I absolutely agree. This is the best long-term solution although > it requires cost in hosting and maintenance. Your server should not > be trusted unless merged into Tails developers' exclusive control. I completely agree. If you arrange for a server and need help in setting it up or maintaining it and you think I could help do let me know. >> - An Electrum server could not broadcast an outgoing transaction >> (payment) sent by you; > I'm not sure what you mean by this. When you send a transaction from Electrum, it's sent do the Electrum server to which you are connected. The server automatically feeds it to bitcoin core via cli command which broadcasts it to the peers (and into the network). The Electrum server could skip this step and drop your transactio
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
Sajolida: “If I understand correctly, the main issue here is about the *change* (and not about the behavior itself), then this should be mentioned most of all in the release notes. If you think that the behavior itself might be confusing, then I guess that this should be solved upstream (in their documentation or the software directly).” S7r and I disagree. Simply noting the change of default base unit could have a big impact in avoiding confusion. “If they have to perform a specific action, then this should be documented. If they don't have to perform a specific action, then maybe we need to adapt the current warning about 'Do not blindly trust the bitcoin balance'.” Yes, they do have to perform a specific action to select the onion Electrum server at the moment. s7r: The mistake that you are making is being too specific with your documentation proposal. Please see the Tails documentation contributors page: https://tails.boum.org/contribute/how/documentation/ . I also proposed specific documentation like yours here: https://mailman.boum.org/pipermail/tails-dev/2015-March/008302.html and found out that it belonged in the Electrum wiki instead of Tails. The main debate is over the DoS documentation. This is a good summary by anonym of a worst case scenario: “Thanks to SPV, the server can spoof the wallet balance. Hence the server operator can scam Tails users, e.g. s/he can buy stuff from a Tails user, and then bump their balance with that exact amount so it looks like they've received payment.” The DoS problem is difficult to solve. The best solution would be for Tails to sponsor its own onion Electrum server. Please see my inline replies that follow. > Hello Sajolida, Michael, > > See inline. > > On 11/22/2015 2:00 PM, sajolida wrote: >> Michael English: >>> Sajolida, please forward this message to s7r. > >> Done. > > > Thanks! > >>> s7r, >>> >>> If you do not have any specific ideas for updating the Electrum >>> documentation, I volunteer to take the lead. Otherwise, you can >>> draft an updated version of the documentation and I can update >>> where necessary. The goal is to document Electrum specifically >>> for Tails and not duplicate the existing Electrum wiki. > >> Thanks for the offer. > >>> Most of the updates like wallet format happen automatically in >>> the background, so they do not need to be documented. I only >>> recommend making two additions. >>> >>> The most obvious change to the user when updating Electrum >>> versions is that the default base unit changes which can be >>> confusing. No, I do not think that we should manually change the >>> default base unit with a config file. That decision should be >>> made upstream. However, users should be aware that the appearance >>> of their Bitcoin balances changes especially when sending >>> Bitcoins. > > > Right, the current page is pretty good: > https://tails.boum.org/doc/anonymous_internet/electrum/index.en.html > > I will include few more additions, especially to highlight how > important the seed is and that is also important to have it backed up > even in case you use a persistent Tails install (since that particular > install can break or etc.). You should link to existing documentation if it is general knowledge that is not specific to the Tails configuration. > > mBTC as default unit should of course be explained. I also want to > include some answered questions about what an Electrum server is, what > it can do and what it cannot do. Documenting what an Electrum server is is completely off topic for the Tails documentation. > >>> DoS refers to the SPV vulnerability of servers withholding >>> information from their clients leading to an incorrect balance. >>> Connecting to a trusted .onion server protects against DoS. Yes, >>> it is not a bug, but it is a well-known limitation of SPV that is >>> specifically relevant for Tor users. Pleas read “Bitcoin over Tor >>> is not a good idea” http://arxiv.org/pdf/1410.6079.pdf . > > > This is unrelated to electrum. It applies to Bitcoin Core (the > software implementing bitcoin protocol - full nodes). Bitcoin core has > a peer-ban-score, where the ban score of a peer (remote server that > you are connected to) increases if that peers feeds you trash data or > tries to DoS you. > > The attack described in that paper takes advantage of the scarce exit > power in the Tor network (~1000 IP addresses) and speaks from the > point of view where an attacker runs few Tor exit nodes that allow > bitcoin exit traffic, and then uses the other exits to feed enormous > amount of trash data to the bitcoin network, hoping the majority of > bitcoin nodes will ban the other exits which are not under the control > of the attacker. Then, you can only connect to a bitcoin peer via Tor > using one of attacker's exit nodes. Hope this explains - it's just a > summary. > > Electrum servers don't have such banning mechanism, they only have > limits of requests per wallet and per address (100/1
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Sajolida, Michael, See inline. On 11/22/2015 2:00 PM, sajolida wrote: > Michael English: >> Sajolida, please forward this message to s7r. > > Done. > Thanks! >> s7r, >> >> If you do not have any specific ideas for updating the Electrum >> documentation, I volunteer to take the lead. Otherwise, you can >> draft an updated version of the documentation and I can update >> where necessary. The goal is to document Electrum specifically >> for Tails and not duplicate the existing Electrum wiki. > > Thanks for the offer. > >> Most of the updates like wallet format happen automatically in >> the background, so they do not need to be documented. I only >> recommend making two additions. >> >> The most obvious change to the user when updating Electrum >> versions is that the default base unit changes which can be >> confusing. No, I do not think that we should manually change the >> default base unit with a config file. That decision should be >> made upstream. However, users should be aware that the appearance >> of their Bitcoin balances changes especially when sending >> Bitcoins. > Right, the current page is pretty good: https://tails.boum.org/doc/anonymous_internet/electrum/index.en.html I will include few more additions, especially to highlight how important the seed is and that is also important to have it backed up even in case you use a persistent Tails install (since that particular install can break or etc.). mBTC as default unit should of course be explained. I also want to include some answered questions about what an Electrum server is, what it can do and what it cannot do. >> DoS refers to the SPV vulnerability of servers withholding >> information from their clients leading to an incorrect balance. >> Connecting to a trusted .onion server protects against DoS. Yes, >> it is not a bug, but it is a well-known limitation of SPV that is >> specifically relevant for Tor users. Pleas read “Bitcoin over Tor >> is not a good idea” http://arxiv.org/pdf/1410.6079.pdf . > This is unrelated to electrum. It applies to Bitcoin Core (the software implementing bitcoin protocol - full nodes). Bitcoin core has a peer-ban-score, where the ban score of a peer (remote server that you are connected to) increases if that peers feeds you trash data or tries to DoS you. The attack described in that paper takes advantage of the scarce exit power in the Tor network (~1000 IP addresses) and speaks from the point of view where an attacker runs few Tor exit nodes that allow bitcoin exit traffic, and then uses the other exits to feed enormous amount of trash data to the bitcoin network, hoping the majority of bitcoin nodes will ban the other exits which are not under the control of the attacker. Then, you can only connect to a bitcoin peer via Tor using one of attacker's exit nodes. Hope this explains - it's just a summary. Electrum servers don't have such banning mechanism, they only have limits of requests per wallet and per address (100/1). So, I think it's not worth it to confuse the users and make reference to this anywhere. >>> - How would people "manually select a trusted .onion server"? We shouldn't recommend a particular .onion server. I host some and we could make it the initial default one, but then the user should be free to select any server (.onion or not). Also, to ensure a high quality service and total reliability for Tails users, I would be happier if I could provide a SSD server for this purpose. >>> - Where can people find "a trusted .onion server"? Exactly. People should only trust the server list in Preferences -> Network because those are servers which are advertised and their utxo set hash is checked. If one of them has a broken database or database not matching the other servers it'll get banned. >>> - How should our current warning about SPV be adapted? See below. > > - Would it be possible to configure Electrum in Tails to use the > existing onion servers on top of the usual servers? instead of the > usual servers? There's no current setting for this, but I made a note for this. Some option like prefernet=tor. > - In that case, do we need to trust them all? - What happens if > some of them go down? I am not sure I understand the q. We can provide one .onion server for when connecting for the first time. After that the user can change if they want. It would be nice if we could attract some funding for this and have a SSD server for this (normal hard disks are slower for leveldb). My server is: 3ffk7iumtx3cegbi.onion but it's not SSD :( from time to time lags for 2-3 seconds, but reliable (99% uptime). == Here are my proposed additions to the doc. page. Feel free to add/remove/rephrase where you think it's needed: 1. Define 'seed', after first line: "- Your wallet can be recovered [...]". Add these lines: - - The seed is the string of words generated by Electrum when cr
