jesboat

that's the point at which you say (reasonably accurately) that the 364 byte thing is written in machine code. it is small enough to manually translate between the binary and asm

* Unauthenticated RCE vs all GNU/Linux systems (plus others) disclosed 3 weeks ago.

* Full disclosure happening in less than 2 weeks (as agreed with devs).

* Still no working fix.

require sufficient info to identify the validation method to be included in an extension in the precert?

It means no extra cost relative to the same car without an AM radio, I think.

In the 2010-2013 era, i did most of my computing over X over ssh on a fast LAN. At the time, YouTube and other video stuff worked fine, and my environment felt as responsive as local computing.

This might be less of an option then you'd think. Android software is often compiled assuming the CPU has comparatively recent instruction set extensions. Older devices, especially lower-end devices (which are more likely to be stuck on older software and more likely to be owned by people without the resources to frequently upgrade), might lack those extensions, making the app unusable. This is not a hypothetical. I've experienced this with FF a couple years ago (and even spent a couple hours trying to figure out how to build from source, but ultimately gave up.)

Different applications can have very different requirements. I've worked on systems which would kill for 5% latency and on systems that would gladly pay 5% for better memory usage.

In the normal course of events, no. If a CA demonstrates itself to be particularly untrustworthy, the actions most root programs might take (adding restrictions, or removing it from the root store entirely) still rely on those changes getting distributed to users, and if users pick up that update to the root store, they probably picked up the update which added Certainly too.

There are conceivable scenarios where GD doing something (or not doing something) could result in Certainly search no longer validating on some subset of older browsers/clients, but they're quite obscure and unlikely. If you include those scenarios as Certainly having a dependency on GoDaddy, I feel like you would also have to say that Certainly depends on their domain name registrar to not give away their domain out from under them.

From TFA:

This government surveillance has had a measurable chilling effect on Wikipedia users, with research documenting a drop in traffic to Wikipedia articles on sensitive topics, following public revelations about the NSA’s mass surveillance in 2013.

I think their statement is accurate. If they've been accepted into root programs (and it sounds like they have), then the GoDaddy cross-sign is only relevant for older browsers, and even then requires no additional or ongoing actions from GD to keep working.

Very few people actually manage root programs: Mozilla, Apple, Microsoft, Google, Oracle, and maybe one or two others in smaller niches. Everybody else either uses the platform's store or ships an approximation (the certificate list and some basic constraints, but missing the more complex policies implemented in mozilla::pkix) to Mozilla 's store.

That includes Debian, so probably also Ubuntu. Dunno about Red Hat but it's probably the same.

Formats like this sort of reenforce Steve Albini's claim that he only records to tape because he's more certain people will be able to play it back hundreds of years from now

This article seems like a pretty strong argument in the opposite direction: about a tape format which is effectively unreadable without significant heroics (to the extent that a documentary was made about trying to play one of these tapes.)

The format admittedly wasn't exactly successful, and I imagine more common formats would have better luck finding usable hardware. But even then, the tape still degrades.

If I really needed something to last a Very Long Time, I'd print it in highly redundant QR codes on lots of paper, and then also print the specs for QR codes and whatever other encodings were necessary.

There's at least one example on this thread so far of an actual web dev hitting this on a not-small website causing bugs for an actual user.

With a 30px record size, it's only ~600k records, which really doesn't seem that unreasonable to me

This is dishonest competition (all other major companies do the same but not as blunt: Facebook, Google, Amazon for example). Twitter could be an exception. But it won't.

During the #deletefacebook movement, Facebook didn't ban links to or discussion of competitors.

I disagree. Two main points of the article are "nothing is inherently slow about doing stuff in userland (as shown by the fact that we made a fast implementation)" and "kennel interfaces, e.g. particular methods of boundary crossing, can be (as shown by the fact that the way they made it faster was in large part by doing the boundary crossings better)".

The title gave me a reasonably decent idea of what to expect, and the article delivered.

The privately run industry is maybe a tiny bit better, but that's not the point.

The point is that the only way browsers have to influence a CA or the industry is the threat to eventually distrust. If they can't threaten that to government-stamped CAs, then those CAs no longer even have an incentive to operate responsibly, and, as we know from the many, many incidents, they almost certainly won't.

Google, Mozilla, Apple, and Microsoft all have presence in the EU, and the EU can exert jurisdiction over them.

That gives control over the root stores for Chrome, Firefox, Safari, and Edge. (And the approximation of the Mozilla store used by most Linux distros, the root stores on macOS/iOS/etc, and the root store on Windows.)

I'm not aware of any other browsers worth considering.

You're saying a State Government can request Google installs a 3rd party app on 1 million phones? If that's true then I'm genuinely astonished. And more so that it wasn't headline news at the time.

Yes. That's what happened. (I'm not sure if the 1E6 phones claim is accurate, but it was a non-trivial chunk of people near MA).

1. Some background process, probably part of Google Play services, installed the app. Users were not notified that the app was installed. Eventually the app, once already installed and running, would put up a notification asking if the user wanted to participate.

