Our Android App’s Permissions Explained

Permissions

Starting on Android 6 (Marshmallow), Android has been improving and shaping permissions, adding more control to users and a better overview of what apps do with those permissions. Apps permissions are going in a direction of more transparency and security.

Still, it’s not always easy to understand why some permissions are needed some times. We at ottonova would like to clarify why we request some permissions and for what do we use them.

Permissions overview

The purpose of a permission is to protect the privacy of an Android user. Android apps must request permission to access sensitive user data (such as contacts and SMS), as well as certain system features (such as camera and internet). Depending on the feature, the system might grant the permission automatically or might prompt the user to approve the request.

Permissions are used to request system functionalities. Some permissions require user approval and some don’t. It depends on the protection level of the permission.
There are 4 levels of permissions: Normal, SignatureDangerous and special.
Additionally there are custom permissions that can be created to request app services access. Basically an app can declare these custom permissions so it can access another app or its own service.

Protection levels

Level Needs user approval? Description Example
Normal No Provides access to data or resources outside the app sandbox. Does not incur any risk to private data or other apps operations. WiFi state, Internet, Bluetooth, etc
Signature No These permissions are granted at install time. Apps that require these permissions need to be signed by the same certificate of the app that defines the permission. Battery stats, carrier services, etc
Dangerous Yes These permissions can provide access to sensitive data or resources or could potentially affect the user’s stored data or operations by other apps. The user must explicitly authorize the usage of these permissions. The app can only use a functionality that depends on these permissions after the user authorizes it. Read contacts, camera, capture audio, etc
Special / Privileged Yes Similar to dangerous permissions, but the authorization of these permissions is managed by Android Operating system. Apps should try to avoid using these permissions Write settings, system alert windows, etc

 

What permissions do we use?

Camera

Permission name: android.permission.CAMERA
Protection level: dangerous

One of the core features of the ottonova app, is that you can quickly scan an invoice or other document and quickly upload it to us. We could use the native camera and not request this permission, but then users would lose the features that we provide by using our in-app camera feature, that gives users automatic boundary/edge detection of documents and editing functions like cropping, rotating, etc.

Permission name: android.permission.FLASHLIGHT
Protection level: Normal

Used to turn the phone’s flashlight on or off for when users scan a document.

Storage

Permissions name: android.permission.READ_EXTERNAL_STORAGE, android.permission.WRITE_EXTERNAL_STORAGE
Protection level: dangerous

Besides scanning a document on the spot, users may also want to upload a document from their phone storage. This includes images or PDFs. That’s why we require this permission, so we can read an imported file from the external storage. This permission is not strictly necessary for users to upload invoices, it’s only necessary if you would like to import a file. We don’t scan the external storage, the implementation of this feature calls the default file picker on the phone, and most file picker apps that come with Android don’t actually require the caller app (ottonova in this case) to request this external storage permission, but unfortunately some do. That’s why we request this permission, so your experience as a user is as smooth as possible. Android 10 is introducing some changes to these permissions, an app won’t have to request access to all external storage anymore and will be able to only request access to media folders in the external storage.

Other app capabilities

Permissions name: android.permission.ACCESS_NETWORK_STATE, android.permission.ACCESS_WIFI_STATE, android.permission.INTERNET
Protection level: Normal

All of these permissions are related to the internet access. The INTERNET one is so we can perform operations that require internet and the other are just so we can know if we’re connected to a network or if we have internet at all.

Permission name: android.permission.WAKE_LOCK
Protection level: Normal

This permission allows an app to keep the phone awake for a certain amount of time. In ottonova’s app case, this is used by our tracking library (Firebase by Google) to keep the phone awake while Firebase communicates with google service to provide helpful app usage data to the server. Users can disable at any time app usage tracking, simply go to App settings > Notifications. If you disable tracking this permission won’t be used at all.

Permission name: android.permission.USE_FINGERPRINT
Protection level: Normal

With ottonova’s app, we have a pin screen to keep your data safe. You can either input a defined pin or use your fingerprint to unlock the app.

