| 3 Aug 2024 |
 Wu Tingfeng | From what I see the closest existing feature that accepts commands from another local app is the delete vault on panic trigger via Ripple. | 09:39:38 |
| Wu Tingfeng | * I think any sort of capability of listening for remote commands, even if explicitly opt-in only by the user, would drive users away from Aegis. Edit: I'm going to clarify that "remote" here means directly over a public network like the Internet, and not commands from local apps that the user has to pair locally, like Ripple. | 09:45:32 |
 alexbakker | In reply to @lantizia:mozilla.org
So the bigger question is... should something like this exist... Would Aegis devs be happy to then take that message with the ID, unlock the vault, get the TOTP that matches the entry that has that ID, generate it's own local system notification containing that TOTP, and relock the vault. Like I said in the issue I linked, if all that's required from Aegis is listening for an intent to surface an entry in the vault, we can consider it once there more technical details are known | 10:19:02 |
| alexbakker | And again, how would you imagine Aegis unlock the vault on its own? User input is required in order to be able to decrypt it. That's kind of the point | 10:19:10 |
| alexbakker | In reply to @lantizia:mozilla.org
So the bigger question is... should something like this exist... Would Aegis devs be happy to then take that message with the ID, unlock the vault, get the TOTP that matches the entry that has that ID, generate it's own local system notification containing that TOTP, and relock the vault. * Like I said in the issue I linked, if all that's required from Aegis is listening for an intent to surface an entry in the vault, we can consider it once more technical details are known | 10:19:33 |
 @lantizia:mozilla.org | If you're saying that is a hopeless endeavour, then all this talk of draft specs for the communication is a moot point. If Aegis has a red line that it can't or won't allow anything to unlock the vault to read data ... without user interaction first ... then this has no where to go. | 10:20:53 |
| alexbakker | Exactly my point, given the constraints, there aren't a whole lot of usability wins here | 10:23:19 |
| @lantizia:mozilla.org | Well it hasn't been your main point until now... and I'd argue there is a whole load of really good usability wins to be found with this idea. | 10:24:06 |
 michaelschattgen | That's why he asked you how you'd imagine a "self-unlock" because we don't see any other option than requiring user input to unlock the vault | 10:28:02 |
| @lantizia:mozilla.org | I haven't imagined one, it'd just require one... if that's impossible then the idea is truly a dead one to me. | 10:29:43 |
| @lantizia:mozilla.org | Is there anyway of having Aegis receive the information... generate a local system notification telling the user that a TOTP code is waiting for them (but not what it is)... wait for them to unlock their phone via fingerprint and somehow piggy back that fingerprint to open the vault too? thus then generate the TOTP code and send another notification? | 10:32:59 |
| @lantizia:mozilla.org | You'd then have the ability to know your phone wants your attention, but you won't get the code until you unlock the phone - and unlocking the phone also unlocks the vault to go do the final generation of the TOTP code shown prominently somehow. | 10:33:48 |
| michaelschattgen | It wouldn't be possible to "piggybank" that fingerprint unlock to Aegis, no. A user has to unlock their phone, then unlock their vault, either via fingerprint or their password. | 10:37:07 |
| @lantizia:mozilla.org | Then for now I'm out of ideas, if anyone has any... there is the GitHub issue. | 10:43:29 |
| @lantizia:mozilla.org | If someone wants to absolutely say "it can't be done" or "it shouldn't be done" then it's fine for it to be closed too. | 10:44:05 |
| @lantizia:mozilla.org | In reply to @michaelschattgen:matrix.org
It wouldn't be possible to "piggybank" that fingerprint unlock to Aegis, no. A user has to unlock their phone, then unlock their vault, either via fingerprint or their password. Although this isn't quite the same. I do know of some applications (like Keepass2Android) that will auto-unlock/lock their database based on the phone being unlocked/locked. But obviously this is different because there expectation is that the user will choose a decent method for locking/unlocking their phone. | 10:48:35 |
| @lantizia:mozilla.org | Presumably to do that though they've had to store the KDBX password | 10:49:44 |
| @lantizia:mozilla.org | alexbakker: you use github in a very strange way to me | 10:51:04 |
| @lantizia:mozilla.org | * alexbakker: you treat github issues in a very strange way to me, and to how I've mostly seen them used. if the idea was a complete one (as you seem to need it to be, for it to remain open) then frankly it'd be a pull request! apparently discussion and gathering of ideas is frowned upon if it's in an easy to find location like a github issue :S | 10:55:51 |
| @lantizia:mozilla.org left the room. | 10:59:05 |
| michaelschattgen | What..? A completely written out idea is very different from an actual PR. The discussion we had here already shows we're open to ideas and possible solutions, but as long as we don't hear any of these the issue is closed. People can still chime in and we already prefer if people search through all our issues before making a new one anyways. | 11:01:37 |
| 4 Aug 2024 |
|  ataemus set a profile picture. | 20:45:37 |
| 8 Aug 2024 |
 valentinb102 | Hello again. I would like to take a crack at https://github.com/beemdevelopment/Aegis/issues/1405 if noone else is working on it. | 13:24:05 |
| alexbakker | Go for it! | 13:24:53 |
| valentinb102 | Alright so I made a few exports of plain.txt from ente. | 13:25:26 |
| valentinb102 | Download ente-auth-codes-2024-08-08.txt | 13:26:24 |
| valentinb102 | Download ente-auth-codes-2024-08-08 (1).txt | 13:26:35 |
| valentinb102 | it looks like the unencrypted version is just like plain.txt but url encoded | 13:27:00 |
| valentinb102 | importing that file back into aegis as plain text returns this: com.beemdevelopment.aegis.importers.DatabaseImporterException: com.beemdevelopment.aegis.vault.VaultFileException: org.json.JSONException: Value otpauth of type java.lang.String cannot be converted to JSONObject | 13:27:41 |
| alexbakker | The unencrypted version should be importable if you choose the "Plain text" option when importing it into Aegis | 13:31:43 |
