Most Mac and iOS applications are breaking the rules and could be removed, is yours?

Image of broken iphone for Mac and iOS applications are breaking the rules

UPDATE: the follow up to this post has been published: How to legally submit an app to Apple’s App Store when it uses encryption (or how to obtain an ERN)

We recently began the journey of submitting Screensaver Ninja to the Mac app store, and found that, thanks to a particular rule and the subsequent, off-putting list of steps one must take, it appears that most Mac and iOS applications are breaking the rules. It all started with a specific question that everybody else submitting to the Mac and iOS App stores will encounter:

Is your app designed to use cryptography or does it contain or incorporate cryptography? (Select Yes even if your app is only utilizing the encryption available in iOS or OS X.)

If you are having any doubts, let me break the bad news to you: if you use HTTPS or SSL in any fashion, the answer to this question is a resounding “yes”. When we started looking around we found a lot of resources saying “just say no and move on”. Apple is probably not really checking whether you are using encryption or not but down the road, you might get in trouble. You are essentially breaking US export regulations by saying “no” there. I’m not a lawyer, so I don’t know how much trouble you can get into, but we prefer to go down the safer route and avoid any future issues.

Crypto US export restrictions

For a bit of background, you can read Wikipedia’s article on exporting cryptography. Long story short, cryptography was/is classified as munition for the US and thus its export is heavily regulated and back in the 90s was mostly forbidden. This applies to you even if you are not in the US: when you submit an application to either of Apple’s stores, Apple will be distributing the app on your behalf, from the US to the world, thus exporting it.

On top of that, if your encryption is non-standard, you need special approval to sell in France, but since this doesn’t affect Screensaver Ninja, I’m going to ignore that case.

Export Compliance

If your app uses any sort of encryption, including SSL, HTTPS, etc, your answers about export compliance should look like this:

Mac App Store questions and answers about encryption

The conclusion from selecting the above answers is that yes, sadly, you need to obtain an Encryption Registration (ERN):

To make your app available on the App Store, you must submit a copy of your U.S. Encryption Registration (ERN) approval from the U.S. Bureau of Industry (BIS).

Apple Store submission despair

If you are in a position similar to ours, those words might have started to make you feel a bit hopeless about your submission to the Apple Store. The following words will push you all the way down into the land of despair. Apple’s FAQ says:

Category 5 Part 2 of the US Export Administration Regulations cover the Information Security section of the regulations. Relevant US export administration regulations can be found on the Category 5 Part 2 page and on the encryption web page.

and then in a very involved way it confirms that yes, you do need an ERN, no way around it. That entry in the FAQ links to page with a promising title: How to file an encryption registration. Whatever hope you managed to muster there, the first paragraph will swiftly destroy it:

BIS has created a new SNAP-R screen for encryption registrations. The instructions for submitting an encryption registration are found in paragraph (r) of Supplement No. 2 to Part 748

I read the whole thing several times and I couldn’t figure out how to file an encryption registration. There’s a link to an example view in SNAP-R… what is a SNAP-R and why do I care? I’m not entirely sure but it seems to be a conduit through which you get an ERN:

When an encryption registration is submitted via SNAP-R, SNAP-R will issue an Encryption Registration Number (ERN)

I kept on googling for this issue and I found some people saying that yes, you need an ERN but most of their links were broken, so another dead end. The frustration!

I rolled my metaphorical sleeves and set to work to crack this nut, and after hitting my head against the brick wall of bureaucracy and several phone calls to different US government organizations, I got my ERN. It is actually possible and it’s not that hard, if you know what to do, and where, and how. We’ll soon post our whole journey hoping that you can replicate it for your own app.

UPDATE: the follow up to this post has been published: How to legally submit an app to Apple’s App Store when it uses encryption (or how to obtain an ERN)

Photo by Geoff Parsons

Review of PyConAr 2015

PyConAr, the Python Conference of Argentina, took place the other week. It was hosted in Mendoza city (known as the land of sun and good wine) and I had the pleasure of being one of the speakers. In this post I’d like to share some of my experience there.

