This is being published with the permission of Uber under the responsible disclosure policy.

The vulnerability detailed in this blog post is being disclosed by Anand Prakash and Manisha Sangwan of team AppSecure. This was plugged quickly by the engineering team at Uber.

This post is about an information leakage vulnerability on riders.uber.com in which we identified an public API endpoint of https://riders.uber.com/profile that could send back server tokens and client secret for applications authorized by the account owner to access their Uber account.

As per Uber’s documentation:

_“The secret for your application, this should be treated like your application’s password. Never share this with anyone, check this into source code, or post in any public forum. Additionally, this should not be distributed on client devices where users could decompile your code and access the secret. If you suspect your clientsecret has been compromised you may generate a new one in your application’s dashboard which will immediately invalidate the old secret.”

This could have been easily exploited by an attacker by connecting their account to any Uber application on production and then using the profile endpoint to retrieve server tokens and client secrets of the connected application in the API response.

Uber fixed this issue by removing this data from the API response, as reported. Uber publicly notified all developers of this vulnerability and asked developers to rotate secrets on a periodic basis.

Notification sent by Uber to developers.

About Uber

Uber is a transportation network company (TNC) headquartered in San Francisco, California. Uber offers services including peer-to-peer ridesharing, taxi cab hailing, food delivery, and a bicycle-sharing system. The company has operations in 785 metropolitan areas worldwide. Uber has a valuation of over $100 billion as per Bloomberg’s report.

How my exploit worked step-by-step

Step #1

Attacker connects a random Uber developer application to their account using OAuth. A few examples of Uber developer applications are IFTTT, Payfare, and Bixby. It is not identified as a complicated procedure as of now.

Step #2

Once the above apps are connected by the attacker to their Uber account, they can use against the endpoint to get the developer application’s confidential data and other significant information of the application using the attacker’s session data.

The vulnerable Uber API:

