Ask HN: Examples of great 'productized consulting' landing pages? - <AUTHOR> I found Jane Portman's "Productized Consulting Guide" intriguing, and am curious to see more examples of how people in different fields put this idea into practice.
Here's an example I encountered today: https://punchlinecopy.com/work-with-punchline/
Do you have a similar page on your site? Have you come across others which impressed you? <comment><USER2> One of my friends does a productized (fixed price) roadmapping session (1) as part of a larger "build your MPV" service. My understanding is that it works out really well for him and his clients. They get to try him out with a fix priced engagement. The output leads naturally to the next step in a larger engagement. If for whatever reason it doesn't workout the client has useful documentation they can take to someone else.

(1) [https://www.reemer.com/consulting/build- mvp](https://www.reemer.com/consulting/build-mvp)

<comment><USER3> Let him know that he has a typo right there in the first sentence :)

<comment><USER4> :facepalm: thanks for the heads up. Fixed!

</comment></comment></comment><comment><USER5> Oh hey, this is my site (Punchline Copy)! Glad it's interesting to you. I can say it's been a super helpful way for me to both cut down the time I spend scoping custom projects, and for potential clients to understand what they'll invest to get started working with me.

<comment><USER6> All these weird prices ending in 7–Is that something you arrived at by A/B testing or something else? Just from first impressions seeing $397 made me notice the prices much more than, say, $399 or $400.

</comment></comment><comment><USER7> My partner and I have recently productized our web design/development services:

[https://madebysphere.com](https://madebysphere.com)

The transparent pricing has really worked for us and our clients as people can self-select, and they know what to expect before getting in touch with us.

Happy to answer any questions.

<comment><USER8> 1 point by scottturman 27 minutes ago | edit | delete [–]

Hello Chris I am in the middle of taking my organization [http://BrightRay.com](http://BrightRay.com) in this direction.

1) Did you find that sending people to these productized pitches had a higher conversion rate, or are you doing it differently?

2) Are you making more money or similar money?

3) Has this cut don on the back and forth bullshit that is a residue of traditional consulting?

4) Where do you find your new clients?

