apt2ostree VS chromium

Hm yes now I remember that point about how the data is anonymous Python objects that you can pass around to functions.

Are there any open source examples? I looked around the github account, but I mostly remember this tool

https://github.com/stb-tester/apt2ostree

I'd be interested in seeing the Python config and Ninja output, to see how it works. Right now it looks to me like the dependencies are more implicit than explicit, e.g. with your copen example

---

The system I ended up with is more like Bazel, but it's not building containers, so it's a slightly different problem. But I'm interested in building containers incrementally without 'docker build'.

I like the apt lockfile idea definitely ... However I also have a bunch of other blobs and tarballs, that I might not want to check into git. I guess you just put those in OSTree?

Our config looks like this

https://github.com/oilshell/oil/blob/master/core/NINJA_subgr...

And all the code is in build/ninja* of the same repo

However, you can get pretty close yourself with a tool like this https://github.com/stb-tester/apt2ostree

With apt2ostree[1] we use lockfiles to allow us to version control the exact versions that were used to build a container. This makes updating the versions explicit and controlled, and building the containers functionally reproducible - albeit not byte-for-byte reproducible.

[1]: https://github.com/stb-tester/apt2ostree#lockfiles

If you have time to test things, you can try to use ostree to manage a Debian installation. This is what Silverblue uses. Their is already a tool to create APT-based ostree images.

On the subject of reproducible debian-based environments I wrote apt2ostree[1]. It applies the cargo/npm lockfile idea to debian rootfs images. From a list of packages we perform dependency resolution and generate a "lockfile" that contains the complete list of all packages, their versions and their SHAs. You can commit this lockfile to git.

You can then install Debian or Ubuntu into a chroot just based on this lockfile and end up with a functionally reproducible result. It won't be completely byte identical as your SSH keys, machine-id, etc. will be different between installations, but you'll always end up with the same packages and package versions installed for a given lockfile.

This has saved us on a few occasions where an apt upgrade had broken the workflow of some of our customers. We could see exactly which package versions changed in git history and roll-back the problematic package before working on fixing it properly. This is vastly better than the traditional `RUN apt-get install -y blah blah` you see in `Dockerfile`s.

IMO it's also more convenient than debootstrap as you don't need to worry about gpg keys, etc. when building the image. Dependency resolution and gpg key stuff is done at lockfile generation time, so the installation process can be much simpler. In theory it could be made such that only dpkg is required to do the install, rather than the whole of apt, but that's by-the-by.

apt2ostree itself is probably not interesting to most people as it depends on ostree and ninja but I think the lockfile concept as applied to debian repos could be of much broader interest.

[1]: https://github.com/stb-tester/apt2ostree#lockfiles

[2]: https://ostreedev.github.io/ostree/

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...