We examined the authentication procedures used by five prepaid wireless carriers when a customer attempts to change their SIM card, or SIM swap.
We found that all five carriers use insecure authentication challenges that can easily be subverted by attackers.
We reverse-engineered the authentication policies of over 140 websites that offer SMS-based authentication, and rated the vulnerability level of users of each website to a SIM swap attack.
We found 17 websites on which user accounts can be compromised based on a SIM swap alone.
🔐 Do note that 2FA using an Authenticator App/Device – I use Google Authenticator – to get a TOTP still is secure. The problem with SMS is the carriers that swap your phone number to another SIM without properly verifying things.
We couldn’t just choose [a framework] because the different tech stacks were picked by different teams (or even different sub-companies) for different reasons and we would have never succeeded if we would have tried to force everyone to use a specific technology like React.
Instead, we had the urge to create a technology-agnostic instead of technology-specific system. A system that is based on Web Standards and would survive the births and deaths of JavaScript frameworks.
I’m very curious to see how Stencil wil fare from all this.
React can be an accessible application framework with the right knowledge and the right know-how. The stigma that it is not an accessible framework is simply not true. It has some of the best built-in accessibility functionality there is out there, and a large community of accessibility advocates that are creating content that is easily consumable in your application.
React didn’t use a <div> for a <button>, you did. React didn’t force extra markup all over the page when you decided to not use a Fragment. React didn’t forget to change the title of the page because that was something you neglected.
Yes! Yes! Yes! … A thousand times YES!
I see many (new) devs enter the JS game to just start throwing things around, totally unaware of (or even worse: neglecting) the foundation layers which JS enriches: HTML and CSS. It all starts with HTML and semantics — many unfortunately tend to forget this.
With a huge chance of sounding like a skipping record regarding this: go read Jeremy Keith’s post “Robustness and least power”. In said post he quotes Derek Featherstone who said:
In the web front-end stack — HTML, CSS, JS, and ARIA — if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works.
Matthew Gerstman explaining a lot of terms that evolve around JavaScript: ECMA, TC39, Babel, Polyfills, …
So you Google how to make your app work in IE 10, or 11, or whatever. You’re quickly flooded with acronyms and terms you’ve never heard before ES5, ES6, ESNext, ES2020, TC39, ECMA. What’s a transpiler? People are debating about polyfills and ponyfills; is there a difference?
If you’re overwhelmed, that’s okay, it’s a lot. This article will attempt to cover the entire ecosystem around shipping new-ish JavaScript to older browsers and how the community decides what features get added to JavaScript in the first place; let’s dive in.
Today I needed to debug an IMAP problem. I got reports from a user (whose password I recently rotated) that Outlook wouldn’t connect, even though they entered the correct new password. The connection to the server was made, but the login attempt always failed.
As I didn’t want to add the account to my local mail client I resorted to the almighty curl to test the connection. Below is how I did that.
🤬 To jump ahead: Eventually it turned out that the newly entered password in Outlook was correct but that Outlook basically ignores it. The correct way to change a password in Outlook is to go to the Control Panel instead, and change it from there (in a window that is basically the same as Outlook’s). Makes sense … NOT!
~
Depending of whether you’re using a secured connection or not, use one of these:
Freek just shared his workflow to squash all git commits into one single commit — Handy for when you’re pushing a first public release of a project. His process involves removing the .git folder and starting off fresh again with a git init.
Wondering if there are handier/shorter ways to achieve this I set off on a Google Search and found some answers as detailed in this StackOverflow thread. Let’s go over the techniques mentioned.
The first commit made on an orphan branch will have no parents and it will be the root of a new history totally disconnected from all the other branches and commits.
This can be useful when you want to publish the tree from a commit without exposing its full history. You might want to do this to publish an open source branch of a project whose current tree is “clean”, but whose full history contains proprietary or otherwise encumbered bits of code.
After you’ve created the orphan branch, you swap it out the with the “old” master:
# Create a new branch, with no parent commits
git checkout --orphan squashed-master master
git commit -m "🎉 First commit"
# Overwrite the old master branch with the new one
git branch -M squashed-master master
~
2. Using git commit-tree
Creates a new commit object based on the provided tree object and emits the new commit object id on stdout.
The command below will create one commit object using git commit-tree and then reset the HEAD to that commit:
git reset $(git commit-tree HEAD^{tree} -m "🎉 First commit")
~
Alias it!
Since the git commit-tree method is a git one-liner, you can alias it:
As detailed in a Twitter thread, the site is built using Eleventy, deployed to Zeit, and screenshots of the sites are automatically taken using Puppeteer.
The source is open, so you can add new services by opening a PR 🙂
Google Fonts is great, but it also has a downside: it affects your page’s waterfall (during which some render-blocking may occur, as it involves CSS) as explained by Barry Pollard:
The problem is that your website (say www.example.com) loads the stylesheet from fonts.googleapis.com, which returns some CSS made up of font-face declarations.
This means you have to connect to fonts.googleapis.com, download the CSS, then connect to fonts.gstatic.com to download the actual fonts.
Fonts are often discovered late by the browser when loading a page (as you need to download the CSS to see them) but Google Fonts are discovered extra late, as you need to download the CSS from another domain, then the fonts from a 3rd domain and, as discussed above, making an HTTPS connection takes time.
This post goes really deep into how it all works. Covers things such as rel="preconnect", font-display: swap;, etc.
