What did Persona get right? Why did Persona fail to gain wide adoption? - <AUTHOR> https://wiki.mozilla.org/Identity/Persona_AAR <comment><USER2> We use Persona at Microcosm, so you can see it in action on sites such as [http://forum.espruino.com/](http://forum.espruino.com/) and [http://forum.islington.cc/](http://forum.islington.cc/) , just click sign-in and you're there.

For our use-case Persona is great. I've personally built the "web account" solution several times for different clients and I did not want to build it again. Persona is the lightest drop-in and easiest to implement solution you can imagine, and it works extremely well.

We've had a couple of issues, but nothing of significance. Mostly these have been us doing things unexpected, i.e. pre-loading user accounts obtained face- to-face and the case of the user@ part of the email address differing from the Persona provided email address.

I personally also wish that persona.js is added to CDNJS to increase the speed by which it's served.

What we found through asking, was that people feel very protective of their Google, Twitter, and Facebook accounts. They will sign in with them, but there's a wariness of doing so as they do not want to be spammed, have things posted on their behalf, etc. These fears mostly apply when people first arrive on one of our sites. We wanted a lower friction to that initial sign-in, and we feel that Persona gives us this.

We also found that on interest-based communities there is a reticence to associate real-identity to the nerdiest of their interests. This meant that not using Facebook and Google is a good thing in our scenario.

One of the things we like about Persona is the user experience. For our product, simplicity and ease are core goals. Persona helps rather than hinders on this front.

We _really_ like Persona and hope that it remains under active development for a long-time.

We are not of the belief that it's failed, simply that it's a slow-burner and needs some marketing support.

<comment><USER3> My first and only experience with Persona is oddly enough, to log into the Islington CC forum (small world) and I found the whole experience oddly disconcerting. Am I logged into Google or Microcosm? Do I have to stay logged into my Google account? What does firefox have to do with my Gmail account? What is Persona and what do they have to do with anything?

I had lots of questions and none were answered on the nice minimally designed log in page. All of a sudden I'm sent to Google, but I don't want my work account associated with ANYTHING outside of work. Ok, I'm smart, I can just log out and no link will be created. I log in with my personal G account and everything seems ok. But now I have to log out/in again to get back to work.

Why all this trouble? I have a password manager, and it can easily remember another 30 character password. If it gets hacked, the damage is limited to a forum that I occasionally visit. No biggie. But now, everything is linked to everything else and who knows what is happening in the background that I agreed to because I didn't read the small print.

Ok, I'm being a bit dramatic. But personally I don't like services to mixed. That's all it comes down to.

One last thing, you mention that people didn't like associating real identities etc, but the only way I could log in was by associating my real identity from my Google account.

<comment><USER2> Disconcerting, that's not come up in any of the UX testing or feedback we've received recently.

In our earliest version (last summer) we had pushed the "Sign In with Persona" branding but later moved to just saying "Sign in". But that was caught in UX testing and we did change that so that it was clearer (by saying less) that you were signing in to the site you were on (Islington CC).

> the only way I could log in was by associating my real identity from my > Google account

The great thing about Persona is you can use any email you wish to login to something. You can choose to use an email address that is associated with real identity, but just as easily you could've chosen not to.

The advantage Persona supplies is that even if you do choose to use an email associated with real identity, Google (or the email provider, e.g. Facebook) will only see a "Sign in to Persona" event, and will not have additional data revealing that you had signed in to Islington CC (in this case).

Persona effectively acts as a behavioural data firewall that grants you sign- in with email ability, but without leaking your behaviour activity back to the email issuer.

If you have any feedback on how you think we can improve this from our side (the forum software), just email me: firstname.lastname@example.com

I've yet to write FAQ support documentation, and I think you could help provide a lot of the questions around sign-in for me to answer.

<comment><USER3> Thanks for the explanation. Maybe my experience was tainted by the myriad times I've been asking to sign in to a service using Facebook, only to be met with a form asking for my name, email and password. So what was all that FB nonsense about then? So to be fair, the Persona procedure was painless in that respect.

Something that would have been helpful would be a bit more information at the first point of contact with Persona. Ok, so I've just gone to the site and clicked the Sign in or Register link, and the pop-up (ugh) that appears doesn't really explain anything. It asks me to sign in with my email. But you don't have my email yet. What am I signing in to? Is this one of those FB logins where you already know everything about me? And where is the registration page I was promised? I was given a choice, but now one of those choices is gone. There's a bit of a disconnect there.

Soldiering on, if I enter a gmail email then Google's presence makes itself known. Why? Did I accidentally click a bookmark or something? Google wasn't mentioned before. Did I fall victim to a xss attack? No way am I signing in to this pop-up asking for the keys to the kingdom. I know I'm sounding a bit thick here, but I'm 100% certain my mother would've bailed by now.

What is missing is some explanation as to why certain info is being asked for, and will it be shared with anyone. I have the option to agree to T&Cs and a Privacy Policy, but I still don't know why. Yes, I could click on the Learn more link at the bottom of the page, but I don't feel I should have to. I just want to register with the forum.

Anyhow, I'll put chicken little back in the pen because I think I'm being kind of harsh. I applaud services such as Persona, but I've yet to use one that I would compel me to integrate it into one of my websites. If I can think of any more constructive criticisms I'll be sure to pass them along. Cheers!

<comment><USER4> How does something like the following sound?:

For this service, you can sign in with your email address. If you are using one of the supported email providers, you will be redirected to them to finish signup, otherwise you will be asked to create a Persona account. Your email provider will not know which sites you are signing in to, and we won't know your email password or other data.

<comment><USER5> I just tried out the forum.islington.cc registration (without being logged in to Google). The way it redirected me to a Google sign in when I gave a gmail address made me think it was going to end up using OpenID at the back end, something I have never used Google for.

Personally, if I _had_ to register for an account on a site that used Persona, I'd create a special email@example.com address (or something similar) to firewall it from my other gmail accounts.

</comment></comment></comment></comment></comment></comment><comment><USER6> In the spirit of helping out my fellow developers at Mozilla, who I respect a lot, I would like to add one additional cause of failure, in the knowledge that it is a bit bracing but is really important and should inform project selection in the future:

Persona fails to solve a problem which either end-users or people who operate websites for profit actually have.

<comment><USER7> This is just another symptom of what I think is a prolonged stagnation at Mozilla. I suspect they've lost touch with the needs of their users a lot of the time.

Firefox hasn't been in a good place lately. Most of the changes since Firefox 4 haven't been to the users' benefit. It's like these changes have been more about imitating Chrome, regardless of whether or not this is good for Firefox's users. Yet Chrome is still superior where it really matters, such as performance and resource usage. If Firefox users are just going to get a Chrome-like experience these days, but not as good as that offered by actual Chrome, then they might as well just move to Chrome. And I think that's exactly what we've seen, and why Firefox' usage numbers are dropping.

We see the same with Firefox Mobile. It really isn't superior to the alternative browsers in any way. In many ways it's significantly inferior. There's really nothing to pull users to it.

Thunderbird was perhaps their second most useful product, after Firefox. Yet they've basically given up on it now. I know I've migrated to another email client, and many others have chosen to do the same, too, now that Thunderbird doesn't really improve over time. Even then, the changes we've seen lately have been more harmful than good. The UI is less usable now than it was in earlier release, for instance.

Firefox OS is another example. It really doesn't offer anything tangible over Android, iOS, or the many other mobile OSes that already exist and already widely available on many devices. In fact, it offers a very limited development environment compared to the alternatives, which surely doesn't help its case. The only reasons I've heard to use it are ideological, about Mozilla somehow being "more open" or something of that sort. That's just not enough to gain real traction, I'm afraid.

And Persona is yet another example. It just doesn't meet the needs of its potential users.

Rust is perhaps the only interesting thing I've seen coming out of Mozilla lately. But it has taken a long time to get to where it is, and I'm not sure if it still has the momentum to have the impact that it might have had were a stable version available a year or two ago. Go, and even C++11, can now provide a lot of its benefits today, if not much earlier.

I think there's been a lot of wheel-spinning at Mozilla lately, in terms of their offerings. Their successful products are being ignored or actively made worse, while their new offerings don't actually benefit a wide audience, or offer an insufficient amount of benefit.

I'm not going to pretend to know how to fix these problems, but focusing on product that users actually want, and giving these users the functionality they want, may be a good start.

<comment><USER8> > Go, and even C++11, can now provide a lot of its benefits today, if not much > earlier.

The main benefits of Rust are (a) bare metal performance with zero overhead with (b) memory safety, for security and developer happiness. Go lacks (a), with its mandatory runtime, garbage collection, and ecosystem based around a non-optimizing compiler, and C++ lacks (b), with its memory safety problems that are real, pervasive, and cannot be fixed without breaking backwards compatibility. What you said is only true if by "a lot of Rust's benefits" you mean "basically none of its benefits".

It sounds like you are unhappy with some of the user interface decisions in Firefox and are trying to use this story as a way to spin this out into some sort of narrative of Mozilla's decline and stagnation.

<comment><USER7> I can use Go and C++ today without fear that code I write now won't be able to compile next month, due to significant language and/or library changes. The same cannot be said for Rust.

Since I can get perhaps 90% of the benefits of Rust today using other languages that I can actually use seriously, I might as well just use them. Had Rust been more stable in 2012, maybe it'd be a different situation today.

And you can read my original comment again, if the big picture isn't clear to you. I hope it's obvious then that this is far more than just a few bad UI decisions involving Firefox. That is an issue, of course, don't get me wrong, but it clearly goes much beyond that.

Almost all of Mozilla's major projects, from Firefox, to Thunderbird, to Firefox for Mobile, to Persona, to Firefox OS, and even Rust are suffering from some pretty serious detachment from the needs of their users. This is resulting in a decrease in adoption, like in the cases of Firefox and Thunderbird, limited adoption in the case of Firefox for Mobile, or basically no adoption in the cases of Firefox OS, Persona and Rust.