Permissions name: com.google.android.c2dm.permission.RECEIVE, com.google.android.finsky.permission.BIND_GET_INSTALL_REFERRER_SERVICE
Protection level: Normal (Custom permission)

Both of these permissions are defined by Google. The RECEIVE is used to receive push notifications and the BIND_GET_INSTALL_REFERRER_SERVICE is used by Firebase to recognize where the app was installed from.

Permission name: android.permission.FOREGROUND_SERVICE
Protection level: Normal

When a document is being uploaded we use this permission so users can put the app to background while we finish the upload operation. Whenever this permission is used a notification is always shown.

Conclusion

Permissions are getting more transparent and users are getting more control over what apps can do. These are vital improvements to help keeping user data safe.
Still, we feel that there are some improvements to be made in this field. For instance, external storage is still not a very safe place to store sensitive data because other apps can access that data without system privileges just by requesting the external storage permission (it’s starting to change with Android 10), that’s one of the reasons we don’t store any sensitive user related data locally, all sensitive data is stored remotely in our servers. At ottonova we use only the bare minimum permissions that we can to make our app and services work, always keeping in mind potential vulnerabilities that could compromise our customers data.

We value transparency, that’s why we made this post.

We welcome changes made to improve app permissions and overall security regarding users data privacy. For example, Android 10 is introducing new permission scopes for external storage access, meaning that apps will be able to simply request access to media folders (i.e.: Images or Download folder). Also, although not used by ottonova, asking for location while on background will require user permission. There are more changes, to see further privacy changes on Android 10 see this link.

References

Recruiting Backend Engineers at ottonova

To do our part and share with the Community, as well as provide a bit more transparency into ottonova and how we are building state-of-the-art software that powers Germany’s first digital health insurance, here are some words about how the Backend Team goes about finding new team members. 

We’re going to cover what we are doing in the Backend Team, what we value, and how we ensure we hire people that share our values.

The Backend Team

Our team is responsible for many of the services that power our health insurance solutions at ottonova. This includes our own unique functionality, like documents management, appointments timeline, guided signup, as well as interconnecting industry-specific specialized applications.

Under the hood, we manage a collection of independent microservices. Most of them written in PHP and delivering REST APIs through Symfony, but a couple leveraging Node.js or Go. Of course, everything we use is cutting-edge technology, and we periodically upgrade.

As a fairly young company, we spend most of our time adding new functionality to our software, all in cooperation with product owners, but at the same time we invest fair effort into continuously improving the technical quality of our services.

Values

Technical excellence  is one of our team’s core values. To this end, we are practitioners of Domain-driven design (DDD). Our services are built around clearly defined domains and follow strict separation boundaries. 

Because we created an architecture that allows it, and we have the internal support to focus on quality, we invest a lot into keeping the bar high and whenever needed we refactor and make sure the Domain Layer stays up to date with the business needs, or that the Infrastructure Layer is performant enough and can scale.

Although most of our work is done using PHP, we strongly believe in using the right tool for the job. Modern PHP 7+ happens to be a pretty good tool for describing a rich Domain, but we like to be pragmatic and where it is not good enough, maybe in terms of performance, we are free to choose something more appropriate.

Expectations from a new team member

From someone joining our team we, first of all, expect the right mindset for working in a company that values quality. We are looking for colleagues that are capable and eager to learn as well as happy to share their existing knowledge with the team. 

A certain set of skills is needed as well, or the right foundation for developing those skills. We are particularly interested in a good mastery of  programming and PHP fundamentals, Web Development, REST, OOP, and Clean Code.

As actual coding is central to our work, we require and test the ability to both write code on the spot, and to come up with clean design.

These expectations can be grouped into four main pillars that a candidate will be evaluated on:

  1. Mindset – able and willing to both acquire and transfer knowledge inside a team
  2. Knowledge – possesses the core knowledge needed for using the languages and tools we use
  3. Clean Design – able to employ industry standards to come up with simple solutions that can be understood by others
  4. Coding Fluency – can easily transfer requirements into code and coding is a natural process

The Recruiting Process

