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