arbll

It might be the wrong place to do security anyway since `bash` and other hard-to-control tools will be needed. Sandboxing is likely the only way out

I'm not sure that's true. While it obviously won't impact the general behavior of the models much If you get a very similar situation the model will likely regurgitate something similar to this interaction.

Technically it will since this interaction will be commented a lot online which will feed back in the next models training runs

> though IMO that should be a reason to switch ISPs, not a reason to stop using DoT If you have that choice, there's many countries that really want to control what their citizens see and can access at this point. If we had DoH + ECH widely adopted it would heavily limit their power.

CDN are by essence proprietary because they are infrastructure vendors. They can be built with open source software but what they are selling isn't software, it's physical servers. The alternative is going on-prem which is impossible for CDN if you aren't google or meta.

I think you are misunderstanding what cloudflare provides if you think Anubis is an alternative. Even if we only consider bot protection they are completely different solutions.

Ah yes because both of those alternatives are non-profits right ?

Rust (not the language) is another good exception that is mostly powered by DLCs and skins today. Continuous updates with balance changes keep the game fresh, ensuring you maintain your playerbase that will in turn buy DLCs.

> The attackers gained access to a legacy, third-party cloud file storage system.

I think the answer is ok but the "third-party" bit reads like trying to deflect part of the blame on the cloud storage provider.

I assumed they only use this setup for youtube, that might be wrong

While you benefit from the V8 fixes it lacks OS-level sandboxing (see above). Chrome is safe because it stacks security layers. Runtime sandboxing is just one of them and arguably the weakest one.

That's not true. It's secure because they are stacking OS-sandboxing on top, forcing attackers to find a chain of exploits instead of a single issue in V8

It used to be 100% runtime-level and it was the golden age of browser exploits. Each of your tabs are now a separate process that the OS sandboxes. They can only access a specific API over IPC for anything that goes beyond js/rendering (cookie management, etc...). An exploit in V8 today only gives access to this API. A second exploit is needed in this API to escape the sandbox and do anything meaningful on the target system.

It's fine for this project since google is probably not in the business of triggering exploits in yt-dlp users but please do not use deno sandboxing as a your main security measure to execute untrusted code. Runtime-level sandboxing is always very weak. Relying on OS-level sandboxing or VMs (firecracker & co) is the right way for this.

I'm assuming it's the render engine that is in pure CSS. You could display a static map in CSS but things like the tools to modify the terrain definitely need JS.

It is based on the impact on Datadog's customers, not on synthetic queries / pings

A single region that is a SPOF for global AWS services*

To avoid operating a database by yourself and dealing with incidents, backups, replicas, failovers, etc... You can use cheap commoditised S3-like storage and run your application statelessly.

If you have access to a database that is well managed on your behalf I would definitely still go with that for many usecases.

well at least it's consistent

I never said it was a poor choice in this specific context but propagating the idea that Deno's sandboxing is safe and "basically the same security as chrome" is wrong and can easily do damage the next time someone that has read this thread needs a way to execute untrusted JS.

Identical to Chrome except the part where Chrome uses os-level sandboxing on top. V8 exploits are common, Deno sandboxing by itself is not a good idea if you are executing arbitrary code.

Chrome does not rely exclusively on V8's security or else it would routinely get exploited (See v8 CVEs if you don't believe me). The hard part of browser exploitation today is escaping from the os-level sandbox put on the processes that run each of your tabs.

Trusting Deno's sandboxing by itself isn't a great idea. An attacker only has to wait for the next V8 exploit to drop, probably a question of a few months at worse.

Now like I mentioned above it's probably ok in yt-dlp context, Google isn't going to target it with an exploit. It's still important that folks reading this don't takeaway "deno sandbox safe" and use it the next time they need to run user-supplied JS.

Deno is a V8 wrapper, the same JS engine as Chrome. Vulnerabilities are very common there, not necessarily because it's poorly designed but more because there's massive financial incentives in findings them.

This plus what you mentioned is why I would never trust it to run arbitrary code.

Now in the context of yt-dlp it might fine, google isn't going to target them with exploits. I would still prefer if they didn't continue to propagate "DeNo iS SaFe BeCauSe It HaS sAnDbOxInG" because I've seen projets that were actually executing arbitrary JS rely on it thinking it was safe.

I wonder if we're going to see JS runtime fingerprinting attempt from google now

The sandboxing features of Deno also seem to have played a role in that choice. I wouldn't overly trust that as a security layer but it's better than nothing.

One anecdote => All Ethereum’s cryptographers are a fraud => All crypto is a fraud

You're deducing a lot from this one quote lol

this type of exploits are goldmines for attackers, it means they have a window of a few month to years to turn any basic access into root. It doesn't have to be a super complex exploit chain, anyone running wordpress botnets it going to add this to their arsenal

Situational but if you're in default configurations it's comparable. Both will need some form of unknown vuln. It boils down to wether you trust more the linux namespacing logic and container runtime glue or the hypervisor logic.

Don't know much about SecureBlue but Kicksecure isn't comparable to Qubes at all. It's a hardened distro, not a way to isolate workloads through virtualisation. Depending on what you're trying to achieve they can both fit but they are fundamentally very different in their approach to security.

I think it will also try to influence what you like to maximize engagement unfortunately...