BuildXL VS chromium

Seems they came up with a way to scale up build toolchains with BuildXL[0]

Doesn't seem fully baked yet though

[0]: https://github.com/microsoft/BuildXL

> With regards to chroot, I stand corrected. I knew it was a tree of symlinks, but I thought it was also more than that because symlinks alone don't seem like a sandbox. Honestly, Cosmopolitan's system appears to be more of a sandbox than that.

To be totally clear: the tree of symlinks thing is a fallback, used only when lacking platform support or when sandboxing is explicitly turned off [0]. On Linux, the normal sandboxing strategy is to use namespaces, like most container runtimes. On Mac it apparently uses sandbox-exec (some opaque Apple tool), as was mentioned above. Chroot, being both non-POSIX, requiring root access on many systems, and not providing the necessary facilities is not really a great fit -- which I assume is why it's not used.

There was experimental Windows sandbox support at one point [1] based on how MS does it for BuildXL (their own build tool for giant monorepos) [2]. Unfortunately it doesn't seem to be maintained, and under the hood it's kinda ugly -- it actively rewrites code in-memory to intercept calls to the Win32 APIs [3], which was apparently the cleanest/best way MS could come up with. However, from Bazel's POV it works in a roughly similar way -- you spawn subprocesses under a supervisor, which is in charge of spinning up whatever the target process is with restrictions on time/memory usage/file access.

On the "sandbox in the interpreter" thing: what kind of checks are you envisioning? It seems like putting checks at that level would end up leaving a lot out -- the goal of any build system is to eventually spawn an arbitrary process (Python, gcc, javac, some shell script, etc.) and so even with extensive checks in starlark you'd end up with accidental sandbox breaks all over the place. For pure starlark rules you could e.g. check that there are no inputs from /usr, but even then if gcc does it implicitly, you're SOL. Or am I thinking of the wrong kind of checks?

[0] https://bazel.build/docs/sandboxing#sandboxing-strategies

[1] https://github.com/bazelbuild/bazel/issues/5136#issuecomment...

[2] https://github.com/microsoft/BuildXL/blob/master/Documentati...

[3] https://github.com/microsoft/Detours/wiki

One of the unexpected use of shadow DOMs for me was a document generated for image resource URLs [1], because the HTML standard apparently specifies the exact DOM structure of the generated document except for the `` element [2].

[1] https://github.com/chromium/chromium/blob/f02ca73/third_part...

[2] https://html.spec.whatwg.org/multipage/document-lifecycle.ht...

Recently my favorite open source mouse gestures extension SmartUp Gestures was taken over by some shady entity (with github no longer being updated of course).

I opened Chrome ticket that they should ask to re-enable extension when ownership changes. They just closed the ticket replying with this link:

https://chromium.googlesource.com/chromium/src/+/main/extens...

:(

Hmm. It looks like files with the .lnk or .pif file extension can only be downloaded on a user gesture: https://chromium.googlesource.com/chromium/src/+/39841e54180...

So it can't be done silently. Although, I do wish the type was marked "DANGEROUS" a la dll files.

On Linux, Chromium uses setuid or user namespaces to restrict the access of sandboxed components and seccomp-bpf to reduce the kernel attack surface.

Check out the Chromium docs on this topic: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/l...

You can also disable JIT in Firefox by setting javascript.options.baselinejit to false in about:config, although you won't get CET.

[1] https://github.com/chromium/chromium/blob/12c232c43ce7324d30...

Chromium targets iOS already: https://chromium.googlesource.com/chromium/src/+/main/docs/i...

For the sake of completeness, I've traced the evolution of the notice over time:

From 2008-07-26: "Going incognito doesn't affect the behavior of other people, servers, or software. Be wary of: / • Websites that collect or share information about you / • Internet service providers or employers that track the pages you visit / • Malicious software that tracks your keystrokes in exchange for free smileys / • Surveillance by secret agents / • People standing behind you" (https://chromium.googlesource.com/chromium/src/+/09911bf300f...)

From 2013-12-07: "Going incognito doesn't affect the behavior of other people, servers, software, or people standing behind you." (https://chromium.googlesource.com/chromium/src/+/c5e36c57178...)

From 2013-12-13: "However, you aren't invisible. Going incognito doesn't hide your browsing from your employer, your internet service provider, or the websites you visit." (https://chromium.googlesource.com/chromium/src/+/70821506825...)

From 2014-02-27: "However, you aren't invisible. Going incognito doesn't hide your browsing from your employer, your internet service provider, governments and other sophisticated attackers, or the websites you visit." (https://chromium.googlesource.com/chromium/src/+/ab54bd65701...)

From 2014-04-29: "Going incognito doesn't hide your browsing from your employer, your internet service provider, or the websites you visit." (https://chromium.googlesource.com/chromium/src/+/eb09a62ef40...)

From 2016-01-15: "However, you aren't invisible. Going incognito doesn’t hide your browsing from your employer, your internet service provider, or the websites you visit." (https://chromium.googlesource.com/chromium/src/+/b7dac1a6a79...)

From 2017-02-27: "Your activity might still be visible to: / • Websites you visit / • Your employer / • Your internet service provider" (https://chromium.googlesource.com/chromium/src/+/cfe102adddc...)

From 2017-03-29: "Your activity might still be visible to: / • Websites you visit / • Your employer or school / • Your internet service provider" (https://chromium.googlesource.com/chromium/src/+/7ca3ccf74e8...)

(Note that some of these were behind a feature flag for a few months.) Also, it looks like they've been intending to modify the new-tab page text for Incognito windows for some time, as part of the "Revamped Incognito NTP" project. You can view the modified text with 'chromium --enable-features=IncognitoNtpRevamp':

From 2021-08-13: "What Incognito doesn't do / Incognito does not make you invisible online: / • Sites know when you visit them / • Employers or schools can track browsing activity / • Internet service providers may monitor web traffic" (https://chromium.googlesource.com/chromium/src/+/e6ae57ba385...)

From 2022-01-25: "What Incognito doesn't do / Incognito does not make you invisible online: / • Sites and the services they use can see visits / • Employers or schools can track browsing activity / • Internet service providers can monitor web traffic" (https://chromium.googlesource.com/chromium/src/+/8b349f6c984...)

Blink can now be compiled for iOS, but without JIT or WASM:

https://chromium.googlesource.com/chromium/src/+/main/docs/i...

https://bugs.chromium.org/p/chromium/issues/detail?id=141170...

I think its weird that Vercel has this limit. There is no practical reason I can think of for having such a limit on URL characters that is so small. Chrome suggests a 2MB limit[0] for example. The platform itself doesn't have one, and Firefox I believe if memory serves (I can't find the source for this claim atm) is 1 MB effectively, and I don't think Safari is any lower than that either (and may well be more inline with Chrome on this, at 2 MB)

[0]: https://chromium.googlesource.com/chromium/src/+/master/docs...