</comment></comment><comment><USER9> patio11 has talked about this as well: [https://training.kalzumeus.com/newsletters/archive/services_...](https://training.kalzumeus.com/newsletters/archive/services_vs_products)

There is also an indiehackers discussion with some relevant examples: [https://www.indiehackers.com/forum/good-examples-of- producti...](https://www.indiehackers.com/forum/good-examples-of-productized- consulting-b9c90a1fed)

</comment><comment><AUTHOR> 30 minute video of a workshop Brian Casel did on this topic: [https://youtu.be/LdDZ3Jyrl4E](https://youtu.be/LdDZ3Jyrl4E)

<comment><USER10> Thanks for mentioning my video! That was an old one.

I've published a lot more about productized services since then. Articles, newer videos, and my Productize Podcast can be found here: [https://productizeandscale.com](https://productizeandscale.com)

<comment><USER11> Glad you resurrected the podcast!

Came here to post a few people to check out if you're interested in productizing (or positioning as a consultant):

\- Brian Casel

\- Philip Morgan

\- Jonathan Stark

\- Kai Davis

</comment></comment></comment><comment><USER12> Checkout [http://visualizevalue.com/](http://visualizevalue.com/)

It's the best example I've seen so far, ticks all the boxes:

\- great content marketing (checkout twitter)

\- specific, short, expensive-gig

\- community (annual subscription)

\- online course (paid for this, so far awesome)

His service and the stuff he teaches are all on the same topic (hence the name): helping you use visual language to describe how you offer value.

</comment><comment><USER13> In my long experience, website doesn't do much.

Most of the business I've got in consulting field is through word of mouth and you spend sometime on call with the customer to understand what exactly they want and what you can offer to them at what price point and if you've previous successful projects to show off to them.

Getting project from a customer who approaches you is really easy provided you've experienced and I start by understanding their requirements then offering them deep domain expertise overview of how we are going to slice and dice the problem at hand.

Now ofc, if you don't have much experience with the domain - the person in front of you'll easily detect your BS.

Websites doesn't really help much other than opening a line of communication and probably displaying some previous customers, success and maybe your company address / size.

<comment><USER14> You have missed the point.

</comment></comment><comment><USER15> We do corporate finance consulting, and here's how we present the "productized" version of our offering: [https://www.fivecastfinancial.com/core-financial- package/](https://www.fivecastfinancial.com/core-financial-package/)

</comment><comment><USER16> We very recently launched a productized service of our main offering: [https://agentrisk.com/together](https://agentrisk.com/together)

The reason was that we had a lot of people who either didn't meet our account minimum to join our wealth management service or they prefer to keep their investing DIY and wanted some help along the way.

Would really like your feedback on the copy/messaging, this is v1.0 and we're iterating on this.

<comment><USER14> Have you been able to close more business as a result of this switch?

<comment><USER16> Yes!

</comment></comment></comment><comment><USER17> Always liked the landing page for:

[https://www.gradientmetrics.com/](https://www.gradientmetrics.com/)

</comment><comment><USER18> This one is nice and simple: [https://leadingup.co/](https://leadingup.co/)

</comment><comment><USER19> I productized my consulting services last year. I have a paid discovery offer called an Ops Performance Review that sets the stage nicely for a larger engagement.

[https://www.bluprintpartners.com/our- solutions](https://www.bluprintpartners.com/our-solutions)

</comment><comment><USER20> This is a good example of a productized service that produces case studies: [https://casestudybuddy.com/](https://casestudybuddy.com/)

I'm not affiliated & have never worked with them, but have heard good things and the site seems convincing.

</comment><comment><USER21> Yes & No Design Studio:

[https://xn--bj8a.com](https://ꑮ.com) (ꑮ.com)

For example, a form for ordering app design and development service:

[https://xn--bj8a.com/app/](https://ꑮ.com/app/) (ꑮ.com/app/)

<comment><USER22> Design and development as a commodity.

<comment><USER8> I1 was just trying to figure out how to verbalize this but yeah. development- as-a-commodity

</comment></comment></comment><comment><USER14> I have never seen the use of credits as a way of purchasing work before? [https://snapcopy.co/buy-credits/5-snap-credits/](https://snapcopy.co/buy- credits/5-snap-credits/)

</comment><comment><USER23> Major Tom ([https://www.majortom.com](https://www.majortom.com)) launched a Shopify site for their services: [https://tincan.shop](https://tincan.shop)

</comment><comment><USER24> We added a productized service to our SaaS [https://versoly.com/done-for- you](https://versoly.com/done-for-you)

We have got a few paying customers from it and it is much easier than just client work.

<comment><USER25>
       Done for you marketing website that actually converts.

I don't understand what you're trying to say here.

</comment></comment><comment><USER26> We productized UX & UI design for Software Companies and have been running a pretty high converting and profitable business from a single page website.

[][https://fairpixels.pro](https://fairpixels.pro)

</comment><comment><USER27> I decided to try the productized consulting stuff about 5 years ago. I haven't changed the landing page much - [https://breue.com/](https://breue.com/)

I'm happy to answer any questions.

<comment><USER28> How do you handle the expectations and communication with customers?

Given the list price for your clickable demo you could burn through that just fielding emails / calls with your clients.

<comment><USER27> This would need to be a much longer answer. But for the most part, it's through defining a clear product roadmap at the start, providing a live work in progress, as the MVP is being built, doing weekly checkin calls with Slack in between, and delicately balancing any potential scope creep.

For your second question. I don't actually do any clickable demos. Only a handful of folks ever ask for one, I tell them to use proto.io or Invision.

<comment><USER28> Oh that makes much more sense :) Does that enable you to work with multiple customers at the same time?

It looks like a fantastic business model for someone with your skillset and talent.

<comment><USER27> Yup, thankfully!

Thank you! :)

It has its ups and downs. I guess the other big factor is that I try to limit the projects I take on, to the more interesting stuff, to try to reduce any fatigue/burnout.

</comment></comment></comment></comment></comment><comment><USER29> I remember one of the first rails consultancies Hashrocket used to have products: 3-2-1 Launch and Rescue Mission.

I want to say 3-2-1 Launch was they build your site over 3 days for something like $30k. You might find something in archive.org.

</comment><comment><USER8> Another interesting example is [https://www.superside.com](https://www.superside.com). They are advertising heavily on one of my favorite podcasts.

</comment><comment><USER30> It's not a consulting but we have productized our design services[1] into small packages. Working well so far for us. [1] Thecanopus.co

</comment><comment><USER31> I developed productized services back in April when my SaaS clients started requesting faster turnarounds on projects, with more limited budgets.

It was also a good excuse to have some more fun with branding! [https://www.mightyfinecopy.com/shop](https://www.mightyfinecopy.com/shop)

<comment><USER14> Love this page. Did you close more business?

</comment></comment><comment><USER32> I don't think I've ever chuckled so hard to a landing page before

</comment><comment><USER33> Has anyone seen good examples of this for marketing?</comment>


How to Revise an Email So That People Will Read It - <AUTHOR> http://blogs.harvardbusiness.org/silverman/2009/04/how-to-revise-an-email-so-that.html?cm_mmc=npv-_-WEEKLY_HOTLIST-_-APR_2009-_-HOTLIST0417

<comment><USER2> If I have multiple points to describe on an important topic, I typically make an outline, and bold a 1-3 word summary for each bullet. As corporate-monkey as that is, it makes it very easy to skim without letting my managers overlook pieces I feel are important.

If they're only going to spend 20 seconds glancing at the response, I want it to be a breadth-first scan of the bolded items rather than a depth-first scan of the first paragraph.

For what it's worth, every management team I've worked under in the past decade of software development has loved it. I feel "uncool" for typing this here, but maybe it'll help someone to try the same approach (in addition to the great revising steps listed in the article).

<comment><USER3> Have you tried eliminating the body of the message, and just sending the bullet-points? If the reader appreciates it because they're not going to read the rest of the message, why _give them_ the rest of the message?

<comment><USER2> Good point. The terse details are there for two reasons:

* _Stakeholders need specifics_ \-- While some managers just need to skim, some peers and deeper stakeholders on the thread require details to validate the points because it impacts them specifically.

* _Managers want access to details_ \-- The manager wants to be able to skim, but also have details on a specific item if they choose to dive into it (now or later). It's hard to tell which ones these will be, so providing extra information after the heading allows them to pick and choose without obstructing their quick-skim-ability.

</comment></comment></comment><comment><USER4> I would recommend Strunk and White's Elements of Style to help. This post was essentially that with a little hastiness for the reader built in. -A

</comment><comment><USER5> Search YC

<http://searchyc.com/How+to+Revise+an+Email>

is your friend for finding duplicate submissions:

<http://news.ycombinator.com/item?id=562447>

<comment><USER6> If this is a duplicate, it's one that a lot of people could benefit from.

Summary:

1\. Delete redundancies. 2\. Use numbers and specifics instead of adverbs and adjectives. 3\. Add missing context. 4\. Focus on the strongest argument. 5\. Delete off-topic material. 6\. Seek out equivocation and remove it. 7\. Kill your favorites. 8\. Delete anything written in the heat of emotion. 9\. Shorten. 10\. Give it a day.

<comment><USER7> Summarising even further... note that most of those involve "delete"!

At least, that's what I usually end up doing. The more concise it is, the easier it is to absorb. It's quite sobering how long it can take to get something that concise though.</comment></comment></comment>


What the U.S. Can Learn From Canada's High-Paying Jobs Recovery - <AUTHOR> http://www.theatlanticcities.com/jobs-and-economy/2013/09/what-us-can-learn-canadas-high-paying-jobs-recovery/6876/

<comment><USER2> The article teaches nothing, it just shows results. _How_ did all those great jobs get created? What did I miss?

This is like telling me that I can learn something from an expert guitar player, then only letting me listen to the expert guitar player. I've learned nothing from that about how to be a better guitar player.</comment>


GNOME 3.16 on OpenBSD [video] - <AUTHOR> https://www.bsdfrog.org/tmp/gnome316.webm

<comment><USER2> This video was created by the GNOME maintainer for OpenBSD.

[https://twitter.com/ajacoutot/status/586957762170597376](https://twitter.com/ajacoutot/status/586957762170597376)

</comment><comment><USER3> I believe the significance is that Gnome 3.X+ relies on systemd? Though I may be mistaken.

<comment><USER4> My thoughts exactly. I'd love an article about how difficult (if it was at all) to port and run on BSD.

<comment><USER5> GNOME 3.16 optionally uses systemd interfaces. It still includes support for pre-systemd ways of doing things.

<comment><USER6> Well, "optionally" in the sense that you can non-trivially excise and shim your way into a working system (the patches for 3.14 on Slackware, at least, are non-trivial and I'd imagine it's even more invasive on OpenBSD which doesn't have, for instance, /proc or /sys). Personally, I can't stand GNOME 3.X so I haven't looked too closely, but even just a couple of versions ago OpenBSD could only do "fallback".

</comment></comment></comment></comment><comment><USER7> Is there something novel here that I am missing?

<comment><USER8> GNOME has had systemd as a hard dependency since 2012: it uses systemd-logind and a few other systemd services for its basic functionality. systemd is only available on Linux systems, therefore it's a pretty great achievement to get it running on OpenBSD.

<comment><USER2> OpenBSD's port of GNOME3 does not rely on systemd at all.

<comment><USER9> I don't think he said otherwise.

<comment><USER5> The poster said "hard dependency". This is false.

<comment><USER6> The unpatched GNOME post 3.12 or so does have a hard dependency, which is why platforms like OpenBSD or Slackware have to patch. If it requires a patch to work around, it's a hard dependency.

</comment></comment></comment></comment></comment></comment><comment><USER10> On a side note Safari on desktop and mobile do not support .webm

<comment><USER11> Safari doesn't support OpenBSD either.

</comment></comment><comment><USER12> I take this video as evidence that everyone in UNIX-land dislikes systemd greatly, and the (Red Hat/Debian/Arch) Linux guys are the odd men out.

<comment><USER13> > I take this video as evidence that everyone in UNIX-land dislikes systemd > greatly, and the (Red Hat/Debian/Arch) Linux guys are the odd men out.

"the odd men out" are the one with the the highest user base (I suppose you know that Ubuntu is moving to SystemD too)

<comment><USER12> lots of tumors end up being larger than the host. I don't see how that makes anything I said any less relevant. if RH/Debian/Arch move away from POSIX and GNU, they aren't Unix anymore. with the RPC GPL/LGPL backdoor, they're barely free software.

<comment><USER5> Linux systems are barely POSIX, were _never_ UNIX, and systemd doesn't have anything to do with POSIX.

Windows has a crummy POSIX layer, and it's not like it ships sysvinit.

Be serious.

<comment><USER12> it's amazing how you can be misleading, while telling the complete truth. are you a lawyer?

Linux systems are quite POSIX. the whole point of GNU was to be compatible.

They were never unix, because they weren't of BSD or AT&T heritage. true, and completely irrelevant.

systemd absolutely hates POSIX, and is actively steering Linux away from it.

I have no idea why windows even applies here. If you are comparing Windows to systemd, you may be correct, but both are abhorrent to OpenBSD users.

<comment><USER14> OS X is fully POSIX compliant. Its launchd is rather more similar to systemd, having abandoned startup scripts 10 years ago.

<comment><USER12> launchd has various levels of support in FreeBSD, and less in Net/OpenBSD. However, I've never heard a single positive thing mentioned about systemd from the BSD community, despite it's apparent similarities to launchd. Apparently, BSD people like Apple more than Red Hat. I don't blame them, personally.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> How does one patch KDE2 under FreeBSD?</comment>


Introducing Mozilla Persona, An Identity System for the Web - <AUTHOR> http://www.mozilla.org/en-US/persona/

<comment><USER3> My company is one of the early adopters of Persona/BrowserID. You can see our dual-auth (with Facebook) system here:

<https://www.voo.st/>

We've been live for several months now in the Real World - our userbase (amateur athletes) is primarily nontechnical. About half of our users choose Persona/BrowserID and half choose Facebook. We were initially concerned about the BID login flow (in particular, the immediate email roundtrip) but it hasn't been a problem and the UX has been refined quite a lot over the last month or two.

For a mass-consumer audience, the combined FB/Persona solution is excellent:

* Facebook unquestionably has the slickest auth experience, even eliminating the followup name/sex/bday questions. However, a significant percentage of the world (possibly > 25%) either Hates Facebook or wants to keep their Facebook account isolated. This is unlikely to change in the near future and could even get worse depending on what sleeping dogs Zuckerberg decides to kick next week. We don't have the option of alienating the FB haters and we wouldn't want to anyways.

* The Persona UX is good and rapidly getting better. BigTent integration with gmail, yahoo, hotmail will bring one-click login to those users. A native experience is being built into browser chrome. All this is coming without me having to write code. It may not be as slick as Facebook, but I like where this train is headed.

* Integration is simple compared to writing a username/password system. The API is incredibly easy to work with. Dual-auth with Facebook is a little more complicated, but a complete Persona-based auth system is a question of hours, not days.

* The fact that identity is just an email address makes it easier to integrate with existing login systems. In our system, you can log into the same account with both Facebook and Persona as long as the emails match. No, email is not a perfect identifier, but even nontechnical users understand it immediately and really - what other option is there? "What email address did I use?" is a lot better than "What weird combination of letters and numbers did I use as a login name?"

* Support on the Mozilla dev-identity list has been fantastic.

We're pretty happy. Honestly, I don't ever see myself writing another username/password login system ever again. Persona is less work for a better UX.

<comment><USER4> OK so I tried to sign up to your site with BID and am pretty confused:

I'm using Chrome. Don't know if that affects things. Anyway.

Hit Browser ID, asks me for my email address. OK fine, add that in. It then says (quickly, and temporarily as it's an AJAX load), that it's looking up my email provider (Google Apps). It then asks me for my password.

So now I'm totally confused. I've not signed up with your site or BID before, so I dont know if it wants my GAPPS password or a new password. I don't feel like I want to put in my GApps password, as there is no Google branding anywhere and the URL is not Google.

So I try putting in my GAPPS password, because I use 2 factor, and it doesn't work. Most likely because I use 2 factor, and I can't authenticate with just my standard GAPPS password.

So it failed. I guess I'm an edge case as most people don't enable 2-factor on their Google account, but I was still really confused when it asked for my email password.

EDIT:

Same thing happened with Firefox version whatever the latest one is.

I'd say it's completely confusing, all in all.

<comment><USER5> I just tried it and once I entered my email address, it then asked: "Next, choose a new password you'll use when you sign in with Persona."

Not sure why you're confused.

<comment><USER6> From <https://developer.mozilla.org/en/BrowserID/>

_"Website operators still get a verified email address for their users, and users only have to remember a single password. BrowserID is also intuitive, since email addresses are commonly understood to be associated with identities."_

Mozilla is really stressing the _"email address/single password"_ concept. If they really mean _"email address/separate dedicated Persona password"_ then they should make this clear.

<comment><USER7> The language around the number of passwords you need is really hard to get right. If you have suggestions, please let me know.

In a world where every email provider supports Persona natively, Persona truly is a "no new passwords" authentication system, since it delegates to your provider. If your email address isn't supported, Persona asks you to create a single new password at login.persona.org. You can then add many other unsupported addresses, without needing more passwords. So it's an "at most one new password" system.

<comment><USER8> Simply always refer to the Persona password as "Persona password".

> In a world where every email provider supports Persona natively, Persona > truly is a "no new passwords" authentication system, since it delegates to > your provider.

I don't know what this means. I won't give Persona my gmail/yahoo-mail email password.

<comment><USER7> Yeah, it's confusing. If your email provider is supported, your browser talks directly to your email provider, without Mozilla in the middle. We don't want your passwords, honest! :)

You can try out the supported email provider workflow by signing up for a dummy account at eyedee.me, and then using that account to sign in at, say, 123done.org.

<comment><USER6> Wait, if this system works with a dummy account, then a valid email address isn't necessary at all. Any domain can set up an identity provider to support user@domain. Why drag email providers into the discussion, then? It confuses everyone.

<comment><USER3> It confuses _you_ because you are a technologist. For 99.99% of the world, user@domain == email address.

"Sign in with your email address" gets the point across. "Sign in with your user identity at a controlling DNS authority" may be more accurate, but will _actually_ confuse everyone.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> That link is to a very high level, non-technical overview, which is not a good link for HN.

Try these links, which go into much more detail, answering the "why bother" questions.

<https://developer.mozilla.org/en/BrowserID/Why_BrowserID>

[http://identity.mozilla.com/post/7899984443/privacy-and- brow...](http://identity.mozilla.com/post/7899984443/privacy-and-browserid)

<http://lloyd.io/how-browserid-works>

Note that BrowserID was the old working name for the project.

</comment><comment><USER10> I believe that a native implementation has been on their plans from the start, but I haven't heard much about it lately. Here's some mockups:

[http://people.mozilla.com/%7Efaaborg/files/projects/firefoxA...](http://people.mozilla.com/%7Efaaborg/files/projects/firefoxAccount/index.html)

There's also some work on integrating existing e-mail providers, so you can get instant identities:

[http://identity.mozilla.com/post/17207734786/id-provider- sup...](http://identity.mozilla.com/post/17207734786/id-provider-support-now- live-on-browserid)

This is probably the web-thing I'm most excited about today, even though the development is kinda slow. I really want to implement it as a sole identity provider on my websites some day.

EDIT: I also began writing a Safari extension that would work like the mockup above, but gave up halfway since it was too convoluted and totally insecure... maybe I should try writing a SIMBL plugin or something like that.

<comment><USER11> A website relying on a single service to serve as a sole identity provider seems replete with risks. That sounds remarkably similar to Microsoft's Passport, an idea that was a non-starter for everyone except Microsoft.

<comment><USER10> It's hard to explain, but it's not much a "service" - the current implementation is just a "shim", since no browser supports it natively. Client-wise, it's just a JavaScript API. In the future, your browser will store your keys, not Mozilla.

But even with the current implementation it is possible to validate the assertion in your server without contacting browserid.org, but AFAIK nobody did it yet.

(I tried to find a reference for that, but they took it down from their Wiki. It used to say "You may choose to validate assertions on your own server": [https://github.com/mozilla/browserid/wiki/How-to-Use- Browser...](https://github.com/mozilla/browserid/wiki/How-to-Use-BrowserID-on- Your-Site/5a1abdd205221e39621c17d7cc3050b3f3b97eed) \- the verification code is still online, though)

<comment><USER7> Your browser already stores your keys, even with the shim. :)

Faaborg's mockups are awesome, but they're well over a year old and not really guiding our current work. Still, definitely take a look at them, if nothing else than for the cool way of doing mockups!

You can definitely do your own verification without having us in the loop, but we'd urge you to hold off until this fall; the IETF is still standardizing some of the data formats we're using, so the exact serialization of keys and assertions might change between now and then. By using our verifier, you're certain to be up to date.

The easiest way to verify-it-yourself is to just run our code locally; it's all open source, after all :) <https://github.com/mozilla/browserid>

(PS: The docs are now on MDN, instead of the GitHub wiki: <https://developer.mozilla.org/en/BrowserID> )

</comment></comment></comment></comment><comment><USER12> So we have this, Open ID, Facebook, Twitter, Google, Microsoft Passport/Live ID, and probably like five other major players I'm forgetting. I apologize for being pessimistic, but this just doesn't seem like a solvable problem. I _want_ it to be solvable, but players like Facebook benefit far too much for them to _not_ push their particular version of "universal" login on everyone. Every player seems to think they are the One True Solution... But so far, it's all one big mess. I don't see it getting better any time soon.

<comment><USER13> I think if you look at Kim Cameron's Laws of Identity, it's clear that the research team at MS has had it right for at least a decade, it's just that none of their ideas have made it into production.

<http://www.identityblog.com/stories/2004/12/09/thelaws.html>

Ballmer had both the plans and source code for an identity product that would have been 10x more advanced than Facebook, but they decided to axe the project so they could make the Zune instead.

<comment><USER14> _Ballmer had both the plans and source code for an identity product that would have been 10x more advanced than Facebook_

 _ANYONE_ can make an identity product that is 10x more advanced than Facebook.

The problem is making an identity product that is 10x _SIMPLER_ than Facebook, without relying on a single source of identity verification.

</comment></comment></comment><comment><USER15> I know this probably fits only me but I never use my email address as id.

Every company and every account I sign up for I give a different email address. I'm not about to use a single one for my ID. Especially when they are easy to spoof (any one can send mail as firstname.lastname@example.com) and they are easy to spam and abuse. I had an email address that got 3000 spams a day. That's why I never give use email as ID because I want to be able to disable any email address that's giving me trouble.

So, not interested in BrowserID I think. Or maybe I didn't grok it.

<comment><USER16> There is a lot of scope for one-time emails, pseudonymous emails and other kinds of not-my-primary-email authentication systems within Persona. One simple example of how this might work is MockMyID:

        https://mockmyid.com/

Try logging into a Persona-enabled website with firstname.lastname@example.com - <USER2> will be able to authenticate without entering any password or giving away any personal information. Of course, so can anyone else, but it might give you an idea of the possibilities in this space.

<comment><USER17> But what is being authenticated exactly in this case?

My understanding of Browser ID is that it's a way to provide an email address to a site operator that doesn't need to be confirmed. It's a single-step subscribe/account creation, rather than an authentication per se.

<comment><USER16> BrowserID provides a way to say to a site "I own this email address", as well as a protocol for the site to verify such an assertion. What the site chooses to do with the information is up to them. It can be used for account creation or signup, but works equally well for authentication to an existing account.

In the mockmyid case, you are saying "I own the address firstname.lastname@example.com". But the MockMyID server will happily let anyone make such an assertion, so you get a simple kind of mock identity.

Of course, you shouldn't use that as your identity on any sites that you care about. Mail to email@example.com doesn't go anywhere, and there's nothing to prevent other people from using the same @mockmyid.com address. But it's a neat example of the sort of thing that is possible.

</comment></comment></comment></comment><comment><USER18> One of the reasons FB and Twitter OAuth became so popular is because they solved a problem for the user (remembering passwords) and also gave the site owner a big carrot (social growth mechanics, more user data).

This seems much more one sided -- it's good for the user that doesn't use FB or Twitter but 'meh' for the website. I'm not sure we'll see fast adoption like we have for OAuth.

<comment><USER7> One of the biggest wins for sites is that we reduce account creation / sign in friction for your users, so you get an awesome, easy flow through your funnel without having to give up ownership of your user data.

We also let you reach many, many more people, since you're not forcing users into joining an anointed social network. Everyone has an email address, and people understand what it means to reveal it.

Also, there's no lock-in, because we're not giving you an opaque, one-way identifier for your users. Instead, you always get a verified email address. Want to switch away from Persona? Add a 'password' column to your database and send a few emails.

Edit: I should also note that we're really, really easy to implement. Like, roll-your-own-integration in less than 3 hours with zero previous experience easy. I want to see us become the de facto auth solution for weekend projects, but we're also a really nice option to put alongside your social login. If you're already offering Twitter and Facebook, why not provide a vendor-neutral option, too?

<comment><USER19> Wait, it relies on email address? ( _quickly reads up on it._ ) ... and it doesn't have user identifiers other than the email address? That is not reasonable: normal people (as in, people who don't know much about what they are doing with computers) tend to have piles and piles of email addresses, none of which hold any canonical weight to them: they have email addresses from ISPs, from schools, from work, and they often have multiple email addresses from sevices like Gmail. If they lose track of one they just get another one (as email addresses aren't even important anyway), and they never remember which one they've used with any given site. I've even seen people purposely get a new email address every now and then as their way of dealing with spam and "people I don't want to talk to anymore". They don't think far ahead, so the notion that their email address from school will be retired a year after they graduate _and given to someone else_ doesn't occur to them (and seemingly didn't occur to you either, as it undermines the argument that it is a reasonable way to do password resets): email addresses are about the worst possible (while still plausible) "unique" identifier you could have come up with. :( (And yes: this is coming from someone who has had a single canonical email address for over 15 years: I also run a popular website frequented by tens of millions of users, many of whom are non-technical customers, and I have had to realize that they are nothing like me.)

<comment><USER20> Here's what would be great for users, being able to sign in with _any_ of their email addresses and passwords. If you could register all of your email addresses and passwords then login would become as easy as entering the first set of details you think of.

<comment><USER21> That's an interesting idea. How would you go about collecting all these emails first though?

Would you tell the user to "just enter all email addresses you ever registered" and then send confirmation emails to all of them? I'd imagine this ending with one or two confirmed email addresses and maybe 3 additional unconfirmed ones.

When the user then tries to use one of the unconfirmed addresses to sign in — what do you do? Refuse log in because the address is not confirmed? Send another confirmation email to that account and ask the user to confirm it? List those confirmed addresses in the account and ask the user if he wants to sign in with one of them?

<comment><USER22> No need to send confirmation emails. Let him login with any email address. If the authentication is successful, you let him in. At this stage, it is a new account so give him an option to link this new account with his existing account with your service. If he had already provided all his email addresses with the first account, there is no need to authenticate one more time. Otherwise, simply authenticate once more with the original email and link the accounts if successful.

</comment></comment></comment></comment></comment></comment><comment><USER23> I read a comment that the email provider can allow anyone to log into your accounts because they can sign any public key they want to say it's valid. This seems to be true from my 10 minutes reading the spec.

I know a password reset function that uses only email is basically the same level of trust in the email provider, and I'm no fan of email based password reset, but this feels even worse -- literally abdicating your security entirely into your email providers hands? Gmail is great because it's free, but I didn't join gmail with the idea of giving them the keys to my life.

Another thing I don't fully grok yet is the 'issued-by' concept. Does this mean that 'Relying Parties' need to whitelist all the secondaries they are willing to trust? How can that possibly fly?

Finally, in a native implementation, how is the keyring persisted on disk kept safe from malware extracting your private keys? If the browser can decrypt the keyring, so can malware.

Ok I lied, one more thing... Is there a password prompt when you first sit down at the native BrowserID implementation? Or does it just assume that your browser means its you sitting there?! Then of course the next question is, how do you tell your browser you are walking away (akin to logout) and is it going to expire all sessions that were tied to your identity when that happens? So much to worry about...

<comment><USER7> > _I didn't join gmail with the idea of giving them the keys to my life._

Nor did I, but as you acknowledged, that sort of control has entered the status quo. Anyone who can break into your email account can trivially reset your password on many sites, at which point, per-site passwords just become another liability. We get rid of those, and empower you to independently decide who to trust with your identity.

> _Does this mean that 'Relying Parties' need to whitelist all the secondaries > they are willing to trust? How can that possibly fly?_

The idea of a secondary (or fallback) isn't central to the BrowserID protocol; it's just a convenience so that we can actually bootstrap a fully decentralized system. In practice, all libraries trust Mozilla's fallback Identity Provider by default. As email providers add native support for the BrowserID protocol less and less traffic passes through our fallback until it simply and automatically drops out of existence.

> _If the browser can decrypt the keyring, so can malware._

Yep, that's true. Same with your password manager, though we are trying to mitigate this by making the certificate itself relatively short-lived. To wit, each client has its own ephemeral keypair with certificates that expire regularly, requiring a silent renewal with the Identity Provider. This creates an opportunity for the Identity Provider to refuse to renew a certificate, should one of your machines become compromised.

> _Is there a password prompt when you first sit down at the native BrowserID > implementation? Or does it just assume that your browser means its you > sitting there?!_

If you have a valid, unexpired certificate available, you'll be able to log in to things straight away. If not, you'll need to authenticate with your identity provider to get a fresh cert. Native clients are, of course, free to implement additional security measures before allowing access to the keystore.

<comment><USER23> Thanks for taking the time to respond.

At least in the case of password resets, it's the site deciding they want "email" to be the weakest link, and many sites will require at least a little bit more (like secret questions) after a reset. In this scheme, email is by definition the weakest link.

The secondaries can never go away, unless sites are willing to straight up refuse customers based on their email address. There is an extremely long tail of corporate email servers out there, and those corporate employees are our users. I guess we just gracefully degrade back to standard usernames and passwords?

So the certa expire AND the key-pair is ephemeral, so if the user doesn't stay logged into their email account, they are going to get login prompts every 6 hours. If you use multiple emails, that means constantly cycling through your various gmail accounts every time the certs expire.

I think you need to allow flushing the key pair manually or else you're saying there really is no way to "Log out" with this. Worse, a user will click 'Log out' on their site, but the cert is still active so anyone can walk up / pick up the device and log right back in. So what we've been taught "make sure you log out and then quit the browser" wouldn't actually apply anymore.

Last thing for the night... If a site falls victim to a XSS vulnerability, does this mean an attacker can call id.get() and steal a users assertion, send it to themselves, and login as a user of my site by replaying the assertion? This is like stepping back to IE5 where cookies couldn't be HttpOnly!

<comment><USER7> Oh, sorry, there absolutely are prominent ways to log out / flush the keypair manually. It's after 02:00 local, so I need to get some sleep :).

As to XSS, the assertion that's transmitted to a site is scoped to that specific site, and is only valid for, iirc, 2 minutes. So replay attacks are severely constrained. Plus, the only meaningful data they contain is the user's email address, so phishing doesn't get you much of value or put the user at risk.

<comment><USER23> So that's a 'yes' this exposes authentication to XSS, albeit the attacker will have to hijack sessions in real-time as the assertions are forwarded to their server.

That's a huge step _backwards_ in web security. Why pass the assertion to the RP via the most insecure channel possible, i.e. the client-side javascript? That was just the easiest way you could find so the RP could tie it to client's session id?!

Obviously the assertion must be sent from the browser plugin directly to the RP. You could do it by injecting an HttpOnly cookie for the RP's domain with the encoded assertion. Javascript can never see it.

In the case of a secondary, the secondary already has an HttpOnly session id with the end user, since they're authenticated in the first place. The secondary would post the assertion back to the RP _directly_ at a well known URL, and the RP returns a URL to the secondary with a nonce built in. The secondary redirects the end-user to that nonce URL so the RP can give them an HttpOnly authenticated session id. I think you can do this in a way such that neither the assertion nor the nonce will be visible to client javascript.

Saying, 'oh your account can only be logged into by attackers for 2 minutes if they can XSS the RP' is beyond disappointing, it's borderline negligent.

</comment></comment></comment></comment></comment><comment><USER24> For most people, it goes like this: click on the Facebook login button, done. OR, click on personaID, have a new window open, enter email, enter password, go through setup, get back to site. This will be hard for most web users to adopt.

<comment><USER25> For other people it goes 'click the Facebook login button' - What? This POS uses Facebook? What access does it get to my Facebook account? Is it one of those weird things that posts all over my Facebook wall? [cancel]

<comment><USER26> Generally I've noticed people are fine with FB login as long as you add "Don't worry we won't spam your friends without your permission" or "We won't spam your feed, we just want to know it's you." or something like that

</comment></comment></comment><comment><USER27> Mozilla Persona (AKA BrowserID) is exciting stuff. However, it doesn't seem to have changed much since the last time it hit Hacker News [0].

There are websites that have chosen Persona as an authentication method. We now need to see the following two pieces implemented:

\- It needs to be implemented in the browser's GUI, like in this old screenshot [1]. People will be able to see the usability and security benefits of having a standardised way to log in that's built-in into the browser. Could we at least have a Firefox extension or a nightly build of Firefox that does this?

\- At least one email provider needs to be a Persona "ID provider", which would eliminate the need to create a Persona password and to click on a link in an email. My guess is that getting Gmail to support this would be slow work, why not try persuading smaller email providers like Fastmail to be the first to openly support Persona?

Fortunately, Persona does work even without these two pieces, using fall-back servers and a shim. But most of the benefits of Persona are only valid once the browser and the email provider deliberately support it.

[0] - <https://news.ycombinator.com/item?id=2764824>

[1] - <http://i50.tinypic.com/2ptyv80.jpg>

<comment><USER7> Much has changed, but we haven't written about it yet. We're working on it. This post to HN caught me by surprise. The new design went live, but we weren't planning on announcing things until early next month. Trying to stabilize and polish the new APIs, etc.

Native support should be coming in Firefox 17, albeit off-by-default. Native support _will_ be enabled on phones running Boot2Gecko, which ship in Q1 next year.

</comment></comment><comment><USER28> Random thoughts:

• The name "Persona" is odd considering something by the same name already exists in Mozilla-land, a fact they seem to be aware of.

• I hope sites use this instead of forcing Facebook login!!

<comment><USER29> The other personas (aka "lightweight themes") are supposedly being re-branded (thought I don't remember what they're calling them). It apparently hasn't happened yet, which will surely lead to some trouble.

<comment><USER30> Why don't they call them lightweight themes?

<comment><USER31> This comment sounds so innocent but it really started me thinking. When should one call things simply by their name and when should one create a new name?

Would Twitter be the same if it was for short text messages? Or are Tweets so different that they deserve their own name?

<comment><USER25> Brands have value that can be protected with trade marks. You can't protect generics with trade marks (easily)

</comment></comment></comment></comment></comment><comment><USER6> As an email provider for multiple domains, I have a hard time seeing what this actually has to do with current email infrastructure. It seems the only time the email address is used is to support a fallback notification, in which case many of the claimed benefits of BrowserID are lost (as you've fallen back to a single centralized identity provider).

Correct me if I'm wrong, but BrowserID/Persona assumes that for a email@example.com identifier there is a corresponding <https://example.org>. That's not true for most of the domains I support. In many cases, example.org doesn't even resolve to to an IP address and web servers are only run on subdomains (and not all subdomains have HTTP servers). Does BrowserID/Persona support a DNS mechanism to discover the location of the required HTTPS web server, similar to an MX record?

The opposite problem is where a user has a single email account with multiple valid addresses at multiple domains, such as email@example.com, email@example.com, firstname.lastname@example.com, etc. I work for an organization approaching a million users where this is the case and isn't going to change anytime soon. Once again, you can't assume there is an identity provider running on a web server at all of these domains. Is there a DNS-based method of discovery to solve this problem?

Does BrowserID/Persona allow users to authenticate against the same system they use when accessing email? If so, why does the OpenPhoto example ask for a password? I thought the whole point was that users avoid sharing credentials with sites. That implementation is very confusing and looks like a scary phishing attack.

Finally, it's not very clear what I should expect in the way of connections from other computers, _whether I'm running an identity provider or not_. This is crucial information to avoid tripping an intrusion detection system (IDS) during unexpected connections, especially from my own users.

</comment><comment><USER32> Now if we can just get Chrome to agree on the same protocol.

<comment><USER33> Technically, this will work with chrome as-is, it just won't have a slick native interface. The basics are already implemented by Mozilla as a HTML/js library you can use on any browser.

<comment><USER34> It wouldn't even be that hard to have an extension scan the dom and offer the signed assertion automatically as Firefox would/could.

</comment></comment></comment><comment><USER35> I tried the OpenPhoto example. One thing that introduces friction compared to username-password: The first time, I have to create a Persona account. Unfortunatelly, I'm not logged in afterwards.

Most sites nowadays log you in right after account creation and just wait for email-verification later. Is that even possible with Persona?

<comment><USER7> Yeah, that totally sucks, and we're working on it.

OpenPhoto is still using our old API, which can't handle post-verification redirects. Our new API does this automatically. Grab a mailinator account and try signing in to <http://123done.org>.

As for creating a Persona account, we're trying to fix that, too. Next month we'll be turning on a feature (codenamed "bigtent") that verifies Gmail, Hotmail, and Yahoo users by sending them through their respective provider's OpenID or Oauth endpoints. No more new account creation. No more email verification loop. Just three clicks and you're done.

<comment><USER27> The webpage should suggest a website other than OpenPhoto, then. First impressions count. (I say this as someone who's really excited by Persona and who wants it to spread as quickly as possible.)

</comment></comment></comment><comment><USER36> Honest question: As an app builder, why would you use this instead of facebook?

Many more users are going to have Facebook logins already, and it provides social information that may be useful to your app.

(Hoping to hear answers other than the dev-centric 'I don't like facebook')

<comment><USER37> Exactly, and I think it's possible that Mozilla just doesn't understand this. Webapps aren't attracted to identity providers because they want to avoid managing a user table in their database, but because existing identity providers like Facebook provide a set of "social" APIs that can support the webapp. I can't see why a site would be drawn to BrowserID instead.

<comment><USER7> > _I can't see why a site would be drawn to BrowserID instead._

There's more to Persona than liberating you from your password column.

Nevertheless, there are still _huge_ classes of applications that don't benefit from social features, but _do_ want the improved experience that Persona can offer. Think banks, universities, corporations, and governments.

So even in the absolute worst case versus Facebook Connect, we still have enormous potential for alleviating the pain of per-site passwords and containing the damage from security breaches in day to day life.

</comment></comment></comment><comment><USER38> Was picking the name Persona such a good idea when it's so close to Personas, another Mozilla product?

</comment><comment><USER39> I've been sitting around thinking about implementing a user system on my current (and first) website to try and keep people returning to the site to see people responding to their stories etc.

Now I'm wondering whether to use Persona or build it myself from scratch.

</comment><comment><USER40> First reaction: the bland beige looks terrible (maybe that's because I'm not American; I always notice that 1/2 of everything is beige when I'm in the US). Combine that with the name and I'm reminded of the Persona contraceptive device.

</comment><comment><USER41> One thing that I don't get about BrowserID is how it's supposed to work on shared systems / web cafes. There doesn't seem to be any obvious way to log out. The best you can do is 'log me out after an hour', which is crap.

</comment><comment><USER42> Okay, I have read the specs, the FAQ, the diagrams, and tried some examples, but I can't really understand how it works.

Could somebody do a quick summary for me? I would appreciate it very much.

<comment><USER7> I really, really need to post something like this on our blog soon. Watch <http://identity.mozilla.com/> for something more polished next week or so. I'd also strongly urge you to just try implementing it on a site. It'll literally take less than 30 lines each of javascript on the frontend and python on the backend, and it'll really demystify the flow between the site and the user.

As an analogy, we work really similarlu to showing a bouncer your ID. The ID has identifying information on it, and it has features that allow you to know that it's authentic and hasn't been tampered with. The bouncer can learn how to validate IDs issued by many different authorities, and can remember this when he sees other IDs from that same authority.

Our IDs are personal public/private keypairs, signed by the email provider.

So, quick and dirty, here's how we work:

I want to log in to 123done.org as email@example.com, but to do that, I need an ID with eyedee.me's digital signature on it. So in a popup, my browser sends me over to eyedee.me to ask for that signature.

Before eyedee.me will sign a public key with my name on it, I have to prove that I really am who I say I am. It's just between the two of us, so I can prove my identity however eyedee.me wants. It could be a password, an RSA keyfob, or entering a code from a text message. Whatever it is, eyedee.me is happy that I am who I say I am, and they sign my key and hand it back.

I want to show this to 123done.org, but it's not enough for it to be valid, since we have to prevent malicious websites or phishers from copying it and masquerading as other people. For my ID to be a valid login token, I have to add two more things: what site I'm logging in to, and a timestamp so it expires soon after I hand it over. I then sign that with my private key.

I then take that whole bundle and hand it off to 123done.org.

123done verifies it by asking for eyedee.me's public key (which can be cached), and seeing if that matches the first signature on the ID. If it does, then 123done pulls out the validly signed public key, and checks if it matches the second signature on the ID. If that matches, then the whole package is valid, and 123done knows that I really am firstname.lastname@example.com.

Does that make sense? It really just revolves around a document with two signatures: An email provider's which says "This key is associated with this account," and a user's which says "I am associated with that key."

<comment><USER43> So in your example, eyedee.me is your email provider, right?

I made a Persona account just now. All I saw happening was that I clicked on a link in a confirmation email. Was there also communication between mozilla and my email provider? (I am with a small ISP who is serving my emails - I have my own domain, so my email address is sthg like firstname.lastname@example.com). What went on behind the curtains, if anything, and why did it work with my small provider right away?

<comment><USER27> No. The fact that you had to click a link in an email is a workaround. If your email provider did support Persona, you wouldn't have had to do this.

That's the great thing about Persona: it works even when email providers don't support it. However, it works best when they do.

</comment></comment></comment></comment><comment><USER44> What about native mobile apps? Is it possible to easily use Browser ID for native iOS and Android apps? Or is it just too much of a hassle getting the information out of the web view?

<comment><USER44> I just found this <https://github.com/mozilla/browserid-ios> however haven't tried it out, yet.

<comment><USER45> Let me know if you need help with that code or if I can answer any questions in general about Persona integration on iOS.

You can contact me through Github or through the project's issue tracker.

</comment></comment></comment><comment><USER46> <http://mootools.net/forge/p/browserid>

^ adapted from this?

<comment><USER47> That is an implementation of BrowserID :)

</comment></comment><comment><USER34> I really, really like Persona. It's federated and it gives the identity provider a vast amount of control over the security protecting accounts.

Want to use SSH keys for auth? Okay. You can do that.

<comment><USER48> Do you have any links to specifications on it? I'm very interested on identity federation. But the post doesn't give away much info on persona's capabilities.

<comment><USER7> <https://github.com/mozilla/id-specs/>

Pull requests and new issues welcome :)

</comment></comment></comment><comment><USER49> Is there a list of all the sites, besides Open Photo, that have already enabled BrowserID?

<comment><USER7> Mozilla has tons of stuff in production running Persona, so we're totally dogfooding with Bugzilla, Mozpad, MDN, Add-ons Builder, Firefox Affiliates, Firefox Flicks, Mozilla Marketplace, and Mozillians.

Voo.st, OpenPhoto.me, Crossword.TheTimes.co.uk, 5apps.com, Haskellers.com, etc. We're also working to get Persona working with some larger sites, but most of those are waiting to go live until after we formally announce API stability next month.

</comment></comment><comment><USER50> Though this is something helpful, I find Mozilla a little slower than google chrome.

</comment><comment><USER51> EPIC FAIL:

<http://www.freeimagehosting.net/us75p>

This buq with webfonts are reporter year ego and stili NGASF on Windows xp Firefox 13.01 its start on Firefox 4

<comment><USER9> I think you're in the wrong thread.</comment></comment>


We Found an Elusive Hominin in China - <AUTHOR> <comment><USER2> There is no link, maybe it is this one?

[http://blogs.discovermagazine.com/deadthings/2019/05/01/hual...](http://blogs.discovermagazine.com/deadthings/2019/05/01/hualongdong- skull/)</comment>


Court: Bloggers have First Amendment protections  - <AUTHOR> http://www.kirotv.com/ap/ap/social-issues/court-bloggers-have-first-amendment-protections/ncsHX/ <comment><USER2> One step closer to protection from 'infringing on freedom of the press' for online (non-print) journalists?</comment>


Here Comes Another Bubble - <AUTHOR> http://www.youtube.com/watch?v=I6IQ_FOCE6I

<comment><USER2> Maybe angel/vc investing is in a bubble, but the tech sector is definitely not. When you view the graph of the NASDAQ between 1990 and 2000, compared to 2000 and 2010 it is pretty clear to see. The NASDAQ could double within the next year and still be right in line with historical growth rates.</comment>


OpenSSH Security guidelines - <AUTHOR> https://wiki.mozilla.org/Security/Guidelines/OpenSSH

<comment><USER2> This all seems good advice for an organisation with fairly heterogenous client/server populations.

<comment><USER3> Seems also to work if you have only cutting edge SSH (since its split by modern/intermediate) which is nice

</comment></comment><comment><USER4> I set this up on my servers, and not a single Android ssh client was able to connect, or even read the keys generated on another device.

This seriously affects my confidence in the security of Android.

<comment><AUTHOR> The intermediate setup should normally work for you, at least with some clients. Seems ok with JuiceSSH.</comment></comment>


One short curated growth hacking idea a day to your email - <AUTHOR> http://growthhackingidea.com/

<comment><AUTHOR> Found this newsletter not too long ago, tried it out, some actionable stuff in these short emails, wanted to share.</comment>