The core issue: Stripe's Payment Intent pattern (server gets token → passes to client → client opens iframe) is safe because the blast radius is bounded; worst case, someone pays your invoice. But the same pattern applied to admin embeds (payroll, HR, financial controls) means a single XSS or compromised npm dependency can exfiltrate full admin access.
The fix I'm proposing (RequestRequest) routes every iframe API call through the host page for server-side JWT signing. The iframe never holds a persistent credential. There are three interactive demos in the post, including a real race condition demo against a Durable Object.
I disclosed this to two vendors in Jan 2024. Both classified it as informational. Neither has changed their architecture.
Hi HN! Reddit has been a promising source of early users for us at chef Connie; for example a single response on a post with lift can easily generate 10+ signups, most of whom finish activation.
We didn't want to miss out on any action—showing up late to the conversation really dampens results!—so we whipped up a microservice to notify us of relevant posts.
Enough friends and founders have asked us to share; thought I would post it here to help you improve your startup or project's odds of success :)
Hope you like it! How can we make this easier to install, or better fit your inbound marketing practices?
Did you consider leveraging the refdb to offer immutable primary keys?
I had been hacking together a Kyoto Tycoon-backed implementation for a project (since dropped); our design exposed the ref id to the user (e.g. 'master', 'master/mhodgson', etc) and branch/merge as necessary. This way, our primary keys remained a constant refName that pointed to the HEAD of a commit chain, each of which referenced immutable commits/trees/blobjects.
Although my days of libgit2 hacking are long past, I'm very curious if/how our design could have been improved; immutable pkeys were important for us as well.
Definitely understand the concern—I set the minimum permissions, but obviously friends list is among them. All the code looks for is user_id; I'm not even storing the access_token generated.
This will be clearer as the readme shapes up, but it's for a private messaging repository, accessible only to folks whose user ID you save in a Redis hash.
For example, assume authed_user_ids = {1: '', 2: ''}. If, after authenticating with Facebook, we determine your user_id is 1, today's date gets stored as your value (authed_user_ids = {1: 'DATE', 2: ''}). The card will then open with Day 0's message, and will display a new one for every subsequent day until the sequence has expired (you will need to auth every time, as the only session variable stored is the OAuth nonce).
If Facebook returns with user_id = 3, the card will open and display some generic "no message for you" content.
Hey HN. I've been seeing a pretty awesome girl for the last couple of weeks, and wanted to send her a series of notes.
To that end, I wrote an ephemeral messaging system using Sinatra + Redis that authenticates her ID against Facebook and will show her a new message every day. Each message disappears from the public web once its day has passed.
I've released the code on Github; you can use it to display any sequence of messages over time to a set of authorized users. Documentation is pretty sparse right now; I'll be posting better comments, a readme, and license information (using MIT) tonight.
Again, you're right on the fact, but not on the interpretation. The medallion system used by most cities restricts the number of cars on the road in a city. However:
1) Most taxi fleets -- especially the larger ones -- collect monthly rent from car owners, rather than own a ton of medallions themselves. The medallion system benefits owners of medallions, not fleets. This distinction, while invisible to the masses, is incredibly important.
2) It's definitely not rare for new fleets to pop up. We talk with plenty of folks who own fleets that are only one or two years old. All you need is a subset of drivers (and/or owners!), a couple of regular clients, and a little gumption. New fleets are popping up, and trying to innovate as best they can. The new, lower-priced, often mobile-based dispatch systems I mentioned in a previous comment have really been a boon to this segment.
3) In most cities, black car licenses are similarly restricted to medallions. The limits may not be posted, but they exist. In fact, a great article about Uber in The Atlantic exposed this issue in DC back in May[1].
4) Again, fleets working with us are achieving similar results; companies like Hailo and GetTaxi (who seem to be trying to work within the system) are as well.
In short: the medallion system is a red herring when it comes to stifling innovation. It is definitely an issue, one that tends to marginalize drivers and unnecessarily restrict supply for passengers. But every one of the companies you and I have mentioned abide by the restrictions it imposes, so your point is moot.
Going back to my original issue: I have no problem with challenging rules, conventions, and decisions (I'm an entrepreneur, posting on HN... do you really expect me to disagree here?). My issue lies in Uber's underhanded approach, where they both flout actually sensible laws and arguably force governments to send C&Ds by refusing to engage with them when initially approached.
I believed this point too when we first started our company, and were more Uber-clone-y than we are now. However, after spending a year working in the industry, I've learned that it's more "catchy idea" than reality.
It turns out that the taxi industry is a little different: the fleets have wanted to innovate for years now, but have little idea how. The regulations clearly permit innovation. In cities where taxis aren't run by the municipal government (i.e. "in cities that aren't New York"), there is healthy competition between taxi providers, in spite of their commoditization (regulated pricing, supply, etc.).
IMO, the existing taxi technology players are the ones who are stifling innovation (and/or "protecting a group of entrenched companies at the expense of consumers"). 2 of the big 3 dispatch technology providers charge hefty fees just to open access to their APIs for new entrants, if they'll even grant you access in the first place. And, due to the long-term, hardware-heavy, dispatch-focused nature of their contracts, they rarely have any incentive to innovate for the passengers; one of them once told me that they have nobody on staff who understands the web or web technologies!
Working with the existing dispatch companies, while not a necessary evil (take Hailo or GetTaxi, for example), is the best way to ensure scale and distribution -- the amount of cash consumer-focused players must spend in this industry in the hopes of curbing cab booking behaviours is enormous. Our research showed that, when calling for a pre-arranged cab, 95% of taxi passengers chose their fleet because it was first to mind, or the fleet they always called. In other words: only 5% of consumers chose what TaxiCo to call for any rational reason. Having an existing brand identity, and a number of cars on the street constantly hocking your wares, goes a long way in this industry.
But even before Uber came along, a wave of new dispatch companies had started cropping up, most of which are relying on a healthy partner ecosystem in order to make it in the first place. But, since dispatch technology contracts have typically been signed as 10-year license agreements, evolution naturally trends to a slow change: a lot of forward-thinking fleets I've met with renewed their contracts in the last year or two, since they didn't feel the new technology was mature enough yet (and, in most cases/for their needs, rightly so).
All this to say: I'm not yet sure what the best way to spark the necessary change is (FWIW: currently leaning towards "open standards", but I'm not 100% sure how that would look yet...
); figuring it out will likely be a huge benefit to my company. But I firmly believe, based on facts and experience, that it's not a regulatory issue.
Thanks, Carter! My partner Krista tried to come into town for that meeting, but they switched the date on her. You almost met!
The human factor is definitely a huge challenge in this industry, and I can understand anyone's aversion to it. That said, if you ever want to chat taxi tech (or FP -- we're migrating more and more of our backend to Erlang every day, and I'd love to learn from your Haskell experience ;), drop me a line!
Thanks -- this is a subject that is near and dear to me.
I definitely agree with you that there is a service gap between Uber and standard taxis. Some of it comes from the app, some of it comes from their quality control.
(On that note: Uber does a really solid job with quality control, and I've personally recommended a stronger emphasis on quality control to fleets we work with. They all seem to want to take us up on it, so I look forward to reporting back on that one soon!)
That said, the points you bring up aren't actually broken by the current regulatory system (save one, sort of... see the asterisk), which is why I am disgusted by Uber's typical reaction to the C&Ds that come their way (and their preparation for them):
- Taxi companies today have a very limited, only-opt-in feedback mechanism: you call and complain if you have a particularly bad or particularly good ride. I've personally spoken with GMs for companies that do hundreds (sometimes thousands) of rides per day about this; they rarely break 20 customer service calls per day. Uber's feedback mechanism -- not a new concept by any means, but new to the industry -- of asking users to rate their ride, and send in some comments after every ride is relatively frictionless and undoubtedly leads to more data points, which can then be shared with drivers to encourage a healthy sense of service. This could and should be adopted by the rest of the industry.
- Again, this is a fantastic innovation, but doesn't need to lie outside the existing regulatory system to succeed; our old business model is proof that they can co-exist. Rarely do cities take issue with apps. Further, most fleets use dispatch systems that directly assign a driver, and all drivers know they will get docked if they take a street hail instead of the passenger they're assigned.*
- Yet again, no regulations prevent this... but I've been the recipient of many a complaining driver myself. While drivers have both legitimate and illegitimate reasons for trying to avoid credit cards (fleets often tax drivers an additional point or two above going credit card rates; credit card transactions must be declared when filing taxes), this again can be solved with an app that respects the current system. In fact, while running HireWinston, we showed our driver partners that the guaranteed 15% tip more than made up for the increased cost they incurred by taking credit cards.
- See first bullet above re: service again.
To sum up, I hear you on all fronts: riding with Uber offers a superior experience to virtually any other cab out there. My point above, however, still stands: all of the innovations and improvements you bring up (which are, from our customer research, consistently the most salient) come from areas that few, if any, regulators take issue with (I know from experience). Which is why, again, I am disgusted by how I've seen Uber deal with regulators.
*I feel for you, though; this situation is at its worst in SF. But on the flip-side, I've heard more "passengers aren't there anymore when our drivers show up" complaints from SF fleets than I have anywhere else in North America. Because of this, it's often more attractive for drivers in the Bay Area to get docked and grab the street hail's certain money than to risk the no-show. IMO, SF taxis and consumers are stuck in this perpetual loop until the supply of taxis increases dramatically.
TL;DR: Uber is innovative, but their approach (or lack thereof) to dealing with regulatory hurdles in each city disgusts me.
It seems like HN has already picked up on the major issues Uber faces in Boston, as well as pretty much every city: a new style of relationships with drivers, and "metering" virtually-on-demand livery rides, which are intended to be both unmetered and pre-arranged.
After seeing this same story repeated too many times now, and the resulting discussion, I feel the need to throw down. You don't need to trust me (IANAL, etc.), but based on my experience in the field -- I co-founded HireWinston (initially a Canadian, corporate-focused Uber competitor; we've since pivoted to competing indirectly by selling taxi fleets) -- I hope I have something to add.
First, the relationships with drivers: Uber tends to work directly with drivers (many, if not all, of whom they hire legally from existing livery services). In order to boost their chances of availability, they spend some of their hard-raised cash to book drivers for entire days, taking a steep loss at first in the hopes of driving enough demand to better satisfy their capacity.
In most cities, there are clear regulations that define a livery service. We found that, if you work as many commenters understand Uber working -- namely, as a network that has pre-arranged agreements with drivers or livery services to shuttle rides in their spare time -- you're in a sufficiently comfortable area not to get shut down. However, the way Uber works to juice supply (especially in newer markets) tends to clearly fall under the definition of a livery service, as they have their own "employees" that they pass rides to.
Second, the meters. This one I'm much more in their favour on: the phones themselves are not metering devices as the laws define them (i.e. they do not themselves calculate the price). I haven't personally torn into their source code, but having heard from an insider and having built this tech myself, I'm fairly confident their Driver App simply sends GPS data back to the server, where the calculation takes place according to a pre-defined rate. The customer either implicitly or explicitly accepts this rate through the TOS and/or by virtue of using the service (assuming the rates are published somewhere).
This setup guarantees they have something to show regulators if ever asked. From our research and testing, the integrity of the data from existing metering technology is similar enough to that from an iPhone or Android's GPS (ideally accompanied by accelerometer data). And, since the calculations happen on a server that records full route information rather than in a black box that discards it: way easier to share this with regulators. So A+.
Third, and most importantly, is what you don't see: Uber's relationships with city regulators. In Toronto, the municipal government sent us an official notice that they were concerned with our business, and that they wanted us to come talk through our business model and underlying technology with them. They were genuinely excited that there was innovation happening in the field in their city, and really just wanted to make sure we weren't doing anything egregiously wrong.
We sat down, and had an incredibly pleasant meeting. 30 minutes, back-and-forth Q&A, with some regulators who have spent years in the space. They appreciated that we knew the laws, had worked to abide by them, and were comfortable with all but one aspect of our business model (cancellation fees). No C&Ds were sent out.
At the end of the meeting, they asked us what we thought of Uber. Apparently, for months, the Uber team was dodging any request for a meeting the office sent them. While I definitely cannot attest to Uber Boston's actions on this front, I can't imagine that Uber Toronto was taking their plays from a different playbook.
In summary: Uber has done a tremendous job pushing the industry forward, and I'm confident that our approach -- selling the underlying software to existing taxi fleets, who truly want to better service their customers but have no idea what to do with technology -- is a more sustainable and dependable iteration on the model. I'm thankful to them, and I truly love a lot of the folks I know who work there.
That said, I have no sympathy whatsoever for these C&Ds whenever I read about them. The company relies on deep pockets and public sympathy for the "underdog technology company" to change laws, rather than working with the existing system. And, frankly, normally I'd even be fine with that... if it weren't the taxi drivers -- the most marginalized members of the entire taxi ecosystem -- who were getting the shortest end of the stick.
DISCLAIMER: I do not, and have never, worked for Uber. Most of my knowledge comes from a mix of an outsider's view and third-party testimony of the approach that Uber has taken in Toronto and NYC. I'm not sure if Uber Boston took a different approach than Uber Toronto or Uber NYC, so take all specifics with a grain of salt.
Those books were the impetus for my first startup: a mystery and math problem solving stand.
I had no customers (something about a 5 year old with a bristol board setting up shop on a tranquil suburban street strikes me as ineffective...), but I've kept the poster I made as a 5 year old kid to stay humble.
Thank you and R.I.P. Donald Sobol... you're the reason I do what I do.
cxz & pud -- If either of you guys want, some friends and I developed a pretty comprehensive collaborative recording suite a while ago that I just couldn't get off the ground.
I've since taken it offline (minimal active users + a couple hundred a month for hosting != sustainable), but if either of you want to take a look at the source code, let me know.
Here's a TNW article detailing what we did, from back in 2010:
The core issue: Stripe's Payment Intent pattern (server gets token → passes to client → client opens iframe) is safe because the blast radius is bounded; worst case, someone pays your invoice. But the same pattern applied to admin embeds (payroll, HR, financial controls) means a single XSS or compromised npm dependency can exfiltrate full admin access.
The fix I'm proposing (RequestRequest) routes every iframe API call through the host page for server-side JWT signing. The iframe never holds a persistent credential. There are three interactive demos in the post, including a real race condition demo against a Durable Object.
I disclosed this to two vendors in Jan 2024. Both classified it as informational. Neither has changed their architecture.