跟讀練習: STOP Running Code On Your Computer - 通過影片學習英語口語

選擇練習模式

每種模式都會開啟全屏練習室。

173 句

如果句子過短或過長，請點選 Edit 進行調整。

Every single time you install a dependency, run an extension in your code editor, run the build process for an app you're working on, or run the app itself,

you are running code on your computer that you did not write.

And that code has access to more than just your project directory.

And just as an example, I have this simple Python script here, and I'm running this with no extra privileges.

All it does is scan the file system.

And with one single command, it has every cookie and session data from Firefox and Chrome,

Slack and Discord, as well as access to my NPM token and SSH private keys, basically everything on my machine.

So when an attacker's code gets onto your machine, it has access to pretty much everything.

And attacker code can come from anywhere.

But what we're probably most familiar with is supply chain attacks.

Essentially, a package on some public repository gets compromised.

And then when end users install that package, they get compromised as well.

But it's not as simple as, oh, I don't have any vulnerable dependencies.

Why should I care or why does this matter to me, your dependencies have dependencies and your dependencies dependencies have dependencies.

These are known as transitive dependencies and it's very possible that even though you're not directly dependent on some vulnerable package,

their dependencies might be the victim of some sort of supply chain attack and that's how these things spread.

These are real incidents

that have increased in their occurrence over the past couple of years as more

and more attackers leverage these developer ecosystems

that we all thought we could trust the main question isn't really if you'll install something compromised, it's when.

And so from there, the question becomes, what can that code do?

And that's what we're going to talk about in this video.

I'm going to give you a basic primer on security concepts, how running code works, how what it has access to, and how you can limit that access.

Because that's really the basic concept that any sort of isolation mechanism or agent container allows us to do, which is prevent the blast radius.

If something gets compromised, you want to make sure that it doesn't have access to everything.

So let's dive in.

My name is CJ.

Welcome to Syntax.

Now, first, let's talk about the blast radius, which is if something goes wrong, what can it do or what does it have access to?

And so if we consider your development machine today, let's say you run all of your projects locally.

Everything is happening just directly on your machine.

If something gets compromised or goes rogue, it has access to everything on your computer.

It has access to your email, it can check if you're logged into your bank, it can access any sort of password vaults, SSH keys, ENV files, essentially anything on your computer

an attacker would potentially have access to if you are a victim of their attack.

And so the fix is easy.

Never run untrusted code on a machine that has anything that you care about.

So we're essentially going to shrink that blast radius to zero by isolating code execution from your credentials and accounts.

So the answer to this is isolation.

When you're running a program, instead of giving it access to your entire computer, we can limit that access.

And there are four security concepts you can apply to any one of those isolation levels

that we'll talk about in the next section.

And the first security concept is the principle of least privilege.

Give it only access to what it needs.

So maybe your program needs to talk to some hosted database, but will it work with read-only credentials?

If so, use those.

That way, if those credentials are compromised, they can't write anything to the database.

Also, don't run code on the same system

that has stored credentials for other services or other unrelated things to the project at hand.

Now, number two, the next security concept is network filtering or egress filtering.

That is, it can't phone home if it can't make requests.

Now, one of the ways attackers take advantage of credential leaks like this are, potentially, if they can run code on your system, they will just send all of the secret data that they found off to some remote computer.

And then maybe later, they can go look and try to use those credentials in certain places.

But if your code is running in an environment that only has access to specific network resources, like specific servers, specific databases, or specific package manager registries,

and not the entire internet, that makes it much harder for an attacker to exfiltrate that data to some remote server or some remote system.

Now, number three, our next security concept is ephemeral environments, that is temporary environments.

Essentially, we can use the environment, destroy it, and then nothing lingers around.

So if there is anything compromised, it's completely gone the moment we delete that isolated system.

And number four, the last one is defense in depth.

So no single layer of protection is enough.

We essentially stack them so we get more security guarantees with these layers of security.

So isolation alone isn't going to prevent that one isolated thing from being compromised.

We can do these other things like only mount the secrets

that it has access to or only give it certain network access to limit

that blast radius if that one isolated environment does become compromised.

Now, how do we actually do all of this?

I'm going to give you five ranks on the ladder of isolation you can choose from.

And level one is containers.

Now, if you're in the world of development, you've probably heard of Docker and you may not be using it yet, but this is one of the easiest ways to get up and going with an isolated environment.