First of all, I’d like to say that I’ve not been using Python as a daily tool for several years. Despite that, I find its community very stimulating so I try to participate in its events every time I can.

The conference was 3 days long, from the 12th to 14th of November, with the first day dedicated to programming workshops for newcomers. The main activity of that day was a DjangoGirls tutorial organized by Argentina en Python and LinuxChix Argentina.

The rest of the days the events were dominated by tech talks. I’d like to highlight (and share resources of):

There also were 2 very good keynotes. One about the Python community, by Ashwini Oruganti and one about microservices by Simon Willison which fortunately was recorded: https://www.youtube.com/watch?v=BUQFMatyzKs

To end this post, I’ll link to some videos and tweets that would complete what PyConAr 2015 felt like: good facilitieslightning talks, books selling, very well prepared coffee breaks and lunches for networking, mums with their babies, world-class speakers and lots of people

Review of Clojure Exchange 2015 London

Image of Bruce at Clojure Exchange 2015 London

I recently attended Clojure Exchange 2015 London, the conference organized by Skills Matter for Clojurians. Like many other attendees I was impressed by the quality of the talks and as a presenter, I was particularly pleased that only a few hours later my presentation, What is a Macro?, was already published, in video form, for everybody to see.

Some presentations I found particularly interesting were:

Yada for RESTfull APIs

Malcolm Sparks presenting Yada in RESTfull web service in Clojure, two different approaches. Yada is a library to create RESTfull APIs that focus on succinctness and on doing as much work for you as possible so you only focus on your business model. Yada is also async-ready and you can stream results. We will consider using it instead of Compojure-API in the future, although we still have to explore how to integrate it with other Clojure components. One limitation it has is that it can only work with Aleph, because the other web services don’t provide back pressure.

Clojurescript: Architecting for Scale

Kris Jenkins presenting his pattern in ClojureScript: Architecting for Scale. Kris shows us how he writes ClojureScript single page applications so he doesn’t end up with a spaghetti of code. The pattern is implemented as a library that he just released for the conference, called Petrol. We are happy to see how close the pattern is to our favorite one, as provided by Re-frame, that we use in Ninja Tools and we plan on using in future projects. Clearly the reactive pattern seems the way to go to write client applications beyond Hello World.

Duct, Covered with James Reeves

James Reeves presenting his aggressively simple framework for writing web applications with Clojure in Duct, Covered. You might know James as weavejester, the author of compojure, environ and so many other super popular libraries. Duct is his take on the web framework arena. It can be said to be similar to Luminus, but its emphasis is in the set up of a componentized system. Something that is easier to ignore at first and comes back to bite you later on. I had a private conversation with James after his presentation and I’m really excited about the future of Duct.

Compared to other conferences I’ve been to, it surprised me how many authors of popular open source libraries and tools we had on stage and that made me wonder how many were in the audience that I didn’t know about. I wished I had better visibility into this as I think cooperation makes for a better ecosystem.

One problem I see in the Clojure world right now is fragmentation; we are all inventing our own ways of doing things instead of compromising a bit, cooperating, and making some ways of doing things faster, better, more tested, friendlier, better documented, and so on.

Saying that, the experience was brilliant and I already bought my ticket for next year’s Clojure Exchange at the bargain price of £95.00+VAT. Do you have yours?


A browser in your screensaver is a square peg in a round hole

We are currently running a Kickstarter for Screensaver Ninja for Windows and someone challenged the need for £5000 to develop such a product. I explained some of the technical details we faced and currently face, and it seemed to satisfy my challenger. I realized I never shared those here, so here it is. Putting a browser into your screensaver is like putting a square peg in a round hole and here’s why.

Chromium on Mac

Screensaver Ninja for Mac is already out there. It’s working and it’s robust, but getting there wasn’t without its pains. Initially, we wanted the Mac and Windows versions to have the exact same rendering engine and thus, we went for Chrome’s WebKit, packaged as Chromium Embedded Framework, or CEF for short.

