floil

And to connect it back to the original post: the moments that make me cringe the most in Grand Designs are the ones where the owner decides, as a cost-cutting measure, to manage the project themselves despite not having prior domain experience. Whereas the author of this article successfully engaged an expert early on, and saw it pay dividends, despite the up front cost.

leafing through the book with gloves

Rare books are typically handled with bare hands rather than gloves. Gloves increase the risk of damage.

https://www.nytimes.com/2023/03/09/arts/rare-books-white-glo...

My interpretation: the paper describes a system that works for a starting concentration of 200 parts per billion, or higher. This is unrealistic because, in real world contamination scenario, you would expect to see a starting concentration of around 1 part per billion.

I've read the book twice, decades apart, and it gave me great joy each times in very different ways.

I can see how this text causes some to experience the opposite of joy.

Both experiences are valid. But like there's not some big conspiracy of people who claim to like this book or this writer as a facade. They say it's great because, for them, it's a wonderful and meaningful experience.

Chrome browser extensions aren't really compiled, though I suppose they can be obfuscated. If you install this extension you ought to be able to find it in your Chrome profile directory and look at the manifest and JS source.

(former longtime chrome engineer here)

Both the KitchenAid and the Hobart use a planetary action which is not the best for kneading bread. A better idea is to find a small spiral mixer where the bowl rotates and the mixer blade spins in place. I have a Haussler Alpha and it's great for tough doughs, and seems appropriately overbuilt.

Site Isolation launched in Chrome in 2018, but the work started in earnest in 2012 -- see the below check-in. The idea in Chrome dated to before the Chrome 1.0 launch; it was the subject of Charlie Reis's PhD dissertation and he interned on Chrome pre-public launch.

https://chromium.googlesource.com/chromium/src/+/c6f2e67ab40...

Site isolation proved to be the biggest refactor in Chrome's history, and was one of the motivating reasons for the webkit/blink fork. Making site isolation work touched a huge host of features, since handling iframes out of process has a way of making simple things incredibly complicated.

The example I always gave was: imagine how the "find text in page" browser feature would be implemented. With the entire document in-process, it was a simple for loop. With the document and its subframes sharded across multiple processes, it is now a distributed search problem that requires handling of out-of-order results and stitching them into a traversal order. What's more, to achieve Chrome's security goals, you want to avoid introducing functionality that would allow the [presumed-compromised] process of the outer document to query the contents of the inner document via the find in page feature. So you can't simply do this as a peer-to-peer query between the renderer processes; it needs to be coordinated by the main browser process.

Congrats to the Firefox team on this milestone.

It's not a whole new level. An aspect of Quadro differentiation has, since ages ago, been based on selectively disabling features that the consumer gpus silicon was capable of. It's the same strategy here.

This makes sense to Nvidia because it creates a segment differentiation and will allow them to charge more for the higher hash rate parts.

As someone who walked away from programming two years ago, reading this stirred something in my heart that I honestly haven't felt since quitting. I've been frankly surprised that I haven't had the desire to code in that time, but it turns out I am nostalgic about the times when coding was a fun process of self discovery.

This article gives me the inkling of a way back to get back to there. Thanks to whoever shared it.

Fairly certain this feature is more then ten years old.

Here you go: https://www.chromium.org/developers/design-documents

When I was a kid, my next door neighbor was an ultra-marathoner and the fittest person I'd ever met. He died suddenly one day of a heart attack while out on a run.

Read it as "both decelerate more slowly and rotate more slowly" and it's an accurate description of what happens when you sweep in front of a curling stone.

Can confirm. The whole group working on that effort has been laid off.

Fwiw: this has always been the case, since Chrome 1.0.

In chromium, the glyph attack defense works by normalizing to a "confusability skeleton" -- the ICU library actually does the normalization. Even within latin-1 this does some mangling: m gets normalized to rn, w to vv, etc. The query rewriting is a different problem, but it's possible it uses the confusables list as an input.

For myself, I switched everything over to Google WiFi's, precisely because they auto-update, and having worked previously on a security-focused team at Google, I trust them to have a competent security team and actually stay on top of the patches. I don't miss fussing with manually updating router firmware. Life is too short.

On the other hand, my Nest thermostats were bricked after a software update this week, so maybe today I'm starting to see a crack in my "auto update is best" dogma...

Did you read the article? She hasn't worked at Instagram since 2014.

