Comment by homakov | Hacker News Reader

Comment by homakov | Hacker News Reader

Parent Full thread

Happy to hear back from like minded person.

1. I myself hate native apps, but the catch is web apps are 100% depended on the servers behind them. So I would be responsible for JS I serve any single request. Otherwise, Web version is fine.

Lots of catch 22. I would definitely through $10k+ on a polished UX + native app, if someone with large userbase can commit to using it. I already gave this project a TON of my time.

2. I hate that 50MB size of electron apps too. Browser extension does have same problem as a website though. That's neither more secure nor more fast derivation, so that idea was dropped first.

3. Actually there's amazing self-discovery iframe - https://securelogin.pw/s when in iframe it will parent.postMessage if you have a native app. But Safari does not support 3rd party iframes...

You think showing app links on the same screen is better? Good idea

4. Will improve the demo app

That's what profiles are for. If you want another identity: create another profile. It is possible to keep unlinked accounts under the same SecureLogin profile, BUT we end up with all websites asking for your E-Mail (like they need it for some reason) so that's why it is sent by default.

Real privacy is hard, it's not just different email. It's different browsing context and sometimes even VM. That's why I do not pursue paranoid level privacy, and just offer Profiles.

Happy to hear more.

> BUT we end up with all websites asking for your E-Mail (like they need it for some reason) so that's why it is sent by default.

I believe that it'd better be explicit (like in OAuth, where the web service asks for a permission to access your email) and optional (defaulting to not asking for email).

Note that services usually don't need emails (at least not right away). They should also continue working just fine if the user decides not to provide their email initially — the service may ask for user's email at a later step. I also see that the similar concept might be used to ask people for or other sensitive data, like delivery/billing address and payment info; this way I as a service developer don't have to store anything on the web service at all except for the unique user token, and the user would be able to provide this information with a single click as well — same as in your demo app where the user confirms a transaction.

> Browser extension does have same problem as a website though. That's neither more secure nor more fast derivation, so that idea was dropped first.

I'd probably disagree here. Installing an extension is much faster/easier than a native app; it can store data in localStorage (so no centralized service is needed), it can solve your Safari-related discoverability issues, and it can provide a really nice UX for web-based service authentication with no context switching between apps. I'm not a security expert, but a browser extension storing your data locally should — theoretically — be as secure as a native app. Am I missing something here?

Would love to continue the discussion offline. Is it ok to email you?

Please email homakov@gmail.com

I can continue about extensions there

Reply on news.ycombinator.com