Passwordless authentication: Secure, simple, and fast to deploy - <AUTHOR> https://hacks.mozilla.org/2014/10/passwordless-authentication-secure-simple-and-fast-to-deploy/ <comment><USER2> At my company we've been using this technique for years. Users have always hated it and after waiting a long time for people to come around, we are now transitioning back to traditional login mechanisms.

The basic reasons users hated it was that a login mechanism needs to be reliable. In particular, we make business software, so if the user was ever unable to get into the system it was a big problem.

While it may seem that you "always" have access to your email, or sms. Not all users (especially non-technical users) always have access to these things. Meaning, even if they have access 98% of the time, that other 2% of the time infuriates them.

It was also a usability nightmare among non-technical users. Traditional login mechanisms dont necessarily mean a more usable experience, but its a pattern that _everyone_ knows.

I think login mechanisms on the web can be improved, but not like this. As someone who has a lot of experience with this, I strongly recommend against it.

<comment><USER3> This really affected me the one day in the past 3 years that I forgot my phone in the morning... There was one site I had enabled 2FA (two factor authentication) on that I hadn't logged in from work yet, and it was really a pain not being able to access it.

Honestly, I've been pretty happy simply using LastPass (with a really long passphrase that I haven't shared with anyone) and generating more complex passwords for sites...

Just the same, not sure what the best answer is... Especially considering shared computers, portable devices and other devices which may get stolen or hacked.

<comment> squeaky-clean I've been very happy with LastPass too. I use it on my desktop and pay for the mobile app. But what I don't get is why we still need to use a password manager extension/app. Why isn't it built into the browser yet?

Google already has all of my passwords saved, and synchronized online across devices for whenever I use chrome (well, the passwords I used before switching to LastPass). Why can't it automatically generate secure passwords for me just like LastPass does?

<comment><USER4> Why can't we be using client certificates generated and stored and synced this same way instead of passwords?! Imagine a world without cookies...

<comment><USER5> Because that would mean you could only log in with computers storing your cert. Passwords might have lots of drawbacks, but it allows you to log in from anywhere on any computer without any other requirements beside remembering it. I don't see this property in any of the proposed solutions to replace passwords thus far.

<comment><USER6> You remember one password... and then can access your master password list.

