☆ Yσɠƚԋσʂ ☆

  • 2.67K Posts
  • 2.94K Comments
Joined 6 years ago
cake
Cake day: January 18th, 2020

help-circle


























  • This is the core of the issue, and it’s wild how many people don’t get it.

    Your phone number is metadata. And people who think metadata is “just” data or that cross-referencing is some kind of sci-fi nonsense, are fundamentally misunderstanding how modern surveillance works.

    By requiring phone numbers, Signal, despite its good encryption, inherently builds a social graph. The server operators, or anyone who gets that data, can see a map of who is talking to whom. The content is secure, but the connections are not.

    Being able to map out who talks to whom is incredibly valuable. A three-letter agency can take the map of connections and overlay it with all the other data they vacuum up from other sources, such as location data, purchase histories, social media activity. If you become a “person of interest” for any reason, they instantly have your entire social circle mapped out.

    Worse, the act of seeking out encrypted communication is itself a red flag. It’s a perfect filter: “Show me everyone paranoid enough to use crypto.” You’re basically raising your hand.

    So, in a twisted way, Signal being a tool for private conversations, makes it a perfect machine for mapping associations and identifying targets. The fact that it operates using a centralized server located in the US should worry people far more than it seems to.

    The kicker is that thanks to gag orders, companies are legally forbidden from telling you if the feds come knocking for this data. So even if Signal’s intentions are pure, we’d never know how the data it collects is being used. The potential for abuse is baked right into the phone-number requirement.












  • I’m guessing you didn’t bother actually reading the paper, here are some relevant quotes from it:

    This paper compares an example implementation from the RISC and CISC architectural schools (a MIPS M/2000 and a Digital VAX 8700) on nine of the ten SPEC benchmarks.

    Performance comparisons across different computer architectures cannot usually separate the architectural contribution from various implementation and technology contributions to performance.

    We will do this by studying two machines, one from each architectural school, that are strikingly similar in hardware organization, albeit quite different in technology and cost.

    There are strong organizational similarities between the VAX 8700 and the MIPS M/2000… Figure 1 shows that the pipelines match up quite closely, with the obvious exception of the VAX instruction decode stage.

    …these two machines are very different in technology, size, and cost: the VAX processor is nine boards full of ECL gate arrays; the MIPS processor is one board with two custom CMOS chips.

    …this paper shows that the resulting advantage in cycles per program ranges from slightly under a factor of 2 to almost a factor of 4, with a geometric mean of 2.7.

    This factor [the RISC factor] ranges from just under 2 to just under 4, with a geometric mean of 2.66.

    The RISC approach offers, compared with VAX, many fewer cycles per instruction but somewhat more instructions per program.

    The correlation has a simple and natural explanation: given reasonable compilers, higher VAX CPI should correspond to a higher relative instruction count on MIPS.

    The MIPS architecture has 32 (32-bit wide) general registers and 16 (64-bit wide) floating-point registers; VAX has 15 (32-bit wide) general registers… This can obviously lead to more memory references on the VAX…

    The time for the simplest taken branch (or unconditional jump) on the VAX 8700 is five cycles. On MIPS, which has a delayed branch, it is one cycle if the delay slot is filled, and two otherwise.

    The MIPS architecture allows instructions to be inserted in code positions that might otherwise be lost to pipeline delays… This ability is not present in the VAX architecture…

    First, we cannot easily disentangle the influence of the compiler from the influence of the architecture. Thus, strictly speaking, our results do not compare the VAX and MIPS architectures per se, but rather the combination of architecture with compiler.

    Second, we measured a rather small number of programs. Measurements that attempt to characterize machines broadly should be based on much more data.

    …we believe that the fundamental finding will stand up: from the architectural point of view (that is, neglecting cycle time), RISC as exemplified by MIPS offers a significant processor performance advantage over a VAX of comparable hardware organization.