Outlining security risks in ‘Nothing Chats,’ an iMessage app for Android made in partnership with ‘Sunbird’. Observe the poor security practices that made it into the production release.

You can read about our findings of ‘Nothing Chats’ post on the Texts.com blog at https://texts.blog/2023/11/18/sunbird-security/

I am the Team Lead, I praised the code. /s

This post is in response to, but by no means a dig on the blog post written by Zard-x on Medium called ‘I Wrote These 10+ Single Lines of JavaScript Code; the Team Lead Praised the Code for Being Elegant’.

One-liners are really cool challenges and very fun to make. I used to spend a lot of my time on codewars.com and codingame.com, which are two websites that facilitates little coding challenges which challenge your ability to write short code, or write code fast.

While code golf can serve as a fun engineering exercise, their lessons should rarely be used in the real world — and when they are — by no means should engineering managers be promoting developers to use this type of code in a codebase. When you’re in a collaborative environment, writing good code should be a priority. That means code that is readable, maintainable, and runs reliably.

Code golf is a type of recreational computer programming competition in which participants strive to achieve the shortest possible source code that solves a certain problem.

— Wikipedia, Code golf

Array Deduplication

Original Source Code

I’m not necessarily opposed to the common trick of removing duplicates from arrays by instantiating, and spreading a set, but due to the amount of times you’re indexing the array, it can be quite poor performance-wise.

Rewritten Source Code

On an array of 1,000,000 randomly generated numbers between 1–100, the original source code only performs at 12% of the speed that the rewritten version does. Since we use a map in the second function, we only have to iterate once over the array, and made it so that checking to see if we’ve already seen an element takes O(1) time.

The code eliminates “tricks,” and instead implores a well-known concept like hash maps, which may reduce the occurrence of inquiries by other developers on your code. The code also has well-named variables, with the function name removeDuplicateStrings defining the action that the function is doing, rather than an ambiguous name like uniqueArr, it also does not use excessively abbreviated words, making the code easier for non-native English speakers to understand.

Notice that the function is not documented. Excessive documentation can sometimes be a bad thing. If your variable names are well named, you may find your comments redundant, and that’s a good thing! If that happens, happily drop ’em, and ship it!

If we’re absolutely dead-set on using spread operators and sets, or we want to remove duplicates of values that are not exclusively strings without writing bloated functionality, all we need to do is document our code, and ensure our variables are well-named.

Get Parameters from a URL and Convert Them to Object

Original Source Code

If there was a bug with this code, how excited would you be when you figured out this is the function you’d be working on? Odds are, not so much. Not to mention that re-building JSON objects with strings is something you want to avoid as much as possible, in this case that’d be quite easy.

Rewritten Source Code

In the rewritten code for this function, we use the convenient native JavaScript URL API which automatically invokes an instance of the URLSearchParams object for us, then we simply use the Object#fromEntries function on the resulting object! This prevents us from having to manually construct a JSON object by mingling and mangling strings.

Notice that we’ve provided a comment for this function! Despite the fact that I’ve included a specification for which type of parameters the function handles in the name of the function getURLParameters, it’s not necessarily clear what format the resulting object would be in.

Check Whether the Object is Empty

Original Source Code

Using ownKeys or Object.keys are both not very performant when checking if an object is empty.

Rewritten Source Code

This rewritten code is an old school method, and man has it passed the test of time! The re-written source code performs 20 times faster than the original method, and that’s only with two properties on an object. The performance boost comes from the fact that you no longer need to create arrays, copy over values, and index keys. You see one key and you’ve escaped the function!

It might not immediately be obvious why we’re iterating over the keys of the object, so we’ve left a short comment in there to ensure that any other developers know what’s going on.

Reverse the String

Original Source Code

In this case, we’re not off to a bad start! We could use a for-loop to get an 80% performance boost on short strings, and we might consider implementing that method if we’re reversing some chunky strings often, but in the case of the odd reversal on lightweight strings, we might just be better off with this functionality.

Rewritten Source Code

Splitting the chained methods across multiple lines is a personal preference of mine, as it allows me to scan the function paths rather than jumping through them, however if someone asked me to change it I wouldn’t make a fuss.

For fun, here is a more performant version.

Generate Random Hex

Original Source Code

