User friendliness of our app

[OlivierHokke]

I though it would perhaps be better if the user can start our app using a dialer code, or the widget, but that it would boot the pin dialog where the user then fills in the real pin. This way, when someone calls the wrong pin (causing it to be logged in the call log), the pin is not leaked in the call log. The code to open our app could simply be something short, like by default #963, or something personal like a birthday. However, then it only opens the pin dialog where the user fills in the pin dialog. Also tapping the widget 4 times would open the pin dialog. Or if icon is enabled in the app drawer, opening it would also open thepin dialog.

This way we can create multiple ways of opening the pin dialog, from where we can then handle the accepting or rejecting of pin codes ourselves with our own pincode UI. We could at a later stage even provide multiple ways of filling in a pin: the default dialer-like UI, a pattern, signature, face/voice recognition, or whatever we come up with in the future.

What do you think, guys? @jzvandenoever @AlexKolpa @AlexWalterbos

[alexwalterbos]

so you want to use two steps; first is to open the app via a dialer code, and then a code to verify if the user is the user?

This way, when someone calls the wrong pin (causing it to be logged in the call log), the pin is not leaked in the call log.

Since we don't catch every called number, a code that is erratic enough will appear in the log.

Multiple ways of opening the pin dialog is not per se a good thing, as it can create ambiguity.

[AlexKolpa]

While I understand multiple ways to access the app sounds nice, I think this would work against user-friendliness.

[OlivierHokke]

The point is that the simple small code to open the pin dialog wouldn't be as bad as leaking the actual pin code to get into the files. Because if the #963 would be leaked, someone could open die pin dialog, but your files are still safe.

[alexwalterbos]

It merely transfers the issue to the app dialog instead of the dialer, doesn't it?

[OlivierHokke]

the app dialog doesn't log anything. No leaking.

[alexwalterbos]

Does the gain in frustration for having to enter two pins not overpower this advantage? I get that it's safer, but the two pins would be set to the same by a fair share of the users for easy access.

[OlivierHokke]

Talking about user friendliness... I don't think we should hide our app at all by default, in my opinion. And especially not open it with the dialer by default, as it is very sensitive to leaking (EDIT: and since it is such a strange idea to open an app using the dialer it could throw in confusion). We should show it by default, and then give the user (using a hint and/or a page on the tutorial) the possibility to hide the app icon, and provide various ways of preference on how to open it differently.

[OlivierHokke]

The dialer code doesn't have to be so secure. it could be your birthday, your housenumber, your lucky number. doesn't matter. If someone finds the code to open the pin dialog, then the files are still safe.

[alexwalterbos]

The problem is that if the user has to dial, then enter the pin code, it will frustrate him/her. The fact that we hide our app by default is another topic of discussion, but that is a demand provided by the project and @synctext.

[AlexKolpa]

Given that Morphing almost works, I agree with the not hiding the application by default.

[alexwalterbos]

True that ^

[OlivierHokke]

I think in case of this discussion they are very related, because it is a matter of user-friendliness. I think we have to find a solution for the leakiness of the dialer and the non-user-friendliness of both app hiding and dialer launching. Especially since user-friendliness is supposed to be our main focus.

In fact, as a regular user I'd even be fine with no morphing. I don't care that someone can see that I have the app, only until I have to go through some simple security check I'd like to hide the icon, change it too, rename it, and open using the dialer. The user will choose himself how to open the app, however which way he/she prefers. The downside of the dialer method is an extra small pin (could even be as simple as '#', in fact, why not make that the default), but the user decides based on a short and easy description on the possibilities.

EDIT: the dialer code could even be the phone number of a contact. Just dial "Pete" (could be a made up friend, or someone you never call) and the pin dialog opens

[OlivierHokke]

Changed title of issue

[OlivierHokke]

Also, the PinManager is supposed to save the pins encrypted in the main folder as they are main folder specific. However the decision to open the app using the dialer is app-wide and not main-folder specific.

I foresee the following problem with this: if someone calls his/her pin, the app needs to decrypt the pin preferences file, but if this happens on a separate thread, android is going to think that the call wasn't caught and will continue with calling the provided code. But if we do the decryption of the pin preferences on the main thread, blocking the UI, the user might experience a small lag, before a code is caught or not.