You essentially define a configuration that says what operating system you're running, what dependencies does it have, what steps need to happen in order to set this container up to be ready for your project.

And then the container runtime uses that configuration to automatically spin up a brand new environment that has everything ready to go.

Now, containerization is operating system level virtualization.

Essentially, every container that gets created gets its own set of processes that it can access, its own file system, and its own users.

But each these containers shares the host operating system's kernel.

So this is a basic level of isolation because if compromised code is able to break out of that container,

it immediately has access to the host operating system and in turn would have access to all of your files.

Now while container breakouts are rare, they do happen and so there are other levels of isolation that we'll talk about soon.

Now related to containers is the dev container specification.

Essentially you define a container configuration specific to the development environment that you need for your project,

And then there are various code editors like VS Code or Zed that can then look at that configuration, spin up one or more containers, and automatically connect your editor instance to that running container.

Then any file changes you make are automatically synced, and any dependencies that got installed or editor extensions that ran or code that ran runs inside the container.

Now, this is a great way to share your development configuration with your team

and make it really easy for people to get up and going.

But like we mentioned, it's running in a container, which isn't necessarily the best type of isolation.

So that brings us to level two in our ladder of isolation, virtual machines.

Now, virtual machines are hardware level virtualization.

Essentially, every virtual machine that gets created has its own hard drive, its own RAM, and its own CPU.

And all of that is being shared from the host system.

So each virtual machine gets its own dedicated resources.

Now, virtual machines are typically more resource intensive and sometimes slower to start up than containers,

but they limit our exposure even more because breaking out of a virtual machine is a much harder technical feat.

And so if vulnerable code does somehow get onto those virtual machines, it's very unlikely that it'll be able to break out to the host operating system.

Now, there are a ton of different ways to get up and going with virtual machines, but one of the easiest ways is to use a program like UTM

if you're on macOS or VirtualBox if you're on Windows or Linux.

And this is just a GUI application you can use to create virtual machines.

Essentially, you can decide how much CPU they get, how much RAM they get.

You can then boot them to a specific Linux or Windows installer, and now you have a virtual machine running on your computer.

Applications like this are a good entry point, especially if you want to learn about Linux.

Even if you're on Windows or Mac OS, you can boot up a Linux virtual machine and then play around with it, and you don't even have to actually have a dedicated Linux machine.

Now, using GUI applications like this is a little more cumbersome

100

if you want to set it up for development because they're only scriptable or automatable in certain aspects.

101

And if you want to create reproducible environments, it's a little bit trickier to do with these GUI programs.

102

One of the more automated and scriptable ways of spinning up VMs is actually from Docker and it's called Docker Sandbox.

103

And it actually doesn't use containers.

104

It uses what is known as micro VMs.

105

And with one command, Docker Sandbox will spin up a virtual machine

106

that is linked to that one project directory that you're running the command in.

107

It has no access to other files on your system.

108

And Docker Sandbox takes that same configuration file that you would use with Docker containers.

109

So this is much easier to set up if if you want more reproducible dev environments for your sandboxes.

110

Now, another tool I came across is called Lima, and it essentially manages virtual machines for you, but from the command line.

111

And there's also a tool called CoLima, which only works on Mac OS and Linux, but it's essentially a wrapper on top of Lima that makes it

112

so that you can use your existing Docker configuration files to spin up virtual machines with Lima.

113

Now let's move on to level three of separation, full separation.

114

Essentially, you have an entirely separate machine for your development workflows.

115

Now, you could go fully custom and rent a VPS or virtual private server, or even rent a dedicated machine from some cloud hosting service, and then set up that machine as your development machine.

116

And then anytime you need to do development work, you SSH into that machine.

117

And that means if that machine ever gets compromised, it's not your computer, all of it is in the cloud.

118

Now, just like all the levels of security that we talked about, if you have a big single dedicated development machine in the cloud, you're not necessarily isolating your projects from each other.

119

And so if you have multiple projects with multiple credentials, you're not really adhering to the principle of least privilege for all of the apps

120

that are running on that development machine in the cloud.

121

So in theory, you could actually combine this with level two separation, where you actually spin up virtual machines on that machine you have in the cloud.

122

And then you basically have three levels of separation between you and the machine that that code is actually running on.

123

Now, you could also go the more opinionated route and use something like GitHub Codespaces.

124

You can essentially spin up a Codespace for any one of your projects on GitHub.

125

And this gives you a machine running in the cloud that only has access to that one project.

