besselheim's comments

I've found Compiler Explorer to be very useful indeed, for two main use cases: gaining insight into how security mitigations are implemented in different compilers, and for quickly checking my working when reverse engineering tricky C++ compiled code.

Really interesting to see how the tool works behind the scenes.

To give another example, Amon Tobin's Verbal achieves a similar effect through piecing together fragments of vocal samples: https://youtu.be/HsdBgQqBfsM

Do you have any evidence of this?

It's the responsibility of the communicating parties to protect themselves against interception if they consider this to be an unacceptable risk. Using end to end encryption for message content secrecy, and obfuscating message routes using e.g. Tor to help mask source and destination pairs.

That's an argument for ensuring that such data is properly secured, not an argument against collecting it in the first place.

It makes sense to collect everything possible, then discard what you don't need later, because when conducting an investigation you don't know in advance which data are of interest.

If your communications are intercepted, stored, but then never looked at, and eventually deleted - this is functionally equivalent to having never been collected at all.

Assuming 32-bit unsigned integers (but similarly for other integer sizes), multiplying by 0x11111111 and shifting right 28 bits would give a function of period 15, at least for inputs between 1 and 0x1000000e inclusive. Faster than dividing by 15.

The WebSDR at http://websdr.ewi.utwente.nl:8901 (based in the Netherlands) can be used to hear the station as it is broadcast. Set to 4625 kHz, USB.

MOV RAX, 1 is seven bytes: 48 C7 C0 01 00 00 00

The work by Hayashi published last year had derived precursor egg cells, but the sperm was from normal mouse testes as usual. As described in the article, they did successfully create healthy offspring, though the success rate was very small.

The distinction does make sense though. If an intercept is taken, never looked at, and eventually deleted, then from a 'privacy violation' point of view it may as well not have been collected at all.

But these still need to be intercepted in the first place, because you don't know in advance which of the 0.01% of records are of interest.

That doesn't help you if the code running outside your filesystem is compromised.

For example, a backdoor implanted in the disk firmware would be virtually undetectable for the vast majority of users.

I agree, expressing non-authentic feelings is so common we even have figurative expressions to describe it, e.g. to "put on a brave face" or "grin and bear it".

On the other hand, it seems that autistics have the unpleasant pressure of doing this in almost every social interaction.

The author of the article believes that their gender cannot be categorised as either male or female (hence a "non-binary" gender), so they prefer for others to refer to them using "they" and its inflected forms, rather than "he" or "she".

The singular "they" is already commonly used when the gender of a person is not known, so its extension into non-binary genders is quite sensible, in my opinion. Some others who regard themselves as a non-binary gender prefer invented pronouns such as "xe" or "ze", but I think expecting others to remember and use these is rather unrealistic, whereas "they" has the advantage of already having mainstream use in similar contexts.

Any permutation could be used, but I suppose you'd want to use ones that form some sort of visually recognisable pattern. For example, a spiral emerging from the centre of the image, or all the even numbered pixels from a linear scan followed by all those indexed by an odd number.

Might be interesting to experiment with different mappings of pixel location to audio sample number, rather than just having a row by row linear scan from corner to corner.

More interesting is exactly why floating point 0.1 + 0.2 != 0.3, and it's due to the way rounding is defined in the IEEE-754 standard:

> An implementation of this standard shall provide round to nearest as the default rounding mode. In this mode the representable value nearest to the infinitely precise result shall be delivered; if the two nearest representable values are equally near, the one with its least significant bit zero shall be delivered.

If we convert from decimal to double precision (64-bit) floating point, here is how they are represented in hexadecimal and binary:

    0.1 -> 0x3FB999999999999A = 0011 1111 1011 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1010
    0.2 -> 0x3FC999999999999A = 0011 1111 1100 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1010
    0.3 -> 0x3FD3333333333333 = 0011 1111 1101 0011 0011 0011 0011 0011 0011 0011 0011 0011 0011 0011 0011 0011
                ^^^^^^^^^^^^^                  ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^

Taking 0.1 as an example, here is what its binary representation actually means:

    sign exponent    mantissa (marked using ^ in the table above)
       0 01111111011 1001100110011001100110011001100110011001100110011010

The exponent is encoded as its offset from -1023, so in this case we have 01111111011 which is decimal 1019, making the exponent 1019-1023 = -4.

The mantissa (BBBB…) is an encoding of the binary number 1.BBBB…, so with an exponent of -4 that makes the actual number 0.0001BBBB….

Applying this for each of these numbers:

    decimal  binary
    0.1      0.00011001100110011001100110011001100110011001100110011010
    0.2      0.0011001100110011001100110011001100110011001100110011010
    0.3      0.010011001100110011001100110011001100110011001100110011

Then if we add 0.1 + 0.2, this is the result:

      0.00011001100110011001100110011001100110011001100110011010
    + 0.0011001100110011001100110011001100110011001100110011010
    -------------------------------------------------------------
      0.01001100110011001100110011001100110011001100110011001110
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

However we only have 52 bits to represent the mantissa (again marked with ^), so the result above has to be rounded. Both possibilities for rounding are equidistant from the result:

      0.010011001100110011001100110011001100110011001100110011
      0.010011001100110011001100110011001100110011001100110100 <==
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

So according to the specification, the option with the least significant bit of zero is chosen.

Converting this back to floating point format we get 0x3FD3333333333334. Note that the least significant four bits of the mantissa are 0100, which corresponds to the trailing 4 in the hexadecimal representation.

This is not equal to 0x3FD3333333333333 (the result of conversion from decimal 0.3, and also what would have been the result here if the rounding was specified the other way.)

Therefore, floating point 0.1 + 0.2 != 0.3.

We know from neurosurgery that some fairly large parts of the brain can be removed without apparently adversely affecting the subject's sense of self, so it seems it must be more complex than drawing a boundary around the gross anatomy of the brain.

The sandbox does block such modification, but a useful exploit would combine the arbitrary code execution vulnerability with a sandbox escape, using e.g. some arbitrary read/write vulnerability in the kernel or similar.

But why do you consider the brain (and presumably no more or no less than the brain) to be the vessel for your self, rather than other boundaries of embodiment?