To get to work with us, a candidate goes through a process designed to validate our main pillars. All this while giving them plenty of time to get to know us and have all their questions answered.

It starts with a short call with HR, followed by a simple home coding assignment. Next there is a quick technical screening call. If all is successful so far, we finish it up with an in-person meeting where we take 1-2 hours to get to know each other better.

The Coding Assignment

Counting mostly for the Clean Design pillar, we start our process with a coding assignment that we send to applicants. This is meant to allow them to show how they would solve normally a problem in their day-to-day work. It can be done at home with little time pressure, as it is estimated to take a couple of hours, and it can be delivered within the next 10 days.

The solution to this would potentially fit into a few lines of code. But since the requirement is to treat it as a realistic assignment, we are expecting something a bit more elaborate. We are particularly interested in how well the design reflects the requirements and the usage of clean OOP and language features, the correctness of the result (including edge cases), and tests.

We value everyone’s time and we don’t want unnecessary effort invested into this. We definitely do not care about features that were not asked for, overly engineered user interfaces or formatting, or usage of design patterns just for the sake of showcasing their knowledge.

It will ideally be complex enough to reflect the requirements in code, but simple enough that anyone can understand the implementation without explanations.

The Tech Screening

To test the Knowledge pillar we continue with a Skype or a regular phone call. This step was designed for efficiency. By timeboxing to 30 minutes we make sure everyone has time for it, even on short notice. We don’t want to lose the interest of good candidates getting lost in a scheduling maze.

Even if it’s short, this call ensures for us a considerably higher match rate for the in-person interview. In time we found that there really are just a handful of fundamental concepts that we expect a new colleague to already know. Many of the other can quickly be learned by any competent programmer.

All topics covered in this screening are objectively answerable. So at the end of a successful round we can make the invitation for the next step.

In-Person Interview

This is when we really get to know each other. This is ideally done at our office in central Munich – easier for people already close by, but equally doable for those coming from afar.

In this meeting we start by introducing ourselves to each other and sharing some information about the team and the company in general.

Next we ask about the candidate’s previous work experience. With this and the overall way our dialog progresses we want to check the Mindset pillar and ensure that the potential new colleague fits well into our team.

After that we will go into a new round of “questioning” to deeper test the Knowledge pillar. Similar to the Tech Screening, but this time open-ended. Informed opinions are expected and valued. We definitely want to talk about REST, microservices, web security, design patterns and OOP in general, or even agile processes.

Then comes the fun part. We get to write some code. Well… mostly the candidate writes it, but we can also help. We go through a few mostly straight forward coding problems that can be solved on the spot. We are not looking for obscure PHP function knowledge, bullet-proof code, or anything ready to be released. We just want to see how a new problem is tackled and make sure that writing code comes as something natural to the candidate. With this we cover the Coding Fluency pillar.

Afterwards it’s the interviewee’s turn. We take our time to answer any questions they may have. They get a chance to meet someone from another team and get a tour of the office.

What’s next?

The interviewers consult and if there is a unanimous “hire” decision, we send an offer. In any case, as soon as possible (usually a few days) we inform the candidate of the outcome.

Interested in working with us? To get started,  apply here: https://www.ottonova.de/jobs

Über unsere ausgeschriebene QA-Stelle

Wir sind stetig auf der Suche nach neuen Mitarbeitern, unter anderem suchen wir auch QA-Spezialisten.

Franz-Xaver hatte dazu einige interessante Fragen, die wir euch zusammen mit den Antworten nicht vorenthalten möchten.

Here we go:

1. Ist Testautomatisierung Teil der QA-Tätigkeit? Falls ja, welche Erfahrung in welchen Programmiersprachen/Frameworks wird hier vorausgesetzt?

Ja, Testautomatisierung ist für uns ein sehr wichtiger Bestandteil. Für die Automatisierung der Web-Tests verwenden wir primär Python 3.
Die UI-Tests von den iOS und Android Apps sind in Java implementiert. Erfahrungen mit Appium oder Selenium sind sehr willkommen, beides setzen wir auch ein. Erfahrungen in der Nutzung klassischer Frameworks wie Page Object Pattern und der gängigen Build-Tools wie Jenkins ist auch ein großes Plus.