<comment><USER5> And where is stored this master password then? If it's on your browser/computer, it's not portable. If it's online, it's possibly less secure (especially if you're not the one hosting it). A physical token might work, but it's usually too specific and not scalable.

Nothing beats plain old password as convenience, that's why they are still so wildly used despite lousy security properties.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> While this feels similar to a password reset process, it is different:

a. you're sending the auth credentials every single time a user wants to login. If email was secure, that might be fine, but it's not.

b. On a password reset, you typically require a user to actually reset their credentials, and then allow them to continue. In this case, if someone accidentally forwards the email, or enters the wrong email address, the recipient automatically gets access to the account, no questions asked.

It is an interesting concept, though. I don't really know if I like it yet, but it's nice to see people trying to work on this problem.

<comment><USER8> Account recovery emails should probably use one time tokens, meaning that after you click on the link once, the link becomes invalidated. This would largely solve the issue with point b.

<comment><USER9> Not only one time tokens, but with limited life-span. So after a while the token expires and is useless. This is a must for such a scheme.

<comment><USER10> Both of these, plus a differentiator between 'current' and 'new' token requests - without that, it's an easy way to log people out of sites by simply knowing their email address. To the point about not always having access to email, it's a pretty simple denial of service vector.

<comment><USER9> Can you clarify, what you mean by "differentiator between current and new token requests"? Currently I don't exactly know which attack form you mean and how it could be prevented by such a "differentiator".

(an example would be nice)

</comment></comment></comment></comment></comment><comment><USER11> The very website they link to [1] via its HN thread [2] states correctly that:

"No, email is not a secure medium. It was never designed to be one. It's susceptible to Man In The Middle (MITM) attacks and a slew of other issues. Users might also have their email accounts abused or hacked into (how many people do you know who have left their GMail logged in on a public computer?). And what about if their email provider gets hacked or their backups stolen?"

Mozilla should know that email is not an adequate medium for one-time password delivery.

They are replacing strong authentication (2 factors) with its second factor alone.

[1] [http://plaintextoffenders.com/faq/devs](http://plaintextoffenders.com/faq/devs) [2] [https://news.ycombinator.com/item?id=7943365](https://news.ycombinator.com/item?id=7943365)

<comment><USER12> > They are replacing strong authentication (2 factors) with its second factor > alone.

Are they? They don't mention anything about replacing 2 factor here.

A typical login is compromised if you know the password _or_ if the email is compromised. This is _not_ increasing the attack surface.

<comment><USER13> One problem is that SMTP itself [1] is just a plaintext email format. Sure, you can send it over a secure connection and most do, but that's left completely up to the provider to decide and therefore never guaranteed.

[1] [https://www.ietf.org/rfc/rfc0821.txt](https://www.ietf.org/rfc/rfc0821.txt)

<comment><USER14> This is by no means a very secure option but do you really care if your www.anime-planet.com or konachan.com account don't use 2 factor authentication.

Some websites just don't need such a high level of security plus you could argue they are probably less careful with your password than say Google is with your email.

Now it can still be hacked but you could argue this is probably an increase in security although it does create a central point of failure just like password managers.

Nobody says Google or Amazon should start using this but websites with a lower requirement of security shouldn't inconvenience their users unnecessarily.

If you're only need is to identify the user for something banal that couldn't do much damage if it gets hacked then this is a good solution.

</comment></comment></comment></comment><comment><USER15> FD I work for a password manager...but I would still think password managers are better even if I didn't.

1) Password managers have security qualities built into them, example forced logoff after X amount of time. Someone who leaves their email up is still leaving themselves available for an account theft. The password requires a key to decrpyt. This isn't the case for email 2) Email is not meant to be secure and attempts to do so have gone pretty badly. A lot of the big email providers are leaps and bounds ahead of where they were 5 years ago but email as a whole is still broken.

I think this is really cool and has a lot of potential, but these things still need some work. You probably shouldn't be rolling this out on things that require a high level of security.

<comment><USER16> 1 seems completely orthogonal to the issue of authentication, and I'm not sure what you mean by 2; basically every site on the internet is built on the premise that your email is secure, and again I don't see how password managers are relevant here.

<comment><USER15> Password managers are a better solution to prevent people from memorizing a lot of passowrds....Copied straight from the article "there is no risk of users reusing passwords"......That is what they have to do with this conversation.

1) isn't completely orthogonal to authentication. Good security products need to help you maintain good OpSec. Pretty much all password managers have features that try to help users maintain good OpSec and cut down on the mistakes they can make.

</comment></comment></comment><comment><USER17> The FIDO alliance has a working solution to the annoyance of the 2nd factor. It requires mobile device support or a hardware token (Yubikey Neo as of October supports the FIDO protocol), but it's much better than standard existing 2-factor because it doesn't require typing in a code from a dongle or app. Instead, the app or dongle authenticates directly once user presence (or in some cases, depending on the dongle or app, biometrics) are confirmed.

That means, for low-security applications, users can reuse passwords, or not have passwords, using only this second one-time-password factor, as long as they don't lose their FIDO dongle or FIDO-enabled mobile device (recovery protocols are at the discretion of different services, but a recovery code that you keep in a secure location is one way way to do it, or emails or text messages for less secure applications).

For high security applications, it avoids the annoying scrolling through a list of 2-factor accounts to get the right code, then typing it in manually.

 _Email_ or _text message_ , even if secure (text messages are not, and emails are probably not) _require internet access_. Mobile internet access isn't always available when logging into a service from some other device that has a different internet connection. Similarly, the mobile network (for text messages) is not always available, either. Even if it's done through email, email service might be down; the machine used to login could be compromised so you wouldn't want to input your (hopefully very secure) email password on the same machine you're using to access some other service. If you don't have internet access via a separate more trusted device, the rationale for having 2 factor is weakened.

A good presentation on FIDO is here: [http://www.yubico.com/2014/07/future- online-authentication/](http://www.yubico.com/2014/07/future-online- authentication/)

There's nothing preventing a FIDO-enabled service from also using email or text message for users that don't have FIDO devices, and account recovery can be done via recovery code, text, email, backup FIDO device, phone call, or a combination. It's all up to the service.

<comment><USER18> Sorry, I don't watch hour-long presentations when all I want is a bullet list of features and requirements. So I have no idea how FIDO actually works.

Here's what I will say: the best combination of security and usability would come in the form of an app that bridges an automatic communication (such as from an SMS, e-mail, or existing [https?] connection) to a TOTP token provider (either in software or hardware) and a prompt to the user to submit the token _over a secured connection_ to the requesting provider. For internet-less use, you'd simply generate and copy the token the way Google Authenticator works now.

From the looks of the NEO & U2F yubico page, it sounds like this is similar to what they're going for; is that correct?

<comment><USER17> It uses asymmetric crypto. It generates a unique keypair for each service you register with, each key linked to a specific dns or service domain. It uses USB or NFC (and requires app, i.e. browser, support) rather than displaying a code and having the user type it in somewhere. The app or hardware key confirms user intent (by requiring a button-press or sampling biometrics), so for example a plugged-in NEO won't auto-authenticate to a site. Beyond that, it works pretty much how you'd expect.

Adding FIDO 2-factor to a service, when the browser/app stack supports FIDO, is as simple as adding a prompt and button press on the NEO to the process (either account setup, adding 2nd factor, or during login, it makes no difference). All the details of creating a keypair or authenticating to a service using a key associated with that service are under the hood.

There's nothing preventing FIDO devices from having additional requirements. They could require a PIN. They could require biometrics. They don't have to be a separate minimal hardware dongle (although, obviously, for the best security, you'd want them to be). (The S5 Paypal + FIDO demo uses the phone itself as a FIDO device, and a fingerprint swipe.)

<comment><USER18> Cool. So it is similar to what I describe, with perhaps one or two differences. For example, you say it requires app support, so.... if you're logging in through your desktop, does your desktop app need to support it? Or can your mobile handle the authentication independent of your desktop?

The reason I ask is that requiring one device to complete the authentication is less secure than two independent devices. While it's great that the NEO can plug into your desktop to auth with the browser, or that NEO plugs into your mobile to auth a mobile app, what I actually want is to start authentication on the desktop and finish it on the mobile, independently.

<comment><USER17> I don't know if that's possible with the protocol.

I guess it would require associating a key with a kind of authentication API endpoint for that service, stored on the device, and forcing the service provider to maintain that authentication API url indefinitely (or would have to force regenerating 2-factor keys when the auth endpoint changes).

It would also require that your FIDO authentication device has separate internet access (either itself or by proximity/connection to a smartphone). That's unreliable, and one of the reasons I hate it when routine authentication tokens have to be sent from the service over data links. It also takes additional effort to pick up your phone, unlock it, get to a FIDO middleware app, select the site you're authenticating to, and then completing the authentication. I don't even know if that's possible... it would require a device (computer or smartphone) to be able to enumerate accounts stored on, for example, a FIDO hardware token. That "feature" could be bad. It would also have to violate the (typical?) FIDO protocol where a hardware token is responding to a specific authentication challenge. Sending authentication authorization blind, which would be required if it were sent out-of-band from a different device, breaks the continuous thread of login attempt, then challenge, then response, then mark the user logged in [and set a browser cookie]. The separate device authenticating out of band can't know that there was even a login attempt. It could be sending authentication tokens continuously, only restricted by service-side rate limits.

> requiring one device to complete the authentication is less secure than two > independent devices

What security vulnerability is there with using the same internet-connected device to authenticate with the FIDO 2nd factor, that can't also be done by malware waiting until after authentication and hijacking or doing malicious things with the account then? Is your concern about malware on the computer compromising the hardware token? Malware on a smartphone could compromise a hardware token too, in that case.

I think there's a much bigger problem: FIDO implementations that don't have a separate hardware dongle; for example, using a Samsung S5 to log into some service, and using a FIDO-enabled app that stores credentials in normal private app storage space on the S5 itself. A secure computing enclave (like on Apple phones, does the S5 or any android have that) makes that marginally acceptable, but far from ideal.

<comment><USER18> This actually makes malware less of an issue, because you'd need to target both a desktop and a mobile device of a particular user in order to MITM. The only things that are happening 'automatically' is the request being sent to the user's mobile device, and the entire process can be verified cryptographically to ensure an attacker doesn't send a false request.

      (HTTPS)
      Client -> Server: LOG ME IN PLEASE
      Server -> Client: Do you have a cookie?
      Client -> Server: NO, BUT HERE's MY PASSWORD
      Server -> Client: I've just sent you a request for an additional auth token. Please confirm it to log in. And please stop shouting.

      (Email, SMS, HTTPS)
      Server -> Client's Mobile Device: Here's a token. Sign it with some crap you've already got and give it back to me.

      CMD generates new token after confirming origin of original request; uses software, or talks to hardware token.

      (App, Website)
      CMD -> User: IS THIS REQUEST OKAY? CAN I SEND THIS THING?
      User -> CMD: Yeah sure, I requested this login. *pushes button*

      (HTTPS)
      CMD -> Server: HERE'S YOUR NEW SIGNED TOKEN
      Server -> CMD: Thanks. Here's a cookie to remember me by.

      Server -> Client: Page refresh! We got the right token from your mobile device, so here's your new cookie, you're logged in.

The only major security pitfalls here are in how you deliver either an app or a website to a user remotely, but there's plenty of good ways to do that already. You can even use boring old existing PKI.

You're not sending authorization "blind", though. You have to request the login from one device with a password, and approve it from another with a button push. In this way, only logins that _you_ requested get sent to you, and only requests _you_ approve get sent back, and _both devices_ would have to be hacked by an attacker to intercept either part of the authentication process. Well, unless they both have your cracked password and inject malware on your mobile. Perhaps putting the button-pressy part on the hardware keyfob is safer :)

Even if none of this were cryptographically signed, look at the typical 2-factor SMS with this process. A user attempts a login and a text is sent to them with a code. The user then puts this code back into the login screen and presses return. If they could simply press a button on their phone they could approve the login without having to type the code in. Of course, we want to require a button press, because an automatic login means anyone who initiates the login (like an attacker with a stolen password) could log in automatically. And what i'm proposing is basically this, but with actual secure connections instead of SMSes or e-mails, and the ability to confirm on the device that the request was legit and not part of an elaborate phishing expedition.

All of this would work without a data connection because you could use QR codes to enter the challenge token into the device and it would spit out the response in a variety of formats.

<comment><USER17> I don't think FIDO conflicts with what you want to do. It simply doesn't mandate it.

If you wanted a 2nd channel confirmation like that, I suppose you could set up the service to link a mobile device (there might even eventually be some FIDO app that accepts FIDO challenge push notifications in a way that's not service-specific). Then FIDO would be used exclusively on the second channel (parenthentical stages 2, 3, 4 in your example). The web interface in that kind of setup would have nothing to do with FIDO.

I don't understand the MITM malware threat model you're envisioning that can hijack an in-band public key crypto exchange, but that can't simply hijack the session on the browser after you've completed (validly) the out of band verification.

Some of the complexity of FIDO is there to enable reasonably secure single- channel authentication (as might be expected, there are trade-offs between easy SSO and subdomain/origin policy security). But I think FIDO would still be valuable if you wanted to do out of band confirmation without a browser. The hardware dongles are standardized (although the requirements to unlock a key can vary from a button press like on the NEO to, hypothetically, biometrics in advanced dongles). Mobile apps would also be standardized, much like TOTP is now, so you could use any FIDO app with any FIDO dongle (or no dongle, if an app offers less secure on-phone secret storage). Without a hardware standard, you either _have to_ store secrets on the mobile device, or you run into the existing problem of needing N hardware dongles for N services.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> The main problem I have with this approach is a theoretical one: What if I can't get a cell phone or permanent email address?

You have to pay to have a phone and possibly have approval from the network/government to join.

Email is a lot better since it's a totally open network. However, Even then I'm leaving myself open to MITM attacks, being locked out of my email by government orders, ISP complaints, company lawsuits.

I will never be locked out of my passphrase.

With that said, after almost creating swiftlogin to do this very thing, I would support this effort as long as this does not become the one true way.

</comment><comment><USER20> Kudos to Mozilla for trying a new way to simplify passwords. Very similar to something we implemented at Shop It To Me in June and that appeared in Hacker News. Here's the link with the conversation: [https://news.ycombinator.com/item?id=7818584](https://news.ycombinator.com/item?id=7818584)

And here's the announcement. [http://blog.shopittome.com/2014/05/29/bye-bye- passwords/](http://blog.shopittome.com/2014/05/29/bye-bye-passwords/)

Overall it has worked very well for us and is no less secure in my opinion than all the reset password options. 2-factor authentication is still better though and should be used for the sites requiring the most security.

<comment><USER21> It's not a Mozilla solution, though, says the developer :-) Hacks is simply publishing about it

</comment></comment><comment><USER22> I really believe in Persona. This is an interesting evolution of it.

Any Passwordless dev around? Care to shime in on this?

Edit: To be more specific, "token-based auth" is an interesting take on the browser-based auth concept. I still think the latter is what will eventually be the solution to the growing auth needs of the web: Authenticate to your browser and your browser authenticates to web apps for you. We see the same thing happening on mobile with apps (eg. on Android, users log into their google account on the android system itself).

<comment><USER23> Persona is no longer developed by Mozilla -- Persona team has been moved to other Mozilla projects: [http://identity.mozilla.com/post/78873831485/transitioning-p...](http://identity.mozilla.com/post/78873831485/transitioning- persona-to-community-ownership)

<comment><USER24> Maintenance of Persona is funded (and staffed), new development is on a volunteer basis. However, there has been some renewed interest in hacking on the codebase (including some pretty significant cleanup). Our immediate goals are separating out Persona's various components into discrete modules and getting new contributor documentation into place.

If you're interested in diving in, join the dev-identity mailing list and drop me a line: [https://lists.mozilla.org/listinfo/dev- identity](https://lists.mozilla.org/listinfo/dev-identity)

<comment><USER22> Dan, what do you guys need help with? I've attempted joining you guys in the past but the IRC channel was dead for three days and the dev-identity list looks overrun with spam.

<comment><USER24> _> what do you guys need help with?_

I'll post some trailheads to dev-identity by Friday; we're just now rebooting some coordinated development effort. Generally speaking, our greatest challenge is an enormous amount of technical debt in the main Persona repo[0]. The cruft and complexity hinder maintenance, slow feature development, and present a huge challenge for potential contributors.

We're specifically trying to tease apart the verifier, frontend, and backend into independent components, but literally any contribution to reduce code complexity / cruft would be welcome. Some ideas: audit / upgrade our node dependencies, replace npm-lockdown with npm-shrinkwrap, try to get Persona running locally and file documentation bugs about what did / didn't work, open a random .js or .ejs file and see if you can make it less verbose or complex. All would be useful contributions.

 _> the IRC channel was dead for three days and the dev-identity list looks overrun with spam._

Right now our IRC coverage isn't great, but the mailing list should be better. The spam is an unfortunate side-effect of Mozilla's weird NNTP/SMTP hybrid lists -- certain incoming messages are somehow bypassing the filters set up in Mailman. I'll look into it more tomorrow.

Otherwise, if you mention my nick on IRC or GitHub, I'll see it. :)

[0]: [https://github.com/mozilla/persona/](https://github.com/mozilla/persona/)

</comment></comment></comment></comment></comment><comment><USER25> Why not PAKE?

"The SRP protocol has a number of desirable properties: it allows a user to authenticate themselves to a server, it is resistant to dictionary attacks mounted by an eavesdropper, and it does not require a trusted third party. It effectively conveys a zero-knowledge password proof from the user to the server. In revision 6 of the protocol only one password can be guessed per connection attempt. One of the interesting properties of the protocol is that even if one or two of the cryptographic primitives it uses are attacked, it is still secure. The SRP protocol has been revised several times, and is currently at revision 6a."

You can salt/password manager/email retrieve on the client side however you want to strengthen you passwords or escrow keys without needing to share state with third party services at all. And they never get a copy of your creds. The server side can easily rate limit guesses per account, report access times, and/or require CAPTCHA challenges.

[https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...](https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol)

</comment><comment><USER26> I think a good middle ground would be to implement this idea into a password manager. You have one strong password to unlock your manager. Sites that support passwordless Would send it to the password manager. Otherwise use it as normal. As long as the password manager is supported on all platforms I think this would be the best solution. As for how it would communicate I always prefer pull rather than push.

</comment><comment><USER27> Is this the fourth or fifth try of Mozilla to replace passwords? Surely it will work _this_ time…

Edit: …which makes it totally sensible to invest time building your site up relying on this stuff.

<comment><USER28> I only hope that an intention of this project isn't to "smoothly" kill support for Persona. From a PR perspective this could look nicely: we kill the project that you depend on, but here is some quite inferior alternative that has zero maintenance cost for us.

<comment><USER24> I don't believe that's at all the intention. However, I am quite interested in this approach, and will be watching Webmaker closely as they roll out a similar scheme. If it works, I'd likely be in favor of transitioning the Persona fallback from long-lived passwords to single-use email tokens. After discussion on the mailing list, of course.

(FWIW, dochtman and I maintain Persona)

</comment></comment></comment><comment><USER29> I've tried throw-away email based passwords twice in the last five years. Every time I try it I run into the same problem: guaranteed speed and guaranteed delivery of email (both in general and that it'll always arrive in the inbox).

Average users get annoyed very quickly when they have to wait even minutes for an email to show up.

I still run into this problem even when using quality services such as Mailgun.

For this approach to work, it requires at least three things

1) Much greater security for email

2) Guaranteed speed of delivery for every email, such that the throw-away password arrives in seconds at a 99.x% rate

3) Guaranteed delivery, such that throw-away passwords arrive in the inbox at an extremely high rate of success (at least 99.9%)

Email will never be able to deliver on these requirements. As such this system will never be effective for deployment on a service that average users use.

</comment><comment><USER30> just needs a browser plugin to check your mail via imap for any email containing a token link to any of your open tabs and to automatically auth you...

<comment><USER31> That seems amazing (:

</comment></comment><comment><USER32> Previous HN discussion: [https://news.ycombinator.com/item?id=8446232](https://news.ycombinator.com/item?id=8446232)

A major drawback here is that it's incompatible with password managers which are a better, more generally-applicable solution. Relying on email means that if your email delivery is high latency or having an outage or an aggressive spam filter then your account access in impacted. Keep in mind not everyone gets their email right away -- many people (my mom) are on >10 minute pull intervals.

<comment><USER9> I agree, that eMail as transport media is far from optimal, but it is the only general available media currently.

I still think that from the point of usability a passwordless solution is better for many applications, where security is not the top priority.

Because so many applications in the web force you to have a password, security in general is at risk. Most people get tired of passwords and use either bad passwords or just one for all. And those passwords are endangering those applications that are really security sensitive.

I would rather like to see, that only a few services (like banks, ...) want to have a password and the others just authenticate their users with less intrusive means.

<comment><USER32> _> Most people get tired of passwords and use either bad passwords or just one for all._

That is what password managers fix. iCloud Keychain has gone a long way towards mainstreaming this. It's built in to Safari and securely stored, encrypted with your OS/device's master password -- which is an improvement on Firefox & Chrome's approach, where master passwords are optional.

From a usability standpoint that email method is way _worse_ , at a minimum due to the latency issues. Waiting a minute for an email to arrive can feel like an hour when you're trying to log in to do something urgent. Password managers work "magically".

For a security standpoint the email method is also worse, because it is only usable with very long-lived sessions -- which is not the best security practice. The article even heavily qualifies this method as not appropriate for sites users "visit frequently".

So by the author's own logic, this method is only appropriate for sites that _NO_ users visit frequently. Which is no sites.

Finally, the nail in the coffin for the email approach is that it's _incompatible_ with the more general password manager solution. So those users who do need to visit a given site frequently can't use a password manager (at least without redirecting themselves to an alternative method, which is also poor usability).

<comment><USER9> This is a circular thinking: Password managers are superior to this approach, because this approach is not compatible to password managers, the "more general" solution.

It is like saying: "We need tv sets because tv sets are the only (valid) means of entertainment."

<comment><USER32> Absolutely false. Password managers are superior because they don't suffer the vulnerabilities I listed with email: high latency, outages, spam filters, and less secure long-lived sessions.

<comment><USER9> I already understood your point, but your argumentation is a little to black and white at times.

</comment></comment></comment></comment></comment></comment><comment><USER33> With the exception of automatically grabbing the token, it's pretty much the same as BYU's SAW[0]. I worked for a startup that was trying to commercialize this technology, but it's nearly impossible to commercialize an authentication tech. It's unfortunate, too, because I think it would make a much better option than most password managers.

0\. [http://isrl.byu.edu/projects/simple-authentication-for- the-w...](http://isrl.byu.edu/projects/simple-authentication-for-the-web/)

</comment><comment><USER28> One of drawbacks of this mechanism compared to Persona is that a web server needs to be configured to send emails with tokens using site's own email credentials. This isn't easy to setup reliably for a small site. A malicious user can easily trick the server to send many tokens to different accounts and cause the sending email to be included on spam blacklists.

<comment><USER34> How is that different from registering many user accounts with many different emails, or using the "Forgot Password" feature using many different emails?

<comment><USER28> If you use Persona, the site doesn't need to send any emails (As I wrote this is a drawback in comparison to Persona, a traditional password based mechanism has the same problem).

</comment></comment></comment><comment><USER35> Using SMS for this may work better than email. Email passwordless tends to get bogged down in little problems. Like the email is slow or goes to the spam folder. Or on mobile, clicking a link in an email may not take you into the web browser you actually want to use the app in. SMS at least should improve on these two problems.

<comment><USER36> SMS is unreliable. It may arrive in an hour, the next day, or not at all.

<comment><USER35> In practice, it seems about as reliable as email, and faster to get to me.

</comment></comment></comment><comment><USER18> Passwordless logins, as implemented today, are less secure than password logins.

 _Flaws in the passwordless login system:_

1\. Authentication is done on unsecured connections. With all of the shouting over privacy and security, here we are abandoning secured, encrypted connections for SMSes and e-mail, two unencrypted, unauthenticated, somewhat unreliable, easily intercepted, plaintext messaging systems.

2\. Replacing an out-of-bound token with one stored purely online. Any actor who controls the network (or your computing device) can subvert the login.

3\. Depends on a pre-existing authentication, which itself uses passwords (or none at all), leaving you at the _exact same state of security_ as you had before. Instead of two passwords that are the same, you have one password (the e-mail password) that is the same, or zero authentication with SMS.

4\. No mandate for multiple-factor auth, nor out-of-bounds auth.

5\. Zero security for the tokens (cookies) stored on the user's system, so data at rest is at risk, unless your browser encrypts cookies with a master password. Of course this is moot considering the total lack of encryption on the smtp/sms side and the lack of out-of-bounds auth.

 _Reasons why password logins are more secure:_

1\. Uses secured, encrypted connections to transmit secrets. Prevents man in the middle attacks and interception of logins.

2\. Provides an out of bounds auth token. The only way to subvert this is to intercept it as it goes into a computing device, meaning either the client or server would have to be compromised at the time of login.

3\. Data at rest is encrypted and only the user's cached token (cookie) can be used to steal a pre-authenticated login.

4\. Password can be unique to the service, so a compromise of one system does not compromise all.

5\. Industry standard is already to require multiple-factor authentication to be combined with this method for increased security.

</comment><comment><USER37> This looks suspiciously like OpenID with the identifiers changed from URLs to email addresses and updated to use modern pop development tools.

I _really liked_ OpenID, even though it had a few issues. The best part was that you could put a few HTML tags at the URL you used as your identity and delegate the authentication - but _not the identity_ \- to a 3rd party. Because you controlled the identity, you could drop the 3rd party and use someone else (or implement the OpenID protocol yourself locally) just by changing some tags.

If "Passwordless" can provide this can provide the same level of _autonomy_ , it could easily become my authenticator of choice.

It looks like it's tied to an email account? Slightly annoying, but trivially worked around if necessary.

<comment><USER34> I don't know how it's implemented, but I see no reason why adding/removing emails to/from an existing account (while logged in) wouldn't be trivial to implement.

The only thing you need to be careful with is to send a notification to the email being removed, send notification to all emails when a new one is added, and enforce some kind of expiry period before a removed email becomes inactive/added email becomes active.

</comment></comment><comment><USER38> This is interesting. A lot of social networks use this sort of authentication for their email notifications, and weekly/daily digests, but don't treat it as a first class login.

Facebook, LinkedIn, Twitter, Quora, etc... use a short expiration on these, but if you ever forward one of your new notifs to a friend, they will end up logged into your account, which is surprising. It usually only lasts for the session, and some are pretty good about double checking if you are coming from a new location or have cookies for another account set :)

For longer lasting sessions, email security seems like a big concern, especially since most people keep all their email forever (gmail) and it's easy to search through.

<comment><USER21> Almost :-) The tokens are one-time only. Afterwards the session is keeping track of the user. Another login requires a different token.

Regarding the emails of Facebook, etc.: Great example, actually! I guess the problem really is that they don't make it obvious to users that they actually hold an authentication token in their hands.

<comment><USER38> Yeah I assumed they were one-time only. In examples I've seen, each link had a different token, so if you forwarded something, one of the links may work if you hadn't clicked that particular one.

When ever I explain this to people, and forward them one of my notifs from Facebook, they get pretty paranoid and shocked, then eventually accept it because of the convenience :)

</comment></comment></comment><comment><USER39> I do not see the benefit of this from a usability standpoint.

From a security standpoint it seems like an absolute nightmare. If you lose the password to your email you could lose access to all your accounts.

Most people do not own their own email server and so this could have catastrophic security consequences.

Of course the sites could check for IP location consistency but in order to spot security threats early you would need to track logins to multiple sites. The only way to do this would be to either give another third party company the ability to track logins and implement fail safes. At that point it begins to operate a lot like the companies which allow third party authentication through Facebook/Twitter/Email.

<comment><USER40> Considering that for most websites one can easily reset the password to your account if they have access to your email, this adds no extra security risk (for those situations which are most common websites eg. Amazon, facebook, twitter etc). So this is NOT catastrophic for security because the current situation is already like this.

For websites where security is a larger issue, this obviously wouldn't be the solution.

</comment></comment><comment><USER41> I implemented something like this as an alternative to the OpenId logins when I was at Fast Company. I believe it's still in use there if you click the person icon to login at the top right, select other options, and then "send me a one time link". Try it out?

We did this because we had people that didn't have Twitter or Facebook logins and needed to use some service that we had. I didn't want to build out a password database so came up with this work around.

Surprisingly we didn't receive that much hate mail about it, and we have a fair amount using it per day, so I'd say that people like it.

</comment><comment><USER42> Is there any advantage of this over using Oauth to 'Sign-in with Google/FB' other than being platform agnostic? similar workflow except tokens are being exchanged between server-server vs sever-email.

<comment><USER11> No, except that SSO via such a service is _more_ secure than the email approach. However, being platform agnostic is quite an important reason.

</comment></comment><comment><USER43> One thing I like about having different passwords and logins for each site is that I don't have to worry about cascading failures.

This seems like it isn't getting rid of user/pass authentication, it's just pushing it onto someone else, in this case your cell or email provider.

Other users have correctly stated that this doesn't increase the attack surface, however it does increase the value of a single vector.

Please correct me if I've missed a key point in the OP, I didn't spend lots of time reading the finer points of the implementation.

<comment><USER44> Your email is already a single vector. Most sites have a "forget my password" link and all you need is the email account to reset the password and access the account.

</comment></comment><comment><USER45> Doesn't this mean that an attacker now only needs the password to the email account and all these passswordless services get compromised as well?

<comment><USER46> Yes. But this is the case with the current 'forgotten password' system.

Securing your email account can be done without 'only' using a password. I use 2 factor auth on my google accounts, for example.

<comment><USER18> Forgotten password systems are supposed to use challenge questions to authenticate the user before resetting the password. (Of course, those same sites often provide a way to reset using challenge questions and _without_ an e-mail confirmation, which is how celebrity accounts get compromised)

</comment></comment></comment><comment><USER47> There are a lot of websites that are not worth the hassle of registering for, but this can make registering on them easy and they may get more registrations.

For important accounts I would still prefer a password only stored in your head and two phase authentication. But for various forums, this type of a setup is better than using third party password manager or same-username- password combination for general purpose.

</comment><comment><USER48> Great idea, I can see that this would be awesome on services I use seldom and often forget my password anyway. But do the average user really care enough to bother with email? or for SMS, will they give away their phone number? Remembering users for a long time also opens up for other breaches. Anyway it is awesome that people are working alternatives!

</comment><comment><USER49> A similar idea was discussed here ([http://www.gnucitizen.org/blog/simple- universal-authenticati...](http://www.gnucitizen.org/blog/simple-universal- authentication-system/)) in 2008.

</comment><comment><USER50> I think we sometimes forget the number of users who would try and get to your service, then bail because they need to boot-up Outlook, or work in a building with no cell reception.

</comment><comment><USER21> Someone just made me aware of www.cotap.com - It's probably using a different middleware, but I think a perfect example of where passwordless login makes great sense!

</comment><comment><USER51> This requires javascript on the client no? That's a no go for me. The little demo site fails for me.</comment>


Want to ace your Y Combinator interview? Be relentlessly empathetic - <AUTHOR> http://blog.perfectaudience.com/2013/04/26/want-to-ace-your-ycombinator-interview-be-relentlessly-empathetic/ <comment><USER2> Another alum here, good list of questions. As was stated, the key to doing well at the interview is _insight_. This can't be overstated. Show them something you understand about your users, market or technology that gets them thinking.

The actual questions will vary based on the type of team you are. I.e. a couple undergrad dorm-room hackers with a prototype, a team that's spent time in the industry they are trying to disrupt, a team that's developed some real technology, or a team with a product that has traction.

But whatever questions you get, demonstrate _genuine insight_ , not marketing speak or cliches. And have a decent answer to every possible question. The partners have spent only minutes with your application, and you've spent anywhere from weeks to months to years on your idea, so this should not be that hard. If you do this, they will get themselves excited and you're pretty much in at that point.

</comment><comment><USER3> Better yet: be relentlessly empathetic, create something people want (need/can't live with it, etc), whether you are interview with YC or not.

</comment><comment><USER4> This is great stuff Brad, and I'd say it's just as important in the day-to-day happenings of your early stage startup, rather than just to ace a Y Combinator interview.

I love your advice about having at least 1 person dedicated to learning about/listening to users all the time. This is so key from my experience thus far with matchist (<http://matchist.com/talent>).

With an early stage startup, it's not about the code at all - it's 100% about the users.

</comment><comment><USER5> These are crucial: How much better is your solution? Why would they switch to your solution?

Switching costs are often underestimated and it's hard to come up with a solid answer for this in many businesses. And even if you do have people who would switch, it's hard to get the distribution to implement a way of getting those users who want to switch.

"Did you know Airbnb thought the "breakfast" in Airbed & Breakfast was a crucial part of their product experience at one time?"

I did not! Interesting.

<comment><AUTHOR> There's a screenshot I've seen from an early version of Airbnb where the listing page was divided into thirds, with a photo of the apartment, a photo of the host, and a photo of the breakfast (!!) all the same size. They really thought a good breakfast was important for listing your unit.

<comment><USER6> To be honest, a good looking picture of eggs benedict could probably convince me to stay with you.

</comment></comment></comment><comment><USER7> How would this work out in a scenario where the customers are a subset of the users. Say, a restaurant menu service that provides restaurants with enhanced menus for their clients. The customers are the restaurants and restaurant owners. But the users include the clients who actually use the menus and may have their own interests and considerations. You may revenue-share with the restaurants, but the customers are still the restaurants. Now there may be questions on this list, where the customers' interests and pain are at odds with their clients' interests and pain. What happens when the customer is an enterprise level business, and you can't speak to them daily or weekly or maybe even monthly?

<comment><AUTHOR> The restaurant is the user in that situation because they're paying you money. A lot of B2B businesses are like this. The user questions are particularly important for vetting these sorts of businesses precisely BECAUSE the user situation is so convoluted.

My company sells advertising and the equation is similar to your situation. Our customers are marketers who use our tools to launch retargeting campaigns that serve ads to their own visitors. Our products have to interact with those visitors in a way that creates value for the business, but our actual customer is the marketer and we need to know his/her needs inside and out.

The "and you can't speak to them daily or weekly or even monthly" is one of the biggest barriers to entry into many very lucrative B2B spaces. One of the reasons why it took us so long to launch our product, <http://perfectaudience.com>, after finishing YC was because our initial product was aimed at enterprises we had domain knowledge of (newspapers), and when that didn't pan out and we had to build a product that went direct to advertisers, we had to go out and gain a ton of new domain knowledge from a customer type we weren't familiar with at the time.

B2B businesses are awesome and hugely lucrative if you can build something lots and lots of businesses want. But building something lots and lots of businesses want is a lot harder than building something lots and lots of consumers want because you're much less likely to have shared experiences with those enterprises than with consumers.

</comment></comment><comment><USER8> Thanks for the post. Interviewing on Sunday.

I've been trying to figure out how much time I might be able to get to explain what we do before the first interruption. 15 seconds? 10? Basically, I get a verbal twitter post, right?

<comment><AUTHOR> "I get a verbal twitter post, right?"

That's a good way to look at it.

<comment><USER8> Thanks. Any chance you want to mock interview me?

We build software that stops law firms from overcharging our customers.

nwenzel edgesolutions.com

<comment><USER9> Ha. As a company that's had six figure law bills we've negotiated back to mid 5s thanks to careful documentation on our part, this tool sounds compelling. A real problem.

</comment></comment></comment></comment><comment><USER10> Not just Brian. Brian and Joe Gebbia both flew to NYC every week.

<comment><USER2> Where was Nate?

<comment><USER11> Probably writing code.

</comment></comment></comment><comment><USER12> So to ace your YC interview one must be empathetic and focus on the user. This is also the advice to give to somebody that wants to deliver a great product, I don't like to think in terms of what to do to get more investors and VC funding instead of thinking of delivering a great product. If you focus on the product and the user, the funding will come but that is not the goal.

</comment><comment><USER13> I would love to see an actual tear-down question list from the man himself, or Gary, or Paul, or Jessica.

For now, I've printed this list of questions to hang in my office. :)

<comment><AUTHOR> Glad you found it helpful!

</comment></comment><comment><USER14> This is essentially the 'Genchi Genbutsu' (<http://en.wikipedia.org/wiki/Genchi_Genbutsu>) principle. You need to get off your butt and figure out what your customers want (although not necessarily what they say they want).

</comment><comment><USER15> Great advice! Small typo, "relentless resourceful" should be "relentlessly resourceful", shouldn't it?

<comment><AUTHOR> Fixed!

</comment></comment><comment><USER16> Awesome post. Thanks Brad!

</comment><comment><USER17> are you actually empathetic if someone has to tell you to be empathetic?

<comment><USER18> I think a lot of it comes down to focus. You have tons of code to work on, maybe family and/or a full time job, etc... It's easy to forget that customer email represents a real person at the other end.

"I'VE GOT PEOPLE SKILLS"

</comment></comment><comment><USER19> Want to ace anything in life, charm your way through everyday conversations and problems and more? Be relentlessly empathetic.</comment>


You can be fined more than $60,000 or face jail if you don't give your password - <AUTHOR> https://www.dailymail.co.uk/news/article-6213007/Police-want-mobile-laptop-passwords-jailed-refusing.html <comment><AUTHOR> p.s. Welcome to Straya</comment>


'I Don't Believe in Science', Flat-Earther Set to Launch Himself in Own Rocket - <AUTHOR> https://www.npr.org/sections/thetwo-way/2017/11/22/565926690/i-dont-believe-in-science-says-flat-earther-set-to-launch-himself-in-own-rocket <comment><USER2> >I know about aerodynamics and fluid dynamics and how things move through the air, about the certain size of rocket nozzles, and thrust. But that's not science, that's just a formula

Wow, I don't even know what to say. Does he think these formulas magically appeared in text books one day?

<comment><USER3> Don't try to reason with a man who is trying to use the scientific method (hypothesis and experiment) to disprove science. "You cannot reason a man out of a position he was not reasoned into."

<comment><USER4> Actually that's pretty cool. Any serious attempt to utilize the scientific method will inevitable lead to something that resembles current scientific knowledge.

<comment><USER5> I guess the fun here is if he's intellectually honest about his observations meeting his theory, or whether the cognitive dissonance will keep his beliefs on the rails he expects. Ideally he'll find himself being drawn back towards the evidence based solution.

Also, I believe it's hard for smoking craters to rationalize about their observations.

</comment></comment></comment></comment><comment><USER6> It would be much safer, and cheaper for him to just buy an airline ticket if he wants to get up in the air. He'll get much higher as well, by several times.

</comment><comment><USER7> Thankfully, science works even if you don't believe in it, that's kind of the whole point.

</comment><comment><USER8> Science is not a belief system like religion. It's not whether you believe or not. In fact, you can completely disbelieve it and it changes nothing about science.

One of the reason I am disappointed every time I hear the climate change debacle it's because one side is deemed stupid about not believing what the other side believes. It doesn't matter what you believe, go to a polluted city and breathe the air. Drink from a polluted river.

You can believe the earth is flat. But when you are launching a satellite, make sure you follow the theories that cater to your model so you don't crash it.

Call the earth flat all you want, just make sure my GPS works just fine.

</comment><comment><USER9> See also the discussion from 21 hours ago at [https://news.ycombinator.com/item?id=15753157](https://news.ycombinator.com/item?id=15753157) .

</comment><comment><USER10> This is worth the live stream, for sure.

</comment><comment><USER11> His website is pretty gear. The tagline "The Most Innovative Man in NASCAR History" has a nice ring to it. [http://www.madmikehughes.com/](http://www.madmikehughes.com/)

</comment><comment><USER12> Crossing my fingers that this guy gets a Darwin Award.

<comment><USER13> If you wish death upon all flat earthers, then you're no better than they are :)

<comment><USER12> Meh

</comment></comment></comment><comment><USER14> Merica!</comment>


The Experience Economy - <AUTHOR> http://cdixon.org/2012/05/26/the-experience-economy/

<comment><USER2> > _It is no coincidence that interaction design is replacing technical prowess > as the primary competency at startups. People who create great experiences > will be the most valuable to startups, and startups that create great > experiences will be the most valuable to users._

Interaction design is not replacing technical prowess. _Interaction design is actually increasing the need for technical prowess._

Now, creating a product that is technologically funcional and fulfills business needs is not enough. It must also fit with the overall user experience strategy.

</comment><comment><USER3> >>It is no coincidence that interaction design is replacing technical prowess as the primary competency at startups. People who create great experiences will be the most valuable to startups, and startups that create great experiences will be the most valuable to users.

That's conclusion is a step too far from the majority of the post. Usability is the most important differentiator when all technology is adequate, but when it is not the fact that the technology exists is most important.

Though I mean most social media, and even things like Heroku and Parse is about experiences, but real technology startups like Planetary Resources or Google care most about technical prowess.

Edit: I just find it somewhat annoying that this article leaps from "startups choose to innovate in experiences instead of technology" to "experiences matter more than technology".

</comment><comment><USER4> I like Chris' writing, but putting aside from the (pretty > prowess)? argument, I don't feel he has correctly mapped cause to effect here.

The reason that UX has become more critical for _certain classes_ of software is because (a) consumers rather than business have become the predominant driver of spending for desktop computers over the last 15 years, and (b) because the web and app stores removed distribution and sales channels as competitive advantages, leaving price and experience.

Product design is now more important, sure, but it's because the playing field has been flattened and because more consumers are buying. NOT because of some broader macroeconomic trend that can be applied to all markets.

<comment><USER5> In Crossing the Chasm, Geoffrey Moore elucidates the critical fact that when selling a product whose economic buyer and end user are not the same person, you must sell differently to succeed. He is right and there's a reason that book is like a bible for tech entrepreneurs.

That said, this fact of life when selling to enterprises is what caused me to permanently exit the enterprise software space. Success requires you to make crappy software.

Fortunately the SaaS-ification of enterprise has allowed the enterprise world to mitigate this problem by allowing the actual end users of products to also be the economic buyer through their monthly budget.

I consider SaaS delivery to be a wonderful financial innovation. I agree with parent that this change isn't due to macro changes in buyers but rather innovations in pricing and channel which align incentives in a positive way.

I encourage all of us HN'ers to continually challenge ourselves to find innovative ways to align incentives for maximum value creation. It's good for society and tends to be even better for profits.

</comment></comment><comment><USER6> point taken, though to say,

"The emphasis on experiences also helps explain other large trends like the migration to cities. Cities have always offered the trade-off of fewer goods and less space in exchange for better experiences."

...is just false & i certainly don't agree with this assertion -- to each is own, but i live in a small town in the mountains and it's pretty rad. i love city life just the same, but the reason most people have moved to cities is because that's where higher paying jobs typically are located. this essay makes way too many assumptions.

<comment><USER7> > the reason most people have moved to cities is because that's where higher > paying jobs typically are located

Yeah, and even that's still just a consequence of the fact that big cities offer more opportunities, which leads to competition for the best candidates. I'm still hoping that this connected world embraces remote working and the trend reverses.

</comment></comment><comment><USER8> The whole first paragraph purports to describe the "developed world," after wwII then proceeds to describe conditions specific to the US. Britain, for example, had food rationing until 1954.

<comment><USER9> Great point... 5 billion people are awaiting the products economy

</comment></comment><comment><USER10> This blog post seems a bit lazy, and lacking in true references (a link is better than nothing but still isn't a great way to cite a source). It raises a good point, but I'd much rather read an article or book that used proper references and made a stronger point. I think the book that kawera linked to might do that.

<comment><USER11> Agreed, it's missing context.

My graduation thesis was around this subject. The book "The Experience Economy" by Pine & Gilmore is a great start and generally regarded as the origin for the idea of experiences as products: [http://www.amazon.com/The- Experience-Economy-Theater-Busines...](http://www.amazon.com/The-Experience- Economy-Theater-Business/dp/0875848192)

A couple interesting articles:

[http://www.experience-economy.com/wp- content/UserFiles/File/...](http://www.experience-economy.com/wp- content/UserFiles/File/Article%20Lapland5.pdf)

[http://www.adaptivepath.com/uploads/documents/apr-005_busine...](http://www.adaptivepath.com/uploads/documents/apr-005_businessvalue.pdf)

<comment><USER12> Well, I would argue that this performance based view has been at least around since Goffman's "The presentation of the self in evereryday life". Management research has already been paying close attention to this subject by the strategy-as-practce research approach, not to mention critical management/organization research. But this is definitely an exciting area with very interesting work coming of of that direction.

</comment></comment></comment><comment><USER13> I think there is a valid argument somewhere here but a lot of the points are based on things that can not be taken as fact. For example, the point about people moving to urban cores is a story that has been reiterated by just about every city mayor but when looking at statistics its not entirely clear that that is what is actually occurring... in fact it seems it may be the opposite <http://www.city-journal.org/2011/eon0406jkwc.html>

<comment><USER14> Your link skirts the issue somewhat (though so does the OP).

The real change that has taken place in cities has not been 'more people in the [designated 100 years ago] city area'. It would be pretty much impossible for most of New York city's 'growth' to happen in the city area (at least, without removing planning regulations entirely). Demand is going up massively though. The inner-city 'slums' of the 20thC are very definitely not coming back and have been replaced by areas of affluence, which are pretty unaffordable to live in for most of the population.

The suburbs are changing too. People are using 'local centres' more, and paying more to be close to a nice one. So even the suburbs are less 'suburban' than they used to be.

</comment></comment><comment><USER15> "Apple, the most valuable company in the world, maniacally focuses on product experiences, down to minute details like the experience of unboxing an iPhone."

Sure, they focus on the experience their customers have...using the physical products they just bought from Apple. I thought it was the conventional wisdom, by now, that Apple was a hardware manufacturer and they make money by getting you to buy physical objects. iTunes, iCloud, etc are ways to make their hardware more attractive.

</comment><comment><USER16> Here's the honest reaction my brain had as I read the article: "What a load of horseshit."

I wanted to write something much more civil and detailed about why I think the article is weak. But then I realized there's a lot of value in just sharing the honest, immediate gut reaction. Yes, it's harsh, but you don't often get that kind of honesty.

(And I am aware of the studies that show experiences make us happier than things -- and I agree with them. That's not where the horseshit is).

<comment><USER17> Where do you think the horseshit is? I've been noticing this effect lately in my business where people don't NEED to buy many things anymore, there are almost always a much cheaper alternative that will satisfy their needs, but people are willing to pay a considerable premium to get an experience/emotion.

<comment><USER16> Fair question. Looking back over the article, I pretty much agree with the first paragraph. And I think the second paragraph may be true -- I've noticed some changes in my own perspective as well as several friends -- though the matter is definitely not clear cut. There's still a lot of excess consumerism in my own life as well as most people I know (everyone I know that I can think of).

Paragraph 3 bugs me because I've never left a music concert, even for performers I absolutely love, without feeling that I had just way overpaid and invested a ton of hassle (fighting traffic, standing in line, etc.) for less reward than I had hoped for. (Correction: one concert that I got free tickets to was a fantastic experience, leading to family bonding and inspiration for life).

And musical recordings are a huge part of my daily life. I don't see musical recordings vs. concerts as a good example of the product/experience dichotomy. A musical recording represents a pre-packaged experience I can have whenever I want ... and that's exactly how it plays out in my daily life.

And the example of cities offering experiences in exchange for other non- experience goods doesn't work for me. City verus rural is not about experience versus product. There are experiences you can have in a rural area that are not available in a city. City people pay money to take trips to rural areas for "experiences". And of course vice versa. So both cities and rural areas offer both experiences and products.

The thing that gives me the strongest sense of "horseshit" is the claim that technical prowess is taking a backseat to interaction design. I can see how it may appear that way to some people -- and those people are exposed to observations I'm not exposed to (since I'm not currently at a start-up).

However, I simply do not think it is possible for technical prowess to take a backseat to anything. Software development may indeed be the most complex endeavor humanity has invented for itself. The desire to make the experience fantastic -- an excellent goal -- simply adds more requirements and hence more complexity. So the most fundamental thing you need in a software company is technical prowess (or at least, technical prowess is one of the fundamental things you need, and perhaps there are 3 or 5 other fundamental things you need as well).

You could certainly argue that technical prowess is no longer enough -- that developers need to understand "interaction design" too, for example. But that's different from saying that technical prowess takes "a back seat" to interaction design.

If you claim that it is more important for a software startup to have access to strong interaction design capabilities than to have access to strong technical prowess, then I claim that you're wrong. Of course, only time could tell which one of us would be right, but I'd feel very confident that the smart money would be with me.

In summary, I think the focus on the entire experience, like Apple has practiced for a while, is a great idea. But I felt like the article over- stated it, and that almost all of the statements the article made in support of the idea wilted as I read them. That, plus some hyperbole (such as "the era of competing over technical specifications is over", and that interaction design is _replacing_ technical prowess), triggered the "horseshit" response. The article made some pretty big proclamations, what with eras ending and whatnot, and if proclamations like that aren't backed up well, you risk triggering a "horsehit" response.

That said, I don't usually go around telling nice people who've shared their thoughts with enthusiasm that I think there stuff is horseshit. I hope you don't take it too hard. My first instinct was "horseshit". My second instinct was to soften that up and sugarcoat it. I almost always follow that second instinct. But this time, I decided what the hell, why not try a smidgen of radical honesty and lay out my full, unfiltered, honest reaction. And whether we agree or disagree, at least you get a glimpse into one reader's reaction.

<comment><USER18> This is a good criticism. "Horseshit" still isn't very nice, though; please lead with this comment next time.

</comment></comment></comment></comment><comment><USER19> I thought this was going to be about how you need varying levels of experience to get a job, sometimes unreasonably. Which got me thinking: that's a social problem that maybe one of these left-field startups could solve. Provide a service which gets young people 'experience' to put on their CV for when the graduate and start looking for work. I guess what it would amount to is internship/apprenticeship arbitrage.

</comment><comment><USER20> If I get the drift of the article, then I'd say Rejection Therapy <http://rejectiontherapy.com> is a good example of a thoroughly experiential product (moreso than say a movie you just watch).

Perhaps it'll be an industry of experiential entertainment that will provide real alternative to Hollywood and the MPAA.

</comment><comment><USER21> The problem with this article is that chris misunderstands the meaning of the word "experience".

In the context of the research about happiness, experience meant real live experiences.You usually remember those kinds of experiences, they become a part of who you are, and you do use memories of them to change your mood.

Products usually have a different happiness charasteristic. They make you happy but only for a short time and then you get used to them.

Is software products or experiences ? well that depends on the software. airBNB seems to fit on the product model, like a well designed lamp. Using a programming language is an experience.

</comment><comment><USER22> An experience economy might be a possible post-scarcity form of economy, but in the world as it exists today outside of the realm of software we're nowhere close to post-scarcity.

Currently the idea of "experience" being the primary goal is being used as a political device in order to force unemployed people to work in for-profit companies without pay for significant periods of time, so I don't think it's a good idea to take a fetishistic attitude towards experience itself whilst simultaneously overlooking other equally or more important issues.

</comment><comment><USER23> [http://www.amazon.com/The-Experience-Economy-Theater- Busines...](http://www.amazon.com/The-Experience-Economy-Theater- Business/dp/0875848192)

</comment><comment><USER24> Four blades? I must have been missing out - I'm pretty happy with a 3-blade razor.

<comment><USER16> What are you, Amish? :)</comment></comment>


Ask HN: Best VPN Server for iPad/OS X/Ubuntu Server - <AUTHOR>

I run my own VPS with Ubuntu Server 10.04 and would like to have my own VPN to secure my connections when I use public wifi connections on my iPad or MacBook Pro.
I've tried looking at PPTP (even the maintainers of the server don't recommend it), Strongswan (NAT Transport is disabled in the Ubuntu package because of security issues), OpenSwan (I couldn't get it to work, possibly due to a bug in the version in the Ubuntu repos), and OpenVPN (not supported by Apple products).
Any tips on what would be the easiest way to get a secure VPN working? <comment><USER2> I connect from my MacBook Pro (10.6), iMac (10.6), iPhone (4.0) and iPad (3.2) to an Open/SWAN server. It works great.

This is with L2TP/IPsec. No crazy auth, just username/password/secret.

</comment><comment><USER3> OpenVPN works for me.

We do use Cisco for work and that works across all of them, but it ain't cheap son.

<comment><AUTHOR> I'd like to use OpenVPN, but unfortunately it isn't supported by Apple, nor does it seem very likely that it ever will be.</comment></comment>


Desktop Notifications for console logs in browser - <AUTHOR> https://github.com/hkirat/notification-logger <comment><USER2> During development, I have to check the browser's inspector periodically to see what my console.log()'s are saying. This leads to having two browser windows open: The browser and the inspector. And in the inspector, I usually only need to see the console. With these desktop notifications, I can develop and debug web apps with just two open windows: A single browser window and a terminal. And it's only adding ~100 lines to your project.

<comment><AUTHOR> Exactly :) Thanks for putting it out there

<comment><AUTHOR> I'm adding this to the description

</comment></comment></comment><comment><USER3> This is actually a really clever project, not sure why this is the first time I'm seeing something like this.

<comment><USER4> I made something similar once, I heavily advise against using it in its current state, it was just experimental, but it's kinda fun to play around with.

It's basically a floating console window with added features. It has two main functions

1\. Notify, call loggy.notify to display a message right in your browser (instead of in the console) 2\. call loggy(name, value), which is meant to track real-time values. For example your mouse position, say you loggy('mouse pos', mousePosition) on every `mousemove` event, it will show you the last value of `mousePosition` in the floating console window. It's like an fps tracker you see in games, constantly updating

It has some other useful features too, it shows diffs between objects every loggy(..) call, and some really weird features I forgot about.

It's fun to play around with, paste the gist in your console and then run this code as an example

var count = 1; setInterval(function () { loggy('hello', 5); count += 1; loggy.notify('we've counted ' \+ count + ' times now!'); }, 1000);

[https://gist.github.com/Azeirah/0e558c439bd59646863a31540aa2...](https://gist.github.com/Azeirah/0e558c439bd59646863a31540aa2534c)

</comment></comment><comment><USER5> Am i missing something here?

Wouldn't it be easier as a browser extension that just gives a notification every time console.log is called?

<comment><USER6> It can be both, just as Livereload: you can add it as a script, or as a extension (which adds that script)

</comment></comment><comment><USER7> Very neat. Plan to take a look at the source code later today. I was thinking of doing a chrome extension that accomplished the same goal, but just used a small pane on the bottom right instead of notifications.

</comment><comment><USER8> Great job, really useful!</comment>


Ask HN: How to Design Beautiful Websites? - <AUTHOR> <comment><USER2> Have you looked into [https://materializecss.com/](https://materializecss.com/)?

</comment><comment><USER3> Use a template or theme designed by a designer!</comment>


Ask HN: Lets start connecting and working together - Post your story - <AUTHOR>

I know a bunch of HNers here have:

  (1) Great ideas but haven't pursued them

  (2) Domains that are sitting and undeveloped

  (3) Live websites - but need help in one way or another
 Lets use this thread to post (1) (2) or (3) above with a description, along with who you are looking for: partnership, consulting, designer, developer, marketer, sales person etc
I know the HN community has so much to offer so I think this thread can be a great way to collaborate and find people to work with.
#### Don't forget to have an email address in your profile's "about" section so others can contact you #### <comment><USER3> I have a niche website that sells a digital service that i started in june. It gets 5-8 sales a month now (each of $30) and raked 1700 people who registered in the past to a mailchimp email list. It has the potential of making >120 sales a month with a good push from seo, email campaigns and the like.

I haven't touched the website for 2 months and i'm considering selling it if someone is interested. Maybe even something else? if anyone owns a website that sales, maybe we can take percentage out of each others websites and spice it up?

<comment><AUTHOR> Interesting - do you have an email where I can reach you?

<comment><USER3> yes just click on my profile

</comment></comment></comment><comment><USER4> (2) - I have Challengify.com a web 2.0 ify type domain, which can be used by startups and goes with various innovative web startup ideas.some are - <USER2> motivating app, programming challenges

I am either willing to giveaway this domain name or ready to partner with developers and like minded people to start something BIG!

<comment><AUTHOR> Cool domain thanks for posting. Quick heads up: make sure you have an email in the "about" section of your HN profile so other users can contact you.

<comment><USER4> Thanks Marco!

</comment></comment></comment><comment><USER5> We are small Mobile application studio for iOS / Android Apps and Games. If you have something in mobile space , feel free to connect with me.

</comment><comment><USER6> I am teaching myself iOS development while working on a few side projects.

Feel free to shoot me an email!</comment>


Tech VCs Promise to Never Disagree with Founders - <AUTHOR> http://go.bloomberg.com/tech-deals/2014-08-05-tech-vcs-promise-never-question-founders-give-free-cash/ <comment><USER2> The headline of this article doesn't really match the contents. Certainly partners from Felicis Ventures will disagree with founders from time to time, they just apparently won't vote against them in board votes. In many circumstances this promise won't have much practical impact.

<comment><USER3> The article doesn't clearly say board votes. It actually says "vote the shares", which, I'm not all that clear how often or with what significance shareholder votes happen in a pre-ipo company.

<comment><USER2> I'm not gonna save never because I'm sure there have been bizarre exceptions but....basically there are never shareholder votes. Only board votes.

<comment><USER4> When the composition of board itself is changed, I think that has to be agreed by shareholders. There can be differences between legislations though.

</comment></comment></comment></comment><comment><USER5> Entrepreneur-friendly is big focus for many investors these days. Witness Techstars equity back guarantee as just one example.

Felicis, based on its exits, is a top-tier micro VC (if you define it as <$100M funds) so this may force the hand of others.

Of course, there are those that feel that "voting along is a unrealistic commercial move that negates the investor's added value to his/her LPs". [1]

[1] From comments here - [https://www.cbinsights.com/blog/founder-vs-venture- capitalis...](https://www.cbinsights.com/blog/founder-vs-venture-capitalist- compensation/)

</comment><comment><USER6> Sounds like the headline of an Onion article...

<comment><USER7> +1

</comment></comment><comment><USER8> Personally, as a CEO, I would like to have an investor questioning my moves so that I am forced to consider my choices from different perspectives.

If I'm constantly being told I'm the golden boy then I'm doomed.

</comment><comment><USER9> So...what happens when the next Gurbaksh Chahal[1] gets funded by Felicis Ventures?

[1] [http://www.newyorker.com/tech/elements/gurbaksh-chahals- ugly...](http://www.newyorker.com/tech/elements/gurbaksh-chahals-ugly-revenge)

</comment><comment><USER10> While I like that investors are now forced to give entrepreneurs a better deal, this sounds like a move too far.

This is like a blank check for entrepreneurs with no strings attached, and no consequence for failure. In fact, the share given to founders in the diversified fund means that financial returns may be had even for a failing business.

That doesn't sound like an entrepreneurial risk/reward type system anymore. That sounds like a guaranteed reward for a bunch of "special" people who are part of some special club.

In fact, it sounds like East Coast investment banking.

<comment><USER11> It's exactly like the stock market, on with larger percentages.

Most people own their stocks totally passive, active shareholders are rare and usually have a big stake in the company.

If everybody who is a shareholder of Google would show up at the shareholder meeting there would be a bit of a space problem.

So passive investors are not rare at all, what is strange about this announcement is that most VCs tout their _active_ role as a plus. This company seems to be taking the opposite tack.

IMO that's wrong, investors can be a useful sounding board and if they automatically agree with every C level decision then you lose a very valuable source of criticism.

</comment></comment><comment><USER12> At first I thought this title was a poorly timed April Fools Joke.

I would imagine there are only a few decisions the founders make that ever come down to votes based on shares. Off the top of my head: Selling the company, firing the CEO, electing a new board, diluting existing shareholders, dividends.

The impact of this decision is probably heavily based on how often Felicis has a big enough stake to be a factor in shareholder voting.

<comment><USER13> Minority protections probably already cover the cases you describe (eg veto rights).

<comment><USER11> Shareholder agreements typically cover even more of them (drag-along, tag- along, first right to refuse and so on).

</comment></comment></comment><comment><USER14> Certainly times have changed. If the bubble does burst anytime soon, people might look at this in hindsight as being another warning sign we missed.

</comment><comment><USER15> ""We'll be voting unconditionally with the CEO," Senkut said in an interview. "It's time for bold moves."///"

spoken like a true believer

</comment><comment><USER16> Great move.

If you just want to invest, and take your hands off, this is great. It means you have less work managing, so you can make smaller 'bets'... err, I mean investments.

Also means the team can get on with it, and have to spend less time managing investors. Yes, some start ups do spend a lot of time doing stuff just to present nicely to investors. From taking days off working on product preparing the office so it looks more professional, to preparing speeches, and developing further pitches.

</comment><comment><USER17> Theoretically, if there is trust between the founders and the VC's shouldn't both of them have one seat?

</comment><comment><USER18> Suddenly the President/CEO title differences matter for co-founders.

</comment><comment><USER19> Ycombinator has forever changed the landscape for entrepreneurs for the better =D</comment>