Furthermore, since booting the app using the dialer is a more app-wide setting, I especially think we should separate the launch from the pin entry and save the dialer launch code on the regular android SharedPreferences (can be read really quick, instead of decrypting first). Again, launching could be as simple as dialing '#' or '123'. It is up to the user to decide how easy/difficult he/she wants it. They will be presented with the options in the Security Settings in the app, where a small text will explain the up/downsides.

[alexwalterbos]

I foresee the following problem with this: if someone calls his/her pin, the app needs to decrypt the pin preferences file, but if this happens on a separate thread, android is going to think that the call wasn't caught ..

This can be prevented. We can block on the decryption, even if it is executed on a separate thread. Since the pin preference file should be very small and to-the-point, I think this will not take long and we can let the user wait for this.

I think we will have to let it up to the user how secure it wants its data (it=he/she). I think the double-up with the dialer and the pin is tedious. I think this is something we will have to look into closer, have a separate discussion setting with quick mockups of every option and invite @synctext to this to share opinions. Since it's become clear we can't be unanimous on this, I think this is what we should resort to.

[OlivierHokke]

As a compromise we could provide the user both options:

• Use dialer with small code to open pin dialog (no pin leaking because of mistakes, more secure, costs about 2~3 easy taps more)
• Use dialer with pin to open app directly (pin could be leaked if you make mistakes, but app opens at once)

Although I'd vote against it. It provides inconsistency. In fact I think it is already inconsistent.

If you guys aren't convinced by the summary below, I'll do some user testing.

Summary

For the sake of this discussion and as an overview for myself, let me make a summary of what I am proposing here:

Use only dialer to open the pin dialog with a simple code. Provide different methods of opening app. Default to the usual app icon in the normal application drawer of the user.

Advantages:

• using dialer to open the opening pin dialog instead, more secure
  • accidental mistakes in pin does not cause a pin leak in the call log
  • a leak of the small launch code only shows the existence of the app, does not provide access to files
• makes clear separation of app launch methods:
  • app always launches in pin dialog: ~provides consistency~
  • each launch method has its clear simple separate way of opening the app
  • user can choose different methods of opening app
  • app icon (normal way) [default]
  • morphed app icon & name
  • invisible widget
    • could be made visible from the app to find it. A tap on the widget hides it again.
    • invisible widget does not put visible nonsense on user's home screen
  • dialer (default launch code e.g. 00)
• tablets don't get ignored
• launch code could be simply our original prefix, only 1 tap and 1 screen load animation extra needed: enter code, dial, enter pin, accept, instead of: enter prefix, append pin, dial
• the different app launch settings can be completely app-wide in SharedPreferences.
  • allows fast reading, no UI thread blocking
  • prevents small slowdowns when user tries to do a normal call
  • if main folder switching ever becomes necessary, does not cause a switch in launch methods due to the main-folder-specific pin settings.
• user will have only 1 standard interface where they may enter the pin, instead of 2 separate.
• allows the use of different "pins" in the future, without a big change in launch methods:
  • pin [default]
  • pattern
  • face/voice recognition
  • finger print

Disadvantages:

• user needs to press 1 button extra and wait for 1 extra screen to fade in.
• can seem tedious

Diagram:

As a compromise we could give the user the following option with the dialer method:

• [ ] Use quick launch append your pin to the launch code when dialing, in order to open this application immediately. Bypasses the use of the pin dialog, but is less secure.

[alexwalterbos]

I oppose the double pin proposal in the dialer path to such extent that I'm now going to vouch for eliminating the dialer entirely. I think we're developing enough other means, and with the morphing we'd have means that would make this all redundant. This is taking way too much of our time, so I suggest we discard it.

[OlivierHokke]

hmm, but if my proposal would be a small modification, would it be worth it in your eyes? It would simply provide another way to open it. We are already at the point that the app opens with a pin. Simply letting a code open the pin dialog is not so difficult. Some people might like it. Although, personally I'd use the widget anyway.

[alexwalterbos]

I like the dialer as it is, I dislike it strongly as you propose (no hard feelings rite?;P). The time factor I mentioned is not implementation. It's the time we've spent discussing this, and will be spending after this. Every project has its non-resolving choice, this is obviously the one for Android Stealth.

Go ahead, and implement it if you like, but I still don't think it is something we will ship. At least, that's my opinion.

[alexwalterbos]

@OlivierHokke's proposal is in master.