Once again, not off to a bad start! I particularly like that we’re directly referencing the maximum hexadecimal value supported for non-alpha colours! Some minor cleanup, and we’ll be in business!

Rewritten Source Code

The only major change I made in this example is that I changed padEnd to padStart. The way this function works is by generating a random 24-bit integer, and then representing it in its hexadecimal format.

The minimum value we can get is 0 0x000000, with the highest value being 16,777,215 0xFFFFFF.

Let’s say our randomValue ended up being 255. Our hexValue would then be ff, and if we padded the end, our return value would be #ff0000, versus if we padded the beginning it would be #0000ff. If we then translate both these values back into integers, #ff0000 would actually represent the value 16,711,680, while #0000ff would represent 255. This means that if we pad the end rather than the beginning, we’d effectively get the wrong value.

In addition to this fact, with the first method, by padding the end rather than the beginning, #0000ff would actually be impossible to generate. Meaning there are plenty of missing values that could not possibly be generated. Specifically, every value between 0x000001 and 0x100000. That is 1,048,576 missing values from our function, but would also tip the odds in favour of all values that end with a 0, some more than others. For example, #100000 would be the result from 0x1, 0x10, 0x100, 0x1000, 0x10000, and of course 0x100000.

Conclusion

That took longer than expected, so I’ll be posting a second part to this blog post at a later date. I had a ton of fun refactoring this code. Would you have done something differently? Leave a comment on Medium or dev.to! I think this is a great learning opportunity for everyone, and I value all feedback!

Want to read more of my stuff? You can check out my personal website. If you’d like to start a dialogue, feel free to tweet at me!

I Re-Wrote These 10+ Single Lines of JavaScript Code, the Team Lead Praised the Code for Being… was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is Jira?

For those lucky enough not to know, Jira is the biggest and by far most popular project management and issue tracking tool in and out of the software development space, developed by Atlassian, founded in 2002, and still one of Australia’s biggest international startups.

Atlassian has created an insanely powerful, customizable tool which boasts robust integrations, every product management feature you could ask for, and yet it seems that it’s often not the case that it’s seen as a piece of software more than it’s seen as a way of life. People live by Jira, and they’ll die by Jira, and I think it just sucks.

How does Jira suck?

The Workflow Detriment

Jira — as the software that handles my issues in a daily basis — should be the piece of software that I interact with the most on the daily aside from a team communication platform. ie. Discord, Slack, etc.

However, as much as I want to use Jira in that way, it just can’t be well-integrated into my workflow. It is tucked away into my web-browser, with slow load times combined with convoluted & unintuitive nested navigation to get where I need to go. I should not need to have a special, dedicated “Jira Hole” in my bookmarks to use it effectively.

Design Oversight Extravaganza

Jira is riddled with what are quite frankly some of the worst design oversights I have seen in any piece of “enterprise ready” software in my life.

Dare you accidentally hit the wrong key while crafting a lengthy, yet beautifully written text: it shall be sent to the nether never to see again, not a warning in sight. I often find myself in navigation loops, find myself making dead-clicks, or having to click buttons that are not buttons to get where I need to go.

User experience & user interface design is a very specialized and developed topic in 2022, I’d even consider it a science at this point, and Atlassian has managed to do it so poorly I simply cannot even fathom what is going on behind the scenes. I am a very download-happy person when it comes to trying out new software, and Jira’s user interface has to be the least intuitive, worst-design piece of garbage I have ever had the displeasure of laying my eyes on.

For software with origins in software development, it baffles me that Jira doesn’t support dark-mode. This means every time I open it, I get flash-banged.

Accessibility & Responsiveness

Thankfully in 2022, 20-years after it was created, Jira has finally addressed the inability for non-sighted users to use their software, yet it’s still not responsiveness to varying screen sizes. Come on.

Context Switching

The lack of a native application combined with the unintuitive UI, convoluted navigation, long loading times, content-layout shifts, inscrutable elements, etc., switching to Jira to edit, update, change or comment on a ticket requires a genuine need for context switching. Meaning it’s very common that you’ll lose momentum on tasks with higher cognitive load directly resulting from Jira.

The cluttered UI alone makes me feel like I’m operating a Boeing 747 in the comfort of my ergonomic chair, all while only having to flip one or two switches and click a button.

Performance