126

There are also self-hosted alternatives like coder.com, and you can essentially run this on your own VPS, but you get a more streamlined interface where you can define what type of environment each project needs

127

that you need to spin up and

128

that brings us to level four on the ladder of isolation

129

which i'll label as paranoid which is potentially justified

130

and these scenarios all try to add as much separation between your computer with all of your secrets

131

and everything you care about and the actual running code.

132

And the first is just a separate laptop.

133

Some of us potentially have old laptops we're not using anymore.

134

And you might be surprised how performant some of these custom Linux distributions have gotten in terms of older hardware.

135

And so I actually have one of these in my home lab.

136

It's just an old ThinkPad running CacheOS, and I use it as a development machine.

137

So it's totally separate from my computer, but it's in my house.

138

It's not even in the cloud.

139

And so I'm able to run all of my development workflows that I need, even on some of the older specs.

140

And to get even more paranoid than that, you might actually use a live operating system.

141

So this is used a lot by hackers or people

142

that don't want to have any trace of anything they've done on a computer.

143

They essentially use a live operating system like Tails OS, or you could even boot into a live USB that has Ubuntu on it, and you do all of your development work there.

144

And then the moment you shut down that laptop, it doesn't save anything because it was just running in that live USB environment.

145

Now, this seems like a really cumbersome way to do some development in my opinion, but it's also totally possible to do.

146

And because these are essentially ephemeral boots, every time you boot up, it's a brand new, fresh operating system.

147

You don't have any secrets or anything that could be extracted by malicious code.

148

And finally, this is hardcore tenfoil hat mode.

149

You could use an air-gapped machine.

150

That is, go into a room, unplug the literal Wi-Fi board from your laptop, and do all of your development work there.

151

And that way, if anything is compromised, it can't exfiltrate that data anywhere because there's no way for it to actually reach the internet.

152

Now, there could be some secret spy device nearby that's actually listening to the sound

153

that your hard drive is making or the sound that your keyboard makes when you're typing.

154

And it could exfiltrate all of that data somewhere else, but we're not going to go there.

155

So these are the five levels of isolation.

156

And if you really want to prevent yourself from being the victim of the next supply chain attack, you should be doing at least level one, if not level two.

157

And combine these levels with the security concepts that we covered at the beginning, including the principle of least privilege.

158

That is, give these isolated environments only access to the credentials that they need and nothing more.

159

And every one of those levels of isolation I talked about has some sort of mechanism for only mounting

160

or sharing a specific directory or specific files and not sharing your entire host file system.

161

And with that, you should also do egress filtering.

162

That is, limit the network resources that any one of these isolated environments has access to.

163

Because if they do get compromised, they potentially won't be able to reach out to an attacker server or exfiltrate your data to an attacker's remote host. And

164

And every one of these isolation mechanisms supports firewalls

165

or operating system level network blocks

166

that can essentially lock down these isolated environments to only have access to the network resources that they need access to.

167

And of course, to bring it all together, defense in depth.

168

Combine all of these various security mechanisms with an isolation mechanism to reduce your overall blast radius if you do become compromised.

169

So that's all I got for you in this one.

170

If you're using any of the tools I mentioned or have suggestions for other tools that people could use, let us know down in the comments.

171

And if you have any questions about setting any of this stuff up, let us know in the comments as well.

172

All right, stay safe out there.

173

I'll see you in the next one.

下載應用

流利口語所需的一切

AI 發音評分逐句打分

音標練習掌握每個音

詞彙學習建立你的詞庫

詞彙遊戲邊玩邊學

掃碼

Download on theApp Store Get it onGoogle Play

同頻道

FOR YOU

本課的詞彙與口語要點

這段影片共有 173 個句子、2795 個單詞可供跟讀。講話部分時長為 13:18。說話人語速較快，每分鐘約 210 個詞，會出現較多連讀和弱讀。 82% 的單詞屬於英語最常用的 3,000 詞，其餘的詞建議在練習前先學一下。

影片中的重點詞彙

影片中 15 個值得學習的單詞，附發音和釋義：

