Import/export


Status
Not open for further replies.

DetlevSchm

Well-known member
Mar 4, 2019
64
5
The current main menu has three functions, that belong together, quite separated:

170

I would bring them together (be it in the upper part, or in the lower) and reword the two import items to make the difference clearer:

  • export
  • import as OR code
  • import as text

Just a suggestion, nothing bad happens if everything remains as is :).
 
  • Like
Reactions: Brassbound

shanedk

Well-known member
May 20, 2018
421
113
He should also add "Import from .sqrl file", which doesn't seem to be there at the moment.
 

DetlevSchm

Well-known member
Mar 4, 2019
64
5
He should also add "Import from .sqrl file"
I remember @kalaspuffar say somewhere else, that he does not want to access the file system, because that requires storage permission granted by the user.

That is for my liking a very good approach.

But, I agree, it looks strange that you can export a binary file, but not import it.
 

kalaspuffar

Well-known member
May 19, 2018
296
106
Sweden
coderinsights.com
Hi @shanedk and @nst0022b

Well, one feature I could add that would not violate this restriction would be to allow you to share an SQRL file with the application. Then the file would be sent as an intent to the application and the application would never need to access the drives.

Then again, can we expect a user to find this function?

Best regards
Daniel
 

DetlevSchm

Well-known member
Mar 4, 2019
64
5
would be to allow you to share an SQRL file
You mean the other way around?

Because this is how it works right now. If I press "save identity", the Android "share with" dialog pops up.

Say, I would then send this file to myself via my email client (I just did so, just for fun), I would then need do "share" the received, attached file "with" the SQRL app (if so prepared by you).

You are right, this would not be obvious for every user :).

Furthermore, if I share the file with one of my two installed messengers, neither of them offers a "share with" dialog. They just allow forwarding it to another contact.

However, two of these three allow to save the attachment to the Download folder.

But then, if you imported it from the Download folder, you could export it to there in the first place.

Anyway, I believe using the file system would cause lesser friction, but I have no opinion about whether you should implement that :unsure:.
 

DetlevSchm

Well-known member
Mar 4, 2019
64
5
Oops, yes, I do have an opinion :rolleyes:.

Using the storage just for importing/exporting the binary representation of an identity is not an essential part of the app's functionality.

Any security conscious user, who does not trust the app, could simply deny this permission and use the textual import/export.

So, yes, I would vote for implementing the new binary import by using the file system.
 

sengsational

Well-known member
Feb 17, 2019
115
36
So the use-case would be:

  1. export the .sqrl file from some other client
  2. somehow get that file into the file system on your phone
  3. press the proposed button on the app settings page and select the file from the file system
In step 2, wouldn't you figure most people would have it as an email attachment? Or where else would it come from?

In any case, rather than have the user start the process in the SQRL client and dig in the file system, isn't it better to define an intent filter with the *.sqrl file type and just have that intent started when the user wants to import a file?
 

PHolder

Well-known member
May 19, 2018
1,223
204
vote for implementing the new binary import
I don't understand why people want this? Any cell phone of any value is going to have a camera and the QR Code export/import is already well defined. Someone please explain why they want this feature?
 

shanedk

Well-known member
May 20, 2018
421
113
@PHolder Because there are a lot of devices running Android, like some cheaper tablets and Chromebooks, where that isn't the case.
 

PHolder

Well-known member
May 19, 2018
1,223
204
cheaper tablets and Chromebooks
You should NOT use the android client on a Chromebook. There needs to be a Chrome extension (and there is) for that.

As for older android devices without a camera... I suppose... but something that old and crappy is not a good candidate for a good experience. I'd prefer that @kalaspuffar created a "low end" Android client for them and leave the current one without requiring unnecessary permissions for a feature that almost no one with a capable Android device will use.
 

Steve

Administrator
Staff member
May 6, 2018
1,016
307
www.grc.com
So, yes, I would vote for implementing the new binary import by using the file system.
I'm confused. The .sqrl S4 storage format =IS= a binary import/export format, isn't it?
After all... the QR code is simply an exact binary replica of the .sqrl file. What am I missing here?
 

Vela Nanashi

Well-known member
May 19, 2018
720
124
Shane do you mean you want to have SQRL installed locally on a device that can't scan QR codes, to log in to sites via its browser? Since it can't be used to scan QR codes and log in other devices if it lacks a camera (or it would be able to import the identity via the QR code too).
 

PHolder

Well-known member
May 19, 2018
1,223
204
What am I missing here
Well the current Android app doesn't request from the OS (and thus the user at/before installation) the privilege to access the filesystem. So it woudn't be able to do a binary import (access of) the .sqrl file without adding that permission the the app manifest.
 

sengsational

Well-known member
Feb 17, 2019
115
36
Or rather than have our app get permission to access to the filesystem, we could tell the OS that our app would like to be in the list of apps that handle *.sqrl files, and we'd fire-up the appropriate activity if we were delivered such a file.
 

PHolder

Well-known member
May 19, 2018
1,223
204
tell the OS that our app would like to be in the list of apps that handle *.sqrl files
I don't know that Android OS has this functionality, does it? (I also don't know that it doesn't... but it doesn't really strike me as a file oriented OS, unlike say Windows.)
 

DetlevSchm

Well-known member
Mar 4, 2019
64
5
What am I missing here?
Summary:
  1. The original post suggested a re-arrangement of menu items with regard to import/export.
  2. Then the suggestion came to offer also a binary import, not just the current export.
  3. The binary export is implemented by using the operating system's "share with" mechanism, and thus does not need storage write permission (1) from the user.
  4. For a binary import there is no other way than reading a file from storage, no matter from where the file originally came (cloud, email attachment, USB connection, ...), so a storage read permission (1) would be necessary.
  5. Then the discussion arouse, whether importing binary files where necessary at all, if all smartphones have cameras.
____
(1) The problem with storage access is, that Android does not restrict an app to a single folder, say Download, but makes the whole file system available.
 
Last edited:

sengsational

Well-known member
Feb 17, 2019
115
36
I don't know that Android OS has this functionality, does it? (I also don't know that it doesn't... but it doesn't really strike me as a file oriented OS, unlike say Windows.)
When you hit the "share" icon, there's a list of apps that pop-up to select from. That's done by putting an entry into the app's manifest to announce to the OS that it can handle the type of file being shared. It's apparently kind of quirky to get it right, but I think it's doable if it needs doing.
 

sengsational

Well-known member
Feb 17, 2019
115
36
4. For a binary import there is not other way from within our app than reading a file from storage, no matter from where the file originally came (cloud, email attachment, USB connection, ...), so a storage read permission (1) would be necessary.
Added bolded text because I believe our app could be made to accept a *.sqrl file that was shared to us from an email client, for instance, and I think that would come without a storage read permission.
 
Status
Not open for further replies.