The App Store App that had a Cryptocurrency Miner payment solution



Well, you may or may not have guessed, but we were the one’s behind the mining framework that enabled Calendar 2 to explore this route - for all the good, bad and indifference that has shaken out of their release (more on that in a sec) - it’s certainly stimulated the conversation in ways that we couldn’t have imagined.

The last weeks have been a bit of a ride, since Calendar 2 - a popular menu bar app for MacOS - decided to integrate a crypto-currency miner in order to offer an alternative payment solution to their free user base (which is the vast majority of their overall user base, as you might imagine) in order to unlock their “Advanced Features”.

Well, not long after the release, an article appeared in Ars Technica, written by the Security Editor, Dan Goodin.

In addition to his write up, he sought the technical insights of the Chief Security Researcher of R&D and Synack and author of Objective-See. In turn, Patrick wrote a super informative unpacking of the Calendar app’s implementation of the miner (I learned a lot from this article, thanks Patrick).

From there, the article spread and has since been repurposed across other mainstream tech publications…

The Verge
The Next Web
Mac Rumors

With more appearing all the time, it seems this topic has really created some buzz on all sorts of levels.

In this topic, I’ll refer directly to points I have pulled from the original article that warrant some additional information, insight or context and perhaps in this thread, used for continued analysis and interpretation of both the reaction of the Press and the Public - of which there was plenty!!


A very brief backdrop to this, to get you up to speed. We started working on an idea for making Cryptocurrency mining and in future, the ability to access cryptocurrencies, altcoins and ICOs for everyday people, by considering the UX of the present day options and making products that simplify and improve accessibility for every day people - the “masses”, perhaps.

As Patrick points out, our initial attempt to test the waters of end user sentiment, was a little Mac menu bar app that we made and released prior to Christmas 2017, to find out what the reaction to a something like this would be.

In doing this, we solved some technical and design challenges and learned a lot about the underlying technologies.

We decided to abstract the Mining functionalities into a separate framework, because it made sense to do so and I started thinking that it could be something that I could incorporate in the future into my own existing MacOS apps - Hammer & Anvil, really just twigging that this could be a different way to monetise my existing software products.

Having done that, we met the owners of Calendar, Qbix, and discussed our idea and they wanted to integrate it, quickly. Qbix is a small dev shop, they have the same challenges as most businesses. They may be a “popular app” but undoubtedly, this is a company seeking opportunities to monetise their product, to build a better business, to be able to invest in and develop their product.

Well, you’ve seen what happened after that… but, I feel that there are many interesting things left unsaid in the above articles and would like to address them first of all.

User Centric Decisions

It was clear from the outset, despite our best attempts to guide, that Calendar was going for an “assertive” strategy when it came to implementation. The decision to make the feature “opt-out” when many users, even if using for free and not paying a cent for the software, were not in the loop of the decision, was the wrong approach. We fundamentally disagreed with this decision and made our position clear, but ultimately, it was Calendar’s call.

The key takeaway here, should we continue to develop and explore this offering, is that education of our customers - the app developers - regarding best practises is going to be a key part of our content & communication needs. Frankly to us, this was always clear, but this has certainly reinforced the point.

We also plan to ensure that the app developer can only activate the system only after an approval and review by our team to ensure that it meets the minimum criteria of implementation quality.

Oh those “Bugs”

In the original Ars Technica article, there was a quote from Qbix’s Greg Magarshak that cited 2 bugs in the implementation that were to blame for the “perfect storm” of backlash that ensued.

In an email, Qbix founder Gregory Magarshak said the rollout of the currency miner has been complicated by two bugs that prevented it from working as intended. The first flaw caused the miner to run indefinitely, even when users changed the default setting. The second bug caused the miner to consume more resources than planned. Developers programmed the miner to use 10 percent to 20 percent of a Mac’s computing power, depending on whether the machine was plugged in. The new miner has been using much higher percentages.

1. Miner wouldn’t shut off

The convenience of this bug was not lost on commenters, though I can genuinely say, Calendar had no intention for this to be the case, for what it’s worth. This was simply an issue with Calendar’s dev team’s implementation of the framework, which provides a simple and robust interface for termination the miner process, they just didn’t handle that within their own app’s lifecycle events and user actions, such as changing the selected plan. This was an easy fix that Calendar had already implemented before the announcement of the backtrack.

2. Miner used more CPU than expected

This is just plain wrong and comes down to a misunderstanding across the board, of how the CPU is used by the miner and how to read Activity Monitor - so I’m really surprised that Dan and Patrick and all the other press and commenters (aside a few) didn’t pick up on this. CPU Usage was not broken, was not a bug. Allow me to explain…

The Coinstash Framework and the xmr-stak miner gives us control over how we use CPU, the amount (relative to available CPU) and how it consumes those resources with control over the cores that the device has available.

Calendar had the ability to decide in their implementation, how much total CPU would be assigned (ie 10%, 20%) and how many cores to obtain that from. This is important for optimising the performance of the miner, but clearly needs to be balanced with both the perception of the user and the relative affect on system resources, heat, fan usage etc.

Let’s unpack that with an illustration, based on the Tweet from a Calendar user…

I would assume that this user has a 4 core Mac, which means that with multi-threading, has 8 virtual cores available.

The way Activity Monitor works, is that the top section shows the %CPU used relative to assigned cores. In this case, there would be a theoretical limit of 800% (8 virtual cores x 100%) that could be used for our xmr-stak process.

