cultural reviewer and dabbler in stylistic premonitions

  • 154 Posts
  • 444 Comments
Joined 3 years ago
cake
Cake day: January 17th, 2022

help-circle

  • would you recommend that book for learning regular expressions as a non CS guy?

    Absolutely, it’s an excellent book which I highly recommend.

    The latest edition (3rd) is almost 20 years old, but I don’t think regex has actually changed substantially since then so it should still be very useful. (I read the 2nd edition cover-to-cover and enjoyed it enough that I bought the 3rd when it was released 😀)

    If you’re going to buy a physical copy from amazon you should use the author’s link here to give him slightly more money for it. But if you just want a PDF I see one is available here.
















  • i don’t usually cross-post my comments but I think this one from a cross-post of this meme in programmerhumor is worth sharing here:

    The statement in this meme is false. There are many programming languages which can be written by humans but which are intended primarily to be generated by other programs (such as compilers for higher-level languages).

    The distinction can sometimes be missed even by people who are successfully writing code in these languages; this comment from Jeffrey Friedl (author of the book Mastering Regular Expressions) stuck with me:

    I’ve written full-fledged applications in PostScript – it can be done – but it’s important to remember that PostScript has been designed for machine-generated scripts. A human does not normally code in PostScript directly, but rather, they write a program in another language that produces PostScript to do what they want. (I realized this after having written said applications :-)) —Jeffrey

    (there is a lot of fascinating history in that thread on his blog…)


  • The statement in this meme is false. There are many programming languages which can be written by humans but which are intended primarily to be generated by other programs (such as compilers for higher-level languages).

    The distinction can sometimes be missed even by people who are successfully writing code in these languages; this comment from Jeffrey Friedl (author of the book Mastering Regular Expressions) stuck with me:

    I’ve written full-fledged applications in PostScript – it can be done – but it’s important to remember that PostScript has been designed for machine-generated scripts. A human does not normally code in PostScript directly, but rather, they write a program in another language that produces PostScript to do what they want. (I realized this after having written said applications :-)) —Jeffrey

    (there is a lot of fascinating history in that thread on his blog…)






  • They have to know who the message needs to go to, granted. But they don’t have to know who the message comes from, hence why the sealed sender technique works. The recipient verifies the message via the keys that are exchanged if they have been communicating with that correspondent before or else it is a new message request.

    So I don’t see how they can build social graphs if they don’t know who the sender if all messages are, they can only plot recipients which is not enough.

    1. You need to identify yourself to receive your messages, and you send and receive messages from the same IP address, and there are typically not many if any other Signal users sharing the same IP address. So, the cryptography of “sealed sender” is just for show - the metadata privacy remains dependent on them keeping their promise not to correlate your receiving identity with the identities of the people you’re sending to. If you assume that they’ll keep that promise, then the sealed sender cryptography provides no benefit; if they don’t keep the promise, sealed sender doesn’t really help. They outsource the keeping of their promises to Amazon, btw (a major intelligence contractor).

    2. Just in case sealed sender was actually making it inconvenient for the server to know who is talking to who… Signal silently falls back to “unsealed sender” messages if server returns 401 when trying to send “sealed sender” messages, which the server actually does sometimes. As the current lead dev of Signal-for-Android explains: “Sealed sender is not a guarantee, but rather a best-effort sort of thing” so “I don’t think notifying the user of a unsealed send fallback is necessary”.

    Given the above, don’t you think the fact that they’ve actually gone to the trouble of building sealed sender at all, which causes many people to espouse the belief you just did (that their cryptographic design renders them incapable of learning the social graph, not to mention learning which edges in the graph are most active, and when) puts them rather squarely in doth protest too much territory? 🤔