This episode about the takedown and reinstatement of the video-downloading tool youtube-dl (Part 1, Part 2) makes three things clear.
One, centralised platforms like Github are single points of failure. This is especially unfortunate on the Internet, which is decentralised from the ground-up. Maintainers of projects like youtube-dl must invest in building a censorship-resistant presence online.
Two, despite decentralization, we need organizations like the EFF, the Mozilla Foundation, the Tor Project, the Wikipedia Foundation, the Internet Archive. To that end, we must support them monetarily and, if possible, by volunteering. We must also hold them to extremely high standards of ethics and neutrality and keep them from being beholden to, or even the appearance of being beholden to, a government or a particular tech company. If they make bad strategic decisions, we must criticise – constructively. They may not be big, but they are too important to fail.
Three, we must recognise that every one of us needs to be an activist for an open Internet. Our actions and inaction have consequences. If no one had expressed their opinion on this issue online – even merely through blog/Medium posts or tweets – it’d be harder for the EFF’s efforts to have the impact that they did. Think back to other instances where Internet companies have been pressured into reversing decisions due to public opinion: the tussle between Apple and the email app Hey being the most recent one. Hey’s founders have a great many followers they could rally, but it was those followers that made the difference. The greater your online audience your capital, the greater your responsibility to be a good citizen of the Internet.
The youtube-dl takedown notice fell into a more unusual category: anticircumvention—an allegation that the code was designed to circumvent technical measures that control access or copying of copyrighted material, in violation of Section 1201 of the DMCA.
Section 1201 dates back to the late 1990s and did not anticipate the various implications it has for software use today. As a result, Section 1201 makes it illegal to use or distribute technology (including source code) that bypasses technical measures that control access or copying of copyrighted works, even if that technology can be used in a way that would not be copyright infringement. Circumvention was the core claim in the youtube-dl takedown.
Establishing that, the post then goes on to state that in their opinion, the youtube-dl project did not circumvent technical measures:
Although we did initially take the project down, we understand that just because code can be used to access copyrighted works doesn’t mean it can’t also be used to access works in non-infringing ways.
Then, after we received new information that showed the youtube-dl project does not in fact violate the DMCA‘s anticircumvention prohibitions, we concluded that the allegations did not establish a violation of the law.
This new information came through a letter sent by the Electronic Frontier Foundation’s attorney [PDF] to GitHub. This is the highlight of the whole story for how well it explains what youtube-dl does and does not do. Quoting from the letter, not necessarily in the order in which they appear in the letter:
when a user requests certain YouTube videos, YouTube’s servers send a small JavaScript program to the user’s browser, embedded in the YouTube player page. That program calculates a number referred to as “sig.” That number then forms part of the Uniform Resource Locator that the user’s browser sends back to YouTube to request the actual video stream. This mechanism is completely visible to the user simply by viewing the source code of the player page. The video stream is not encrypted, and no secret knowledge is required to access the video stream… Importantly, youtube-dl does not decrypt video streams that are encrypted with commercial DRM technologies, such as Widevine, that are used by subscription video sites, such as Netflix
We presume that this “signature” code is what RIAA refers to as a “rolling cipher,” although YouTube’s JavaScript code does not contain this phrase. Regardless of what this mechanism is called, youtube-dl does not “circumvent” it as that term is defined in Section 1201(a) of the Digital Millennium Copyright Act, because YouTube provides the means of accessing these video streams to anyone who requests them.
To borrow an analogy from literature, travelers come upon a door that has writing in a foreign language. When translated, the writing says “say ‘friend’ and enter.” The travelers say “friend” and the door opens. As with the writing on that door, YouTube presents instructions on accessing video streams to everyone who comes asking for it.
youtube-dl does not violate Section 1201 of the DMCA because it does not “circumvent” any technical protection measures on YouTube videos.
This is wonderfully explained, and the analogy is spot-on.
I do not expect Github’s lawyers to have understood this mechanism when they first received the takedown request from the RIAA, but one would expect them to have discussed this with someone technical at GitHub, who either knew or could have asked the project about this mechanism, and this technical person and the lawyers could have determined that it did not circumvent technical measures. My guess is that in an effort to project neutrality, they did not initially take a stance one way or another. Indeed, the blog post has a short section at the beginning titled “Why did Github process this takedown in the first place?” which doesn’t really address why they went all the way to removing the youtube-dl project if they understood the issue:
As a platform, we must comply with laws—even ones that we don’t think are fair for developers. As we’ve seen, this can lead to situations where GitHub is required to remove code—even if it has a multitude of non-infringing uses—if it is in fact designed to circumvent a TPM. But this is exceedingly rare.
I think it’s the EFF’s advocacy, finally in the form of a legal document, that gave GitHub the confidence – or cover – it needed to do the right thing. That combined with the public outcry against this.
What worries me as much as the end of general-purpose computing for the masses is that so few seem to understand that it is ending. Many are content to use “devices” that are merely stripped-down Internet appliances masquerading as reasonable substitutes for what they have replaced. Has the word “device” been substituted for the word “computer” in an effort to erase even the memory of what we are losing? Many do not understand, because they are too young to ever have used a true general-purpose computer. They have no experience with anything but locked-down platforms–just as 96% of the generation before them knew nothing but Microsoft operating systems. To call this a tragedy is not being overly dramatic.
People find ways around oppressive practices [but] I also know that solutions can sometimes take decades to appear. Whole generations can be lost in the mean time. This is why the trend toward stripped-down, Big-Brother-controlled computers has me genuinely worried. I am not looking forward to a near-term future in which my operating system is so locked down that I cannot install the software I want. Many have already reached this future, perhaps without even having realized it.
One could imagine a worse scenario than restricting the distribution of ‘forbidden’ of binaries: the Mac is the development platform for MacOS, iOS and other Apple operating systems. The toolchain is entirely Apple’s, right down to the compiler/linker. It isn’t far-fetched at all for Apple to identify and refuse the compilation of code – that is, even if you managed to get hold of the youtube-dl source code, your Mac could refuse to turn it into an executable binary for you, even just to run on your own machine.
This is not an outlandish scenario. There have been countless examples of Apple taking software off its App Stores. But Apple has also revoked developer certificates for iOS before, most famously with Facebook. It is not hard to imagine Apple taking this one step further to disallow compilation of what it considers disallowed code.
The two big distinctions between an operating system for a ‘personal computer’ like a desktop or laptop, and one for a phone or tablet are (a) the ability to run arbitrary software on the machine and (b) the ability to build software for the machine on the machine. The freedom to do either on Big Sur for Apple Silicon is severely constrained.
2. The operating system is controlled
The bootloader on Apple Silicon machines will be locked. This means that they will not support booting into other operating systems like Linux.
The Verge also referenced the same section of the podcast in the specific context of Apple’s BootCamp service with which people could dual-boot Windows and Mac OS on Intel Macs:
Apple later confirmed it’s not planning to support Boot Camp on ARM-based Macs in a Daring Fireball podcast. “We’re not direct booting an alternate operating system,” says Craig Federighi, Apple’s senior vice president of software engineering. “Purely virtualization is the route. These hypervisors can be very efficient, so the need to direct boot shouldn’t really be the concern.”
Of course I’d like to see a clear statement from Apple than a comment in a podcast, even if it was Federighi who made it.
But this means you also don’t have the option to use just the Mac hardware and install your own software, as people do with Linux (and Windows) on their Macs today. In other words, you cannot install an open source operating system with an open source toolchain to compile and run open-source software on the M1 Macs.
3. The architecture is controlled
The M1 (and all of Apple’s system-on-chips) are not licensed. This means only Apple can manufacture them, and consequently the only machines that can have M1 chips are Apple Macs.
This is as opposed to the thousands of different laptops, desktops, tablets, two-in-ones and other machines that run on x86 and x86_64. Intel, AMD, VIA and other companies typically only manufacture the processor, not entire system-on-chips. So you have computers with different processors, graphics cards, RAM and input-output capability, with different BIOS/UEFIs with support for different bootloaders and, therefore, different operating systems – even more than one on the same computer.
But so in the Apple world there’s no concept of buying an ‘alternative’ M1 machine with an unlocked bootloader so you can install Linux or BSD or another open OS on it.
The lock-down is utter and total.
Summing up
So. MacOS on the Apple M1 Mac computers severely limits what software you can run on it. The locked bootloader prevents the installation of anything other than MacOS. And the proprietary nature of the chip prevents the existence of any alternative M1 computers without locked bootloaders.
For most people – Apple’s customers – these restrictions are all a net positive. They make their computer safer. Developers that make software for ordinary people now have to jump through some additional hoops, but that is in order to make things difficult for malware creators.
But for those who value openness and want control over their software, the M1 machines are closed at every layer of the stack. Look for alternatives.
Update: Point 2 may have changed. Here’s a Reddit discussion that points to a WWDC 2020 video stating that non-signed operating systems can be made to run on M1 Macs. I’m speaking to people to understand this better. If this is true, it also makes Point 3 moot, though not untrue.
By designing the Mac operating system specifically for this hardware (and vice versa), Apple’s M1 computers are now much more powerful at the same power consumption levels than their equivalent Intel ones.
However, with this chip, Apple’s computers are well and truly closed machines.
This closed nature is a problem because of just how much control it takes away from you, who’s paid for and ostensibly owns the machine and the software on it.
Let’s see just how bad it is.
1. Application software is controlled
The question is one of control over the software that you can run on the machine. With the M1, Apple will only allow signed software to run. From Apple’s documentation ealier this year:
New in macOS 11 on Apple silicon Mac computers, and starting in the next macOS Big Sur 11 beta, the operating system will enforce that any executable must be signed with a valid signature before it’s allowed to run.
Over the years, Gatekeeper has become more strict, recently adding a notarization requirement. On macOS Catalina, Gatekeeper not only checks whether the software was signed by a valid Developer ID certificate, it also “phones home” to check whether Apple has notarized the software, again refusing to run it if the check fails. Mac developers must sign up for the Apple Developer Program, sign a legal agreement, and pay an annual fee of USD $99 plus tax in order to obtain a Developer ID code signing certificate and upload software to Apple for notarization.
This article goes on to describe how – while not obvious – one could override these warnings on Catalina and run unsigned software. On MacOS Big Sur running on the M1 chip, Apple appears to have removed this exception. No matter what software you download and run – whether command-line tools or graphical applications – they will need to be signed.
This level of control means that Apple could refuse to sign certain apps if it wanted to, for reasons that have nothing to do with security. We have recently discussed how the youtube-dl project was taken off the code hosting site github. In the future, should Apple decide, it could disallow the running of youtube-dl binaries entirely, either downloaded from github or sourceforge or others. The only way that anyone would be able to run this tool would be to download the source code, compile it themselves and run it on their computers only by issuing themselves a local certificate to sign with. But they would not be able to hand that compiled code to someone else – even another Apple M1 machine they own – without compiling it separately.
That effectively kills distribution for software that Apple chooses to censor.
A long-time iOS engineer I know, who I ran this post by, had the following counterpoint:
Apple is definitely making it a pain for anyone to arbitrarily run 3rd party executable code, but to me the end result is just that developers will have to jump through a few more hoops. There will probably be a homebrew/pip/npm like solution that solves this soon. The end user should not see any significant change if they’re coming from modern Macs.
As for the Developer ID requirement – anecdotally I have only heard of one developer whose certificates were unilaterally revoked. Apple is far more likely to suspend your developer account and leave the certificates. This still makes Apple the arbiter of what you can run on your computer, and they will charge the developer for that privilege, but if you’ve only ever run GUI apps on your Mac this has been effectively the case for several years.
However, even Mac OS Catalina, leave alone Big Sur, appears to check for notarization of unsigned executables – even those not built using XCode. A simple hello world program compiled directly using clang is still subject to the same notarization check.
(Part 2 – It’s not just software; it’s control at the Operating System level and at the chip level)
a person… bought a used Tesla from a dealer—who in turn bought it at auction directly from Tesla under California’s lemon law buyback program—advertised as having Autopilot, the company’s Advanced Driver Assistance System. The entire Autopilot package, which the car had when the dealer bought it, costs an extra $8,000. Then, Tesla remotely removed the software because “Full-Self Driving was not a feature that you had paid for.” Tesla said if the customer wanted Autopilot back, he’d have to fork over the $8,000.
To be clear, this is not a subscription service. This is a one-time package that was paid for by the original buyer, upgrading the car’s capabilities over software. Tesla’s policy here is that the purchase belongs to the owner, not to the car. There still appears to be confusion about whether enhancements can be transferred to the new owner. I couldn’t find anything on Tesla’s site, but found these two contrasting threads. One, on Tesla Motors Club titled “Why is FSD not transferable to your next Tesla?” FSD is full self-driving. The second is on the Only Used Teslas site, “Does Autopilot/Full Self-Driving Transfer to Subsequent Owners?” which states that it in fact does:
Q: What about owners who added Autopilot and/or Full Self-Driving Capability after delivery? A: Those features will also be active for the life of the car, and will transfer from the current owner’s Tesla account to the next owner’s account.
TNW spoke with a number of new and used Tesla sales departments in the UK who all confirmed that if a second-hand Tesla is specified with additional options like Autopilot and FSD, that is what the customer will receive.
In the case of the individual mentioned in the Vice article, Tesla did restore the functionality the original owner had bought, but only after the car enthusiast website Jalopnik ran an article about it – and Vice and The Next Web.
We have seen before (here and here and here) about “smart” devices that you do not own despite having paid full price for. A Tesla seems to be among the most expensive one in that list.
I’m not advocating for or against buying a Tesla – or for that matter any smart device [1]. I do think we should be more conscious, more circumspect when we buy new devices, since an increasing number of them have electronics, a connection to the Internet, and a link to the manufacturer throughout their lifetimes.
Advertising is sexy. Skepticism never is.
[1] I had in fact paid the deposit for two Model 3 units when they were announced in 2016 (and had it refunded when it was clear Tesla would not be launching in India any time soon).
I wrote earlier about the code of the youtube-dl project being taken down by the Microsoft-owned code-hosting website Github, in response to a notice by the American music industry’s RIAA.
Numerous reporters told Freedom of the Press Foundation that they rely on youtube-dl when reporting on extremist or controversial content. Øyvind Bye Skille, a journalist who has used youtube-dl at the Norwegian Broadcasting Corporation and as a fact checker with Faktisk.no, said, “I have also used it to secure a good quality copy of video content from Youtube, Twitter, etc., in case the content gets taken down when we start reporting on it.” Skille pointed to a specific instance of videos connected to the terrorist murder of a Norwegian woman in Morocco. “Downloading the content does not necessarily mean we will re-publish it, but it is often important to secure it for documentation and further internal investigations.”
Central to all of these examples is the fact that journalists can process a local copy in ways that the video hosting platform does not offer. It’s possible to download a high-quality video and audio file from YouTube [1], but the quality at which YouTube streams that same file in your browser depends on the quality of the internet connection, your actual device.
There is a perfectly good reason for YouTube streaming a lower-quality version: you want your viewing experience to be as lag-free as possible. But seeking to remove tools like youtube-dl take away choice in the matter.
Similarly, as the article describes, journalists use downloaded files of protests or events for further video or audio analysis. They may use it to compare video frames, voices and so on. These are not features that YouTube provides – once again, justified.
The appeal of YouTube is its audience, which is why people post videos there in the first place. So YouTube optimises for ease of use and discovery [2] not for analysis. Once again, seeking the destruction of youtube-dl, and presumably others like it, means removing all other capabilities than just passive viewing.
The USA recording industry’s massive overreach to safeguard its narrow – and narrowing domain, and Microsoft/Github’s capitulation, has great implications for access to information world-wide.
[1] Remember that YouTube is only one of the video hosting and streaming sites that the unfortunately-named youtube-dl supports.
[2] There are other issues there with YouTube’s recommendation algorithms often promoting misinformation and indirectly inciting violence, but that is another topic for another day.
A scammer can use the same tricks against you on your other accounts, like your Gmail. Such attacks are more common than you think. According to this BBC article from April, Google was blocking 100 million phishing emails a day.
What does a Gmail phishing attack look like?
Phishing techniques improve every day, and are quite sophisticated even today.
You could get an email that looks like it’s from Google, but is not, asking you to tap a button – it could say it’s for account maintenance, to accept new terms and conditions, to download a Google Doc someone’s shared with you or a number of other things.
When you click on the button in the email, you get a screen that looks like this:
This screen looks like it’s from Google, but it isn’t. The only way to tell is by carefully looking at the URL (the web address in the bar). For most of us who are perennially distracted, it’s really hard to tell the difference.
You enter your username and your password, but it’s read by the attacker instead of by Google. You have lost control of your account. Your attacker can now use Google’s security features against you and log you out – from your browser, your Gmail app, Google Docs – everything.
If someone gets access to your Gmail account, or any other email account like Yahoo, Outlook or iCloud, they could then get into other your other accounts – Instagram, Facebook, Snapchat – by sending a password reset email to that email account, and then changing the password.
How do I protect Gmail – and my other accounts?
Gmail has support for two-factor-authentication, that is, support for a second layer of protection beyond your password/OTP.
This second layer is a six-digit code that you enter after you have entered your email address and password on a new computer/app install. So you see two login screens, one after another, instead of one.
As we will see in detail below, the scammer may be able to trick you into giving up your Gmail password, but it’s really hard for them to be able to get your two-factor code.
Not just Gmail/Google, here is a list of common accounts that you can and should enable this two-factor-authentication for:
Gmail (or Google) account
Apple iCloud account
Facebook
Instagram
Snapchat
Linkedin
Twitter
Dropbox
But, you ask, how is it practical to remember six-digit codes for all these accounts? Surely it isn’t wise to use a single code for all these accounts.
That’s right. In fact, you don’t need to remember any of these codes at all.
You will use a new app, Authy, to generate new six-digit codes whenever you log into Gmail or these other accounts from a new phone or computer.
Authy is a dedicated two-factor-authentication app (now owned by the Internet infrastructure company Twilio.) You can see a screenshot of my own Authy app with two-factor set up for several accounts.
You can see that Authy’s auto-generated a code for one of my accounts which I can just type when I login. So I get the full benefit of this second layer of protection without remembering codes for any of these accounts.
You can install Authy on more than one device – say your iPhone and iPad. You can even install it on your desktop computers. You secure the app itself with an Authy password – which is the only password you need to remember (or store in your password manager).
Setting up your Gmail account with two-factor protection using Authy
Keep the following handy: the Gmail app on your phone. And a laptop browser window.
Now. Login to your Google Account Management page at accounts.google.com. Tap the “Security” section on the left. Scroll down to the “Signing in to Google?” section. You’ll see that “2-step verification’ is off. Click it.
Now you’ll go through a simple wizard to set up your two-step verification. Tap Next on the Introduction screen:
Tap “Continue” on the next screen, titled “Use your phone as your second step to sign in”
Now on the next screen, the wizard says that Google has sent a notification to your Gmail app.
Launch the Gmail app on your phone and instead of your inbox, you’ll see a login notification. Tap Yes.
On the next screen, “Backup”, tap “Use another backup option”
You’ll see a bunch of recovery codes. Tap “Download”. Rename the text file to “Gmail Recovery Codes” and save the file in your My Documents folder.
Just one more step: On the next screen, under the “Add more second steps to verify it’s you”, tap the “Authenticator App” section.
On the next screen, choose whether you have an iPhone or an Android phone. I picked iPhone, but the steps are the same.
On the next screen, you’ll see a QR Code displayed.
Now on your phone, open the Authy app. Tap “Add Account” and pick “QR Code”.
Scan the QR code on your laptop screen. Your Authy app will immediately identify and add the account. And start displaying six digit codes.
The screen on your browser will automatically refresh to ask for a six digit code. Enter the six digit code that’s displayed on your phone’s Authy screen.
You’re done! Now, when you sign in to Google or Gmail or Google Drive on a new browser on your laptop, or a new app install on your phone, you’ll enter both your username and password, and then the latest six-digit code on your Authy app. That’s it!
Logging into Gmail with your new, secure two-step flow
Here is what your new login looks like. First, your user name and password as usual:
Your account’s login screen will then ask you for your second-factor code.
At this point, you look for the code in the Authy app. Authy will generate a code that is valid for a maximum of 30 seconds.
Type this code in the login screen and you’re done!
Why two-factor authentication protects your Gmail account
Let’s go back to the example at the beginning of the post. We saw how you could receive an email that looked very much like it was from Google. It has a link for you to click – the email could say that it was for account management, reviewing and accepting new terms and conditions, or a number of other things.
You don’t review the sender’s email address, which Gmail and other email apps usually collapse, and you need to tap a button to reveal. You think it’s a legitimate email, click on the link, and are taken to a very realistic-looking Google authentication page, asking you for your email address and password, which you enter.
At this point, because the web pages were hosted by a scammer and not by Google, they now have your password. They can now log into Gmail – or your Google Account and prevent you from logging back in.
But if you had 2FA set up, once the scammer entered your email and password into the Google login screen, they would be asked for your second-factor code. They don’t have it. They have no way of going back to you and asking you for another code.
But could they not have asked me for the second-factor code when they displayed the fake pages? Here’s the problem for them: they have no way of knowing in advance if you have two-factor authentication enabled on your account or not.
Finally, when they attempt to log in using your (scammed) password, you’ll get an email immediately from Google, which looks like this:
You’ve probably seen this email often – but don’t ignore it!
You will know immediately that something is wrong, since this was not you. Once you know this, you can – and should – change your password right away.
(You’d get this email even if you did not have 2FA setup, but by that time it’d be too late, since the attacker would have logged in to your account).
Protecting from really malicious attackers
But what if the scammer was someone who knew you, who is targeting you specifically, who knew – somehow – that you have two-factor turned on, and custom-built a two-factor flow to phish you? A couple of things:
One, your two-factor code is only valid for 30-second intervals. Subtract from that the time it takes for you to look at the code, memorize it, switch back to the login screen, type it (or, if you copied it, then paste it), and tap next. The attacker now needs to copy that code from their malicious code into the Google login screen they’re using to get into your account within whatever few seconds are left. It’s not impossible, but it’s really hard, and even harder to get right in the one shot that they have.
(And it’s not like the 30 second countdown starts when you open the Authy app. Try it – you could well open the app midway through a 30-second cycle, so the time the attacker has is even less).
Two, when you log in with your two factor code on any browser, select the ‘Don’t ask again on this computer’ box on the two-factor screen:
Why would you want to tell the browser to bypass the second factor? Because access to your browser is safe – since it’s on your password-protected phone or computer – and now you can distinguish between a trusted and an untrusted page. How?
Let’s go back to the truly malicious attacker, who has found out beforehand – somehow – that you have set up two-factor authentication, and has created a fake Google-like flow that asked you for your second-factor code. You are fooled by the genuine-looking email, and you click on the link. Your browser opens. You are further fooled by the genuine-looking login page, so you enter your username and password. Now you see a genuine-looking second-factor page.
At this point, you should immediately be suspicious – you’ve explicitly specified to this browser that you don’t want Google to ask you for a second factor code. That should tell you it’s not a genuine web page, and you can pause and check the email and the login page are genuine.
Links to set up two-factor authentication for Instagram, Facebook and other social media
Authy has helpful guides with steps and screenshots for setting up 2FA for many common services. Everything above on how 2FA protects your Gmail account is applicable for all the services below.
If you own an iPhone, Mac or iPad, you should also turn on two-factor authentication for your Apple iCloud account using these instructions. The only difference is that you don’t need to use Authy. Apple will send the second-factor code to one of your devices as a notification.
Remember
In each case, choose to use an ‘authentication app’ over using ‘SMS’. Add the account to Authy in the same way as in the Gmail example above.
In each case, save any recovery codes that are displayed on screen. In the rare case that you are locked out of your Authy account AND need to use your second factor for one of your accounts, you can use one of these recovery codes to log in.
So. I hope this gives you a good idea of not just the what, but also the why and how of protecting your accounts with two factor authentication.
If more of us do this, and spread the word, we can defeat phishers and scammers – something unimaginable today.
Appendix: questions I usually get about two-factor authentication
Why not have my second factor sent to me over SMS?Why bother with a whole new app?
After all, this is how the “3D secure” protection works on credit card payments. Your credit card number and expiry are like your username, your CVV is your password, and then the SMS you receive from Visa or Mastercard or American Express or RuPay is your second factor.
The problem is that SMS as second factor is known to be insecure. Motivated attackers have been able to take control of your mobile number itself using a technique commonly known as SIM swap. After such an attack, your SMSes are now sent to their phone instead of yours. This 2020 CNET article describes this method:
Hackers have been able to trick carriers into porting a phone number to a new device in a move called a SIM swap. It could be as easy as knowing your phone number and the last four digits of your Social Security number, data that tends to get leaked from time to time from banks and large corporations. Once a hacker has redirected your phone number, they no longer need your physical phone in order to gain access to your 2FA codes.
Positive Technologies was able to hijack the text messages using its own research tool, which exploits weaknesses in the cellular network to intercept text messages in transit. Known as the SS7 network, that network is shared by every telecom to manage calls and texts between phone numbers. There are a number of known SS7 vulnerabilities, and while access to the SS7 network is theoretically restricted to telecom companies, hijacking services are frequently available on criminal marketplaces.
As of today, it’s unlikely that a casual attacker will resort to SIM swapping or an SS7 attack. But don’t discount malicious attackers – ex employees/teammates, a relationship that ended badly, a competitor, or someone who values access to your email/social media to get info about someone you know.
Why use two-factor codes instead of Google’s default notification system?
Google today pushes you to use its notification system as your second factor. This doesn’t require you to copy and paste time-sensitive six digits codes, ostensibly making your second factor login experience simpler. This is how it looks. After you enter your email and password, you see this screen:
If you open your Gmail app, it’ll open to this screen:
If you tap yes, your browser proceeds to your Gmail/Google Drive/whatever Google service you were logging into. This works across devices – you could be logging in on your laptop and tap Yes in the Gmail app on your phone.
Clearly there are advantages.
One, you’re not reading and re-typing six digit codes, so there’s no chance you’ll mis-type anything.
Two, it’s a single tap, so it’s much faster – there is no chance that the code will have expired by the time you paste it.
Three, the notification shows you the location of where the login is taking place. If your attacker isn’t in the same city as you, this is an immediate sign something is wrong. Same with the device. If you don’t own a Mac, and the notification shows that the login is taking place on one (like in the screenshot), you’re being phished.
Four, the 2-step verification screen lists the names of your device(s) that have Gmail installed. You can see that the text in the screenshot says “Google has sent a notification to your Rahul Gaitonde’s iPhone and Rahul’s 12.9” iPad Pro”. It’s almost impossible for an attacker to know this level of detail about you, so the fake two-factor screen that they present to you will almost certainly not name your devices.
So why should you use the Authy app instead of this seemingly elegant method?
One, everything we’ve seen above only applies to your Google account. To secure your Instagram, Facebook, Snapchat, Uber and other accounts, you’re going to need a code-based method anyway. Simplify your life. Use one solution instead of many.
Two, there is a real security downside.
Let’s revisit our walk-through of the phishing attempt. You’ve been fooled into clicking on a phishing email, fooled into entering your email and password on a phishing login page. In addition, your attacker, who is targeting you personally, has determined that you do have two-factor on, so they’ve created a page that resembles the 2-step verification screenshot above. As you enter your user name and password, they copy the password into an actual Google login screen, ready to get into your account.
Now, since you’re distracted, it’s likely you’ll fail to notice the location and device in the 2 factor notification in your Gmail app. After all, you haven’t noticed that the email – and these login screens – aren’t genuine. So. If you tap the notification (because you think you are in fact logging in), your attacker is in – instantly.
Contrast this to if you had pasted or typed your two-factor code. As we have seen above, it’s time-sensitive. And therefore
… your two-factor code is only valid for 30-second intervals. Subtract from that the time it takes for you to look at the code, memorize it, switch back to the login screen, type it (or, if you copied it, then paste it), and tap next. The attacker now needs to copy that code from their malicious code into the Google login screen they’re using to get into your account within whatever few seconds are left. It’s not impossible, but it’s really hard, and even harder to get right in the one shot that they have.
(And it’s not like the 30 second countdown starts when you open the Authy app. Try it – you could well open the app midway through a 30-second cycle, so the time the attacker has is even less).
In the case of the Gmail notification, the attacker doesn’t have to do any work. You tap the notification, they’re in. In this case, they have to read, copy, paste the code and tap Go within a tiny unit of time that they don’t know.
Why use Authy instead of the Google Authenticator app?
Google’s guides heavily promote their own Authenticator app over others like Authy. Even their code-based two-factor login screen refers only to the Google Authenticator app:
I’ll point you to Authy’s comparison guide, but here are the main bits: Google Authenticator is only available on mobile devices (not Macs or PCs), it can only be installed on one device at a time, it can’t restore from encrypted backups like Authy can.
The one-device limitation has caused problems in the past,. Due to a combination of factors, I was once forced to reach out to Google support to restore access to my account:
If I had been able to install Google Authenticator on my iPad or Mac, this wouldn’t have been an issue at all.
Disclosure: I own stock in Twilio, which owns Authy. I have no other relationship with Authy and received no compensation from Twilio/Authy for this article.
… these ideas often formed at the seam of the “natives” versus the “immigrants.” If you are Instagram-native, what you consider a great idea for a new retail space or ecomm brand is likely very different than someone who isn’t exposed to the same thousands of pics…
The upcoming generation are using tech in a different way. They are Fortnite-native. Minecraft-native. They are streaming-native. They use “insta” differently. Food delivery will be considered a human right. The expectations will be very different.
I often think about how different generations think about the Megatrends and Big Questions that we explore on this site.
Xennials like me were born in a mostly analog world, but grew up when PCs became common in people’s houses. Millennials always had a PC in their houses, connected to the Internet, and grew up with Nokias and Motorolas. Gen Z have not experienced a life before smartphones with 3G connections.
I think that the answers to making the right choices about each of these issues is timeless, but it is the natives, to use Andrew Chen’s term in this context, who will get the word out most effectively. Building an audience will come naturally to them. And because they have navigated social networks in their most socially fraught years in school, are well aware of an audience’s value as capital.
Immigrants like me will use more traditional mediums, like this nearly two decade old blog, and traditional models, like the megatrends and big questions, to raise awareness.
The youtube-dl project is no longer available on Github. A crying shame. youtube-dl is used not just to pirate – it’s also to archive videos of protests & rights violations before they’re taken down – depiction of violence is a violation of YT’s TOS! 1/
Youtube-dl is a legitimate tool with a world of a lawful uses. Demanding its removal from Github is a disappointing and counterproductive move by the RIAA. https://t.co/VUbTokd4cP
It’s to archive videos of public events, which may have nothing to do with music. Even when they do have to do with music, as this artist says, youtube-dl was why he had a copy of his *own* performance: 2/
I've used YouTube-DL to download lectures, free documentaries, debates and discussions, interviews, and NASA video footage. But because the program can be used to download music, it clearly should be taken down.
I use the tool occasionally to create a copy of rare versions of 50-year-old+ Hindi film songs that perhaps a few dozen people are interested in anymore, and which you won’t find on iTunes or any store. But they’ll be lost to the world if that YT account ever goes offline. 3/
youtube-dl will likely be down until the creators find an alternative repository, which will likely also be an RIAA target, very likely pushing it onto the Tor network, which’ll definitely get it labelled in the mainstream press as a piracy enabler – that‘ll be the narrative. 4/
More than anything, Github’ acquiescence sets a very worrying precedent. As this tweet says, cURL (& wget) are widely used open-source projects to download a wide variety of content. You could make the same case to shut these projects’ hosting down. 5/
Do I know anyone at @Github? This is bullshit. We’ve used youtube-dl before for a project archiving activist videos about BLM/police brutality.
This should be a loud wake-up call for the @mozilla Foundation, the Electronic Frontier Foundation , the Free Software Foundation – on their watch, a Microsoft business unit became the world’s most popular code hosting service, including for critical Internet projects 6/
The FSF had plans for its own code hosting service in Feb but it doesn’t look like they’ve reached a decision, much less begun execution. Sadly, paid, full-time teams will almost always execute *faster* than volunteer teams like in the FOSS world. 7/ https://libreplanet.org/wiki/FSF_2020
Censorship-resistance needs to be a top-level criterion for evaluation, for anyone who is building anything of value for the Internet. A strictly free (or open source) code hosting platform is of no use if it or its projects can be taken down just like with youtube-dl. 8/
This should be an equally strident wake-up call for other projects – such as @The_Pi_Hole, which I have written about so often, and which are hosted on github. If the RIAA has gotten its way, the much larger online advertising industry could very easily act next. 9/
There are so many other projects that survive publicly ONLY because they either fly under the radar or have not yet been targeted. Two that immediately come to mind are the Calibre project and its (independent) Kindle De-DRM plugin. 10/
Another thought that struck me after the thread is that a USA-centric industry association filed a notice under USA law to a USA-based company, Github/Microsoft, and knocked offline a project that
had contributors from all over the world
was forked by people all over the world
made a tool that was used by people from across the world
to download videos and knowledge created and posted by people from around the world
We think of the Internet as a shared resource. Practically, it is subject to the laws of just a few countries, especially the USA, and a few massive companies, also mostly registered in, and subject to the laws of, the USA. This is not a criticism of the country – such centralisation of authority and control in the hands of any one or few countries is detrimental to the future of the Internet as we know it.
I will probably have more to say about this, but this is it for this post.