The app was intentionally subtle, in that it had no application icon, which would presumably make it very difficult for user to disable contract tracing if they had enabled it. If you managed to uninstall the app, it would get reinstalled silently again.

2. The lawsuit alleges that there was no legal requirement or court order. Even if there had been, the lawsuit argues that the conduct would still have violated federal and state law and constitutions.

It is really pretty shitty, and, IANAL, probably is/was illegal, with the caveats that (a) I'm not sure whether Massachusetts or Google or both should be considered responsible; and (b) they might try to argue that a user's acceptance of Google's ToS and privacy policy constitutes permission.

> If you really think about it, the only real difference between main memory blocking and disk blocking is the amount of time they may block. > This is a somewhat confusing analysis you have here. Direct read/write from memory for all intents and purposes doesn't block. Why do you say that reads and writes may also block?

Reads and writes from actual, physical, hardware memory might block, depending on how you define "block", in the sense that some reads may miss CPU cache. But once you get to that point, you could argue that every branch might block if the branch misprediction causes a pipeline stall. This is not a useful definition of "block".

The thing is, most programs are almost never low-level enough to be dealing with memory in that sense: they read and write virtual memory. And virtual memory can block for any number of reasons, including some pretty non-obvious ones like. For example:

- the system is under memory pressure and that page is no longer in RAM because it got written to a swap file

- the system is under memory pressure and that page is no longer in RAM because it was a read-only mapping from a file and could be purged

-- e.g. it's part of your executable's code

- this is your first access to a page of anonymous virtual memory and the kernel hadn't needed to allocate a physical page until now

- you're in a VM and the VMM can do whatever it wants

- the page is COW from another process

An Apple Watch with Crash Detection can only notify authorities if you have your iPhone with you, or if it’s connected to a mobile network or Wi-Fi.

from TFA

Keep in mind you should have some some backup way to access your account in case the mac dies. Dunno if Apple IDs support recovery codes or something similar or if you'd actually need two apple devices.

Most likely, they don't keep any backups with user data longer than a short threshold, e.g 60 days. This is pretty common practice.

Facebook's "phabricator" is very different from OSS, to the extent that at this point probably most of what's left is terminology and architectural boundaries. The diff (PR) UI was completely rewritten; I think repo browsing too. Most of the storage got refactored to use common storage code.

But I'm not sure how costly it is for thousands/millions of coroutines.

Still cheap: you only need to preempt the threads which are actively running user code. If a coroutine is ready to run, but not actually running, you don't have to do anything with it (as long as you check for safepoints before entering user code.) That means your safepoints cost is `O(os threads currently running user code)` which in most runtimes is `O(num cores)`

My interpretation was that the author meant "even if we tried to review all changes between current HEAD and the last known-safe commit, it would be difficult if there were large commits (e.g. a giant refactor.)"

The module is amazing and actually kinda terrifying: it grafts in a decent bit of xnu, rather than re-implementing all xnu's features from scratch. This is made a bit more sane because Mach was designed to be extremely portable and has a good abstraction layer for manipulating very low-level stuff like page tables and contexts. But it's still kinda incredible. Part of me wonders if it wouldn't have been easier to graft Linux into xnu instead.

https://github.com/darlinghq/darling-newlkm

I think the storage was replicated by 2013? Definitely by 2014. It didn't have automated failover, but failover could be done, and was done during the relevant drills for some time.

I think it only stopped when the storage services got to the "deprecated, and we're not bothering to do a failover because dependent teams who care should just use something else, because this one is being shut down any year now". (I don't agree with that decision, obviously ;) but I do have sympathy for the team stuck running a condemned service. Sigh.)

After stuff was migrated to the new storage service (probably somewhere in the 2017-2019 range but I have no idea when), I have no idea how DR/failover worked.

It's salient that the video is from 2010. Where I was (not Google), the push to make everything multi-region only really started in, maybe, 2011 or 2012. And, for a long time, making services multi-region actually was a huge pain. (Exception: there was a way to have lambda-like code with access to a global eventually-consistent DB.)

The point is that we made it easier. By the time I left, things were basically just multi-region by default. (To be sure, there were still sharp edges. Services which needed to store data (like, databases) were a nightmare to manage. Services which needed to be in the same region specific instances of other services, e.g. something which wanted to be running in the same region as wherever the master shard of its database was running, were another nasty case.)

The point was that every services was expected to be multi-region, which was enforced by regular fire drills, and if you didn't have a pretty darn good story about why regular announced downtime was fine, people would be asking serious questions.

And anything external going down for more than a minute or two (e.g. for a failover) would be inexcusable. Especially for something like a bloody login page.

This issue is affecting the global console landing page, which is also hosted in US-EAST-1

Even this little tidbit is a bit of a wtf for me. Why do they consider it ok to have anything hosted in a single region?

At a different (unnamed) FAANG, we considered it unacceptable to have anything depend on a single region. Even the dinky little volunteer-run thing which ran https://internal.site.example/~someEngineer was expected to be multi-region, and was, because there was enough infrastructure for making things multi-region that it was usually pretty easy.