Working with Jira is like using the controls of military tank to drive a Tuk-Tuk. Complicated yet slow. Fun fact, when you open lightly populated Jira board view, you download ~24MB of data cross ~350 requests, and every ticket you preview is an additional ~20MB across ~90 requests.

That means if you open the Jira board view, and preview 10 tickets, that’s almost a quarter of a gigabyte that you just downloaded across over 1.25K requests, much of it uncached and redundant.

If we compare this to Notion with a highly-populated workspace, it initially downloads ~13.5MB over ~120 requests, with each previewed page downloading only about ~0.2MB over ~20 requests.

Customization Galore

One complaint many others have with Jira is just how customizable it is, management will go absolutely crazy with making Jira a completely new product, implement blocking processes and intense red-tape, and that’s why when someone complains about Jira the catch-all response is either “you’ve configured it wrong,” or “you’re using it wrong.”

Despite that fact, my experience with Jira has been rather minimalistic, never have I been on a team with overcomplicated processes around Jira itself, nor did we go crazy with the customizations, yet it was still problematic and abrasive to use.

Why does Jira suck?

Jira promotes bureaucracy-rich workflows that are built to convenience off-the-floor workers, managers, executives, etc., at the expense of those who are interfacing with it on a daily basis. As I outlined in the intro of this post, Jira is an insanely powerful tool, just not for the people who have their sleeves rolled up high. It generates amazing reports, fantastic predictions, fancy charts, great managerial tooling, makes imposing processes easier, has robust integrations, etc., and that’s why most managers I’ve spoken to really enjoy Jira, while on-the-floor engineers either range from fiery-eyed hate to toleration.

I think Jira does a good job of making teams look much busier than they are, but in the end I see it more as a “talk more not do more” situation.

A very common response I get when I ask developers why they use Jira is because they either don’t care, or haven’t found a suitable alternative.

The Alternative

Linear

Linear is the perfect antithesis of Jira. Rather than a slow, loose, unintuitive ticket management experience, Linear provides a highly fast and intuitive UI with realtime changes wrapped in a beautifully crafted, opinionated platform built with software developers in mind. It cuts out the unnecessary bureaucracy and leaves engineers with a ticket management experience that integrates very well into their day-to-day thanks to its desktop application, theme customizability, command palette, offline functionality, and speed. It integrates into a plethora of software including Zendesk, Intercom, Figma, GitHub, GitLab, Zapier, and gives you full-access to built custom integrations using their GraphQL interface.

Linear has been a pleasure to use on the teams I’ve worked on that have opted for it, as well as a no-brainer for collaborative personal projects. Although a potential downside to Linear is that it is built explicitly for engineers, thus may not be suitable for other teams such as marketing, design, etc.

Other Alternatives

If you’ve given Linear a try, but it just doesn’t work for you, some viable alternatives include GitHub Issues, Asana, ClickUp, YouTrack, Trello, Pivotal Tracker, and monday.com.

Real Quotes from Jira Users

If my article wasn’t enough of an articulation of the common frustrations with Jira, a small directory of quotes exists on a website called ifuckinghatejira.com, here are a few excerpts.

Jira is middle-management-ware, a term I made up for software that serves the needs of middle management, or, at least, the needs middle management thinks it has, which comes to the same thing as long as you’re selling to them. What are those needs? Metrics. Being able to make charts and graphs and summarized reports for the next-higher level of management, so they can say that their team is productive.

Every time I open Confluence or Jira I want to claw my fucking eyes out. It’s slow, hard to navigate, and terrible.

Tickets in JIRA are not the work itself, never was and never will be, it is a LARP of the work, but it gets taken for the central thing. This is an illusion. Fixing a bug without filing a JIRA ticket is in itself progress. Moving a JIRA card without any other change is not. Yet the second is what’s visible and therefor what’s rewarded.

I hate Jira. You need to watch a few hours of tutorials to be able to understand this piece of crap.

The momentum of its user base plus incoherent analyst opinions only serve to discourage moving to something actually useful/modern/user centered/updated/etc.

It is bad, really bad, like come on your page takes 5 seconds to load on every click with a 100Mb internet and loads of ram, seriously? I don’t want to talk about the super unintuitive interface. It is basically cancer. And you can’t use something else if your organisation decides to use it.

it’s not meant for devs but for project managers — and project managers like to make the devs do their job in that horrific tool. Imo there should be a dev view that is dead simple, and a PM view with all the complicated bells and whistles.

