**It's hard to build cloud-synced collaborative apps if you genuinely care about user privacy. Most apps are not private by default _by design_. They should be.**

## Making apps for making music

I write songs. It's something I've done since I was a teenager. It's a theraputic process. The main benefit comes from the process itself. Most of the time no one hears these songs but me (and maybe the guy who lives upstairs).

In 2014 I released an [Android app created to help capture ideas for songs](https://play.google.com/store/apps/details?id=com.shaunchurch.songwriter.app). It's for jotting down ideas for lyrics and recording snippets of audio to go with it: playing guitar, humming a melody, recording an improvisation to review later.

It works great. I put it up for sale for a modest price and over recent years people have been discovering it organically and buying it. A growing number of them now use it consistently to record ideas. I use it myself often.

It's basically a notes app. Nothing fancy. Nothing original. But because it's focused on the songwriting niche there is an opportunity to cater specifically to those needs. I have a list of ideas for the future.

## Private work

Songwriting is often a [personal artistic exploration of ideas](https://www.brainpickings.org/2014/09/22/joni-mitchell-in-her-own-words-malka-marom). There's a need to open up to possibilities and be non-judgemental. To be free from the perceived judgement of others. To be free to express without consequence and rely on editing later to remove the bad or the embarrassing.

The creative process can be volatile, and [sometimes work needs polishing](https://www.brainpickings.org/2014/07/15/leonard-cohen-paul-zollo-creativity/) before it makes sense in the world.

For me, the data this app stores is sensitive. I need to be confident there is protection from prying eyes to fully engage.

## Big brother is watching

The idea of someone watching while you create ideas for songs is not conducive to a non-judgemental, free approach to creativity. **There's a cost to being seen and it shows up as self-censorship**.

I don't want the embarrassing teenage poetry of the first draft of the second verse I'm working on to make it out of my edit window. If there's a possibility of it getting out onto the public internet I'm going to think twice about writing it. That could be a loss. I might have reworked it in to something less cringe inducing, while carrying that same sentiment; it could become something that resonated with other inner juveniles. In part, that's the essence of songwriting.

**If we're censoring our true feelings we can't write our best work**. It's important to have privacy built-in to the apps you use to capture your creative ideas.

Data privacy is even more of a concern for other types of data. Consider private journaling or diaries.

_"But who is watching?"_

## Platforms as a service

Most application platforms store all user information in plain text. If I build an app today using Google's Firebase, I have access to every byte of data uploaded by that app's users.

If I build an app which offers users "a private diary, synced to your web browser through the cloud", it's now possible for me as the app administrator to read every sentence they write in the app in most cases. It may not be legal--depending on what terms and policies I ask users to agree to--but it will be possible. I'm not sure what sort of audit trail exists, if one exists at all.

The implications are obvious, but to be clear: **as the admin of a diary application built on Firebase the developer has access to the private diary entries of the users.**

That also goes for direct messages on that obscure dating site you joined that time.

## Offline for now

Songwriter's Notebook is not built on Firebase. It stores all recorded data in the app's secure directory on-device. It stores the lyric content and all the file metadata in a simple SQLite database in that same directory. This means we can rely entirely on Android's built-in security. It's difficult to gain access to the data in that directory without rooting the device.

The Export function allows you to optionally export files to another location for back up. This is opt-in and means you can make decisions about who you share your data with.

## The problem with offline for now

Keeping the data on-device means the app has no multi-device sync capability. It has no multi-user collaboration. It has no ability to re-import a previously exported backup. These are hugely important features, that are unavailable in part due to my desire to retain privacy. I want to allow users to opt-in to sharing, multi-device and multi-user collaboration features only if they need them. And then, I still want the data to remain unreadable to anyone not explicitly granted access.

The existing export feature encourages users to backup their data to less private services: Gmail or Dropbox for example. In some ways data shared with online services unencrypted becomes part of the public record. It could leak at any time, due to a technical oversight or a malicious hack. It happens all the time.

This caution comes at a cost. The app is less capable than a lot of modern apps because I think user privacy is more important than those features. But I still want those features. Multi-device cloud-based data sync is a baseline expectation for apps today.

**I would like to find a way to have both syncing and privacy. To have a cake that I can share with my friends if I feel like it, without having to offer everyone a piece.**

## The Challenge

**It's very hard to build a secure, offline-first, privacy conscious application that allows you to _opt-in_ to cloud-based multi-device sync and collaboration features.** Especially as a solo developer.

Some points for thought:

- **There is a crisis in software development when it comes to user privacy.**
- Everything you post unencrypted to an online service should be considered as part of the public record.
- There is no guarantee of privacy in most circumstances, but many services fail to make any attempt at it.
- Developers are building all sorts of software using development practices that don't consider user privacy in any way.
- There's a lot of work to be done to make private services more accessible. To make apps built this way more useful, convenient and streamlined.
- How many services have you used that rely on Google's Firebase Firestore or Realtime database? Probably many.
- This service shares your data with the app owner with no protections.
- Privacy is a growing concern.
- Offline-first is a growing movement
- Surveillance capitalism: there is every incentive to spy on user data, collect it, sell it and process it for derived information. Better if it's not available unless we opt-in.
- The problem is keeping your data private while still allowing effective multi-device access and multi-user collaboration.

The goal is to build offline-first applications that can work offline-only on any platform, but that can optionally move some data online, encrypted between devices and users, to allow multi-device access and multi-user collaboration.

I plan to write more on this in future and I'm interested to hear what you think.

I'm [@shaunchurch](https://twitter.com/shaunchurch) on twitter.

App privacy, part I: Apps are not private


I have a love/hate relationship with SVGs.

They're wonderful. They're annoying.

Occasionally I catch myself becoming frustrated with some of the issues I've run into while using them. Then I remind myself what it was like before browsers had reasonable SVG support, when I'd have been using images or icon fonts. Pain is relative.

Today I ran into an interesting issue doing some break point testing of a navigation menu with [Cypress.io](https://cypress.io). Once again an SVG was centre stage in an episode of _bizarre browser behaviour_.

## Click Test

I have a menu bar. It has icons with labels at large screen sizes. On smaller screens the labels disappear leaving only the SVG icon.

I wanted Cypress to test the menu and navigation on a selection of screen sizes from 320px to 1920px.

This is easy to do by looping over an array of width, height pairs inside the test, each time setting the screen size with `cy.viewport()` before clicking the buttons:

```javascript
it("clicks the button", () => {
  screens.forEach((screen) => {
    cy.viewport(screen[0], screen[1]);
    cy.get(buttonSelector).click();
  });
});
```

This worked fine at higher resolutions, but failed with a nasty error as soon as the navigation labels beside the SVG icons disappeared on smaller displays.

```
CypressError: Timed out retrying: illegal invocation
```

_*Interesting.*_

## Hmmm...

Inspecting the element gave no clues, and I could still click the element manually even inside the Cypress UI.

Putting a label beside the icon made the test pass. Removing the label made it fail. It was quite peculiar. A label by itself would pass. The icon by itself would fail. The icon and the label would pass.

Any other sibling element made the test pass. A solitary SVG would always fail. Unclickable.

I turned to Google. There was a [test case filed in an issue on Github](https://github.com/cypress-io/cypress/issues/2258)! This always inspires a feeling of camaraderie.

_Someone knows my pain!_

It turns out a [bug in Cypress](https://github.com/cypress-io/cypress/issues/2258) caused any SVG or _any element containing *only* an SVG_ to become _unclickable_.

[The fix](https://github.com/cypress-io/cypress/pull/2246) is in the next release which is, amusingly, due out just as I discover I need it.

It wasn't really the SVG's fault at all. It was framed.

Testing with Cypress is so pain free that it really hurts when you do run in to a strange issue. I reminded myself of all the trouble I had trying to drive Selenium with JavaScript.

This is nothing.

Pain is relative.


Bizarre browser behaviour: SVG in the Cypress Tree


As so often happens with code left unattended, my static generated website inexplicably stopped generating with the current release of the generator. 404s now reigned where out of date content pages used to be king. Reverse chronological posts became chronological. Bad writing resurfaced from the depths of a forgotten history.

It sometimes feels inevitable that code over time will eventually break itself, but this isn't quite true. Things change around it, until eventually something responds unexpectedly--or not at all. The messages miss, or say the wrong thing.

_I'm sorry, who are you?_

It was a bug fix, or an improvement that missed consideration of your use case. Maybe you were using it wrong all along.

If change is the only constant your website will eventually break, too. The old build that used to run is no longer compatible with this machine. Essential security updates cut the tether to the functional past. The eternal braid of dependencies has tangled to the point it cuts off it's own oxygen supply.

I suppose I'm growing accustomed to obsolescence. It breaks even if you don't do anything, so don't be afraid to change it. You can hear the cries that _"it wasn't supposed to be like this!"_ echoing into a backwards compatible abyss.

After this brief existential overreaction and a cursory search that led _nowhere fun_, it looks like I'm going to give Gatsby a try. Hugo's esoteric template language was never my cup of tea, so I won't drink it now it's cold. Lots of folks hate JSX too, but better the devil you know. Ask Kylie.

Maybe _this_ time I'll actually use it to write a bit, too.

_This time will be different._

Of course it will.


://shaun.church

Featured projects

Songwriter's Notebook

Crypto Litmus

Latest posts

App privacy, part I: Apps are not private

Bizarre browser behaviour: SVG in the Cypress Tree

It breaks all by itself