<comment><USER9>
      > Since I can get perhaps 90% of the benefits of Rust
      > today using other languages

Incorrect, unless you're one of the rare few using Ada or Cyclone. Bare-metal memory safety is fundamentally impossible in both Go and C++.

      > Had Rust been more stable in 2012, maybe it'd be a
      > different situation today.

Incorrect. I was there! And trust me when I say that 2012 Rust was very far off the mark. Rust is a language that was designed to be released in 2014, not 2012 or 2006 or 2038.

      > Almost all of Mozilla's major projects, from
      > Firefox, to Thunderbird, to Firefox for Mobile, to
      > Persona, to Firefox OS, and even Rust are suffering
      > from some pretty serious detachment from the needs
      > of their users.

Citation needed. By any estimate, Firefox still has a fifth of all web traffic, with 500 million users. Firefox for Android has between 50 and 100 million downloads and is the highest-rated browser on the Android app store. Firefox OS continues to find new carriers and launch in new territories, which is more than can be said for Tizen or Meego or Symbian or Ubuntu Touch. And even though Rust hasn't even launched yet we're seeing month-over-month growth in traffic on every outlet.

Your narrative really needs some rethinking!

</comment></comment></comment></comment></comment><comment><USER10> I simply don't understand this blog entry. I guess it's their official project resignation... OK. Even so, it seems misinformed about the adoption problems. Persona, to me, seems a truly lovely solution to a difficult problem. It was successful, just at the beginning of a hard adoption curve.

What's missing is fully functional, advertised implementations of the Service Provider, that work with LDAP and ideally older Kerberos backends. What's missing is the native, built-in interface. What's also missing is a SLA... big players can't adopt it unless Mozilla says they are going to support it. What's missing in Persona is a promise to have the code security audited and get it passed federal agencies. What's missing is some grass-roots effort to get it into universities.

What they list as failures aren't exactly. So, there are some UI issues.. but those aren't the problem. The Persona service was meant as transitional, till native implementations appeared. It's not going to adopt itself, they need a "Sales Engineer" full time working on adoption. Hell, they could even _charge_ people for that sales engineer and many would pay for it. The alternative to Persona is Shibboleth/Kerberos, and Persona kicks it.

<comment><USER11> Note that this isn't a blog entry, it's a wiki page. We (Mozilla community) often use the Mozilla wiki as a place to store long-term notes or information.