Even stripped down, it’s still too complicated. The wealth of features tend to lead to practices that can be bad for overall productivity even if they look useful on the surface.

JIRA is powerful. BUT… the UX is bloody awful. As in makes me want to stab myself in the eyes daily. The number of times I’ve lost content due to terrible and buggy UI is growing numerous.

JIRA. Fucking JIRA. Everybody just fucking hates it. It tops the list of shit pieces of software by a fair margin, followed by JIRA in second place and JIRA in 3rd.

Jira presents an excellent exercise on how not to do UX. The interface is slow, cluttered and unresponsive. Want to figure out how to do anything? God help you, because the design certainly won’t.

I avoid doing any kind of work with JIRA besides what’s absolutely necessary — and even then I pull my hair out in frustration.

Jira is so mind bogglingly awful, clunky and slow, I would rather peel off my skin and bathe my weeping raw flesh in a bath of vinegar than have to use Jira for one more day!

You can find more quotes like these are ifuckinghatejira.com, it’s a little cathartic, honestly.

You can read this blog post, and more like it on my personal website. Want to argue with me about how much you love Jira and disagree with my opinion? Tweet me @ridafkih on Twitter!

It’s all too common. You’re coding away in TypeScript, utilizing an external library, and you’re digging around the code for that type you just can’t find and… bam! The type you’ve been searching for is not exported!

You could either re-create the types locally, fork the repository and export the types, or work with what you’ve got! Today, I’m going to show you how to do the latter.

Inferred Return Types

Let’s say we’re utilizing a function from an external library which returns an object that lacks explicitly defined type information as follows.

When using this function, TypeScript will automatically infer the type as follows.

This is fine for basic usage, but if we want to do something with the type, it may become difficult.

If you’re unfamiliar with the ReturnType, your first instinct might be to recreate the type yourself.

Thanks to ReturnType, which takes a generic — that being a function type signature — we can get the return type even if its not explicitly named.

We can either use it directly, or assign it to our own named type.

Now we are able to use this as a property in another local function.

🎉 Awesome! This is so much better!

Nested, Unnamed Types

Sometimes we do have an exported type, but we just want one property of that type. Again, if you’re unfamiliar with TypeScript your first instinct might be to simply redeclare the type. However, we can actually access that by simply using our handy square brackets.

Let’s say we have the following interface.

Now let’s say we want to create a function that checks if a human being’s language is English, but we only want to pass in the language name in a type-safe manner, rather than passing in the whole human.

All we do is narrow the type down the interface using the keys inside some square brackets, and we’ve got a type safe function!

✨ Easy peasy, right?

Variable Unnamed Object Type Signatures

This one is a little more obscure, but something I ran into while creating a custom Notion renderer for the latest version of my personal portfolio. If we have an array where we have multiple possible type signatures of objects, and the possible object types in question are not named, things can get yucky very quickly.

As you can see, the attributes are inconsistent.

Let’s define an array of objects which utilizes our CustomHTMLElement type.

Let’s say we want to get a list of all the img elements, our first instinct might be to use the raw Array#filter method.

As you can see, the problem with this is Array#filter does not immediately respect type inferences. TypeScript still has no idea that any of the other object types have been eliminated as a possibility.

In this case, the inferred type of the return type of the getAllImgElements function is () => CustomHTMLElement[], so we still have the exact same original degree of ambiguity.

Thankfully, we can leverage the Extract generic type available in TypeScript 2.8+ combined with a TypeScript predicate to tell TypeScript what to expect after we’ve filtered.

Conclusion

TypeScript is an absolute beast, but because of the nature of its subset language: JavaScript, things can get a little funky sometimes. Luckily, we all love a challenge.

You can read more content like this on my personal blog!

If you liked this post, check me out on Twitter to be kept up to date on future posts! ❤️

A few months ago I spoke with CBC news to give an overview of a plethora of security flaws I found in PORTpass, an attempt to bring digital proof-of-vaccine to Canadians. While that article was meant for a broader audience, today I will outline their security flaws from a technical perspective for all the developers out there.

My Background

My name is Rida F’kih, I am a 21 year old Canadian software developer & reverse engineer at MaxRewards.