Continue reading this post at Screensaver Ninja’s blog →

Happiness as our culture

Image of happy faces to reflect remote working culture

Being a completely remote working team, our personal lives here at Carousel Apps have become entwined with those of our work life. In fact, I’d go so far as to say they are no longer separate entities, but rather each involves the other to form…well, life as a whole. Personally, as I recently explained in a Remotive article, remote work has been one huge positive leap in the right direction, and one that I’ll never step away from. But this isn’t just thanks to the fact that I can set up shop from the comforts of home – it’s so much more than that now. At the heart of our happiness and genuine drive to work, lies the genuine concern for our happiness itself. And this is a major contributor to Carousel culture.

Things weren’t always better

Just a few decades ago and, let’s face it, in many companies nowadays, work was work and not to be confused with one’s emotional or personal life. Bar occasional chit-chat, hobbies, home and family life were left at the office doorstep, to be picked up again upon entering your front door, slipping into comfortable clothes and assuming your ‘other identity’ of whomever you may be at home. As Nate Hanson wrote in “The Last Generation of People Who Hate Their Jobs“, “Business is business.” And like him, my dad also donned his suit and tie to sit in a cubicle, counting the days till early retirement.

On the threshhold of change

But now, ideals are changing. Tech is allowing us new freedoms. Newer generations are recognising that life can be lived to its fullest and that’s only possible if one feels fulfilled not just on the weekends, but also inclusive of Monday through Friday 9am to 5pm. We’re entering the next paradigm in human history; it’s time to be teal. It’s not just that businesses have realised that happy employees are productive employees, more importantly, we have started to care about people. The realisation that business does not have to mean a cubicle-cell and an emotional vacuum means some companies, including yours truly, are welcoming new takes on company culture.

Our approach to low-cost happiness

If you’re thinking that fostering happiness must be an easier thing to do with spare cash – think company retreats, hobby support and handy health gear a-la Buffer – well, yeah, you’re probably right. Cash does make the world go round, but not its full 360. Our team is a small one and we haven’t yet had our lucky break. So here’s our approach to a happy and fulfilling culture, with minimal spending.


Our team logs in and out of our virtual workspace at all times of the day, our faces popping up then vanishing again from Flowdock as and when we please. Whilst to some this may sound disjointed, we’ve created a workflow that supports this type of scheduling or lack thereof. Through many helpful apps, which we’ll look into in more detail in the future, structured processes including funnelling specific tasks through certain routes, and very clear communication, each one of us knows exactly what we should be doing independently of the others and are kept up-to-date on tasks. Like forming any habit, it took some weeks of being stricter on ourselves to follow certain paths, and yet now it feels like second nature.

And the freedom this creates is priceless. Work doesn’t hold us back from getting on with life. Juanjo can drop his wife off at work every day, Pablo pops out to conferences and talks, I get to spend afternoons taking my kids to the beach. The balance between work and everything else is exactly that, balanced. With no limitations and stress about having to be somewhere at a certain time, without the need to stress about missing important appointments or even just to be able to pop out to meet a visiting friend for a coffee, and with the opportunity to sit down to a computer when we feel our most productive, it’s easier to embrace doing just that.

Going beyond our personal freedom, we decided we also wanted this for the company as a whole. Although we could market our team as a ready-made package with developers and customer support crew at the ready, selling out our services for commission would sap the joy out of our work. Nothing beats the excitement of brainstorming a new idea, building it, releasing it, watching it grow and knowing that the potential is limitless. We work from passion.

Team Support

We all need a little help from our friends, right? For us, the same applies at work. We may be hundreds or even thousands of miles apart, but knowing your team has your back gives us that warm fuzzy feeling inside. Not just for times when emergencies pop up and you ask your colleagues to help complete your tasks, to which they always say ‘yes’ with a little smiley icon, but for the happy things too. Like giving Mhairi a Skype-high-five for catching a great wave or congratulating Pablo on buying (and using!) his first kettlebell.

