Hacker News new | ask | show | jobs
by nixgeek 3498 days ago
What's the communication path between untrusted <-> trusted components look like and are you doing anything special which might prevent the vulnerabilities which Project Zero recently reported in 1Password[1], LastPass[2], Dashlane[3] et al?

[1] https://bugs.chromium.org/p/project-zero/issues/detail?id=88... [2] https://bugs.chromium.org/p/project-zero/issues/detail?id=88... [3] https://bugs.chromium.org/p/project-zero/issues/detail?id=89...

1 comments

No untrusted component will have access to your data without user confirmation. This means you'll always have to click a button on the main app to fill a login for example.

There are two ways in which logins are filled in the browser:

- One is based on OS X Automation and AppleScript (this will work with Chrome and Safari without our Safari App Extension enabled). Succinctly, with this solution, Secrets will execute a small JS script on your frontmost browser windows to see if there are any logins to be filled. If so, it will present you a "Fill" button. Pressing that button will execute another JS script that will fill that form. In this scenario your data is send via Apple Events.

- When you have the Safari App Extension enabled, the process is similar. But instead of Secrets actively looking for logins forms on frontmost browser windows, the extension will let it know what is available. Again you will still need to press a "Fill" button on Secrets. Once you do your data is placed on a private clipboard that the extension uses to then fill the login.

There are no local servers, and the extension doesn't have access to your data. By design, none of the linked vulnerabilities would apply.

If you're wondering why the two methods, the Safari App Extension came later and the reasons are detailed here: https://outercorner.com/2016/10/19/version_1.4.0.html