Moreover, github.io is in the public suffix list, so it is effectively a TLD (foo.github.io is a different site from bar.github.io; they can't become same origin by means of document.domain).

The risk of eval() is giving control of the site data of foo.github.io to the author of a stackoverflow comment.

The warning is part of the fun, though.

Oh my.

Find out if it works for you by typing your employers name (or your spouse's/parent's/etc - coverage seems to be for "family") here: https://care.lyrahealth.com

This probably doesn't help OP but might help a reader who's facing the same logjam and qualifies: see if your employer (or a family member's) offers a benefit through https://www.lyrahealth.com/ . It is a super streamlined process that takes all the pain away of triaging what's going on and figuring out which type of provider to use, and then selecting one. I got it through my wife's employer even though I'm not on her medical insurance. There's a diagnostic survey, then they suggest some providers (with a strong default choice, which makes a huge difference), and even help you draft the appointment request email. And they follow up to make sure you get help. It still feels like you're owning the request for help, which is pretty important -- it just puts the whole process on rails.

Depression can take away your ability to complete any of the above steps... I know because I didn't get help for years because of the (minor, but thanks to depression, major) hurdle of finding a suitable provider through my work benefits.

Therapy works, y'all.

In chrome, what's blocked is page-initiated top-level navigations to data URLs (because of spoofing concerns). You can load them in iframes, and you can still do a browser-initiated navigation to them (i.e., type them into the omnibox). They can be used freely as subresources.

Http Redirection to data: urls has been blocked in chrome for at least half a decade. There's really no reason to allow that, a server can just as easily return the data as the response body.

Moreover, x and y are not independent on this plot -- x is just the rank of y. A graph constructed this way can never dip down. So a linear-looking upward trend is basically guaranteed.

Nvidia's gross margin is north of 60%. They want to sell GPUs. It seems more likely that they're trying to segment the market so that they can charge miners, gamers, and deep learning customers different prices; the per-customer limits are a way of accomplishing this, since gamers don't need to buy in bulk like the other two.

Yes, but site per process is harder: iframes need to be booted out of process when they cross a site boundary.

To illustrate how much complexity this brings, consider a browser feature like find-in-page. It used to work by traversing the document and descending into subdocuments synchronously. It was basically a big for loop. With the page and its iframes split across multiple processes, now we need a protocol and interprocess communication to coordinate the find operation, and assemble the matches together into a tree. The results of this async operation can arrive in any order, and you need to filter out late arriving responses for previous queries, when the user modifies the search string.

This pattern needs to be implemented, rinse and repeat, for hundreds of subsystems. It was really hard.

Sooner than it would have if Spectre hadn't happened. Spectre, in my view, really changes the cost/benefit considerations here.

Wish I had a better timeline to share, but with stuff like printing not working properly, it's not an easy decision to just flip it on for everyone.

Setting it to star allows arbitrary cross origin access (star means 'any site' in this context). Omitting it is supposed to be the opposite. Important not to confuse the two!

Enabling site per process in chrome will give your users some protection of their data on your site, but only if your mime types are already correct. See the probably linked document for recommended headers.

Great question.

Your intuitions are mostly right, in that the document blocking logic is related to CORS protection. In fact, when the document blocker sees a valid access-control-allow-origin header in a response, that's sufficient to allow it through.

However, there are a couple reasons though why CORS alone is not enough. First, the CORS checks (the ones that generate console warnings when they fail) are done inside the renderer process -- meaning some of the response data has already arrived in the process, and may be available for exfiltration by an agent able to read that process's memory.

Secondly, CORS only applies to cors-enabled requests (e.g. XHR and fetch). Our goal is to prevent, say, the HTML of your bank account details page or a similarly sensitive JSON-based API from arriving in any renderer process other than one dedicated to rendering pages for your bank's site. An attacker could point a script tag at the target resource -- script tags by default aren't required to go through the CORS dance (as an aside, <script crossorigin> exists, but I'm not entirely sure why). Since the attackers goal is just to cause the response to wind up in its renderer process memory, the attack still succeeds even if the JSON or HTML doesn't successfully execute as valid javascript.

So we need something stronger, which runs outside the renderer process. The idea is to look for responses that would necessarily result in an error in the context of any legitimate cross-origin use case (other than fetch/xhr, where CORS dictates what's legal). We need to block HTML, but allow stylesheets, images, and scripts. The blocking logic is really based on the substance of the http response, rather than what the renderer says it's to be used for, since the renderer is untrusted in this scenario.

JSON is a particular headache, since a subset of JSON is also valid javascript (dicts are syntax errors, but lists are we aren't), and as a result, JSON in the wild is often prefixed, and thus doesn't sniff as JSON. JSON also is often served with a JavaScript mime type.

An important takeaway for website authors is to serve any JSON or HTML with the appropriate mime type and the nosniff header.

The three data sources you mention are kept in the browser process (which is the privileged singleton process that spawns the sandboxed child processes that actually parse and execute web content). However the child processes can query and mutate them (to support e.g document.cookie). Those JS apis do work in iframes. In your example, we would create a facebook.com subframe process separate from the foo.com process for the main document.

You can see your example in action by enabling site isolation, visiting a page with a FB like button, and opening Chrome's task manager. You can even kill the subframe process, and it shouldn't take down the whole tab.