search

kalaspuffar / secure-quick-reliable-login

This repository is an implementation for SQRL (Secure Quick Reliable Login) on Android.
MIT License
115 stars 29 forks source link

Intent.ACTION_OPEN_DOCUMENT #314

Closed kalaspuffar closed 5 years ago

kalaspuffar commented 5 years ago

Research feature

alexhauser commented 5 years ago

Hi @kalaspuffar ,

sounds like a great feature. This would enable easy import of .sqrl files from local storage as well as from cloud providers, usb devices etc. directly from the app. Also, it would be a great complementary feature to #260 and should play nicely with my current implementation (pending PR) thereof.

And allthough the docs would want us to use ACTION_GET_CONTENT instead...

ACTION_OPEN_DOCUMENT is not intended to be a replacement for ACTION_GET_CONTENT. The one you should use depends on the needs of your app:

  • Use ACTION_GET_CONTENT if you want your app to simply read/import data. With this approach, the app imports a copy of the data, such as an image file.

  • Use ACTION_OPEN_DOCUMENT if you want your app to have long term, persistent access to documents owned by a document provider. An example would be a photo-editing app that lets users edit images stored in a document provider.

... I still think having all the document provider sources in one single UI is compelling.

One question I have is how would we surface this feature? In advanced functions -> Import, should we present another choice where one can choose between "Scan identity QR code" and "Import identitiy from file"?

//EDIT: The choices above should also include "Import with text input", this way we would have one single entry point for all the import tasks.

Best regards, Alex

kalaspuffar commented 5 years ago

Hi @alexhauser

All your comments above align with what I've been thinking since I heard about the feature. Listening to all Google I/O talks at the moment. Interesting that this feature haven't been more highlighted.

Is it supported in all of our supported API versions?

Best regards Daniel

kalaspuffar commented 5 years ago

Hi again @alexhauser

Maybe you should do this new feature with moving things around and adding GET_CONTENT in a separate branch/PR to make the review process quicker.

Best regards Daniel

alexhauser commented 5 years ago

Hi @kalaspuffar ,

great to hear that we're on the same page on this one!

Is it supported in all of our supported API versions?

Not exactly, it is available starting from API level 19. But we could implement ACTION_OPEN_DOCUMENT for >= 19 and ACTION_GET_CONTENT for earlier APIs.

Maybe you should do this new feature with moving things around and adding GET_CONTENT in a separate branch/PR to make the review process quicker.

I fully agree. But then i'd like to wait for the PR for #260 to be reviewed/merged, so that I can base everything off of a clean, reviewed state.

Best regards, Alex

kalaspuffar commented 5 years ago

Hi @alexhauser

Great to hear.

So ACTION_GET_CONTENT is supported pre API 19 or did you switch them around in your comment?

If I understood you in the first comment we wanted to use ACTION_GET_CONTENT for all file open tasks. We don't want to write just read so it should work for all implementations if supported.

About #260 I might have found a bug in it or the file export. Could not import with password when testing in emulator. Could be an emulator issue and I did it at work between tasks so have not tested it extensively.

Best regards Daniel

alexhauser commented 5 years ago

Hi @kalaspuffar ,

sorry for not making myself clear enough.

The docs state:

On Android 4.3 and lower, if you want your app to retrieve a file from another app, it must invoke an intent such as ACTION_PICK or ACTION_GET_CONTENT. The user must then select a single app from which to pick a file and the selected app must provide a user interface for the user to browse and pick from the available files.

So no big choice for API level 18 and earlier.

On Android 4.4 and higher, you have the additional option of using the ACTION_OPEN_DOCUMENT intent, which displays a system-controlled picker UI controlled that allows the user to browse all files that other apps have made available. From this single UI, the user can pick a file from any of the supported apps.

Starting from API 19 and higher, we could use the ACTION_OPEN_DOCUMENT, which I think is much more user friendly, because you don't have to choose a "file picker" app before even locating the file. Also, it provides access to all registered file providers through one single system-controlled UI. This should help avoid inconsistencies between different devices/manufacturers.

I therefore tried to make the point that, even though the docs state that in our case for only reading a file ACTION_GET_CONTENT would be sufficient, I'm still leaning on using ACTION_OPEN_DOCUMENT for API 19 and higher in order to leverage all its benefits.

I suggest that I'll start implementing ACTION_GET_CONTENT first, since we'll need this anyway. I'll then add optional support for ACTION_OPEN_DOCUMENT, and in we find the feature more user friendly and worth the code split between APIs, we can activate it for API >= 19.

Sounds like a plan?

Best regards, Alex

kalaspuffar commented 5 years ago

Hi @alexhauser

Sounds great

Best regards Daniel

alexhauser commented 5 years ago

I meanwhile have the ACTION_GET_CONTENT implementation working along with the restructured import UI. This will come out nicely!

Waiting for the other PRs to get reviewed/merged before preparing one for this.

Best regards, Alex

alexhauser commented 5 years ago

Hi @kalaspuffar ,

in the forum thread SQRL client feature comparison at https://sqrl.grc.com/threads/sqrl-client-feature-comparison.416/, there are only two features marked as missing for the Android client:

|  |Feature                         | GRC | iOS |Android| Linux |WebExt
|--|--------------------------------|-----|-----|-------|-------|------
|16|Import ID as binary_81          | yes | ??  |  no   | no    |  no
|17|Import ID as binary_206         | yes | ??  |  no   | no (1)|  no

Is our sqrl file import solving one of those two? Can you please point me to any resource describing those formats, so that I can start woring on them?

Best regards, Alex

kalaspuffar commented 5 years ago

Hi @alexhauser

I believe that the formats they are talking about is the pure binary format and the base64 format.

Although S4 is nominally a binary representation, it may be necessary to convey the file over a binary-hostile medium. In this case the standard eight-byte signature will be converted to all uppercase 'SQRLDATA' and the balance of the database will be encoded into 6-bit base64url format for representation, storage or transmission over a binary-intolerant channel.

Not sure that we support base64 keys though. But loading the identities either by sharing or opening a file would solve these as well as the other solutions.

https://www.grc.com/sqrl/storage.htm

Best regards Daniel

Best regards Daniel

alexhauser commented 5 years ago

Thanks for pointing me in the right direction, Daniel! 👍