POST /api/getAuthorisedApps HTTP/1.1
Host: riders.uber.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:62.0) Gecko/20100101 Firefox/62.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: [https://riders.uber.com/profile](https://riders.uber.com/profile)
content-type: application/json
x-csrf-token: XXX
origin: [https://riders.uber.com](https://riders.uber.com)
Content-Length: 2
Cookie:

Data getting leaked in API response:

{“status”:”success”,”data”:{“data”:{“uuid”:”xxxx”},”clientScopes”:{“authorizedClientScopes”:[{“clientID”:”xxx”,”scopes”:[“history”,”offline_access”,”profile”]}]},”scopeDetails”:[{“applicationDetails”:{“applicationID”:”xxx”,”owner”:{“userUUID”:”xxxx”,”userEmail”:””},”applicationSecret”:”xxx”,”name”:”xxx”,”description”:”abc”,”privacyPolicyURL”:”[https://appsecure.in](https://appsecure.in)","surgeConfirmedRedirectURI":"","webhookURL":"","applicationType":"","requestsPerHour":{"low":0,"high":0,"unsigned":false},"redirectURIs":["xxxxxx"],"appSignatures":[],"defaultScopes":["history","profile"],"whitelistedScopes":[],"originURIs":[],"serverTokens":["xxx"],"ipWhitelist":[],"admins":[{"userUUID":"xxxx","userEmail":""},{"userUUID":"xxxx","userEmail":""},{"userUUID":"xxxx","userEmail":""}],"developers":[{"userUUID":"xxxx","userEmail":""}],"tags":[],"oauthEnabled":false,"smsVerificationEnabled":false,"cobrandingEnabled":false,"supplyOnly":false,"isInternal":true,"cobrandingDetails":{"nativeURL":"","androidFallbackURL":"","iosFallbackURL":"","displayName":"","linkName":"","logoUUID":"","logoFiletype":"","generatedLogoURL":""},"availableScopes":["delivery","history","history_lite","places","profile","ride_widgets"],"openScopes":["delivery","history","history_lite","places","profile","ride_widgets"],"developerScopes":["all_trips","request","request_receipt"],"createdAt":{"low":xxx,"high":0,"unsigned":false},"updatedAt":{"low":xxx,"high":0,"unsigned":false},"displayName":null,"iconURL":null,"publicDescription":null,"appGalleryDetails":{"mobilePlatforms":[],"publicationState":"","redirectURI":"xxxx","permissionState":""}},"permissions":null,"userRoleInvitations":null}]}}

Disclosure Timeline

October 5th, 2018: Report sent to Uber’s Security team.

November 6th, 2018: Issue resolved by Uber. AppSecure asked Uber to notify all developers in case their app secrets were no longer confidential. We verified the fix.

December 20th 2018: Uber replied, stating, “They are in process of notifying the developers and in process of putting up long term fix in place for this issue.”

February 8th 2019: Uber rewarded us with $5000 bounty and notified all developers via email about the same. The issue was publicly disclosed after the action was conducted.

Summary

This post is about a critical bug on Uber which could have been used by hackers to get unlimited free Uber rides anywhere in the world. This post also explains few best practices while integrating payment gateways.

Description

Uber Technologies Inc. is an online transportation network company, headquartered in San Francisco, California, with operations in 528 cities worldwide. Users can create their account on Uber.com and book a ride. When the ride is completed a user can either pay cash or charge it to their credit/debit card.

But, by specifying an invalid payment method (for example, abc, xyz, and so on), I was able to ride Uber for free.

To demonstrate the bug, I got permission from the Uber Team and took a free ride in India. I wasn’t charged for any of my rides, using the invalid payment method.

Vulnerable request:

POST /api/dial/v2/requests HTTP/1.1 Host: dial.uber.com {“start_latitude”:12.925151699999999,”start_longitude”:77.6657536,
“product_id”:”db6779d6-d8da-479f-8ac7–8068f4dade6f”,”payment_method_id”:”xyz”}

Steps to reproduce:

1. Replayed the above request with random characters as payment_method_id.
2. Ride was free.

Video POC:

Thanks to Uber Security team for fixing this quickly.

The timeline

Aug 22nd 2016: Vulnerability Report to Uber.

Aug 26th 2016: Uber requested more information about the bug.

Aug 26th 2016: Took a free ride and replied with ride details

Aug 27th 2016: Vulnerability fixed by Uber.

Sep 10th 2016: Rewarded with $5000 bounty by Uber.

Takeaways

As a developer, you should always take care of the below test cases when integrating payments:

a) Verify if the payment was success or failure by doing a server to server request to payment gateway or verifying checksum to the payment gateway provider.

b) Always validate the amount of the item with the amount which was paid by the user to the payment gateway.

c) Validate currency in the payment API calls. For example, the attacker can pay 50 IDR for a 50 USD item.

d) If you are storing credit cards/debit card information, then always check for authorisation if an identifier is being passed in one of the API requests.

AppSecure is a specialised cyber security company with years of skill acquired and meticulous expertise. We are here to safeguard your business and critical data from online and offline threats or vulnerabilities.

Contact us: hello@appsecure.in

Uber has transformed the world. Indeed, its inconceivable to think of a world without the convenience of the innovative ride sharing service. Tracing its origins in a market which is constantly being deregulated, Uber has emerged triumphant. Operating in over 58 countries and valued roughly at US$ 66 billion, Uber has rapidly expanded to established branches in over 581 cities in over 82 countries with the United States, Brazil, China, Mexico and India being Uber’s most active countries.

If that wasn’t impressive enough, in 2016 the company completed a total of 2 billion rides in one week. When you consider the fact that the first billion rides took Uber 6 years, and the second billion was garnered in a mere 6 months, it’s not surprising to see Uber emerge as a global business leader. This worldwide phenomenon is built on a simple idea, seductive in its premise - the ability to hail a car with nothing but your smartphone.

It took the problem of hailing a taxi and gave everyone an equitable solution while further capitalizing on the emerging market. And smart people are asking the right question: How do I build an app like Uber for my business needs?

Humble Beginnings

It all started in 2008, with the founders of Uber discussing the future of tech at a conference. By 2010, Uber officially launched in San Francisco. In 6 months, they had 6,000 users and provided roughly 20,000 rides. What was the key to their success? For one, Uber’s founders focused on attracting both drivers and riders simultaneously. San Francisco was the heart of the tech community in the US and was thus the perfect sounding board for this form of technological innovation to thrive.

In the beginning, Uber spread their App through word of mouth, hosting and sponsoring tech events, and giving participants of their events free rides with their app. This form of go-to-marketing persists today - giving 50% discounts to new riders for their first Uber ride. This initial discount incentivized users to become long term riders, and the rest was history. As more and more people took to social media to tell the world about this innovative new App - the sheer brilliance of their marketing strategy paid off.

Product Technology Cohesion: How Uber Works

What makes Uber, Uber? For one, it’s the ubiquitous appeal, or the way in which they streamlined their product, software and technology. It was, at the start, fresh, innovative, and had never been seen before. So if one were to replicate the model, they’d need to look at Uber’s branding strategy.

To use Uber, you have to download the app, which launched first on iPhone, then extended to Android and Blackberry.

Uber’s co-founders, Garret Camp and Travis Kalanick, relied heavily on 6 key technologies based on iOS and Android geolocation. What really sold it though, was its clear core value - the ability to map and track all available taxis in your given area. All other interactions are based on this core value - and its what sets Uber (and will set your app) apart from the crowd. To build an App like Uber, you’ll need to have:

1. Registering/Log-in features: Uber allows you to register with your first name, last name, phone number and preferred language. Once you’ve signed up, they’ll send you an SMS to verify your number, which will then allow you to set your payment preferences. Trip fares are charged after every ride through this cashless system.

2. Booking features: This allows drivers the option to accept or deny incoming ride requests and get information on the current location and destination of the customer.

3. The ability to Identify a Device’s location: Uber, via CoreLocation framework (for iOS platforms) obtains the geographic location and orientation of a device to schedule location and delivery. Understanding iOS and Android geolocation features is crucial for this step, because that’s what your App is running on.

4. Point to Point Directions: The Uber App provides directions to both the driver and the user. Developers of the Uber App use MapKit for iOS and Google Maps Android API for Android to calculate the route and make directions available. They further implemented Google Maps for iPhone and Android, but cleverly adapted technology from other mapping companies to solve any logistical issues that might come up.

5. Push Notifications and SMS: You get up to 3 notifications instantly from Uber when you book a ride.

• A notification telling you when the driver accepts your request
• One when the driver is close to your location
• One in the off chance your ride has been cancelled

You further get the full update on your driver’s status, down to the vehicle make and license number, and an ETA on the taxi’s time of arrival.

6. Price Calculator: Uber offers a cashless payment system, paying drivers automatically after every ride, processed through the user’s credit card. Uber takes 25% of the driver’s fare, making for easy profit. They paired with Braintree, a world leader in the mobile payment industry, but other good options avaible are Stripe, or Paypal, via Card.io.

Here are few more much sought after features for the user’s side of the App:

• The ability to see the driver’s profile and status: Your customers will feel safer being able to see your driver’s verification, and it’s makes good security sense to ensure you know who’s using your App for profit.
• The ability to receive alerts: Receive immediate notifications about the status of your ride and any cancellations.
• The ability to see the route from Their Phones (An In built Navigation system): This is intrinsically linked to your geolocation features, you want to be able to direct your taxis to the quickest, most available routes.
• Price calculation: Calculating a price on demand and implementing a cashless payment system.
• A “spilt fare” option: Uber introduced this option wit great success. It allows friends to spilt the price of the ride.
• Requesting previous drivers: It’s a little like having your favourite taxi man on speed dial, and is a good way of ensuring repeat customers.
• Waitlist instead of surge pricing: Avoid the media hassle of employing surge pricing by employing a wait list feature, so your users can be added to a waiting list rather than be charged more than they should, and to keep them from refreshing the App during peak hours, reducing the resources required by your backend infrastructure.

Another key to Uber’s success, that should be noted by potential developers of similar Apps, is the way in which Uber operates. They tap into more than one market which equates to more riders, more drivers, and more business for the company. Uber has mastered the art of localization - the ability to beat out pre-existing markets and competitors, which further retains their customer base by improving their own business strategy.

They’ve taken local context and circumstances into consideration. For example, they partnered with Paypal in November 2013 to provide as many people in Germany don’t use credit cards, and switched to services based on SMS messages in Asia as there are more people but fewer smart phones per capita. This helps them cater to various markets and and optimize profits.

The Uber marketing strategy isn’t static - it’s dynamic. Expansion was necessary, and the business model reaps profits from saturating the taxi market with their customers and drivers, driving their exponential growth. What aspiring App developers can take from this is that you need to design your App for flexibility.

Design your App in a way that’s going to let it take a hit and roll with punches. Having a system in place that allows you to build and integrate changes effectively within the App and allows team members to communicate effectively is of paramount importance.

What made Uber so successful was its ability to reshape how we think about technology and its operation. Indeed it made the market a better, more efficient place through the innovative on-demand service.

What Technology is Uber Built on?

The tech side of the App is written largely in JavaScript which is also used to calculate supply and predict demand. With the real time dispatch systems being built on Node.js and Redis. Java, as well as Objective-C is used for the iPhone and Android apps. Twilio is the force behind Uber’s text messages, and push notifications are implemented through Apple Push Notifications Service on the iOS platform and Google Cloud Messaging (GCM) for the Android App.

How much does Uber make?

Actually, it’s a lot less than you think. The $66 billion valuation, after the 25% commission (which rounds out to about $0.19 per ride) mostly goes towards credit card processing, interest, tax, compensation for employees, customer support, marketing, and various anti-fraud efforts.

How much does it take to build Uber?

Uber’s not just one App, it’s two - one for the rider and one for the driver. The cost of developing an App like Uber is dependent on a number of factors

• the cost of building an MVP
• product development and acquisition
• getting the economics of marketing sorted
• the constant cost of building on and improving your App’s analytic capabilities

When you make an App like Uber, you’ll invest a fair bit into design services, backend and web development, project management, not to mention Android and iOS native app development. The total man hours round out to around 5000 hours for similar on demand taxi Apps, which puts the cost of developing such an App to around $50,000 (assuming that your team works for $50 dollars an hour). However, since hourly rates roughly range from $20 to $150, median costs could be higher or lower.

Conclusion

To wrap up, Ubers success was due to several factors, including a clear business model and interaction based features, and not the other way around combined with a marketing strategy focusing on attracting users.

The question on everyone’s mind of course is how can you reduce the overall risk of failure by making sure that your idea and product are viable when you’re developing an App?

One way is to use a Mobile App development partner (such as Octodev) that has worked on many such Apps and understands the processes involved. An advance of using such a partner is they’ve worked on many such App development projects and have the practical experience in product development to avoid the pitfalls and make the most of your vision.

Octodev App Development Process

Another important part of ensuring that your App development project is swiftly and smoothly executed is having a clear road map and regular communication during the project. There are many approaches to achieve this and we, at Octodev, use a consultative approach to App development. We draw from our successful App implementations. Get in touch with us now if you want an accurate cost for your own Uber like App idea.

This article was originally published on the Octodev Blog.

Uber and Cabify, the leading non-taxi rideshare companies in Latin America, both charge minimum fares. Only Uber has implemented time charges.

After running a simulation of 72,000 trips, we were able to observe the financial impact of opting in — or out of — features that we identify as valuable tools that hedge both ends of the partner-driver risk curve.

The partner-driver risk curve

Let’s assume that Company XYZ only charges by the kilometre and a base fare called banderazo in Colombia, and bandeirada in Brazil. By the way, base fare is not the same as minimum fare.

For a driver using Company XYZ’s app, all trips are not equal. The following graph shows how a driver’s risk will vary at different trip lengths and speed, when only charging by distance. The graph assumes that all other factors for the trip are the same.

As you move right across the X-axis, the distance of trips gets longer. Moving up the Y-axis means that cars are moving at higher average speeds. Drivers’ risk for Company XYZ increases in the opposite direction relative to average trip speed. This is because drivers spend more time on trips without charging for it. This graph is not meant to imply that trips follow a Gaussian distribution. Trips likely follow a right-skewed, Pareto-like distribution, as shown in the simulation below.

As shown above, Company XYZ drivers probably dislike both short trips travelling at slow speeds (due to heavy traffic, client stops, or other reasons) and especially long trips travelling at slow speeds. Long trips at slow speeds pose a much higher risk to Company XYZ’s drivers, forcing them to assume the opportunity cost (and gas expense) of time spent in traffic. When drivers do not charge for time, this tail risk is placed directly on them.

Simulating rideshare trips in Kanyeville

For the remainder of this study, we’ll use data obtained in one month from a simulation we ran for an imaginary market called Kanyeville (yes, named after Yeezy).

The simulation runs with the following assumptions:

• The distance of trips follow a right-skewed distribution
• Mean trip distance equals 4 km
• 20% of trips have a slow average speed of 5 km/hr, while 80% have normal average speed of 40 km/hr
• Each rideshare company in Kville (how locals call it) has an average of 200 daily active drivers. Each driver makes an average of twelve trips per day, totalling 72,000 trips per month, per company.

_Data generated using [SciPy](https://www.scipy.org/" rel="noopener" target="blank" title=")

The first chart shows trip distribution, by distance, at normal scale. The second uses a logarithmic scale to increase the visibility of the curve’s tail. In the log graph, the high variance in the tail, indicating that long trips, those above the mean-trip distance (MTD), can vary highly. In this sample, drivers drove trips that were as far as 60 km.

In this study, we analyzed two pricing features that impact different ends of the curve. Minimum fares increase monetization at the front-end of the curve (where short trips are found — meaning those under the MTD make up about 80% of total trips). Time charges have their highest positive impact on the curve’s tail, where longer trips are found.

Sure, time charges affect all trips. Anyone who’s been in a car knows the difference between being stuck in traffic while driving a couple of blocks and being stuck in a traffic jam while on the highway. Now imagine being a rideshare driver who only gets paid by the distance. We’ll also measure what this difference means financially to drivers.

The impact of the minimum fare

To measure the impact of minimum fare, the following script simulates the value of drivers’ fares over a month, with and without a minimum fare (MF):

Simulation results are shown in the illustration below. Daily gross fares are compared from different perspectives. Each scenario assumes a charge of $0.50/km and a $2.50 minimum fare:

The plots on the left compare the frequency distributions for daily fares. The minimum fares shift from the front end of the curve towards higher values. The gap in the graph on the top right shows how mean daily fares nearly double because a minimum fare is charged. Finally, the bottom-right plot shows the daily benefit, in dollars, from minimum fares. It shows a mean daily benefit of around $17 per driver. To be clear, these are the values of daily gross fare and have not been adjusted for company commissions.

In terms of cumulative probability, the following graph compares the curves of daily fare values for scenarios with and without a minimum fare:

The benefits of minimum fares are once again very clear. Nearly 50% of Kanyeville drivers make over $40/day in gross fares when they charge minimum fares. Only 10% of drivers who do not charge minimum fare make over $40/day.

These results make a good argument for minimum fares. This is probably why minimum fares are so common. But what about the impact of charging by the minute? We’ll take a look at that in the next section.

The impact of time charges

To measure the impact of charging by the second, the script below ran to simulate a month’s worth of individual trip fares, per driver, with and without a time charge:

Note: In this section, we imagine that there are two rideshare companies in Kanyeville: Company U and Company C. The only difference between their pricing structure is that the former has a $0.05/minute time charge.

Simulation results are shown in the four graphs below. Individual trip fares are compared between the two companies. One company only charges by distance ($0.50/km) and the other charges by both distance and time ($0.50/km and $0.05/minute):

Top left: Shows trip-fare frequency distribution when companies charge by distance only. Top right: Shows the trip-fare frequency distribution when companies charge by both distance and time. Bottom left: Same as top left graph, but on a log scale. Bottom right: Same as top right graph, but on a log scale.

In the graph above, the top row compares trip-fare frequency distributions between two companies. One company charges only for the distance of the trip (top left). Another company charges for both distance and time (top right). The second row uses a log scale to increase the visibility of the tail for both curves.

Why log the results? Because at normal scale, both distributions appear similar (with most fare price occurrences at the front of the curves). At log scale, the impact of the time charge is much clearer. The longer tail shows a larger number of high-fare trips. It’s important to note that for the companies represented in this graph, the mean fare values were $3.50 and $4.00, respectively. This indicates a 14% increase in average fares.

The plots below split low-fare trips from high-fare trips, for both pricing models, to review the change in mean and maximum-trip fares.

The time charge barely had an impact on low-fare trips (those below the mean), where it increased mean fares by roughly only 1%. However, the time charge played a crucial role on high-fare trips, where it increased mean fares by 31% and doubled the maximum-fare values.

Further, the following violin plots split the data by pricing structure, trip distance, and trip speed:

As expected, long distance trips with slow average speeds saw the highest increase in fare price — more than double — when a time charge was added. Out of the $41K in total monthly fares in this simulation, 66% came from long, slow trips. These occurred only 5% of the time.

The frequency of fare increases can be succinctly summarized in the following:

• There was no fare increase 60% of the time
• There was a 4% average fare increase, 15% of the time
• There was a 14% average fare increase, 20% of the time
• There was a 119% average fare increase, 5% of the time

The odds of seeing a fare increase can be better observed in the following cumulative probability graph:

The rider experience remains mostly the same. Only rarely (5% of the time) do high price increases kick in. However, for drivers, when that increase kicks in, it acts as a hedge. The increase effectively reduces the impact that heavy traffic and/or rider stops would otherwise have on the drivers’ daily income.

Essentially, when a rideshare company adds a time charge to its pricing model, it embraces long-tail events. This includes long trips in high traffic, which mostly favor drivers (who take a greater percentage of the fares). Companies that only charge by distance remain fragile to these events. The long-tail event risks are transferred completely to the drivers, who have to assume additional costs — such as gas, opportunity cost of their time, and wear and tear of their cars — without making any extra revenue.

Sure, the second company might argue that they purposely favor the rider by having the driver assume the tail risk. But one must wonder if this is actually sustainable. After all, riders and drivers have asymmetric impacts on the operations of their company.

A good way to quantify this asymmetry is to observe the stark difference that rideshare companies will pay for new riders and drivers. For example, some companies will hurl cash at their competitors’ drivers to get them to try their app — I’ve seen offers go as high as $500/driver — but, has anyone ever offered as much to a rider?

I’ve never seen a new rider get offered more than $25. But let’s say $50 was offered. That number still values a driver 10 times more than a rider. With that in mind, it makes sense for rideshare companies to protect their higher value users — the drivers — by transferring the tail risk to the riders.

Thanks for reading! If you enjoyed the article, hold down the ? button below to help spread the word.

You can find the code repository on my Github. Use it to run your own pricing simulations!

If you have questions about either implementing it for your own analysis, or want to collaborate on a future article, or simply wanna say “Hi”, hit me up on Twitter and/or LinkedIn.

We want it, and we want it 10 minutes ago.

We want it with no friction, no barriers, and most importantly, without talking to a human. If we don’t get it, we feel anxious. And this feeling has crept into our daily life.

There’s a reason why listicles outperform long form. We want all the information now. There’s a reason we won’t even watch a YouTube video if it includes a 30-second ad. We want that video now. When our Uber or our Halal Guys Chicken Platter is late, or we are unable to track the driver in realtime, we lose it.

Why? It’s embedded deep in the human psyche. As Neil Patel puts it:

In most psychological models, humans are believed to act upon the “pleasure principle.” The pleasure principle is basically the driving force that compels human beings to gratify their needs, wants, and urges. These needs, wants, and urges can be as basic as the need to breathe, eat, or drink. But they can be as complex as the “need” for an iPhone 6 or some other cool new product.

Beyond the Human Psyche and Into Business

If not already there, businesses are beginning to pivot towards instant gratification, the emotion that comes from being delivered a service or piece of information when the user demands it across every vertical and industry.

Deliver the data, the product, or the experience when the user requests it.

Take the on-demand economy. The masses are armed with smartphones and munitioned with applications. And as a result, that accessibility to technology has made the on-demand economy an appendage of how we operate on a daily basis.

You can literally have somebody else do anything for you with the push of a button. Do your laundry. Deliver your groceries. Pick up your child from school. Take your dog out to poo. The on-demand economy has revolutionized urban centers and rural areas alike, across the globe. And it’s only growing as new apps flood the market to solve problems that are both minuscule and mission critical to life.

Me, hailing a fake Uber

The on-demand economy is just one example of businesses driven by the sensation of instant gratification, but it’s not just about delivering a good or service in a short period of time. It transcends that. It’s about delivering something (like an experience or bit of information) when the user requests it.

This is huge. One of the promises of the Internet of Things is the instantaneous delivery of data from devices to other devices or end users. You can know immediately if your door is locked, your sprinklers are leaking, or your baby is crying. In a nutshell, successful businesses of the present and future are built on the sensation of instant gratification.

The next question, how will businesses deliver it, and what does the future hold?

The Underlying Technology That Drives Instant Gratification

Delivering instant gratification is no easy task, and requires a combination of underlying technologies, especially when it comes to scaling the application or service. However, as the technologies improve and more players enter the game, it’s getting easier, and more innovative.

There are three major pieces — the UI/UX, the serverless infrastructure, and the streaming. What will the users interact with, and how do we deliver the experience to them?

UI/UX

A beautiful and easy-to-operate user interface, and the experience it creates for the user is a driving force for instant gratification. There’s been a massive surge in innovative, beautiful APIs and platforms to build interactive UI/UX for web, mobile and Internet of Things apps. And even better, the best ones play nice with other APIs and platforms, creating a beautiful harmony of interworking functions. These APIs and platforms are what the user consumes and craves more of.

In looking at UI, take Mapbox for example. Mapbox is an incredibly flexible mapping platform that not only provides beautiful “pixel-perfect vector maps,” but a slew of mapping and geolocation APIs to power directions, navigation, geohashing, geocoding, and more. At a developer’s fingertips is a powerful, scalable solution to do just what their homepage does make maps that move you.

Mapbox makes mapping APIs to empower developers to make maps that move you (was that a mouthful?)

Less sexy than Mapbox, but equally important, are a steady stream of APIs and services that power the user experience. You may not know that they’re there (and if you don’t, that means they’re doing a good job). These services power a small piece of the user experience, and focus on just that.

Stripe handles billions of dollars a year, and offers a wide-variety of online payment APIs. Stripe is the reason that when you get out of your Uber or Lyft, your fare is paid. And your food delivery is covered.

Paying for stuff has never been easier

A seamless user experience, with a delightful user interface, to fulfill the instant gratification, is the result of dozens of interworking APIs, services, and platforms. Some you see, some you don’t, but all contribute to the instant gratification.

Realtime Streaming / Data Push

Beautiful user interfaces are nothing without good data. By good data, I mean getting the data where it needs to go, when the user wants it. It’s the glue that holds everything together, and the means behind delivering the instant gratification — instantly.

Lots and lots of messages being sent incredibly fast

At its core, this is done by sending and receiving small packets of data (most commonly JSON) through data centers from one place to another. And it’s important to note that data streaming is bi-directional, not one-way, so data flows seamlessly between any number of publishers to any number of subscribers and vice versa. You can break it down into two types of realtime interaction:

Streaming: the instantaneous transfer of data as it changes, in realtime. This could be streaming geocoordinates of a driver or package and publishing the location data on a live-updating map, an alert confirmation an order or proof of purchase in the form of a push notification or web alert, or an updated weather reading on an IoT sensor.

Data Push: sending a single message to any number of subscribers. This could be sending chat messages between users or triggering a device action, such as turning on a connected lightbulb via a mobile app.

Data streaming and data push is really at the heart of instant gratification. Users crave that updated data is it changes, and these protocols, and the infrastructure behind it, is what delivers it.

There are both open-source and hosted solutions for doing this. The main difference is that with open-source options, you’ve got the core protocol, but you’re responsible for servers, failover, device support, security, and more. Some examples include WebSockets, REST, and Socket.IO.

Hosted-solutions provide the data streaming protocols (and in some cases, additional realtime functionality), but also handle the infrastructure behind the scenes. Some examples include PubNub and Pusher.

(Serverless) Infrastructure

It’s not that you don’t NEED servers. It’s that you don’t have to THINK about those servers.

The infrastructure of the instant gratification engine is at the base of everything. It’s the cloud providers and the data centers. It’s the logging, provisioning, routing, load balancing development, deployment, and everything in between. And paramount to each of these areas is security and reliability. And this is now an expectation of apps everywhere today.

A key aspect of this is the affordability of it, and it’s why so many on-demand companies are able to come out of nowhere and disrupt a market. Services like Amazon EC2 let you rent servers and pay only for what you use. It may seem like a no-brainer, but this gives companies big and small enterprise grade servers, affordable no matter what size their company is.

And this is what’s led to the rise of _serverles_s, which is a bit of a misnomer in itself, but has been all the buzz lately. Serverless isn’t servers not being needed anymore, but rather developers not having to worry about servers, because they can outsource all that to a 3rd party and focus on developing, not sysops. As a result, we have teams able to build globally scalable apps at a fraction of the speed, without having to invest headcount and resources into infrastructure.

Looking Forward — Artificial Intelligence

Still in its early days, but guaranteed to be a big player is the growing adoption of AI, and how it can enhance instant gratification. Right now, we’ve got easily accessible AI that act as a personal assistant, coordinating meetings via email, so users don’t have to play email tag and wait hours or days to schedule a meeting.

HAL 9000 is here to help you buy new shoes, not kill you.

But AI will continue to advance and become a core part of the on-demand economy, and delivering instant gratification. IBM Watson is rolling out dozens of easily accessible innovative APIs to process inputs and deliver outputs in seconds. Watson, for example, can analyze a conversation for user sentiment and respond accordingly.

Taking humans out of the loop on tasks that are simple, but require the end user to wait, will be huge going forward. Expect chatbots and virtual assistants first, and more advanced AI services (Amazon Drones anyone?) further down the road.

So the question is, what will we deliver instantly next?