Barring vandalism (which this isn't), you can think of it as a public internal wiki for Mozilla, that has pretty much everything we're allowed to make public (Unlike HR stuff for employees, which goes on an internal wiki) that we want to write down.

(This doesn't address your argument, just wanted to clarify that)

<comment><USER12> So, to confirm, is it a post-mortem or not? I'm about to launch a fairly big project using Persona and would love to know if its a bit to get shut down..

<comment><USER13> Same!

So far, it seems to me that persona is an incredibly useful technology in our space (Enterprise SAAS apps). Our space is populated by lots of apps that have various shitty login systems, but one thing they pretty much all have in common is an email address - and Persona seems to be a killer SSO system for securely leveraging/livening up these existing databases of email addresses.

Unless I'm missing the point, I don't see much alternative either. Just looking at the traffic from the Persona communit reinforces to me that I never want to be building my own authentication system - even if persona were to die as a project I would be better off cloning it than writing my own (or giving in and using social login, which is pretty undesirable in the enterprise world).

</comment></comment></comment></comment><comment><USER14> I think they're spot-on with the idea that it needs to be integrated into sites rather than appearing as a separately branded popup.

I tried it out on a site I was building a couple months ago. Every time I had a non-"techie" user try it out, they got confused. What's this popup? What's Persona? What am I signing up for exactly? It was just bad UX.

That said, I think there's a very real need for what they're offering. I don't want to store passwords myself, even if they're hashed. I also don't want to re-implement forgotten usernames, passwords, reset emails, etc. It's a bother, I'd rather focus on my app rather than a solved problem like this, and to be honest I don't quite trust myself enough to get it 100% right.

So, I think it would be the best of both worlds to offer auth as an API rather than providing their own experience. As in, I could just call Persona.login("username", "password", ...) and get back an assertion. I really hope they go in this direction.

<comment><USER15> UX is one major problem with Persona. I built a small site that used Persona a while back (without offering any other login choices) and most user can't figure out _how to sign up_.

Facebook login as a separate brand works because user already knows and uses Facebook. This is completely opposite in Persona case. User don't already have Persona "account" and they don't understands why should they sign up for it.

IMO, Persona should aim to replace _classic login_ instead of social login, e.g. by making Persona nearly invisible to the user.

<comment><USER16> _Heartily_ second the idea of Persona being re-rolled as classic login replacement, with emphasis on standardizing login best practices, such as password strength, password format disclosure, input naming that plays nicely with other password management systems, etc. The sheer amount of cruft and non-standardization involved with basic site login actively discourages user involvement. If Persona solved _that_ unobtrusively, they would be adopted and evangelized all over the land.

<comment><USER17> And I'll 'third' the suggestion. Would love to see a SSO option that didn't bleed private info and wasn't linked to someone trying to make money from my data.

</comment></comment></comment></comment><comment><USER18> Could we please consider not implementing something completely new, but fixing TLS client certificate auth, finally making it _usable_? Every browser out there supports this already, but UX is horrendous. All what was relatively polished over the years was the presentation of server certificate when you click on lock icon in location bar. The rest (selection of client certificate, generation of a new one, viewing a backing up of installed ones) remains needlessly scary to use by ordinary humans, so it can't be used except if we know users are quite tech-savvy.

Instead of bringing a new technology with known downsides (like [https://news.ycombinator.com/item?id=7219034](https://news.ycombinator.com/item?id=7219034)) we could give a second life to a known and provably working one. Doing so we could promote security (HTTPS), anonymity (not giving email address by default, unless one's provided with a signed certificate, chosen by user's decision) and independence from any service providers (including email and domain registrars) at the same time.

(Added after an hour) To illustrate my point: [https://www.dropbox.com/s/fn4nuwszt5buuzd/tls_auth_ui.png](https://www.dropbox.com/s/fn4nuwszt5buuzd/tls_auth_ui.png) (mad design skills and windows 8, sorry for both; wording is not changed but I suppose it needs improvements, too)

</comment><comment><USER19> I rejected Persona out of hand at the time[1] for the design gaffe of using HTTPS at the root of a corporate website[2] (worse, via a _DNS apex A record_ [3]) as the identity-provider infrastructure discovery mechanism.

I haven't reviewed the protocol since maybe a year ago, but my view then was that system administrators within enterprises could only adopt Persona as identity providers if federated discovery was via records in the DNS, as the lords of protocol design intended, preferably SRV records at that.

Not the only barrier to adoption, perhaps, but definitely one of them. No-one substantial was likely going to use anything but the Fallback server, and there is no commercial reason to choose that rather than social-media-SSO where you'll enjoy the marketing bonus of reaching their outbound feed.

[1] [https://news.ycombinator.com/item?id=5447097](https://news.ycombinator.com/item?id=5447097)

[2] a !! blunder because marketing won't let you in many organisations. also because most sites won't even have a port 443 https listener, let alone a valid certificate, on the apex A record. all this indicative of lack of real- world experience by the designers.

[3] a !!!! blunder see e.g. [https://devcenter.heroku.com/articles/apex- domains](https://devcenter.heroku.com/articles/apex-domains)

<comment><USER4> DNS is a good option, but you'd need DNSSEC, which not many people have.

<comment><USER19> Persona is already using DNS for resolution, just very badly.

I just went looking. There's a whole thread over here: [https://github.com/mozilla/persona/issues/1523](https://github.com/mozilla/persona/issues/1523) & [https://groups.google.com/forum/#!msg/mozilla.dev.identity/d...](https://groups.google.com/forum/#!msg/mozilla.dev.identity/dP44TDzBnhI/3MijAKI1oR8J) where the developers effectively shitcanned the idea of using SRV records because they fear DNSSEC. Hilariously ignoring the huge elephant in the room viz. that they were already relying on DNS to resolve endpoints.

The verification, the trust, comes from TLS with a valid cert, and that doesn't change, however you located the https listener in the first place.

Even better, though, if you did use DNSSEC you can validate a self-signed cert via DANE/TLSA rather than having to buy one from CrappyCA. And that would make the ISPs _very_ happy.

<comment><USER4> As I explained in issue 1523, the above is misunderstanding Persona and conflating various issues, and is wrong. Pretty much the only way Persona uses DNS is to perform an A lookup to get the user's domain, which could be SRV (or have an SRV fallback instead).

The issues above talk about delegation, which is a whole other matter.

<comment><USER19> No, that is exactly what I'm saying. It should be an SRV lookup to find the support document. This solves a lot of problems. No misunderstanding here. You may actually be in total agreement with me.

<comment><USER4> I am in agreement with you, but the misunderstanding is about DNSSEC, etc. The only reason SRV records are not used for that is probably that nobody suggested it (it's a good idea, you should probably open an issue).

</comment></comment></comment></comment></comment></comment><comment><USER20> Lack of promotion. Most people don't know what is it. Possibly this will improve over time.

Also, why are you guys talking about Persona in past tense? sounds like you're dropping the project.

<comment><USER4> I agree with the first part, and was also puzzled by the second part. Are you guys dropping it? I don't think there was enough of an effort made to consider it a failure, creating a new login system for the web won't take three months.

</comment></comment><comment><USER21> Another point. Not everything is web-based (I know it might be hard to believe at Mozilla), and the fact that you have to use javascript to access the API is also a limiting factor.

<comment><USER22> This is a service _specifically_ for web based applications.

Most, if not all users have JavaScript enabled. The ones savvy enough to turn it off, will also be able to turn it back on.

<comment><USER23> When I first looked at Persona/BrowserID eons ago, there were non-web ways to use it. I remember some examples given that worked in a terminal or with an embedded device.

</comment></comment></comment><comment><USER24> I really like Persona. I use it (with the browserid gem for sinatra) for a couple of my side projects, as the only login option. It works great when it works and developing without having to bother about password management is great, though I first had to get my head around how that concepts works, serverside, that I have to remember an email address of a user in the database to assign him special rights (example: admin of a blog). What I didn't like, though granted, some of that is not very universal:

1\. I made a small user test with it, and all user failed to complete the login, iff the email was new to persona. Because then, the new account has to be activated by email, and the link in that email lead to the persona account management. All users were confused by that and asked for confimation what to do, when confronted with the email confirmation message, and all of them got stuck in the new tab with that account management and were unable to return to the registration page on its own.

I understand that it is possible to change that link, though I didn't find that parameter at that time and marked it as an issue to fix later (A quick search just now showed nothing). And it might be a gem thing. Still, bothered me.

2\. I would have loved a demo mode that works offline (maybe that exists?). Had spotty internet for a while and it was very bothersome to test the persona part of the project, as the registration/login worked only every 10th time, if at all. That was so cumbersome that I stopped working on it till I got a better connection. Which also means that a user with a bad connection won't have fun with persona, not resilient enough.

3\. I don't like that the name was used for another FF-Project before (FF- designs, if I'm not mistaken) - if that confused me at first, it might confuse users. Have no better alternative though (maybe I would just brand it _Email Login_ ).

4\. The browserid-gem for sinatra doesn't work with ruby > 1.9.3, and the maintainer does not fix the issue even though there is a working patch in a pull request. So instead of just having to specify the gem in my gemfile, I have to provide the link to the alternate github implementation. I hate that, that does not feel safe. I tried to look up how a gem might be replaced with another one and found nothing about how that (or the gem infrastructre in general, note that this was while having no really usable internet connection) work.

</comment><comment><USER25> The page is more positive than the title. It recommends:

* Persona should be pared down to its core: a decentralized email verification and login API for the web. No more session management, no attribute exchange. * Persona should be built natively into Firefox, Fennec and Firefox OS to make the JavaScript shim unnecessary on these platforms. The base functionality should be cross-browser, but the experience should be optimized for the native platforms. * Sites should control most of the user flow and Persona should be almost invisible to users. * Sites should be able to offer these benefits to their users with a native UA implementation: better UX, reduced login friction and phishing protection.

All of which sound great!

BTW, has Persona reached 1.0 yet? Last I was aware, it was still in beta, which might partly explain the lack of adoption.

</comment><comment><USER26> It failed to get wider adoption because the average consumer doesn't see the problem they solve as a problem. There's a far small potential userbase who recognize the privacy benefits of the Persona system.

<comment><USER27> I don't think privacy is the main problem they solve, but the user's need to skip the tedious signups all the time.

<comment><USER28> Which they can already do with accounts they most likely already have: Facebook, Google, Twitter, LinkedIN any OpenID provider... So the only potential benefit of Persona is the privacy, and if a user doesn't care about that then it's just another account you have to worry about (i.e. the very problem it tries to solve). As it stands, Persona's problem is that it just reinvents the wheel with slightly different spokes when people already have wheels that they consider good enough.

</comment></comment></comment><comment><USER29> What did it get right? It can be useful and it's backed by a solid brand.

Why did Persona fail to gain wide adoption? For the most obvious reason: because nobody cares. People don't want to use something new unless there's a pressing reason. Trivial conveniences don't cut it.

</comment><comment><USER30> Because it's Yet Another Pointless Single Signon.

I don't see the point compared to having separate logins so if one is compromised, others aren't. Even past that, that space is already hugely cluttered with OpenID, OAuth, Facebook, Gmail, Twitter...

Persona is a solution in search of a problem.

<comment><USER31> I hope I'm wrong but Firefox OS feels similarly to me so far.

<comment><USER30> Firefox OS seems like a joke, and I'm sure it only being on low-end Chinese phones reinforces that.

</comment></comment></comment><comment><USER32> "We made Persona a user-visible brand but that competed with a site's own brand."

This would indeed have been the main reason for me not to use it. I have not been in a position to implement login functionalities recently, but when I do, I will still strongly consider Persona, and even more so if the Persona brand can become almost invisible as it says in the post.

</comment><comment><USER33> I have hard times explaining the added value of Persona over OpenID. It's just the privacy and even tech people don't see that as a point.

So I searched on Google, and this probably didn't help Mozilla: [http://security.stackexchange.com/questions/5323/what-are- th...](http://security.stackexchange.com/questions/5323/what-are-the- downsides-of-browserid-persona-compared-to-openid-oauth-facebook)

</comment><comment><USER27> I was put off by the name. BrowserId was an OK name, but FirefoxId would be better, to leverage the good name of firefox in the user's mind.

<comment><USER34> Definitely. Persona sounds too Personal.

<comment><USER35> It's also confusing branding because Mozilla used to refer to browser branding as "personas".

</comment></comment></comment><comment><USER36> How about

* we didn't give some people a way to join?

I don't know whether it is my Internet disability manifesting, or some kind of weird region limiting or sth., but in last 6 months I tried to create a "Persona account" several times, followed the instructions precisely, and always ended up with a nonexistent "register"/"create account" button.

Was Persona account creation disabled at some point in time? Why wasn't it clearly stated anywhere on the page? Or am I _that stupid_ and can't see a register button?

<comment><USER11> This highlights another one of the problems, which was explaining what Persona was to people.

See, there's _technically_ no such thing as a "Persona account". Persona is a system that lets you log in with an account that works with the system. Someone who provides an account that supports Persona logins is called an Identity Provider, or IdP.

However, most places don't work with the system when it first comes out, so Mozilla provided a "Fallback IdP" that just did straight up email verification. Getting your account from the Fallback IdP is what you probably wanted to do, and AFAIK the only way to do that was to essentially attempt to login with an email that didn't have an account with the Fallback IdP, which would trigger the verification step for you to create an account.

This is a bad mixture of a) A confusing concept that's really hard to explain, and b) Bad UX around the fallback IdP and getting an account with it, especially if you don't assume clicking "Sign Up" will work for you.

It's complicated by the fact that, if one of your goals is to get other login systems (like Facebook or Google) to support Persona as an IdP, you don't necessarily want to push people towards creating accounts with the fallback.

It's hard to get all these things right, and I agree that Persona needs some more work to find a good solution to the problem of creating accounts that work with Persona.

<comment><USER17> You hit the nail on the head here. I'd add that if part of persona's success is tied to getting email providers to adopt it by becoming an IdP then it's likely a flawed model. Why would google support/promote something that competes with Google+ sign up bit offers a poorer ux and robs th of the data they crave?

</comment></comment></comment><comment><USER37> Users are very much accustomed to accepting the security and privacy implications of conventional web logins. Persona promises to improve on that by introducing itself as a third party. However, users with a trace of security awareness will be skeptical of promises like that and will subconsciously do a simple equation in their heads: if everything else fails (the promised improvements), then more involved parties imply less privacy/security. Getting beyond that point requires at least a level of understanding that allows for a rough estimation on a scale between "totally bogus" and "this might actually work if done right".

</comment><comment><USER38> I never even knew what it was, because I confused Mozilla Persona (some authentication thing) with Firefox Personas (themes for Firefox - note the s).

</comment><comment><USER39> I'm not sure why I don't see other people complaining about this but I myself tried to be my own Browser ID provider and after trying to install it for a couple of days I failed. Now I still have to use it with Persona which is just another centralized login system.

</comment><comment><USER40> When Persona was released, they split the FOSS crowd between OpenID and Persona adoption. Having two similar tools that solve the same problems (regardless of which one is better) did nothing beyond create two incompatible camps, each advocating for one while discouraging adoption of the other. I see it as a rather large blind spot of Mozilla to not recognize this.

As an administrator, I would also like to complain about this behavior from a practical viewpoint. Spending first mindshare and time implementing OpenID to solve a real problem, Persona came like an unwanted alternative to a solved issue. Had they joined like an upgrade (i.e. backward compatible with OpenID), my reaction would to be an advocate rather than skeptic.

<comment><USER4> When Persona was released, OpenID is already dead. I implemented OpenID on a few sites (I was an early proponent) and had nothing but trouble. Nobody could remember their OpenID URL, whereas everyone knows their email address.

</comment></comment><comment><USER41> Tried to register on forums posted here as an example of Persona integration. Have gmail email, so no password authentication (OAuth or OpenID instead.) Did not work due third-party cookies blocked in my browser. Sorry, this is not going to work for me.

</comment><comment><USER42> "Users and developers trust Mozilla and want us to fix identity on the web."

Maybe it's just me, but I trust iceweasel, a firefox derived browser that originates from Mozilla, but their continued increased interest in accumulation of browser and user data (albeit more anonymized than google et al), does not lead me to trust them.

I accept persona is designed to protect against id-provider leakage, but when my id provider also has hooks to my browsers anonymous statistics and crash logs - I don't accept it's really private or trusted. (Same reason I don't login to chrome either...)

<comment><USER43> Your viewpoint is almost certainly in the minority here.

</comment></comment><comment><USER44> I don't find Persona compelling, but I do think they offer an interesting value proposition for people - and framework developers - who have to implement their own user authentication.

Even Django - which is about as close to the proverbial bicycle with training wheels as you can get - can be a pain, especially after django-registration was abandoned. The Django documentation was never really good either, to make matters worse.

It also makes writing guides that much simpler, so although Persona doesn't hold much sway in a vaccum, it's great to have as a pragmatic option.

</comment><comment><USER45> what would make Persona a killer solution for me is if it could hand out disposable email addresses to every site I sign into, that forward transparently to my main address (a la Gishpuppy). This way, I can identify which site is the cause of me suddenly receiving a bunch of spam (whether they're doing it themselves or their email database was hacked). Then its a simple question of disabling that disposable address from forwarding to my private one, and notifying the site that their database might be exposed.

</comment><comment><USER46> Wait, is this a postmortem as in Persona is being discontinued?

<comment><USER47> It sure reads like that. What the heck‽ It is a good system and just needs continued work and support. This is a very poor way to announce a discontinuation or a very poor writing style for a reflection on an ongoing project.

</comment></comment><comment><USER48> So I want to use Persona. So I go to [https://login.persona.org/](https://login.persona.org/) and there is no "Sign Up" just "Sign In". So I enter my email which is through GMail and it is asking me to choose one of my Google Accounts.

1: I want Persona not permission to use my Google Account with another service. 2: I entered an email why would I want to use a Google Account with a different email?

<comment><USER23> 1\. It's decentralized; email providers provide the authentication. Google doesn't directly support Persona right now, so Mozilla is supporting them via an Identity Bridge that hooks into Google's OAuth functionality. Google doesn't see what site you're signing into, just that you logged into a thing using Persona. Before Identity Bridges, you had to click a verification link in an email; this is a lot better.

2\. I don't think Google exposes a way to use OAuth and skip past the list of accounts.

</comment></comment><comment><USER49> As a FORMER firefox developer (add-ons), I think my reasons for persona not taking off are as follows:

1\. value proposition for developers was never clear

2\. many saw it as a firefox only thing

3\. chrome usage is overtaking firefox

4\. I felt burned by developing for firefox in the past, why was I going to do it again (this is me personally, and is likely my #1 reason)

5\. Never saw how it simplified my users lives.

6\. I saw it as another waste of time like openID ended up being (and I loved the idea of openID, but so few people ever used it).

/rant

</comment><comment><USER50> The session management Persona does is a pain. It's great for single-page apps and awful for traditional web apps.

<comment><USER51> It does seem inelegant that I can't seem to avoid having _two_ sessions: Persona's and whatever I have for my site. I'm not sure how the two ought to be combined, or even if the Persona session is necessary. I guess maybe Persona can just confirm the email association whenever the site requires it and just stay out of the loop otherwise.

</comment></comment><comment><USER52> It is really great that they have guts to admit the failure. Though this confession is a bit overdue, I hope they've learned the lesson and some day will come back with a better solution. No doubt that the problem is really worth solving.

</comment><comment><USER53> I use it on several sites, and it works quite fine, The problem is with users they are so used to registering with "omgonies/1234568" into sites that federated login is weird to them

<comment><USER54> The right way to solve problem of disposable logins on your site is to support anonymous access for everything that registered users can do.

</comment></comment><comment><USER55> Is Persona dead? Why does the post say "did fail" instead of "has failed (so far)"? The latter would imply that ongoing efforts will be made.

</comment><comment><USER56> make it work with oauth, then at least i can support it without redoing my entire session system.

</comment><comment><USER57> I really hope it works out. So easy

</comment><comment><USER58> for the record the main reason for adoptions issues around me seem to be: i got a fb/googke/twitter account that let me login too. i aint making a new account/pass. privacy? i care but not enough for that

</comment><comment> chris-at Does Persona support native iOS/Android apps? And if not, why?

</comment><comment><USER59> A classic case of less is more (or better).

<comment><USER60> not really. the biggest problem was no adoption from larger sites, while most of them offer facebook login...

quote: We looked at Facebook Connect as our main competitor, but we can't offer the same incentives (access to user data).

<comment><USER6> That quote is _alarming_ to me, because it fundamentally misunderstands why companies choose to use Facebook Connect. Absolutely no B2C company in the Valley has ever decided to use Connect because it lets you slurp in demographic information. They do it because of a) a mostly mistaken belief that it increases conversion rate to a signup and b) a mostly accurate belief that after you get someone to Connect you're going to be much, much more successful at getting your content on their wall as a viral distribution mechanism.

<comment><USER60> your second point is almost the same as the quote but worded differently. access to user data and/or easier access to their fb wall...

</comment></comment></comment></comment><comment><USER61> Sounds like persona should have just been a trusted oauth2 provider.

</comment><comment><USER62> What was Persona?

<comment><USER63> Firefox themes I think.

<comment><USER21> Nice one. Not sure if trolling, but for the record:

\- BrowserID has been renamed to Persona

\- Personas have been renamed to Firefox themes

Yup.</comment></comment></comment>


Spring Boot Application Deployment as JAR and WAR on CPanel Server - <AUTHOR> https://www.jvmhost.com/articles/spring-boot-deployment-war-jar-shared-cpanel-server/ <comment><AUTHOR> We build proof-of-concept JAR and WAR Spring Boot application and show how to run it on shared cPanel server using any of our Java hosting packages.</comment>


.NET Micro ORM Review - FluentData - <AUTHOR> http://www.codecognition.org/2013/03/micro-orm-reviews-fluentdata.html

<comment><USER2> Exhibit A: Yet another proof for having three obligatory pieces of software for every beginning programmer: an ORM, a blog engine and a CMS.

On a more serious note, FluentData is a wheel reinvented, square. PetaPoco anyone?

<comment><USER3> There are several micros (I'm sure you know) but I love the micro, micro approach of Peta. I'll admit that up until recently, I've always setup my own classes with data myself. Looking back on projects, it actually hasn't been that bad. These are medium sized applications and, yes, setting up properties is super annoying and can take a while but, in retrospect, it hasn't cost me that much really, I don't see how I could save more than a few hours with an ORM and I have 100% control over my database interactions, code separation, complete knowledge about exactly what it is doing, and a fast application.

I like Peta because it's the smallest most minimal ORM I've found. I can grasp most of what it's doing after little work with it and it's fast enough for me though I'm definitely not pushing it too hard.

</comment></comment><comment><USER4> I've fallen head over heels for (Perl's) DBIx::Class and it's ability to "prefetch" joined data[1]. In short, it will populate the top level objects, as well as the items they join to from a single query (yes the DB will have to send duplicate info). I find it really convenient.

Recently I've wondered what other ORMs support this feature or something similar to it. Anyone care to comment?

[1] <https://metacpan.org/module/DBIx::Class::ResultSet#prefetch>

<comment><USER5> It sounds like what you're referring to is something I know as eager loading[1]. Most good ORMS have this e.g. Django[2], NHibernate[3], Rails[4]. The 'select N+1' problem[5] is fairly common.

[1] [http://stackoverflow.com/questions/1299374/what-is-eager- loa...](http://stackoverflow.com/questions/1299374/what-is-eager-loading)

[2] [https://docs.djangoproject.com/en/dev/ref/models/querysets/#...](https://docs.djangoproject.com/en/dev/ref/models/querysets/#prefetch- related)

[3] [http://nhforge.org/blogs/nhibernate/archive/2008/09/06/eager...](http://nhforge.org/blogs/nhibernate/archive/2008/09/06/eager- loading-aggregate-with-many-child-collections.aspx)

[4] [http://guides.rubyonrails.org/active_record_querying.html#ea...](http://guides.rubyonrails.org/active_record_querying.html#eager- loading-associations)

[5] [http://stackoverflow.com/questions/97197/what-is- the-n1-sele...](http://stackoverflow.com/questions/97197/what-is- the-n1-selects-issue)

<comment><USER4> Ah, that's probably a much easier term to google. Part of the problem always seems to boil down to terminology. :) I figured it must be present in other ORMs, it seemed _way_ to useful to not be pervasive.

It looks like select_related is the equivalent Django method to what I'm referring to in DBIx::Class, although prefetch_related (which you linked) looks superior in many respects. I'm fairly certain DBIx::Class allows a similar method to prefetch_related, but it may or may not be automatically done. I know it supports object caching, so it shouldn't be to hard to achieve in a few lines (but automatic is nice).

Interestingly, I don't see a way in Django to specify complex select fields to be included along with the default fields for a record. In a simple case that can be used to get a count of something, in complex cases it could be used to actually compute something on the DB to group and/or limit by (group by having). I'm probably just not familiar enough with QuerySets from this small bit of exposure to work it out.

NHibernate... That's a lot of code for something that should be simple. I imagine that's for explanatory reasons, and that much code isn't needed for most queries.

</comment></comment></comment><comment><USER6> What's the point of this when you have EF?

<comment><USER2> Doesn't it suck?

<comment><USER7> No, Dapper does not suck. I too have been using Dapper at our company recently and its been an incredible boon to our db performance and code readability.

Plus, if its good enough for the Stack Exchange team, then its plenty good enough for me.

<comment><USER8> The "Doesn't it suck" comment was not directed at Dapper.

<comment><USER7> Whoops! Sorry for the misunderstanding then. I was using the Hacker News+ Chrome extension and it nested the comments incorrectly...</comment></comment></comment></comment></comment>


ASK:Help needed on developing web widgets - <AUTHOR>

hi,
I need links to information on how to develop web widgets using html, css, dom and ajax. thanks. I am really stumped here. <comment><USER2> I think your best bet is to break it down into small (very small) problems, to try to tackle each one, and to ask questions _about specific problems_ on <http://stackoverflow.com> when you get stumped.

</comment><comment><USER3> How far have you got, what's your developing background? What sort of widget, what deployment are you aiming for?

Is this a homework assignment?

<comment><AUTHOR> This is a side project of mine, and not a homework, my main stay is python/web2py framework. I am thinking along the lines of a web widget.</comment></comment>


Google +1 tracks mouse movements? - <AUTHOR> http://stackoverflow.com/questions/6667544/why-does-google-1-record-my-mouse-movements

<comment><USER2> According to the link, this is being used as a source of entropy to generate random numbers. Fascinating.

<comment><USER3> Hah!

That's so simple, yet so brilliant.

<comment><USER4> Mouse movements have been long used as a source of entropy in desktop applications.

<comment><USER5> Indeed. Putty's keygen thing has been using it for quite a long time for example

<comment><USER6> /dev/random too :) [http://www.mail- firstname.lastname@example.com/msg01708.htm...](http://www.mail- email@example.com/msg01708.html)

</comment></comment></comment></comment></comment><comment><USER7> I'm not sure how often research papers reflect reality, but Bing may be doing this as well, according to this Microsoft Research paper: <http://jeffhuang.com/Final_CursorBehavior_CHI11.pdf>

<comment><USER8> This is a very good paper, but it seems to approach mouse tracking specifically from the search perspective. Perhaps not extremely pertinent, but still super interesting.

</comment></comment><comment><USER9> Google Analytics does it too, which makes approx. 85% of all web sites you visit.

<comment><USER10> adblock'd sites dont do it :)

</comment></comment><comment><USER11> cute, but surely there are less intensive ways of generating random numbers?

<comment><USER12> I've always been a fan of using electronic noise. It's not complicated to build a device which does this. Weekend project to "hello world" scale if you're not too picky about specifics.

Easiest way is probably with a webcam, which will also give you a pretty good bitrate. The general schema is to read out the bias noise. You do this by blocking out any incoming light to get dark noise + bias noise. Dark noise is an assumed static shift due to CCD characteristics, so read N frames of this and look for the median signal. Subtract that off and you've got the bias, or at least something that's close enough for a weekend project.

Better version, start reading up on the math of noise sources in whatever device you want to use for a sensor. Also do an analysis of N samples to see how close the result comes to the expectation value given the type of noise involved and what deviation is expected at N samples.

<comment><USER13> There's no way to deploy this over the web, unless you use Flash to acquire their webcam video or audio.

<comment><USER12> Packet latency, for example.

The general idea is that there are many noise sources which technology normally needs to route around. To find random number sources, you reverse this.

<comment><USER14> Even something as simple as packet latency is really hard to get from JS. the timing functions you get from the browser are way too low resolution. Also the only network latency you can test for is doing an xmlhttp request as that's the only way o do any network communication (minus web sockets which arent generally available)

Aside of that, you get no direct hardware access to measure and even if you would, there is still the timer resolution problem.

Very recent browsers provide an API to get strong random numbers, but this is even less widely available than web sockets.

So either you take the mouse movement or you use something like Java or Flash, or you use bad numbers.

<comment><USER15> > * the timing functions you get from the browser are way too low resolution.*

The JS time function returns epoch milliseconds, not seconds. At the scale of network latency (hundreds if not thousands of milliseconds), the lower order bits should be effectively uniformly distributed. Resolution isn't your problem, the number of usable bits per network call is.

<comment><USER14> The problem is that the JS engines in browsers rely on not-so-sophisticated APIs to get to their millisecond values. This means that yes, you do get time in milliseconds, but the value is only updated every 40 to 100 ms

<comment><USER16> I think some browsers on Windows are using QueryPerformanceCounter for timing, which has microsecond precision.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> Seems like overall, it's definitely code to help thwart gaming of the +1 system, as there is already a cottage industry that offers (presumably) automated +1 clicking services for money.

</comment><comment><USER18> <http://www.ghostery.com/> prevents it

</comment><comment><USER19> Does the emperor wear any clothes?</comment>


Japan's purple machine [pdf] - <AUTHOR> http://ovid.cs.depaul.edu/Classes/CS233-W04/Papers/PurpleMagic.pdf <comment><USER2> Is that some student report, or a class handout, or what?

The classic work on this subject is "The Man who Broke Purple", a biography of William Friedman. Friedman is probably the greatest name in cryptanalysis. He changed the field from guessing to crunching. (See page 301 of [1]. That's where modern cryptanalysis began. Explanation at [2].) He was also the founder of the National Security Agency.

[1] [http://marshallfoundation.org/library/wp- content/uploads/sit...](http://marshallfoundation.org/library/wp- content/uploads/sites/16/2014/06/Methods_II_watermark.pdf)

[2] [https://en.wikipedia.org/wiki/Index_of_coincidence](https://en.wikipedia.org/wiki/Index_of_coincidence)</comment>


Show HN: Trolley lets you take payments from your static site - <AUTHOR> https://trolley.link <comment><USER2> My $.02 FWIW:

\- Your 2% on top of Stripe's fees is off the charts IMO. Stripe charges $.30 + 2.9% and they're taking care of the actual payment. You're merely making it simpler to insert a button.

\- The difficulty in practice isn't creating a button to make the payment; it is what happens before and after the payment. Offer to host and automate the delivery of the access-restricted deliverable when it's digital (ebook, software, etc.). Work with Zapier and similar to offer integrations on their end. Provide your users with a way to run their own affiliate program. (Charge extra for that.)

<comment><AUTHOR> Hi Thanks for the feedback.

Inserting a button is part of what Trolley does.

But really what it's doing is stopping you having to build / host the back end server and code that handles the tokenised payment exchange for Stripe (Stripe - and all other similar payment processors _require_ there to be some non- front end code to handle secure token exchange)

So I'm hoping that 2% works out better than managing a server and potentially hiring a developer to build you some code if you can't write it yourself :)

I'm still feeling out prices... 2% was the starting point because it's in line with services that sort-of compete (Celery, SnipCart and so on)

Totally take your points about digital asset delivery - it's on the backlog.

Thanks again!

<comment><USER2> Having done this a few times, integrating a payment processor you're unfamiliar with to a site takes a few hours when they don't provide a library and you're doing it for the first time. I might have misunderstood what you're offering, but to me it sounded like you were basically providing that as a hosted service.

Stripe's API is reputably simple, and Stripe provides ready-made libraries to make your job even simpler. I can't imagine for a moment that using the ready- made library Stripe provides on Github takes more than an hour or two. So you're basically talking about a $10-50 job depending on how generous you feel when hiring an online code monkey or an adolescent down the street to do it for you.

Free + 2% might work for some non-technical user who wants to experiment with selling a product _right now_ without investing a penny. It won't the moment the idea takes off. You'll immediately look for something with a monthly recurring fee.

The reason breaks down to psychology. When you sell a lot of stuff online, you only see the monthly recurring charge _once_. The transaction fees, by contrast, will be all over your statement. Sooner rather than later, you look at each and every single one, thinking: "Sigh, so much money being spent on this... Why am I paying for this again? Can't I use something else?"

As an anecdote to illustrate the point further: where I live, banks charge a tax on transactions, and what essentially amounts to a tax on paying that tax to boot. It's tiny - under .1%. But cash transactions are, as you'd expect, commonplace - including for things like buying houses.

At any rate, what I'm trying to get at here is that unless you're delivering something on top that is valuable enough to retain your users, you'll only be attracting users who are looking for a _temporary_ solution to experiment with an idea. I'd expect them to churn the moment they see enough transactions that your extra fee associated with each one will prompt survey cheaper alternatives.

One such value, by the way, is having most if not all of the things you want to use in one place, or good APIs and integrations to be able to use the 3rd party tools you want. This matters a lot too in practice.

Maintaining and integrating several different poorly written self-hosted apps to run the cart, billing, delivery, affiliates, accounting, a few types of analytics, etc. is grueling. Integrating multiple hosted tools to do the same is also grueling - but less so, and it doesn't involve much maintenance. Being able to use new apps and services Zapier-or Segment-style is, by contrast, not grueling and extremely valuable.

Anyway, good luck with your project!

<comment><AUTHOR> Thanks - that's good and well-reasoned advice.

I'm iterating rapidly on the idea - and in particular I'm happy to talk to customers about pricing plans that aren't currently listed on the landing page (if that means fixed fee and no transaction cost then that's doable)

tbh I'm not sure that Stripe appeals to the most cost-conscious entrepreneurs, and right now I _am_ targeting those who want to test ideas rapidly, and who are likely to then find time / money to build out their own integration (which will mean I have a high degree of churn if I don't adapt. That's fine, it's all learning!

Again - thanks for all the time you've spent replying. Good luck with your project(s) too :)

</comment></comment></comment></comment><comment><USER3> Just my feedback: The 2% transaction fee on top of Stripe is a big turnoff for me.

My main use would be selling digital files via Stripe (ebooks, etc). Other services like getdpd.com offer that as a cut-and-paste button for static sites at a fixed monthly price plus they handle hosting and delivering the files to the customer for that same fee.

I'm not saying you need to try to target the same niche, I'm just offering one potential customer's feedback :-)

<comment><AUTHOR> Hey That's good feedback, thanks.

I'm definitely happy to talk to potential customers about alternate pricing models....

Basically the fee is a % field in the DB, if I wanted to reduce it, or zero it and work through invoicing or direct payments for individual customers, that's cool)l with me.

If it's of interest, drop me a line on firstname.lastname@example.com and we can work out a model that's better for your use case.

<comment><AUTHOR> (I'm already looking at digital downloads as a feature, too :-)

</comment></comment></comment><comment><USER4> Just a suggestion, place a demo pay button on the homepage so visitor can know what it looks like without registering an account. Might probably gain more interest and conversion rate.

<comment><USER5> Also, what options are available on the backend? Will the buyer be asked for a billing address? Can I turn this off? Can they be asked for a shipping address? What happens when someone buys something? Do they get an email? Do I get an email?

I'd consider answering these questions either as documentation that goes through all of the options available on the backend and/or as a walkthrough of the complete process from signing up to getting an order. A demo Trolley account that's set up with a Stripe test key wouldn't be a bad idea either.

<comment><AUTHOR> You're quite right. We're working on a demo setup :)

FYI though - yes, you can choose whether to collect billing & shipping info at a per-product level.

The buyer and seller both get notified by email (and if you have the Stripe app as a seller, you'll get a push notif). The charge gets fully logged in the seller's Stripe account, with all metadata (so if you ever disconnect Trolley you don't lose anything about your customers)

</comment></comment></comment><comment><USER6> Sorry to hijack, but I've long had this idea, and possibly offer it to people here for stealing, but mainly want feedback on whether it'd be worth implementing:

You, the creator, make some content available for download. You only require the visitor to give you an email address, optionally requiring validation. The visitor then downloads and consumes the content. After some amount of time, configurable by you, the visitor gets an email saying "hey, if you enjoyed my content, please click here to pay me the recommended $X, or ignore this email to be notified later, or click 'no thanks' to never be notified again". Basically, paying after the content was consumed, but not so much later that they've forgotten about it.

What does everyone think?

<comment><USER7> I think it's a nice idea that would lead to very little revenue for the creator. You're making it easier to get the content free than to pay for it - is that the intention?

<comment><USER6> It's for content that's free/pay what you want. Not for content that's already behind a mandatory pay wall.

</comment></comment></comment><comment><AUTHOR> Maker here...

I designed this to be a simple Stripe-backend-as-a-service for people who want to take money fast without having to roll any backend code.

e.g. landing pages that take a deposit for your product (KickStarter style)

<comment> p-ross Looks sweet, what are the key differences between this and Stripe Checkout? [https://stripe.com/checkout](https://stripe.com/checkout)

<comment><USER8> Correct, I immediately thought of Stripe Checkout, which is very nice.

<comment><AUTHOR> Checkout is great - but it'not enough to sell online on its own (I think my comment above that explains this posted just after yours, so you may not have seen it :-)

Trolley requires and uses Stripe Checkout, but it's there to make it easier and faster to sell - especially if you want a static HTML site - than checkout alone.

</comment></comment></comment></comment><comment><USER9> My $.02: I am surprised people are so aversed against the idea of browser based micropayment. I think that's the one component missing from the internet; which could also save us from Amazon and ads. And make content creators richer. (No, Paypal does _not_ count; for obvious reasons and too many clicks … 2?4?)

</comment><comment><USER10> This looks really good.

Few questions:

1\. Would this be able to support subscription/recurring payments? E.g. for SaaS.

2\. Do you have a versioned release of the JavaScript file so that Subresource Integrity (SRI) can be used?

3\. Could you document the origins that the JavaScript file loads content of different types from, so that it would be easy to lock this down using a Content Security Policy?

Thanks.

<comment><AUTHOR> Great feedback, thank you!

We don't support subscriptions today - but we're actively working on it. Single-item payments is our MVP but subscriptions are next.

Documentation is .... um, "light" at the moment.

Right now, you should be able to use connect-src,img-src,script-src all "[https://svr.trolley.link"](https://svr.trolley.link")

We also depend upon Stripe Checkout, so you should add the attributes for their stuff too ( [https://stripe.com/docs/security](https://stripe.com/docs/security) )

Don't have a versioned release right now, which is a gap. Thanks for pointing it out, I'll sort it :-)

</comment></comment><comment><USER11> This is a neat idea. I work with 250 caving clubs that each have individual websites (generally wordpress) and need a way to collect annual membership dues and one time donations.

Most of these clubs have been around for decades, are not growing fast, but have a small very engaged membership. The only time these clubs work with developers is if a member happens to be one and volunteers the time. This really sucks for the member who happens to be the developer. (I stop telling people I can build stuff.)

Most clubs are collecting cash or check in person and at best are using Paypal which sucks because of the off-site experience. I would never set a club up with Stripe because I know if I leave no one will be able to maintain the code, but I would try this out.

</comment><comment><USER12> Nice, but there are better options.

Use flatmarket:

[https://github.com/christophercliff/flatmarket](https://github.com/christophercliff/flatmarket)

The guy developing it was even nice enough to set up a heroku button; can be run for free: [https://github.com/christophercliff/heroku-stripe- checkout](https://github.com/christophercliff/heroku-stripe-checkout)

You'll still incur stripe charges, but no extra 2 percent.

</comment><comment><USER13> The structure of the JavaScript is interesting. It looks like this:

      if(typeof Math.imul == "undefined" || (Math.imul(0xffffffff,5) == 0)) {
          Math.imul = function (a, b) {
              var ah  = (a >>> 16) & 0xffff;
              var al = a & 0xffff;
              var bh  = (b >>> 16) & 0xffff;
              var bl = b & 0xffff;
              // the shift by 0 fixes the sign on the high part
              // the final |0 converts the unsigned value into a signed value
              return ((al * bl) + (((ah * bl + al * bh) << 16) >>> 0)|0);
          }
      }

      [240k of minimized JavaScript
       generated by ClojureScript]

The non-minimized code is just a copy/paste of the imul polyfill [1] from MDN. I'm curious why that is needed, since the ClojureScript seems to already have an imul polyfill included (the function named Ed in the minimized code). Is ClojureScript's polyfill broken?

[1] [https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Global_Objects/Math/imul#Polyfill)

<comment><AUTHOR> ClojureScript uses the Google Closure compiler under the hood.

From a quick dig around, looking at the Closure changelog, they introduced a polyfill of their own; I'm guessing this went in after CLJS built one, so now there are 2 in the compile / transpile chain.

One of the consequences of nothing in life being simple any more!

<comment><USER14> Not simple?

Maybe you're doing it wrong. Just make blockchain backend, run it as a serverless process on k8 and voila, can't be simpler.

<comment><USER15> Don't be sarcastic, it doesn't add to the discussion. You're just saying you agree in a silly way and citing some things you also happen to find needlessly complex.

<comment><USER14> > You're just saying you agree in a silly way and citing some things you also > happen to find needlessly complex.

Thank you oh wise one. I had no clue

<comment><USER16> We've banned this account for repeatedly breaking the site guidelines.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

</comment></comment></comment></comment></comment></comment><comment><USER17> Looks interesting! We've deployed Snipcart on a few static/React sites to keep them self contained which offers a JS powered cart/checkout experience for the same 2% load on the payment fees.

Do you see Trolley evolving to include a cart to allow multiple product purchases?

<comment><AUTHOR> Hi @justkez

Definitely, yes. Right now we're focussing on making Trolley as lightweight and easy to get started as possible, before pulling in more features.

I'm really interested in your feedback on how Trolley stacks up against its' competitors; if you had some time to drop me a line on email@example.com I'd love to talk to you in more detail.

Our pricing is also MVP so if you think there's something I'd have to do there to win business from you (or people in your position) then I'm keen to understand that too. I'm already aware of use cases like agencies building sites for their clients that might need an alternate pricing model :-)

</comment></comment><comment><USER18> Does Trolley also handle calculating sales taxes and integrating Stripe's sales tax on orders features? Or is there a 3rd party involved/recommended when using Trolley?

</comment><comment><USER19> Could you put a demo up, perhaps? Obviously, most people wouldn't actually go through the whole process and send money, but I'm just intrigued how it "feels".

<comment><AUTHOR> Working on it :)

</comment></comment><comment><USER20> It will be good to add more payment processors. I am already using Braintree and switching to Stripe is not something I would do.

<comment><AUTHOR> Hi Yes, we're looking at Braintree and Adyen for the future, but for MVP Stripe was by far the easiest starting point.

Thanks!

</comment></comment><comment><USER21> Where does it send the money? What countries does it work in? Does it require any kind of identity verification papers?

<comment><AUTHOR> Hi Trolley is essentially a front-end to Stripe (in Stripe terms we're a Platform working with Standard account).

That means that it works where Stripe works, and the money flows to your bank account through Stripe.

[https://stripe.com/gb/payments](https://stripe.com/gb/payments)

(Trolley never sees your card details or touches your money; the only pieces of Personal Information we ever see are email addresses and shipping names & addresses.)

What Trolley adds on top of Stripe is that we handle the integration code for you so you don't need a server or to pay for a back end developer, and we make it super easy to put a payment button on any website that triggers the whole process :-)

</comment></comment><comment><USER22> You lost me at 2%

</comment><comment><USER23> Hey Rory, can you add more gradients on more elements on the site? I don't think there is enough to proper be catching the gradient fad. thanks.

<comment><USER16> This breaks the rules, both for Show HNs ([https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)) and for HN itself ([https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)). Maybe you didn't mean it in a jerkish way, but it's hard to tell.

We detached this subthread from [https://news.ycombinator.com/item?id=18083428](https://news.ycombinator.com/item?id=18083428) and marked it off-topic.</comment></comment>


Uber reportedly tracked Lyft drivers using a program named 'Hell' - <AUTHOR> https://techcrunch.com/2017/04/12/hell-o-uber/ <comment><USER2> I really hope that Uber's shenanigans get studied in ethics classes in Computer Science and other technology degrees. When I was doing my CS degree, we had a mandatory ethics class (which I hated at the time but in hindsight think is a good thing). Ethical implications were something I hadn't previously thought of much, but in the field I've encountered them many times.

Based on the news that has been coming out from Uber, I think it's time for our industry to re-focus on the ethics of what we do. Being technologically cool, doesn't make something good.

<comment><USER3> What's unethical about this? They were doing market research. It's not much different from stalking your competitor on google and going after the users they advertise to.

<comment><USER4> Intentionally accessing a protected computer system without authorization and obtaining information from it is a federal criminal offense (18 USC 1030 (a)(2)(C)).

<comment><USER5> The part of CFAA that classified breaking a EULA or Terms of Service as unauthorized access is a horrible law that is frequently abused (most famously Aaron Swartz)

It is rightfully broadly criticized, and that shouldn't change because Uber are the perpetrators here

<comment><USER6> Just because you like Aaron Swartz doesn't mean that the law was 'abused'. He flagrantly violated MIT's terms of service and knew that he was doing so.

<comment><USER5> > He flagrantly violated MIT's terms of service and knew that he was doing so.

Yep and that shouldn't be a federal offense with ~20 year jail term with a lifetime criminal record

It's private companies defining federal law and dictating enforcement for their own purposes. You wouldn't let Wal-Mart define what it's own tax laws are, or have McDonalds define what RICO is - having companies define what theft or trespass are is just as absurd.

edit: the list of notable CFAA cases reads like a tragic comedy[0]

There is a case in there where someone was charged for encouraging his union members to email complaints to a company and when it crashed their mail server he was charged under the CFAA.

[https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act#N...](https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act#Notable_cases_and_decisions_referring_to_the_Act)

<comment><USER6> The sentencing is up to the judge, not the law. Swartz was never sentenced to anything. You are getting the 20 year figure from media outlets that added up the maximum possible sentences for everything he was charged with, which bears no relation to how sentencing actually works.

Also, it _obviously_ has to be a federal offense, since wires cross state lines.

<comment><USER5> > The sentencing is up to the judge

With 97% of federal cases ending in plea agreements sentencing is overwealmingly in the hands of prosecutors.

In the Swartz case she wanted him to plead guilty to every single charge and serve up to 6 years. Hence the suicide.

As leverage in negotiations they told him at trial he was facing up to 35.

<comment><USER6> >serve up to 6 years.

It was 6 months, not 6 years. [http://archive.boston.com/metrodesk/2013/01/14/mit- hacking-c...](http://archive.boston.com/metrodesk/2013/01/14/mit-hacking-case- lawyer-says-aaron-swartz-was-offered-plea-deal-six-months-behind- bars/hQt8sQI64tnV6FAd7CLcTJ/story.html)

>As leverage in negotiations they told him at trial he was facing up to 35.

Again, this is a nonsense figure. Can you give an example of someone who has been sentenced to 35 years in jail for similar crimes?

<comment><USER5> The whole point is that they don't sentence people to 35 years - they use that as a threat to leverage them into pleading guilty. Hence the dictatorship- level 99%+ conviction rates.

Same thing happen to Aaron, they hung a 7 year sentence around his neck if he didn't please guilty to all charges and accept the deal they offered him.

Even the innocent would please guilty in those circumstances, it's the only rational thing to do.

<comment><USER6> >they don't sentence people to 35 years - they use that as a threat to leverage them into pleading guilty.

But you contradict this in your own post. They threatened him with a 7 year jail term, not a 35 year jail term.

The plight of the innocent in the US system is very real, but irrelevant to the case of AS, as he was very clearly and unambiguously guilty.

<comment><USER5> There is no contradiction. Let me break it down again.

The original DOJ press release[0] when Schwartz was charged:

> If convicted on these charges, SWARTZ faces up to 35 years in prison

That maximum sentence is not uncommon in CFAA cases as most charges carry 10 or 5 years and layering charges together is very common (ex Mathew Keys faced 25 years on 3 charges for sharing a password)

Facing 35 years Swartz enters plea talks and is offered 6 months recommended, up to 6 years but guilty to all charges

The prosecutors tell him if he doesnt take that deal and goes to trial then they'll be seeking a 7 year minimum 35 year max

A lot has been written about the problems with not just federal sentencing and plea agreements (internationally it is a unique system) but also specific problems with CFAA and sentencing guidelines:

[https://www.eff.org/deeplinks/2013/03/41-months-weev- underst...](https://www.eff.org/deeplinks/2013/03/41-months-weev- understanding-how-sentencing-guidelines-work-cfaa-cases-0)

[0] [https://web- beta.archive.org/web/20110724043722/https://www....](https://web- beta.archive.org/web/20110724043722/https://www.justice.gov/usao/ma/news/2011/July/SwartzAaronPR.html)

<comment><USER6> Again, 35 years is simply the figure derived by adding up all of the maximum sentences. Swartz had good legal advice. He knew he wasn't going to be sentenced to 35 years in jail.

The problems with plea agreements relate largely to innocent people being pressured into taking them because a trial is too risky. Swartz had clearly violated the law, so he would have had nothing to gain from going to trial in any jurisdiction.

See e.g. here for further analysis:

[http://volokh.com/2013/01/16/the-criminal-charges-against- aa...](http://volokh.com/2013/01/16/the-criminal-charges-against-aaron-swartz- part-2-prosecutorial-discretion/)

>... realistically, Swartz was facing anything from probation to a few years in jail if he went to trial — depending largely on how you value the loss he caused — and either a 4 months in jail or 0-6 months in jail if he pled guilty.

<comment><USER5> How does that justify having a ridiculous 35 year sentence hanging over somebody for a terms of use violation? That is murder levels of sentencing

The case was far from clear cut, weev had his case overturned and the Lori Drew case was overturned specifically because the judge said terms of use violations don't apply under CFAA

I read Orin Kerr a lot, abd agree with almost all of what he says in the series he wrote on the Swartz case - I only didn't buy his justification that overprosecution is ok because all the other prosecutors also do it

Swartz's main concern was a lifetime criminal record and not being able to work, and second pleading guilty to charges that he (and many others) don't agree he was guilty to

I def agree with Kerr that the unauthorized access statutes need to be reformed tho, that would have the Swartz case irrelevant and placed it back where it belonged - in a civil court

<comment><USER6> >How does that justify having a ridiculous 35 year sentence hanging over somebody for a terms of use violation?

It's arithmetic. The maximum sentences are what they are, and their sum is what it is. Justification doesn't come into it. But a 35 year sentence was never "hanging over him". He had good legal advice. He knew that he would not go to jail for 35 years.

>The case was far from clear cut,

He physically broke into one of their network closets while attempting to disguise his identity. If that doesn't count as unauthorized access, nothing does.

>Swartz's main concern was a lifetime criminal record and not being able to work

Which, as Kerr points out, makes it absolutely baffling that he did this in the first place. It's often glossed over, but it really was an enormously stupid thing to do. It's sad that he got himself into so much trouble by doing it, but I can't see how anyone else is to blame for that. Especially when he'd already had fair warning after the PACER incident.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> I strongly prefer lyft's side, haven't used uber in years and the last year I drove for ridesharing I exclusively drove for lyft and not uber, but I really don't have a problem with this. OF COURSE you should collect intelligence on your competitor's activities - if they expose information publically (e.g. showing the cars on the app / API) and cross-correlating with the uber drivers that still are logged on - what is the objection to this?

Mind you, some of the other things uber has done, like hail a lyft and repeatedly cancel, are totally not ok.

<comment><USER8> Collecting intelligence is one thing. But deliberately abusing your competitor's systems in a way they did not intend to allow in order to collect intelligence is not only ethically wrong, but also likely illegal, as this article mentions.

<comment><USER9> Indeed. Quoting the article:

 _Hell originated after Uber created fake rider accounts on Lyft and used software to trick Lyft's system into thinking those riders were in certain locations. This allowed Uber to see the eight closest available Lyft drivers to each fake rider._

<comment><USER7> This is a very "benign" fake, akin to scraping a website for information... Moreover, you could just as easily do it with a 'real' account; and just use the 'real' account far... Less often than you're using it to scrape the info.

<comment><USER9> This wasn't public information to be scraped, hence the requirement for an account.

Creating fake accounts for this purpose is a violation of the current terms of service [1] (these might have been different in 2016):

 _9\. Restricted Activities_

 _h. forge headers or otherwise manipulate identifiers in order to disguise the origin of any information transmitted through the Lyft Platform;_

 _l. use any robot, spider, site search /retrieval application, or other manual or automatic device or process to retrieve, index, scrape, "data mine", or in any way reproduce or circumvent the navigational structure or presentation of the Lyft Platform or its contents;_

[1] [https://www.lyft.com/terms](https://www.lyft.com/terms)

<comment><USER10> Terms of service are not law.

When an end user breaks the terms of service of whatever system, most people would say that terms of service mean nothing. But since it's Uber, uuuuh, the scary terms of service!!!

<comment><USER11> With how the CFAA works, yes this sort of thing can absolutely be against the law. "Unauthorized" is a pretty broad term.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Trying to think through how Hell must have worked, Uber must have decoded Lyft's encrypted Rest APIs and were able to hit an endpoint that returned the 8 nearest available rides given a user and geolocation. Given a large metro area such as LA, you would probably need to make hundreds of requests with fake geolocations to be able to map out the whole area. You would probably only need to do it maybe every 5-10 minutes to get decent resolution for a semi-live map. Depending on Lyft's rate limiting you might get by with in the order of dozens of fake accounts. Given Lyft's scale this would probably be small undetectable noise in their analytics and wouldn't really degrade their systems. I would say it's only semi-shady, probably doesn't rise to the level of civil or criminal lawsuits.

<comment><USER13> Uber could just run Android or iOS emulators running Lyft with fake user accounts and fake geolocation.

<comment><USER14> The article claims that's how it worked

</comment></comment></comment><comment><USER15> It's only because Uber's view of its own drivers is known as heaven/god view.

edit: discussed in article.

Call me a pessimist, but I am betting that, despite the long and rocky road ahead, Uber is eventually going to succeed. And we're going to see the emergence of a new corporate template.

</comment><comment><USER16> I don't see how this is nefarious, Uber is scraping data that Lyft is sharing publicly. And based on Lyft's response, my hunch is that they do the same thing.

If anything, this story distracts us from legit nasty business practices - like repeatedly cancelling on Lyft drivers to waste their time and lower their earnings.

<comment><USER17> _Uber is scraping data that Lyft is sharing publicly._

Except they're really not. They accessed data from an API that is only available to the Lyft app by creating some fake profiles. That means their profiles couldn't legally have agreed to the app's terms and conditions, so it wasn't legally permissible for them to access the API. So no, they weren't just accessing information that Lyft were "sharing publicly".

<comment><USER18> Do you think it's OK for violating the T&Cs of an app to be illegal? Isn't that the same as using the F word on a forum when you agreed not to? Didn't we go through all this with Aaron Swartz and one or two other high profile hackers?

<comment><USER17> _Do you think it 's OK for violating the T&Cs of an app to be illegal?_

I don't think determining legality and harm should be a boolean operation. There are layers of subtly and nuance in most things, and the law is one of them. I don't think posting the F word on a forum where the owner doesn't want you to post it should be treated as an equal violation of the law as deliberately abusing your competition as a billion dollar business. The amount of damage, and perhaps _potential_ damage should be considered. When I swear a reasonable person would think the harm is minimal. When I try to sabotage another company where the damage could result in billions of dollars of lost investment and thousands of jobs vanishing a reasonable person would think that's pretty bad. They're technically the same 'crime', but they're obviously not the same in scale.

<comment><USER16> Legality should be boolean - either you're following the law or you're not. If guilty, however, the penalty should be proportionate to the harm done.

In this particular case, Uber is guilty of breaching Lyft ToS's clause around no data mining. However, this seems like an insignificant infraction, there is likely to be zero legal penalty. Lyft's only recourse is to either shut down Uber's accounts or feed them bogus data.

</comment></comment></comment></comment></comment><comment><USER19> Interesting how they didn't punish drivers who also drove for Lyft, they actually rewarded drivers who also drove for Lyft with better Uber offers.

<comment><USER20> Uber & Lyft need a large pool of drivers readily available. The quick pickup is a key part of the experience that makes them superior to taxis. Especially drivers who are rated well. I'd be kind of surprised if a driver's rating didn't factor into their entire incentive program. I carried a 4.9 Uber rating by the time I quit driving and they were issuing some really attractive incentives by the end.

</comment></comment><comment><USER21> >If there were several Uber drivers near an Uber rider but one of those drivers was also frequently available on the Lyft network, as seen by the Hell program, Uber's ride-dispatch team was supposed to "tip" that ride request to the driver who was "dual apping," or typically looking for riders through both the Lyft and Uber apps, sometimes by using two different smartphones at the same time. The person involved in the program called it "privileged dispatch" and said Uber aimed to use that to squeeze Lyft's supply of drivers. [from the original article on The Information]

I think this should be the most controversial part of the program. Essentially, Uber favored its drivers who used both Uber and Lyft at the expense of its drivers who were strictly loyal to Uber.

</comment><comment><USER22> What is wrong with Uber's management? I don't think I've ever read anything positive about the company.

From their numerous gender bias and sexual harassment claims, to their CEO acting like a bratty spoiled 15yr old and bitching out a driver, to trying to skirt public safety laws by refusing to register their self-driving cars after being catered and begged to do so by government regulators simply because they don't give a fuck, to this whole Waymo lawsuit, to this. I think this shitty company needs a complete change of upper management.

</comment><comment><USER20> I drove for both Lyft and Uber last year, and I could swear that Uber was tracking Lyft. I'd get a call for an Uber and while fumbling around with the phone getting to the Lyft app to drop driver mode, I'd get a Lyft call in. Totally anecdotal, but it happened enough that I noticed. Eventually I quit trying to double dip, it was just too stressful. I'd make a call on which to use based on the incentives being offered, basically, or if things were slow on one I'd switch to the other.

</comment><comment><USER23> At this point, what hasn't Uber done?

<comment><USER24> At this point, is anyone else feeling like there's might be some vendetta- driven campaign directed against them?

<comment><USER25> Somebody very much wants them to fail.

It's starting to feel like the campaign to pump up all the Russophobia

<comment><USER26> Except there's more evidence of Uber's failings than for the accusations levied against Russia.

</comment></comment></comment></comment><comment><USER27> I love how "There has been some recent tension between her and Kalanick, with some investors blaming bad press for Uber's woes (wrong!), although sources said that was expected given all the controversies at the company of late." becomes "Uber's head of communications Rachel Whetstone recently quit, reportedly because of conflicts with Kalanick."

</comment><comment><USER28> _Lyft said "We are in a competitive industry. However, if true, these allegations are very concerning."_

Notice the careful non-statement by Lyft. It's hard to believe Lyft isn't doing exactly the same thing.

It's not questionable behavior to track what your competitor is doing. That's the first step toward beating them. And yes, Uber is trying to beat Lyft, just like Lyft is trying to beat Uber. That happy balance is a good thing for consumers.

It's pretty strange that I have to second-guess whether to post this comment since it could be interpreted as a defense of Uber. But the PR spin is getting to be a feeding frenzy.

Is _all_ tracking now unethical? Under what circumstances should you be allowed to track other people? Google knows more about you than your significant other. Should they be allowed to do this? Is this ethically questionable? What is the categorical difference between Google and Uber? These are questions which have no clear and easy answer, but it's painted as if it's so clear-cut.

<comment><USER8> > _It 's hard to believe Lyft isn't doing exactly the same thing._

No, it's actually really easy to believe that Lyft isn't tricking Uber's computer systems into giving Lyft real-time info on Uber's drivers and fare prices. Please stop trying to make excuses for Uber's shitty behavior.

<comment><USER24> _> it's actually really easy to believe that Lyft isn't tricking Uber's computer systems_

How, or why, is that really easy to believe?

<comment><USER8> Because most companies don't intentionally break the law or engage in fraudulent activity. Just because Uber does this all the time doesn't mean Uber's competitors must do it too.

</comment></comment></comment></comment><comment><USER29> > _[Uber] used software to trick Lyft's system into thinking those riders were > in certain locations_

Could this be a CFAA violation? Are there any prosecutorial jurisdictions with lots of Lyfts and few or no Uber?

<comment><USER26> I'd be surprised if this couldn't be spun into a federal crime if there's any interest in taking this to court and involving the authorities.

</comment></comment><comment><USER30> I always wondered why Uber showed fake cars on their map. I remember them citing "technical" issues which seemed suspicious given that it's not a hard problem, and Lyft actually shows car locations. I wouldn't be surprised if the fake cars came about as a result of the Hell program when they realized car locations could be used against them.

</comment><comment><USER31> Please note that the whole "illegal access to a computer system" business is what Aaron Scwartz was being prosecuted for. I don't think we want to promote a restrictive idea about what constitutes authorised use of a system, just so we can have a go at an unpopular taxi service.

<comment><USER26> The two situations are very different.

As technology goes, Aaron merely accessed what was already accessible to every user. Uber accessed information a single user wouldn't have had access to.

As ethics go, Aaron downloaded information that represented publicly funded research and would be available to the public if academic publishing wasn't so horribly defunct. Uber extracted operative business information that was only meant to be exposed a fraction at a time to provide specific services.

As motives go, Aaron tried to make information publicly available for free. Uber tried to poach Lyft's drivers and sabotage Lyft's operational model for financial gain.

The only value of Aaron's case in this discussion is as an example in the form of "If what Aaron did was grounds for criminal prosecution, how is what Uber did not a federal crime?".

Even if you disagree with the ethical aspects, Aaron exfiltrated information available to any normal user (just at a larger scale than intended) whereas Uber intentionally exploited a design flaw to access information not available to any individual user. If both crimes could be described as "doing X, and then doing the same thing again a lot more times" for Aaron X was "downloading a file intentionally made available to all users" whereas for Uber X was "downloading information only intended to be available to a single other user".

</comment></comment><comment><USER32> So is Uber just getting its dirty laundry wikileaked more than American intelligence services are now or what

</comment><comment><USER33> Is Uber the only tech company using unethical and immoral practices to take out the competition? or the only one to be caught?

(Not asking as a defense for them, I'm just curious, and cynical, I believe they all do this, but thats an ignorant belief as I dont know)

</comment><comment><USER34> >Hell originated after Uber created fake rider accounts on Lyft and used software to trick Lyft's system into thinking those riders were in certain locations. This allowed Uber to see the eight closest available Lyft drivers to each fake rider.

This is not ethical. It's not.

</comment><comment><USER35> I would really like to know what is unethical (or even illegal) about this (just so I can understand this correctly).

Uber

* created multiple fake accounts on lyft to know about it's drivers

* figured out that it's drivers were assigned numerical ids

* used said ids, to track lyft drivers.

imho, this is just figuring out your competition (say by signing up to the service) and then using this knowledge to improve your service (by incising drivers on both platforms to ditch one).

This is one of those "do things that don't scale" mean (or my interpretation of it). I say this because, one multi-billion $ "startup" is doing this to another multi-billion $ "startup".

Also, I'm sure this would never be an issue if Uber was not in the press for other crappy stuff they did.

</comment><comment><USER36> Are user location credentials often accidentally exposed in other app's APIs? This isn't something I have much knowledge in and am just wondering how often this is a security issue.

</comment><comment><USER37> Doesn't seem much different than Google indexing the web. They were just crawling Lyft.

<comment><USER26> They created fake accounts with fake geolocation to extract information, then they exploited a design flaw in Lyft's software to perform an enumeration attack that allowed them to extract full information about all drivers in real time in order to exploit that information financially.

Google crawls public websites while respecting counter-measures like the `robots.txt` protocol. They also don't create fake accounts. They most certainly don't perform enumeration attacks to find more content to index.

This is nothing like what Google does. If Google did this, they'd be called out the same way.

Heck, if anything, this is similar to what Aaron Swartz did, except Aaron did it to make the information public rather than profit from it for financial gain -- and the data he did it with was neither sensitive nor private.

</comment></comment><comment><USER38> If I were Lyft, I might try to detect what traffic is coming from suspect clients and present an inaccurate view to them to maximize inefficient spending on Uber's part. This seems like it should be easy to do without harming someone in case you inaccurately label someone as illegitimate.

<comment><USER26> It is interesting that Lyft didn't detect this malicious behaviour and this raises some questions.

Did Uber try to obscure what they were doing by spreading the requests over various IPs to cover their tracks? This would indicate that they knew they were doing something malicious (which could affect sentencing if this is considered a federal crime under US law which it actually might be -- though IANAL).

If this really was "realtime", why didn't Lyft notice the unusual request volume? What could they have done to detect this as suspicious and investigate? Are there some specific lessons other companies could learn from this?

<comment><USER39> Detecting these kinds of behaviors is hard without generating false positives. GPS on phones arent always the most reliable thing, especially if the user is opening and closing the app.

An app that did try to stop this type of behavior was Pokémon Go. It took them a while to do even halfway well.

</comment></comment></comment><comment><USER40> That's appropriate, considering Uber itself seem to have been born in Hell.</comment>