1Password for Linux development preview

Post by zwirbl » Wed, Aug 05, 2020, 8:57 AM UTC

dgellow wrote: post #228

_b8r0 wrote: post #206

I was a 1Password user from when it was fully self-hosted until they started pulling bait and switch tactics to move people to subscriptions and online vaults[1]. I also had Windows licences, and Windows was certainly a 2nd class citizen while I used 1Password. And of course, it doesn't look like the 1Password Linux client is open source. The back-end certainly isn't. I switched to Keepass[2] initially, synchronised…

FYI, the Windows application is now at the level of the macOS version. I was also annoyed by the move to a subscription model and waited a while before accepting to switch. But I'm now quite happy paying yearly given how well they improved their cross-platform support.

Post by Shacklz » Wed, Aug 05, 2020, 9:15 AM UTC

shaan7 wrote: post #167

twblalock wrote: post #141

Earlier quoted context omitted.

Why shouldn't it be Electron? Should it be GTK? Why not QT? Linux doesn't have a standard desktop environment or widget toolkit. Electron doesn't seem like a worse choice than the other options, and it's easy to find engineers who know how to work with it. 1Password doesn't just store passwords. It has a bunch of other features. It's a fairly complex app at this point. It also has fairly similar user experiences in W…

> Why shouldn't it be Electron? Because every Electron app is inconsistent with the rest of the desktop. I use a dark theme system-wide but Electron won't care [edit: 1Password has custom integration for GTK theme]. Honestly, this isn't something the developer of the app have to put years of research in (Slack for example). The toolkit is supposed to do the integration (GTK, Qt, [Cocoa?]) and clearly Electron doesn't…

Post by pjmlp » Wed, Aug 05, 2020, 9:36 AM UTC

yoz-y wrote: post #252

pjmlp wrote: post #236

Earlier quoted context omitted.

"Engines" like common logic written in languages like C and C++, using in-house toolkits where RenderButton() or ShowDialog() would do the right thing on each platform. Apparently a forgotten art. As for VMs, I am all for stuff like React Native, not for packing Chrome with each application. Not only it shows laziness where Web == ChromeOS, bloats the applications and is yet another way for turning everyone into Chro…

I understand the sentiment. But I think the best approach is a bespoke app for each platform in the own native toolkit. I have rarely enjoyed using a Gtk or Qt app on macOS because they feel alien. On windows for example there seems to be no rhyme or reason for widgets, mainly due to historical reasons. Games don’t need to be consistent because they take up the whole screen and are immersive. Some very specific progr…

Post by m12k » Wed, Aug 05, 2020, 9:38 AM UTC

_b8r0 wrote: post #206

I was a 1Password user from when it was fully self-hosted until they started pulling bait and switch tactics to move people to subscriptions and online vaults[1]. I also had Windows licences, and Windows was certainly a 2nd class citizen while I used 1Password. And of course, it doesn't look like the 1Password Linux client is open source. The back-end certainly isn't. I switched to Keepass[2] initially, synchronised…

Post by risyachka » Wed, Aug 05, 2020, 9:48 AM UTC

jooize wrote: post #76

burnte wrote: post #55

Earlier quoted context omitted.

If you can't trust them to host an encrypted blob, you can't trust them to run code on your local machine. I agree with you that the resistance isn't rational.

Hosting my encrypted data means anyone with sufficient access at any single time can copy the encrypted data and attack it or me, then or later when eventually feasible. Hosting only an executable I download and execute means the adversarial extraction of data must be contained within the executable and bypass all security from within my system. There is a window of opportunity for sending out a signal indicating the…