My development journey started at 15, from reverse-engineering to scammer-vigilantism then teaching coding to kids to web & mobile development.

What was PORTpass?

PORTpass was a private attempt by a local Calgarian entrepreneur to bring vaccine passports to Canadians.

The Data At Risk

The data at risk wasn’t light stuff.

PORTpass had the business requirement of collecting loads of personal data, collecting photos of government IDs, health card numbers, verification selfies, full names, dates of births, blood types, and more.

The data on PORTpass would be enough to be at risk of social engineering, or even have financial accounts opened in your name.

What went wrong?

First, we must familiarize ourselves with Murphy’s Law.

Murphy’s law is an adage or epigram that is typically stated as: “Anything that can go wrong will go wrong.”

— Wikipedia, Murphy’s Law

I’d argue that PORTpass was the epitome of Murphy’s Law from the perspective of the user, and criminal negligence on behalf of its creator due to their inaction after these issues were brought to light.

The Vulnerability

The primary vulnerability is called “Improper Access Control,” which is described by the Common Weakness Enumeration — a community-developed list of software & hardware weakness types — as “software [that] does not restrict or incorrectly restricts access to a resource from what should be an unauthorized actor.”

Some pseudo-code to describe a properly managed & created endpoint may appear as follows.

import express from "express";
import { loggedInUser } from "@/utils/authentication";
import { getUserInfo } from "@/utils/users";

const app = express();

app.get("/user/:userId", (request, response) => {
  const { userId } = request.params;
  const authenticatedUserId = loggedInUser(request);

   if (!authenticatedUserId  || authenticatedUserId !== userId)
     return response.status(401).send("Unauthorized");
   else
     return response.status(200).json(getUserInfo(userId));
});

Here, we would send a GET request to /user/[userId], and receive back user data only if we are authenticated into the same user we are requesting.

A poorly architected endpoint may be coded as follows.

app.get("/user/:userId", (request, response) => {
 const { userId } = request.params;

 if (!loggedInUser(request))
  response.status(401).send("Unauthorized");
 else
  response.status(200).json(getUserInfo(userId));
});

Here, we’re not checking which user is authenticated, only if the user is authenticated. Thus, an authenticated user could request ANY resource, even if it doesn’t belong to them. For public posts this is appropriate, for private information like government-issued photo IDs, health care cards, and confirmation portraits, this is a massive flaw.

The Catalysts

Sequential User IDs

PORTpass users requested their resource by using sequential user IDs. This means that if you were the first user to sign up for their service, your ID would be 1, if you were the second, it would be 2, etc.

Had they used a cryptographic solution — such as UUIDv4 — scraping user information would have been significantly more difficult, however in this case formulating a script to collect all registered user data was trivial.

/**
 * Gets the user profile from the PortPass API.
 * @param {number|string} userId The user ID of the target user.
 * @returns {Promise<any>} A user object.
 */
const getUserProfile = async (userId) => {
  const profile = await axios
    .get(USER_PROFILE_URI + userId.toString())
    .then((response) => response?.data)
    .catch(() => ({}));

  return profile;
};

for (let i = 0; i < 19577; i++)
  getUserProfile(i + 1).then(saveUserData);

No SSL

Since PORTpass didn’t have SSL certificates, packets that your device sends or receives could be altered or intercepted. With websites, its easy to identify a secure website by finding the little “lock icon” next to the URL, however with applications its a little more ambiguous.

Exposing Developer Tooling

PORTpass’ backend was created using Django, which has an interface which allows you to test endpoints from your browser without having to use REST tooling like Postman, or Insomnia. Optimally, PORTpass would have secured their endpoints so knowing their paths would provide no additional capabilities, however, they didn’t, and thus traversing their entire backend was trivial.

Conclusion

We all want to get our projects out there, but if we don’t have the experience necessary to accommodate for basic security considerations, getting your code reviewed or learning the basics of security should be considered good options.

In this case, a non-technical founder wanted to hastily get a product out there, so they hired a developer from overseas without the ability to evaluate the quality of code.

I’m very thankful to the CBC for their help in finally being able to hold the creator of PORTpass accountable, an address these concerns rather than simply ignoring them or claiming to be defamed.

Did you enjoy this content? You can read more posts like this by visiting my personal portfolio, and you can follow me on Twitter to get updates when I create new articles.

Click here to read this post on my blog.