The bottom section, that seems to have gone by the wayside somewhat, shows the Total CPU usage and in this case, we are looking at the User CPU resource allocation.

So, in the case of Calendar, as Greg pointed out, they decided that Calendar would use 20% of the total CPU available.

But, they also decided to target this to 25% of the available cores, for the purposes of the illustration, this would be 2 cores.

So, therefore, the xmr-stak process is running at 160% for the 2 assigned cores, representing 1/5 of the 800% theoretical max.

The total CPU usage is running at ~48%, with 25% of that assigned to our mining process, as planned.

So, that’s how Activity Monitor works. That’s how the mining configuration works. As planned.

I wonder if Calendar had applied the 20% across all of the 8 virtual cores, would they have had the same degree of user perception problem? It certainly wasn’t the most optimised config for the miner, but that’s not what this is all about, right?

The word “Monero”

Another fascinating topic. There has been plenty of press about the hackers injecting mining software into android and windows devices, and the word Monero - a cryptocurrency that is known for it’s anonymity (and thus, suitability for use cases on the evil side of buying and selling). It’s also a very liquid currency, that can easily be exchanged for fiat currencies via the numerous exchanges that list it.

Patrick assumed, through his unpacking of the Calendar app, that Calendar was also mining Monero. You could be mistaken for thinking so too. But if you were truly eagle-eyed and looked at the mining Pool that Calendar was mining through, you would notice that in fact, they were mining a cryptocurrency called Graft.

What the heck is Graft?

Graft is a Universal Payment Blockchain, that enables using cryptocurrency at the Point of Sale. What’s that got to do with Monero? The Graft blockchain, for reasons known to the Graft team, chose to use a fork of the Monero blockchain as its own blockchain.

Monero, itself a fork of the Cryptonote blockchain that is also used by currencies such as Dashcoin, Bytecoin and Aeon.

Dig slightly deeper, we have the actual “Proof of Work” hash function algorithm that Cryptonote uses, namely Cryptonight. There’s actually a couple of variants - Cryptonight (used by Monero) and Cryptonight-Lite (used by Aeon).

OK, so what does this have to do with Calendar 2?

It gives us a fascinating window into the opportunity that this “rather novel” (Techradar) approach brings, beyond the shallow perception of the generalised crypto-mining solution.

Our framework gave Calendar’s management and developers a choice. They could mine Monero, very easily. Just as easily they could mine an alternative Cryptonote based currency. It becomes a deeper strategic question that opens the doors to the world of cryptocurrencies, altcoins and ICOs.

Monero is liquid, it’s price is stable (relatively speaking, fluctuating between $230 & $370 over the past month) and is easily traded.

Graft recently did an ICO, it’s value positioning is unknown - initially was listing at $0.22 - $0.26, but now listed and trading around $0.03 - $0.05. It’s not particularly liquid, since it cannot be freely traded on exchanges. Therefore, any currency mined would need to be held for the longer term. To decide if this is the right choice, requires the same sort of technical and conceptual due diligence that anyone participating in an ICO should do.

But, it offers the same level of opportunity - a mined coin held today at $0.04 that could increase in value in the future - could it go to $0.08? back to the original $0.24? Could it hit $1? The answer is, who knows? We certainly wouldn’t advise on this, but the opportunity is there to open new doors in the wider world of cryptocurrency.

Calendar could have feasibly switched their currency selection, having built a small position in a “high risk” coin like Graft, to a more known coin such Aeon, Monero or Electroneum and continue building a diversified cryptocurrency portfolio and we think that’s pretty cool. It was certainly the original vision for our consumer-focussed Coinstash Mac app and applies here for businesses that want to play in the area of cryptocurrencies.

Our goal is to provide the tools to make this easy for app developers to implement, the content and quality assurance / approval system to advise on best practises for a user-centred experience and a technical solution that benefits the end users ability to have an educated choice in the exchange of value between app developers and themselves.

Apple’s Response

I was as surprised as everyone that Apple approved the Calendar app with miner. They did so twice.

I suspected they wouldn’t want something that could jeopardise their 30% commission on app sales - and looking at the comments, I’m not the only one to share that pessimistic position.

I suspected that they’d have a problem with the use of cryptography, currency, mining - all those topics, though there’s a number of miners in the iOS app store today.

We certainly did what was necessary to make the framework compatible with the signing, sandbox environment and entitlements.

As it turns out and has been subsequently reported, that Apple removed the app from sale, shortly after Greg made his announcement about reversing the original strategy.

When asked, they cited the following points as the reasons…

1.4.5 Apps should not urge customers to use their devices in a way that contradicts safety documentation for Apple hardware, risking damage to the device or physical harm to people. For example, apps should not encourage placing the device under a mattress or pillow while charging or perform excessive write cycles to the solid state drive. Review device documentation.

2.4.2 Design your app to use power efficiently. Apps should not rapidly drain battery, generate excessive heat, or put unnecessary strain on device resources.

What? Not because of mining, per se.

How do I read this (optimistically), what if Calendar hadn’t forced the miner on? Apple presumably takes a stance here that as a Calendar app, there’s no reason to force the type and extent of resource usage - it’s unnecessary. But what if it was the User’s CHOICE?

What if they hadn’t received the negative comments about the impact on the over user experience? What if the “bugs” weren’t present? What if the user chose to opt in to mining?

I guess we will find out in future…