It may be that we’ve happened to find the friendliest people around to join the team, but more likely, I get that feeling that creating such a supportive environment brings out the best in us all. And we like to share the love.

Remote Work

I’ve found my ideal city to raise a family in Barcelona; Mhairi spends her free time surfing at her local beach in Bali, and Vladimir has stayed close to family in Belgrade. With such differing goals and lifestyles between us, there’s no one city that would keep us in tune with our goals. Instead, living in the places where we thrive on a personal level, allows us to concentrate on what needs doing on a professional level.

The core characteristics

You could say that these three features form part of the core of Carousel App’s culture. They’re what we’ve discovered to work for our team thus far (remember, we’re pretty new to this scene) so there’s always room for our ideals and our methods to evolve, but one thing I’m sure of is that happiness will always remain at the heart of what we do.

Picture by Senorhorst Jahnsen


Using Brakeman

One of the tools I learned about at Ekoparty was Brakeman, an open-source vulnerability scanner which does static analysis of Ruby on Rails applications’ code to find security issues. It’s a gem, so installing it is straightforward:

It’s as easy to use as cding into the directory of a Rails app and running  brakeman -o report.html . It’s really fast, just a couple of seconds for a middle size Rails app.

Brakeman is extremely suspicious, so after running it, a developer has to examine the output to check for example if the values arriving to a certain function are dangerous or not or if proper validations are being performed.

From a big list of warning types, these were the ones that appeared in my case (a very stable production app that was subject to similar analyses in the past):

  • SQL Injection: false positives. They were cases of string interpolation used as parameter of methods like .where  but the interpolation was done with variables defined in the code, not with tainted variables (with content read from user input).
  • Command Injection: one of these was a security issue. The code was supposed to run Rake tasks and looked like this: system("rake #{task}"). The fixed code, that doesn’t trigger the warning, is: system("rake", "#{task}").
  • Mass assignment: this is meant to prevent cases of instantiation with data received directly from the user, like: User.new(params[:user]. According the docs “Brakeman will warn on uses of without_protection”; it does even if the call is done with a literal hash with the parameter without_protection set to true: User.new({username: "jjconti", admin: false}, :without_protection => true). Issue filed.
  • Dynamic render path: according to the docs, “These warnings are often false positives, however, because it can be difficult to manipulate Rails’ assumptions about paths to perform malicious behavior. Reports of dynamic render paths should be checked carefully to see if they can actually be manipulated maliciously by the user”. For us, they were false positives.
  • SSL Verification Bypass: the application was connecting to a server using SSL but wasn’t checking the validity of the certificate. A man-in-the-middle attack could be performed. The Brakeman suggestion of changing http.verify_mode from OpenSSL::SSL::VERIFY_NONE to OpenSSL::SSL::VERIFY_PEER  was accurate.
  • File Access: this is a dangerous one. We have only one case of this. The code was something like: send_file payment.send(file_type).path. Despite the fact that it wasn’t a direct file access, before that line there was a check ensuring that file_type had only valid values: raise "invalid file type" unless file_type.in?(valid_types).

Cases like the last one were ignored to avoid too much noise in the report. For this purpose, Brakeman can read an ignore file. The file is a regular JSON file but the recommendation is to create and manipulate it using the tool itself:


Brakeman wasn’t able to find too many security issues is this app (2 out of 11 warnings of confidence level high) but the application is very stable, running in production for several years now and a similar analysis was performed on it in the past. In spite of this, the exercise of reviewing the code with another set of eyes (even if it was to finally discard a security issue) was enriching.

Picture by Simone A. Bertinotti

jar-copier version 0.3.0 released

We just released a new version of jar-copier, 0.3.0, that includes:

  • Better reporting of misconfiguration.
  • Thoroughly testing misconfiguration reporting.
  • Added the possibility to manually specify the jars (not java-agents).

The main change is the last item, which was planned but now it became clear that some people actually wanted it.