單詞	發音	釋義
essentially 副詞	/ɪˈsɛnʃəli/	本質上 /本質上, 基本上
container 名詞	/kənˈteɪ.nəɹ/	容器
compromise 名詞	/ˈkɑmpɹəˌmaɪz/	妥協 /妥協, 和解
isolation 名詞	/ˌaɪsəˈleɪʃən/	隔離 /隔離, 隔斷 /隔斷
isolate 動詞	/ˈaɪ.sə.leɪt/	孤立
spin 動詞	/spɪn/	轉動 /轉動, 自轉 /自轉
cloud 名詞	/ˈklaʊ̯d/	йүн, 雲 /雲
configuration 名詞	/kənˌfɪɡ.əˈɹeɪ̯.ʃən/	編排 /編排, 配置
blast 名詞	/blæst/	疾風 /疾風
mechanism 名詞	/ˈmɛk.ə.nɪ.zəm/	機械 /機械, 機構 /機構
boot 名詞	/but/	靴子, 長靴 /長靴
separation 名詞	/ˌsɛp.əˈɹeɪ.ʃən/	分割, 分離 /分離
radius 名詞	/ˈɹeɪ.di.əs/	橈骨 /橈骨
package 名詞	/ˈpæk.ɪd͡ʒ/	包裹, 包
server 名詞	/ˈsɝvɚ/	伺服器 /伺服器, 伺服器

影片中出現的短語動詞

單詞	釋義
get up 動詞	起床

影片中的語法

說話人最常用的結構，並附上影片中的原話：

結構	影片中的用法
被動語態 be + 過去分詞 — 強調發生了什麼，而不是誰做的	are known · are compromised · being compromised
現在完成時 have/has + 過去分詞 — 過去發生但與現在仍有關聯的事	have increased · has stored · you've probably heard
定語從句 who / which + 從句 — 補充說明人或事物	radius, which is · paranoid which is

需要注意的發音

說話人用了 48 次縮略和弱讀形式，例如 you're, don't, we're。請按聽到的簡短形式來說。

“sh” 和 “zh” 音: essentially /ɪˈsɛnʃəli/, isolation /ˌaɪsəˈleɪʃən/, configuration /kənˌfɪɡ.əˈɹeɪ̯.ʃən/, potentially /pəˈtɛnʃ(ə)li/, separation /ˌsɛp.əˈɹeɪ.ʃən/
長單詞——注意重音位置: essentially /ɪˈsɛnʃəli/, isolation /ˌaɪsəˈleɪʃən/, dependency /dɪˈpɛndənsi/, configuration /kənˌfɪɡ.əˈɹeɪ̯.ʃən/, potentially /pəˈtɛnʃ(ə)li/

如何用這段影片練習

先完整聽一遍影片，不要開口，記下不認識的單詞。
先用 0.75 倍速逐句跟讀，熟練之後再回到正常速度。
錄下自己的聲音並與原聲對比，特別注意 essentially, container, compromise 這類單詞。

什麼是跟讀法？

跟讀法 (Shadowing) 是一種有科學依據的語言學習技巧，最初開發用於專業口譯員的培訓，並由多語言者Alexander Arguelles博士普及。這個方法簡單而強大：您在聽英語母語原聲的同時立即大聲重複——就像是一個延遲1-2秒緊跟說話者的影子。與被動聽力或語法練習不同，跟讀法強迫您的大腦和口腔肌肉同時處理並模模擬實的講話模式。研究表明它能顯著提高發音準確性，語調，節奏，連讀，聽力理解和口語流利度——使其成為雅思口語備考和真實英語交流最有效的方法之一。

影子跟讀法: 閱讀完整分步指南 →

跟讀練習: STOP Running Code On Your Computer - 通過影片學習英語口語

選擇練習模式

下載應用

同頻道

Can This Robot Be My Personal Assistant

8 Tech Choices to Lock In Before Agentmaxxing

8 New CSS, JS and HTML Features You Should Know

I bought Black Market AI Tokens on Chinese Amazon

AI Is Stealing From You

推薦影片

OWASP Top 10 Explained

GitHub Copilot now controls your command line...

Armchair Architects: Resiliency in the Cloud – Core Patterns

The Engineering that Runs the Digital World 🛠️⚙️💻 How do CPUs Work?

Crypto Agility Explained: Protect Data from Quantum Computing Threats

🚫 Java Deadlock Explained: Why Your Code is Stuck 😱 (Beginners Must Watch!)

Every Cybersecurity Beginner Should Watch This First (Networking Fundamentals)

Linux got wrecked by backdoor attack

How I deploy serverless containers for free

The easy way to keep your repos tidy.

Traceroute: You're Probably Reading the Results Wrong

AI Can Write Code. And That’s the Problem.