2.  Welche Art Tests soll genau durchgeführt und entwickelt werden (Akzeptanztests, Regressionstests, UI Testing, Backend-API Tests…)?

Es werden Regressions- und Akzeptanztests entwickelt und durchgeführt. Die Entwicklung und Durchführung der automatisierten UI- und Backend-Tests gehört ebenfalls zu unseren täglichen Aktivitäten.

3. Welche Anwendung soll genau getestet werden? Handelt es sich um die ottonova App? Falls ja, sollen beide Versionen (iOS und Android) getestet werden? 

In unserem QA-Team testen wir sowohl unsere verschiedenen Web-Anwendugen, als auch unsere mobilen Apps (iOS und Android).

4. Wie groß ist das Entwicklerteam und aus wie vielen Mitgliedern besteht das Testteam? Wie viele Releases wären pro Tag zu testen?  

Es gibt mehrere Entwicklungsteams, die aus Backend-, Frontend-, Mobileentwicklern und der QA bestehen. Die Entwicklungsteams nutzen die agilen Entwicklungsmethodologien wie Scrum und sind funktionsübergreifend organisiert (cross-functional), beinhalten also z.B. auch Product Owner oder Mitglieder unserer Versicherungsfachbereiche. Aktuell sind bei uns zwei dedizierte Personen Vollzeit für das QA-Testing zuständig, und kümmern sich dabei um manuelles sowie automatisiertes Testing.

5. Richtet sich das Stellenangebot für Werkstudenten ausschließlich an (immatrikulierte) Studierende oder können sich auch berufserfahrene Personen mit abgeschlossener Ausbildung bewerben? 

Wir sprechen in der aktuellen Stellenausschreibung gezielt Werkstudenten an, weil wir in der Vergangenheit gute Erfahrungen gemacht haben. Wir sind natürlich immer bereit, Studenten einiges an Wissen und Erfahrung zu vermitteln. Natürlich haben Personen mit abgeschlossener Berufsausbildung bei einer Bewerbung die gleichen Chancen.

6. Handelt es sich um einen zeitlich befristeten Vertrag? Wie hoch ist die wöchentliche Arbeitszeit? Welche Weiterentwicklungsmöglichkeiten habe ich in Ihrem Unternehmen im Bereich QA?

Wir sind bei allen Punkten flexibel und gehen gerne auf die Wünsche und Vorstellungen der Bewerber ein, das betrifft sowohl die Wochenstunden als auch die Vertragsbefristung. Werkstudentenverträge sind standardmässig auf ein Jahr befristet und besitzen einen fixen Stundenlohn. In unseren Arbeitsverträgen für eine Vollanstellung ist immer eine Probezeit von 6 Monaten vorhanden. Eine Festanstellung nach einer Werkstudententätigkeit (oder auch Praktikantentätigkeit) ist immer unser höchstes Ziel. Die Weiterentwicklungsmöglichkeiten sind je nach Mitarbeiter individuell, wir unterstützen bei der Verwirklichung deiner Ziele wo wir können.

Welcome to our ottonova.tech Blog!

Hello everybody,

with this post we want to kick off the ottonova tech blog and also explain a little bit why we’re doing that.

With this blog we not only want to keep up the tradition that “every tech centric startup should have a blog”.
We sincerely want to give you insights on how we create the technology and platform behind ottonova – the new kid on the block, the first private health insurance since over 17 years.

We’re assembling a strong and experienced IT team of over 25 people and growing. We’re focusing on everything it needs to create and run a private digital health insurance in 2018: Multi platform programming, cloud infrastructure, quality assurance, data science, data security, and, last but not least, office IT.

Our idea is to regularly publish interesting articles about our work and events. Something around 2 articles per month seems reasonable. Every IT member at ottonova is invited to participate, even other departments might contribute if it is inside of this blog’s scope: Technology.

Hope you’ll regularly visit our humble pages,

⭐️,
Andreas