Remove Coinomi wallet from "Choose your Bitcoin wallet" page #1622
Comments
|
I agree that transparency should be set to 'checkfailtransparencyclosedsource'. Last real code update on GitHub has been in April 2016. @erasmospunk Comments? |
|
@erasmospunk Could you push your recent updates and tag the latest release? |
|
There is indeed a delay in publishing the code, however this decision was taken after being accused by hundreds of users that we stole their funds, as they funded their wallets and after a while their funds were gone. Apparently scammers were cloning Coinomi wallet and then run campaigns, MLM schemes, they even organized proper presentations where they had the investors download the malicious clones and fund their wallets, and after a few weeks their funds were simply gone. They didn't even bother to change the Support link inside Coinomi's menu which was still forwarding all inquiries to our Support e-mail, which is basically why we are aware that so many users were scammed and lost their money and along with that their faith to crypto-currencies. Is this really the message we want to pass on to the new adopters? It's our duty to welcome new users to cryptoland and protect them by all means. On top of that, delaying the publishing of the source code also puts a hold to parasitic ventures like uberpay.io who basically built their revenue model on top of a clone of an older version of our wallet and didn't even bother to run their own back-end servers, last time we checked they were still parasitizing on our back-end servers, which are paid by us, of course. And uberpay is just an example, there are many more like them who have been making a buck on our sweat. This kind of behavior only harms legit projects like Coinomi which has been serving hundreds of thousands of users for almost 4 years, and to achieve that we have also spent hundreds of thousands of USD in development and operational costs apart from the time and effort we put into this, so maybe we should focus on what is really harming our community instead of going after those who have been helping cryptos evolve since day one. As for the "shady" part, there's nothing shady about Coinomi. We have been around since 2014 and no user has ever lost their funds because it was the wallet's fault. We are an established company registered in the UK and we are fully liable for the software that we produce. As for the source code, nothing has changed to the private keys management and address generation part which is what you should be focusing on and for which the source code is already available on GitHub for everyone to review. Will Coinomi's removal from bitcoin.org help the community more than it will harm it? If you believe that the answer is yes then go for it. As for us, we feel obliged to protect the users and therefore we cannot allow scammers to keep on cloning our wallet. |
|
@GeorgeKimionis Thanks for stating your postion. I am sorry to hear about your problems with fraudsters and thieves. These uberpay guys do not mention coinomi as a source at all. That is even under the old license illegal. I see that your new license forbids commercial use. Will this change your delayed code publishing? I think removing you from bitcoin.org was never on the table (at least from my perspective). |
|
@GeorgeKimionis there are multiple open sourced bitcoin wallets who can be forked by anyone, and none of them complained about being forked by scammers and therefore closed their source. I can't see why Coinomi should be anyway different. Anyway, everything you said about "nothing has changed" in the private keys management and address generation part, can't be verified, and this is the main problem. Users need to trust you that "nothing has changed", and if you didn't understand the fundamentals of bitcoin: we are against "trust". |
|
@Bitim To be fair, almost everyone uses the compiled version from the app store. As I mentioned above there is no guarantee that it contains the same code as devs push on GitHub. So there is always trust involved when you installed compiled software. |
|
@Mirobit it doesn't matter, if you want to be "basic transparent", you should provide users the ability to not trust you. If you're not providing this option I think you do not deserve this title, whatsoever. Otherwise every other scammer can get this title. |
|
@Mirobit thank you. It is illegal indeed not to mention the source and keep the same license as the source, even under the old license. The license was changed so we can have control over who is cloning our wallet and in combination with the delayed opening of the source code it seems to be working pretty well. And yes, you are totally right, unless deterministic builds are provided there is absolutely no guarantee that the source code on GitHub reflects the compiled binaries listed under the various app stores (which also answers @Bitim's remark on trust). @Bitim as we are in contact with many wallet providers in the industry I know for a fact that there are others that faced similar issues, maybe not to that extent, but I'd rather let them speak for themselves. Apart from that, all companies are responsible for their actions and no one shall dictate them what is the ethical way to run their business. Coinomi is currently the only mobile-first wallet that provides true ownership and supports more than 70 different blockchains and many dApps and ERC20 tokens, while the vast majority of the wallets listed on bitcoin.org are bitcoin-only and fraudsters typically have a special affection for coins with a better anonymity than bitcoin, maybe that's why, but then again I'm not going to try to reason the fraudsters' actions or take any defensive position on this matter, Coinomi has a great reputation and that should be enough to inspire trust where trust is needed. BTW I suppose you performed the same checks for every other wallet listed under bitcoin.org as you did with Coinomi and found their published source code to be in perfect sync with their latest releases and also checked that the compiled version is exactly the same as the one you get when compiling their published source code, right? Because if you didn't one could say that you are targeting Coinomi here and since I don't see any more "Remove XXX wallet from Choose your Bitcoin wallet page" entries in the Issues page, one would have to start wondering why. |
|
@GeorgeKimionis, are you trying to market me your wallet? Because it sounds like that. I don't really care about your product, its features or its "reputation" (great or not); I care about transparency. So everything you said about your product is worthless for me, because I need to trust you on this. So please stop. Anyway, you shouldn't hide behind some excuses like "scammers forking my wallet" to explain your shady approach, while there are many other fork-able wallets, that are not closing there source, because of this reason. So if you won't take any defensive position on this matter, you should know that you can't have your cake and eat it, meaning you can't boast with the "basic transparency" badge, when this badge have some basic requirements that you are not comply with. And no, I didn't performed the same checks for every other wallets listed under bitcoin.org. I did some checks on multiple wallets. Actually I targeted shitcoin's wallets, trying to find some transparent wallet for this purpose, and after I found one (Coinomi), that IMO is not transparent, and listed on bitcoin.org website, I decided to take an action against the misleading information regarding this wallet on bitcoin.org website. That's all. |
@Bitim even if the latest code is available, if the builds are not deterministic then the users have to trust the publisher. And since none of the wallets listed on this website except for Core provide deterministic builds the users have to trust the publisher of each wallet. Maybe you should educate yourself better before deciding to waste more of our time.
@Bitim I hope you didn't just call us "scammers". (!)
@Bitim that sounded rather insulting. And who exactly is "we"?
@Bitim what makes you think that you have the right to call Coinomi a "shitcoin wallet" and more than that to call these coins "shitcoins"? What a hideous approach!! OK guys, I'm not going to just sit here and listen to @Bitim's insults. He is clearly targeting Coinomi here and his behavior resembles that of a paid troll. The way this conversation goes makes it non-constructive, to say the least. Let's put and end to it, we all have better things to do than to feed the trolls. |
Having the latest code available gives users the option to not trust you. They can choose to not trust the builds that you publish and to build the software themselves. By not even allowing that option, you are providing no transparency. |
|
Bitcoin.org has a (mostly) objective criteria for determining what wallets should be listed, so I suggest we try to keep the discussion focused on the following topics:
I think the part of the policy relevant to this issue is,
Specifically, it is my understanding that this does not require a wallet to be what most people call open source - but it does require that the wallet vendor keep their publicly-viewable source code up to date. It is also my understanding that that a OSI-approved open source (or FSF-approved free software) license is not required for Coinomi's current transparency score; this was discussed previously in issue #896 - however, I do again believe that we require wallets publish their current code to get that transparency score (even, as discussed elsewhere in the comments, if we have no easy way to check that they do). @GeorgeKimionis is there anything we can do to get you to keep the public code repository synced with the releases? If not, do you think your situation with the fraudulent clones warrants a change in Bitcoin.org policy? (Edit: and, if so, can you suggest a phrasing for that policy?) |
|
@harding IMO if a wallet is unable to publish source code that corresponds to the latest publicly available version of their software, they should not be listed. This rule should be enforced with no exceptions. Regarding cloned wallets, breadwallet deals with this issue too (there have been numerous cloned versions of breadwallet on the appstore) and yet it is still open source and the source code publicly available. |
|
"Basic transparency" according to bitcoin.org website:
So you are not complying with the first requirement: publish the source code for the client.
I didn't.
I do have the right to call shitcoins shitcoins, and wallets for these coins "shitcoin's wallet".
I understand it's not so easy when someone criticize you, but I'm not targeting anyone or anything specifically. I do care about security and transparency with no exceptions. For now, Coinomi is the only wallet listed on bitcoin.org that I found not complying with the basic requirements. |
|
@achow101 I personally agree with you. However, Bitcoin.org had for many years listed proprietary wallets with completely closed source code. Over time, we've shifted policy to discourage this and currently the only wallets allowed to have closed code are in web wallet section of the wallets page. That said, I think it's fair to see if @GeorgeKimionis (or anyone else) can propose a reasonable alternative that the rest of us haven't thought of but which we'd find satisfactory and which would allow us to continue listing Coinomi. |
|
@harding I agree completely with both of your comments above. Thank you for saving me from having to write it, and for saying it better than I would have. |
|
@harding this is indeed a rather delicate matter. Our main concern should be to do everything to our power to protect the users. The publicly-viewable source code policy laid the right foundation for Bitcoin.org, however it could be time for an update. I wouldn't have any issue with allowing access to our latest source code versions to well-known and trusted contributors like yourself and @crwatkins (or any other well-known contributor or independent security auditor) in order to review our source code, but this would create extra work for you (for which I would obviously be more than happy to compensate you for) and would also impose the "quis custodiet ipsos custodes" paradox for the community, but at this point is the only solution that can possibly satisfy all parties and also leaves the fraudsters on the outside. Another option would be to re-allow the listing of non-publicly-viewable-source-code wallets with certain criteria, such as:
The truth is that even with the case of a fully open source wallet, if the developers go out of line they have the power to push an update to the app stores and steal users' funds and by the time a reviewer would find out (assuming the developers would push that code to their public repository, which will hardly be the case) it would already be too late. Even worst, a hacker could steal the publishing keys and the code signing certificates and push this update and cause the same tragic results. So maybe it's time to start focusing less on the code itself and focus more on the team behind it. I could easily accept a clear distinction between publicly-viewable source code wallets with deterministic builds vs all the rest, however publicly-viewable source code wallets with no deterministic builds practically don't differ much from any other closed-source implementation. Any sense of security and transparency that comes as a result of reviewing the publicly available source code of a wallet with no deterministic builds in reality has no solid grounds, so maybe it's time to enforce deterministic builds for all listed wallets. In any case, we cannot allow even a single satoshi more to be stolen from the users' wallets because we did nothing to protect them in the first place. |
|
@GeorgeKimionis Thank you for your considered reply about this tricky issue. Keeping source code private would seem to be an effective way to prevent script-kiddie level fraudsters from cloning your app, but I'm not sure it's an effective deterent against more skilled attackers who could simply copy your UI into a different app (whose development could be much easier than your actual app since they wouldn't necessary need to build in any of the crypto parts---they could just generate wallets on their own server and push status updates to the app to make it look like the wallet resided on the mobile device). Or they could decompile your app, modify it, and submit it to the Play store. Or they could perhaps even take the time to entirely reverse engineer the app---fraud can be much more profitable than honest work, and duplicating someone else's work is never as hard as doing it the first time (especially if the duplicator doesn't care about quality control). It seems to me that the closed source strategy might work for one wallet or a few wallets, as the fraudsters will just focus on cloning the other easier-to-clone wallets. But if all wallets went closed source, then the fraudsters might just build separate apps that cloned the UI elements, making no app any safer from having fraudulent copies than it is today. However, public source code does provide users a powerful hedge against one of the most common type of wallet failures we've seen on Bitcoin.org---wallets going out of businesss (or their maintenance teams disbanding). When the code remains available, this is at worst annoying, as someone can always figure out the wallet data and encryption format. But if the code isn't available, it could lead to permanent bitcoin loss. And, although I agree that published app binaries could differ from published code, a public repository allows permissionless investigation of the software, allowing security researchers to look for problems without having to reverse engineer software. I believe several wallets (perhaps most notably BlockChain.info) have had major flaws discovered and dealt with responsibly (or mostly so) through this type of unsolicited public review. It's a somewhat different issue from the main one being considered here, but most of the wallets with public source code that we list are FOSS, which is something I think many contributors to this website (currently maintained in a FOSS repository) think is important (I sure do) and which also some users reading the Wallets page would like to use as a factor when choosing what wallet to use, so even if there's a risk that non-deterministically-built wallets could trick us, I think there's a strong desire for us to score public-code wallets separately from private-code wallets (if we list the later at all outside of a special section). (Digression: I would like to note that I believe deterministic building is possible on Android for wallets published through F-Droid. I see several well-known wallet apps listed there, although I don't know if they're legit or if they use deterministic builds---if any of the authors are reading this, feel free to open an issue or to poke @crwatkins or myself to see if we can develop a process to allow us to integrate that into your Bitcoin.org wallets page listing.) Given the above and after thinking about this all morning, it remains my personal opinion that Bitcoin.org is helping users best in the long term by continuing with its current policy of only listing user-private-key-control wallets if those wallets also make their source code publicly available. This does mean that users who install wallets without clicking through the Bitcoin.org Wallet page (or another reliable resource) are at increased risk of installing easily-made malicious clones, but I think that risk would be replaced be the equivalent risk of installing less-easily-made malicious clones if every wallet closed its source---and for every wallet that closes its source, we'd have to deal with other problems too. I happy to keep discussing this. I don't think we need to rush into any decision here. |
|
I again agree completely with @harding. In particular, I don't believe that this particular situation warrant urgent immediate action, so that we have time to solicit and consider wise comments. |
|
Thanks everybody for their comments. I have set the transparency to @harding I agree about the abandonware problem, two examples that come in mind are Ninki and Hive wallets. The code is out there but the apps don’t work anymore and if you want to get your coins back you need technical skills. When creating Coinomi, I wanted a wallet that would keep working even in the case we disappear, so that the user can restore their coins in another wallet. Hence the Coinomi wallet uses BIP32+39+44 and there are tools to extract your keys. Also as @GeorgeKimionis said, the latest source code is available to any well-known and trusted contributor or independent security auditor. |
|
@erasmospunk thank you for the PR updating your scoring. Unfortunately, I don't think that resolves the underlying issue, which is that (in my interpretation) Bitcoin.org's current policy requires current source code be publicly available for wallets with local private keys. Specifically, the policy says:
That's why I think the options here are to either delist Coinomi or change the policy. I've explained why I think the policy is good for users (helping prevent one type of bitcoin loss and allowing permisonless security research); @achow101 has provided a separate reason---allowing users to review the code and run a version of the app they compiled themselves (although, IMO, this reason may be entangled with FOSS rights and so not directly corresponding to the policy above). I appreciate your responses that Coinomi provides a recovery tool[1] and that source code security review is still possible (although with your permission first). I think those are both good, but I think revising our policy to allow those in substitution for up-to-date public code would be a loss for users. And, although it's a bit separate from this issue, I think we should ultimately be moving in the direction of requiring wallet code be OSI or FSF compliant so that users can not only recover from wallets going out of business but can even choose to continue maintaining the code themselves, as happened with Armory. I don't know what the other Bitcoin.org contributors think. Am I misinterpreting the policy? Are recovery tools and private code review adequate substitutes for public code? Is the policy otherwise reasonable? [1] That page says, "This project is 100% open-source code" but I don't see an open source license provided on that page or on the corresponding GitHub repository. Would you be able to provide such a license? |
|
@harding added the license for the recovery phrase tool. Thanks. As @GeorgeKimionis mentioned, maybe it is time for a policy update. We currently allow web and hardware wallets to be closed source and as long as there is transparency about the availability of the code, a user can make their own decisions. |
|
This is not the time for policy update (or any other time). Bitcoin.org should keep its recommendations safe, secure and transparent as much as possible for users . Bitcoin.org shouldn't promote every other shady services. |
|
@Bitim we all get it that you are on a mission to delist Coinomi from Bitcoin.org, which is pathetic, to say the least. If all the above applies to Coinomi then I expect you or any of the contributors here to constantly run the same checks (such as that the code is public and kept up to date, etc) for every other wallet listed on bitcoin.org and also publish these reports on a daily basis (maybe automate this?) since we are all for transparency here, as for web wallets and hardware wallets and according to the general spirit of openness, clarity and transparency they should also be removed unless they publish all of their proprietary code so that full transparency is achieved. |
|
@Bitim I'd appreciate it if you stopped calling Coinomi a scam in this issue. I do thank you for raising the issue about their repository not containing recent commits, and we'll continue to discuss that (with your welcome continued participation) and make a decision. However, if you have additional concerns beyond the public source code one, I think they belong in a separate issue ticket. If the information is confidential, please feel free to email one of the site maintainers. PGP keys for encryption are available. @GeorgeKimionis I'd appreciate it if you stopped insulting our process in your responses to @Bitim. I'm sorry that you feel Coinomi is being targeted, but the issue here is that Coinomi appears to violate a Bitcoin.org policy. It doesn't matter what the motivations were of the person who reported that issue, it's still an issue and we still have to deal with it. I think the issue of unfairness raised by @erasmospunk is worth considering. I'll reply when I have done so, and I encourage others to do the same, but please let's try to focus on that issue or any other issue directly related to the policy. |
|
@Bitim, how does exactly public code protect users from a trivially embedded backdoor code on an app store update? By your definition of safe, if an anonymous person publishes a forked version of Andreas' Android wallet with the only change of painting the app green, it should be listed on Bitcoin.org, right? What could possibly go wrong? |
|
@erasmospunk Bitcoin.org's policy helps us prevent listing your example case. Specifically:
I understand that you don't think public code is important---if you did, you would've kept your code public. However, it's important to other people for the reasons described above:
The current objection is that it's not fair for us to allow wallets without public code in the web section (and, arguably the hardware section) but not the mobile or desktop section. The immediate response to that is that (1) we're in the process of moving those web wallets to a separate page for exchanges, after which we can change the web scoring to be more consistent with mobile and desktop, and (2) the hardware wallets that don't provide code are under additional hardware restrictions and must satisfy additional testing criteria to be listed here (and, still, they're not given the best score). In short, even if there's current disparity in conditions between the different sections, I think we should move towards imposing the conditions requiring public updated code access to all sections rather than removing those conditions from the mobile and desktop sections. I'm still happy to continue discussing, but my personal opinion at the moment is that (1) the current Bitcoin.org policy about open and updated code access should not be removed and (2) Coinomi's code policy is not compatible with that policy, and so Coinomi should be delisted. |
|
@harding I stand corrected regarding my example. To get internal wallet file (protobuf format) you need to root your smartphone and if you did get it the code to parse it is available in the repo (the private key management and tx signing is done with Bitcoinj). |
|
@erasmospunk As I stated before, having public code gives users the option to not trust you. They could compile the wallet themselves and install their own personally compiled version instead of trusting the version that you publish on the Play store. Regarding wallet formats, the issue is not whether users now can get the wallet file and retrieve their coins. Suppose in the future the wallet format were to be changed to something proprietary in a closed source version. Users using that wallet format would be unable to recover their coins if you stopped developing Coinomi and pulled it from the Play store. I'm not saying that that will happen, but having the latest source code available is a protection against such a scenario. Also, rooting a phone is not that hard; there are guides for doing it all over the internet and it gets easier by the day. On the other hand, getting Bitcoinj's wallet tool to work or extracting the wallet parsing code out of the available source code is way harder to do and requires programming knowledge, something that rooting does not require. |
|
@achow101 I agree with you. The policy that we have may one day change, however for the time being the latest versions will stay closed source. From my understanding the core issue is that the binaries we distribute on the Google Play Store are not accompanied by publicly available source code. One possible solution to this issue is changing the "Install" link to our latest version available on github. It is 100% backwards compatible with the current version. The latest version has a bit nicer GUI and supports some more coins. The v1.6.5 has all the source code available so anybody can compile it, study it and make some security auditing (as we didn't change the core security mechanism from that version). Also, if we disappear, the backend server is ElectrumX that we regularly contribute code to. |
|
@harding asks
I believe that you are correct about the current policy requiring public source code. I prefer public source code for performing wallet reviews. Some of our criteria are most easily and more accurately verified with access to source code. This is a major consideration as to why I do not review banks and why have I warned hardware wallet developers that I may not be able to complete a review without source code. I personally would not be interested in entering into private agreements to be able to perform reviews, although others may still be interested. I believe that our current review process necessitates public source. Reviewers write reviews and everyone else reviews the reviews. I would be interested in discussing alternative processes, but our current process relies on public source. All that said, I totally sympathize with Coinomi. At bitcoin.org, being an open source project, we have dealt with similar cloning issues (not very effectively). In addition, I'll note that Coinomi is a very usable wallet. One of the things that I don't specifically review is usability even though poor usability can render an otherwise good wallet unsafe. It would be a shame to lose the Coinomi listing, so I'm hoping we still might be able to find a way for Coinomi to meet our criteria. |
As the policy of Bitcoin.org does not allow closed source wallets that allow user private key access, we are changing the link for the Coinomi Android wallet to point to the Github release page, that contains the latest open source version along with the necessary source code. Additionally we revert the transparency to "checkpasstransparencyopensource" as the source code is available from the same site.
|
The bitcoin.org link will no longer point to the closed source version hosted on the Google Play Store: #1627 |
|
@erasmospunk, your solution is a deceit. Instead opening your latest source code for public review, you want to change the Coinomi's URL on bitcoin.org website, to some old irrelevant repository with irrelevant source code, just to keep it on the website and keep the free publicity for your product. It's ridiculous that you want to redirect the users to irrelevant website, while hoping they will search your other closed source product with the same name, in app stores. |
|
@erasmospunk @GeorgeKimionis I'm not sure that installing the app from the repository link is a satisfactory solution. I agree with @Bitim's remarks that it's likely many users will prefer to search the Play store rather than download the APK (which some devices may make difficult). However, in order to investigate, I tested downloading and running the APK directly and, before I could even agree to the ToS, it prompted me to update to what I assume is the non-public version:
|
How does this violate any of the listing policies? Users are free to use any version of any app they wish to. Following your analogy, no OSI/FSF website should provide any links to Oracle's MySQL Community Edition code and binaries (licensed under GPL as part of a dual-license) because it's likely many users will prefer to search it on Google and download it from the official website instead of using that website's link and therefore they might end up using the proprietary Enterprise, Cluster or Cloud editions of MySQL. If, however, you believe that the listing would be better off without the update prompt and the reasoning behind this is strong enough then we can simply remove it from the repository and the binaries, despite the fact that it doesn't violate directly or otherwise any of the listing policies and that by doing so we take away the freedom from users who would otherwise be given the option to upgrade their copy or stay with the current version. |
Actually, they're not. Your license says,
My current personal assessment is that:
I have a hacker's appreciation of clever solutions, and so I thank you and @erasmospunk for trying to think of one for this situation, but I think the wording of the Bitcoin.org wallet listing criteria clearly requires that a wallet's current version should be publicly available:
If other Bitcoin.org contributors agree, I can open (with regrets) a PR to delist Coinomi. Thank you again for taking the time to discuss this issue. |
|
I agree. |
|
@harding I could offer to have our attorneys modify the EULA to better fit bitcoin.org's purposes but this would just go on like that forever and frankly I don't want to waste any more time and energy on any more impasse debates. The bitcoin.org listing contributes an insignificant percentage to the total inbound traffic of our store listing anyway so delisting Coinomi isn't quite as big of a deal for us as one might think. Bitcoin.org has served a subtle purpose for newcomers over the years but thankfully this isn't the 2010's any more and there is just so much credible information floating around from so many different sources that makes the listing on this website far less important than it used to be a few years ago. Nevertheless, thanks for having us on board for as long as it lasted and for helping us out with the listing process; special thanks to @crwatkins who has been extremely helpful throughout the process. We can now finally go back to our work and focus on what we do best, and that is building the world's finest multi-asset wallet, which isn't part of the bitcoin.org family any more. @harding no need to wait for the other contributors to consent, we request to get delisted immediately just like we should have done 10 days ago and saved all this time and energy for something truly meaningful. Also, after the delisting we will seriously examine the possibility of shutting down our public repositories. Another battle won for open software, I guess. Or maybe not. |
Closes bitcoin-dot-org#1622 Coinomi no longer provides updated public source code, violating the Bitcoin.org listing policy for wallets with local key storage.
|
PR #1639 has been merged and this conversation has been locked and closed now that we've reached a solution. If any further discussion is needed, please open a new issue. |
This wallet is shady, and its "Basic transparency" is practically none.
The latest commit in their git repo made on February 6th, 2017, when they changed their license from Apache to some custom license (the last actual change made on March 6th, 2016).
On the other hand, the latest version on Google Play Store, released on June 3th, 2017!
The "Basic transparency" attribute of this wallet should be changed to none at least, if not removing this wallet from recommendations. This is a security risk for users.
Thanks.
The text was updated successfully, but these errors were encountered: