If you see a phishing link, you can perform a DNS A record request to find their IPs, typically behind Cloudflare. You can report them to Cloudflare. Their WHOIS record will tell you who their registrar is, and again you can report them there too. If they use URL shorteners, you can report those.
If you're talking about toposes, many logics do not correspond to them. It's the other way around: many category theorists/logicians needed jobs and found computer jobs and hence the category theoretic perspective in CS.
You don't know what you're talking about. Applications of category theory to computer science predate the first US computer science department. There weren't any computer science jobs to speak of.
Categorical logic is larger than elementary topoi. I would wager that you can't name a logic not expressible in category theory.
>Applications of category theory to computer science predate the first US computer science department.
This doesn't sound plausible: according to Wikipedia, Eilenberg and Mac Lane introduced concepts of CT in 1942, and CT was originally used mainly homological algebra, with applications in logic/semantics later. Certainly CT was given credence by Grothendieck and Serre, working on (and solving) Weil's conjecture in the 50s and 60s. Lawvere's 1963 thesis predated categorical logic (according to his own words, <http://www.tac.mta.ca/tac/reprints/articles/5/tr5abs.html> p. 12, "but the method here, and indeed in the whole ensuing categorical logic, is to exploit the uniqueness by using adjointness itself as an axiom"). The first computer science department in the US was started in 1962 in Purdue University. Meanwhile for contrast the proofs of Church and Turing were published in 1936.
>I would wager that you can't name a logic not expressible in category theory.
I prefaced my statement with an "if"; you're not talking about toposes apparently. The interpretability of one theory in another is a concern of logicians and I'm not familiar with any restrictions on category theory, indeed it can be used for logics. I do not know topos theory but I was basing my statement on what I heard Colin McLarty say in an interview of his <https://www.youtube.com/watch?v=81sPQGIWEfM>, can't give timestamp; he definitely named logics that cannot be expressed by the topos of a space.
I feel that you've used two straw men: 1) specifically naming US 2) ignoring my "if topos" and saying "expressible in CT".
This is a phony work in progress (I do not mean to disparage the author, just the work itself, or perhaps the YC submission). There's no direction, it's just "let's do it because ... ?" Here is the authors' answer to "Why Category theory?":
>The answer lies in the abstraction and generalization capabilities provided by category theory. It allows us to see beyond the specifics of a particular programming language, problem, or system, revealing the underlying structures that are common across different domains
Rest assured you will not find much of that by reading category theory (CT). This type of studying of CT reminds me of Shaolin monks trying to fight boxers (hint: the boxer wins).
Another peculiar thing about these notes is that the author colored every CT diagram (and worse even, there is no logic to the color choices, it's just randomized.)
CT is a nice subject as any other, and useful to those doing research. You don't need it if you're not doing specific math/CS research that uses it. Anything that could be useful to you from CT can be explained in one afternoon over some coffee or beer. For example, the notion of universality could be useful to many programmers: the "most general" object of its kind, and how that is reflected in relation to other objects of its kind; a brief example would be that the "free" language of all strings in the letters A and B is universal amongst all languages of strings A, B with relations, (relations such as AAAB = A.)
Don't enter turbulent waters if you're not a swimmer! Maybe you can take a boat instead. For those who already know CT because of other motivations (in particular, because they're mathematicians who have spent many years studying mathematics), the applications of CT to computer science can come somewhat naturally, but for others, it's an uphill battle and a waste of time.
IMO Bartosz Milewski gave a pretty good answer to the "why" question in the preface to his book:
> Second, there are many different kinds of math, and they appeal to different audiences. You might be allergic to calculus or algebra, but it doesn’t mean you won’t enjoy category theory. I would go as far as to argue that category theory is the kind of math that is particularly well suited for the minds of programmers. That’s because category theory — rather than dealing with particulars — deals with structure. It deals with the kind of structure that makes programs composable.
Composition is at the very root of category theory — it’s part of the definition of the category itself. And I will argue strongly that composition is the essence of programming. We’ve been composing things forever, long before some great engineer came up with the idea of a subroutine. Some time ago the principles of structured programming revolutionized programming because they made blocks of code composable. Then came object oriented programming, which is all about composing objects. Functional programming is not only about composing functions and algebraic data structures — it makes concurrency composable — something that’s virtually impossible with other programming paradigms.
During an afternoon someone who understands the concepts can explain the relevant parts without requiring an understanding of CT from the other party. Hence: don't bother with CT.
I don't mean to be rude, but what has Bartosz Milewski done that is relevant in programming?
> I would go as far as to argue that category theory is the kind of math that is particularly well suited for the minds of programmers. That’s because category theory — rather than dealing with particulars — deals with structure. It deals with the kind of structure that makes programs composable.
I would argue this shows that Bartosz Milewski has no idea what programmers actually do. Programming is all about the particulars. Programmers are the ones who have to think about and ask "but what if the person's last name in their country of birth includes characters which our OCR system can't reliably discriminate" or "but what if an attacker sends us a small UDP packet with a spoofed source IP, will we send a lot of data to that IP and spam them?".
Programming is very, very rarely about abstract structure. We programmers are the ones who have to handle of the myriad nitty gritty details of abstract ideals, not the other way around. Sure, sometimes a nice abstract library can solve certain simple recurring problems. But that is a minute minority of all programming work. And if you don't enjoy getting your hands dirty and finding out how many pixels actually fit on the screen, or what exactly happens to bit 15 of the output register when bits 5 and 7 of the control register are set and the input signal is larger than 1024, then you won't last long in the profession.
I'm not, not at all. I'm just pointing out that programmers are people who learn to, and like to, delve into the details. Architecture is fun, but it's a tiny part of the job, ultimately.
The biggest part of a programming job is pinning down the details of your requirements.
Pinning down the details of your requirements is _exactly_ the act of choosing the correct level of abstraction. When picking out what matters for correct behavior, and what doesn't, you are defining an abstraction.
Sure, but abstraction is not in any way the same thing as architecture (which is what you were talking about), and it's not structure (which Bartosz Milewski was talking about).
And besides, Category Theory is mostly concerned with finding similarities between different mathematical objects, when you look at them abstractly and ignore some details. It helps you find that numbers with adding are homomorphic to functions with composition. But programming is about telling a computer how to actually add 156 with 1571 by adding bit to bit, and how to compute the composition of two functions by computing the result of the first and putting it in a register so the second one can take it as input, which CT doesn't concern itself and no category theorist cares about in the slightest.
> programming is about telling a computer how to actually add 156 with 1571 by adding bit to bit
programming can also be about producing generic solutions that commit to some minimal set of assumptions so that solutions work across a variety of contexts, e.g. regardless of whether your data is floats or ints.
sometimes good engineering is about finding decisions you can avoid making or thinking about. Sometimes you have to decide how to add the numbers bit by bit, but for that particular example, it's even better to not care about how the numbers are added up (which is a detail of the CPU or a bignum library or whatever).
What about GnuTLS and GnuPG do you think makes them insecure? I think that they offer something unique and that must be factored in; i.e. if you compare them to competitors, you can't compare apples to oranges when making judgments for them. In mind I have projects like Open/Bear/Boring SSL to compare GnuTLS with, and sequoia for gpg. I really like sequoia, but it offers a different product to gnupg.
Emacs is a mosaic of 50 years of computer history, security is not its priority, but I guarantee you that in bug-gnu-emacs any security/network-related patches are most welcome.
Well, how about the fact that gnutls allowed passive cleartext recovery attacks to go unpatched for about 2 years?
How about the fact that GnuPG is predicated upon the web of trust which has been demonstrated not to work, encourages misuse in the form of long-lived identities which discourages key rotation, has no ratchets nor forward secrecy, has multiple internal key parsers, and a littany of vulnerabilities involving authentication and downgrade attacks?
GNU is just organizationally incapable of producing secure code. These tools are not good tools. GnuPG in particular offers absolutely nothing that another single-purpose tool doesn't do better, but for some reason people get emotional and mount all kinds of irrational defenses of it. GPG is not good. It is broken at a fundamental level.
>How about the fact that GnuPG is predicated upon the web of trust
No it is not, the web of trust is one mode of operation out of infinitely many that you can come up with, it's not forced upon the user. It was evangelized for a long time until the keyservers got DOSed. In retrospect obvious, but also gnupg is more-or-less an "activist" project -- big corps and govs are against encryption for the masses by and large. Had it had institutional backing from the beginning (which it never got) it'd have a much more robust model for users to work with.
>encourages misuse in the form of long-lived identities which discourages key rotation
You can automate key rotation with gpg. The long-lived identity argument can be seen as a strength too, short-lived isn't always better.
>a littany of vulnerabilities involving authentication and downgrade attacks?
I'm not aware of these; do you mean that GnuPG is not secure by default in its algorithm list? It chooses compatibility over security, but you're free to change the configuration. I think it's too harsh to say that GnuPG is inadequate because of that.
>GNU is just organizationally incapable of producing secure code.
I don't see why that'd be true, anyone can contribute to GNU so there is nothing inherent about GNU that makes its projects insecure.
>GPG is not good. It is broken at a fundamental level.
Works for me! I use it to sign my git commits and tarball releases, and with gpg-agent I get to authenticate to SSH servers.
This is an anonymous blog, and the author conceals their identity, which is already an issue for me. Let's look at the alternatives to PGP that the blog recommends, I will paraphrase:
1) Sign software with sigstore.dev
The issue here is that you delegate trust to places like GitHub or other OIDC providers. You also have to trust Fulcio and their CAs. <https://docs.sigstore.dev/about/security/> for details. Maybe you don't want to do that, in part because you're not guaranteed that the service will remain free, or perhaps you're more serious about security than GitHub.
1-alt) Sign software with minisign.
Maybe I don't want to use Ed25519. Maybe I want to revoke the signatures. There's many issues one may have with minisign.
2) Signing git tags/commits
Advises to use SSH, no explanation why. Advises Ed25519, why not Ed448? The explanation to not use RSA is by linking to <https://blog.trailofbits.com/2019/07/08/fuck-rsa/>. I will only quote one thing from this article:
>RSA was an important milestone in the development of secure communications, but the last two decades of cryptographic research have rendered it obsolete.
You can't say it is obsolete when it is still in use. I'm not sure what the author(s) mean by "obsolete", but it is not true that RSA is obsolete. (If Ed25519 breaks but RSA doesn't, who will be obsolete?)
3) Sending files between computers
Here it recommends Magic Wormhole. That's shocking to me, I don't understand why it is recommended. Why not rsync? If you look at the 2016 presentation for Magic Wormhole <https://www.lothar.com/~warner/MagicWormhole-PyCon2016.pdf>, the pitch is that it is especially useful when the computers are unrelated. How often is that the case? Rsync is a much better solution for anyone who wants to transfer files between servers they have access to.
4) Encrypting Backups
Here they recommend tarsnap as "the usual recommendation", I've got to say, it's definitely not the usual recommendation.
5) Encrypting Application Data
They say to use Tink or libsodium. Tink has many implementations in each language, (how does that help security?) and libsodium doesn't support RSA, two things on top of my head that may be deal breakers.
6) Encrypting Files
They recommend age; wishful thinking as most people do not use age. In fact most people do not bother encrypting files, and it is not something that is done often. The author likes to talk about footguns, well there's certainly many footguns to file encryption. This is where the most analysis is on this blog article too, but this is a niche case.
7) Private Messaging
It recommends Signal. What about e-mail?
>(Unless you’re legally required to use PGP because of a government regulation… in which case, why do you care about my recommendations if you’re chained by the ankle to your government’s bad technology choices?)
It comes off as know-it-all.
Let me close with this: Cryptography is infamous for debates. It never ends, and many people have ended up with egg on their face for their claims. Tread carefully and don't rely on others too much!
More in keeping with the Unix philosophy of doing one thing and doing it well (GnuPG in particular does a mediocre job of many things), the best move is to replace it with a suite of single purpose tools.
For example, signing commits with minisign or signify.
>For example, signing commits with minisign or signify.
These tools don't work well with git or the git forges, and they do not work at all with fossil. (Obviously signify is a good choice if you're using OpenBSD.) Furthermore they lock you in entirely in their choice of algorithm, Ed25519, which may not be what you want (Why not Ed448?)
As far as adoption goes, and adoption is hard to get going, GnuPG is what is used in Linux the most...
"Github supports GnuPG signatures" does not contradict the statement "GnuPG is trash". I will not engage further, it's obvious you are not interested in honest discussion of the technical merits.
You can add a patch to git to support more signature types than just OpenPGP. You may then be able to move mountains and get GitHub/others to join in the validation. Finally, if you can find bugs/exploits in GnuPG, you should report them and you will definitely get credit and recognition for them. They are not trivial to find.
> I will not engage further, it's obvious you are not interested in honest discussion of the technical merits.
Well you are neither, all you do is throw unobjective flames around ("gnupg is trash") and post various claims about bad security without backing them up, implicitly demanding that other people do the leg work of disproving your accusations against the GNU project.
I have heard it said that a problem with GPG is that it does encryption AND signing when you'd ideally have separate tools for those tasks, like, for example, age for encryption.
I know, not an amazing alternative imo as they're also saying it takes a long time. I just wish I didn't need to be all in into Guix to easily play around with such projects, which aside from that, look really cool.
Did you catch that page there aside from the manual, where they describe how to install it on Ubuntu? https://artanis.dev/blog/build-0.6-ubuntu.html it seems quite detailed, maybe it wouldn't be so bad to get through.
A lot of people are not aware that HTTPS certificates do not necessarily guard you from certain types of attacks like DNS injection. You can see <https://www.youtube.com/watch?v=exy5JwAU8qk> for one example where an attack campaign called DNSPionage obtained valid certificates for their attacks.
To explain the issue with HTTPS certificates simply, issuance is automated and rests on the security of DNS, which is achieved via DNSSEC and most do not implement.
Technically it's an attack against the certificate issuing authority, bypassing their authorisation checks (is this person really authorised to issue a certificate for the domain).
Trouble is even CAA entries won't help here (if you're spoofing A records, you can spoof CAA records too). DNSSEC might help against this, I don't know enough about DNS though.
Another type of attack is an IP hijack, which allows you to pass things like http authentication (the normal ACME method), but won't bypass CAA records. Can't use letsencrypt to issue a cert - even if you own the IP address my A or AAAA records point to - if my CAA doesn't have letsenctypt as an approved issuer.
With DNSSEC you can be certain that the response you got was issued by the nameserver that is claimed (well, by someone who owns the private key). The domain owner, and registrar can both be at fault, the CA is the last entity to blame because they are performing an automated check of domain ownership. For maximum security you'd want to buy your own TLD as my YT video talks about, to circumvent any other registries, registry wholesalers, and registrars' security models, but an adequate protection for most is to use registry/registrar lock and implement DNSSEC correctly. IP hijack will then not work when all of the above is done correctly.
Another option is manual certificate issuance with a CA whose security model is better than yours, but not implementing DNSSEC leaves you open to other attacks.
Misissuance from direct DNS spoofing basically never happens. When the DNS is used to misissue a certificate, what has normally happened is a registrar account has been phished. Direct DNS spoofing is an exotic attack. Further: DNSSEC has only a partial fix for it, and the WebPKI has non-DNS-dependent mitigations (most obviously CT, but also multi-perspective DNS lookup, which is apparently going to be a BR next year).
Generally speaking, setting up DNSSEC is probably a bad move for most sites.
Good way to rob your child of their childhood... Kids need less schooling, not more, especially with the state of education (worldwide, it's bad everywhere).
edit: the author discovered his children like math and he's a banker with a math degree from MIT, talk about being oblivious to the effects of nurture.
how is allowing a kid to do what they have fun with (maths in this case) "robbing them of their childhood??
If it involved tears and pressure for performance and obligation, yes, that's questionable. but a brain that wants to brain around for fun and giggles with other brains? greatest childhood ever.
Kids don't brain around for fun, if you put them in that extremely competitive environment they will compete. Kids have fun playing with their friends. Take it from Terry Tao, who has been through all of this and also has a fields medal: <https://terrytao.wordpress.com/career-advice/advice-on-gifte...>.
>[..] any short-term advantage one might gain in working excessively towards such benchmarks may be outweighed by the time and energy that such a goal takes away from other aspects of a child’s social, emotional, academic, physical, or intellectual development.
I'm more radical than him in my viewpoint. Academia and industry is infested with broken people with robbed childhoods. Heed my warning and don't let it happen to your children.
Eh. Kids definitely do brain around for fun. More so if they have other kids (or parentd for that matter) who also like to "brain around".
I do agree that we need to be careful not to focus on things a kid is good at so much that we neglect other areas that they may not so naturally excel in.
I think you might just be having trouble wrapping your head around the concept that someone might enjoy working through some math concepts as much as other recreational activities.
There are a lot of fun math materials out there, especially if you don’t have to follow the dry (and quite frankly slow) school curriculum/materials.
I like to do that as well. Just want to keep it short :)
Also I use vim mode for bash and since it's in .inputrc I also have a vim mode in gdb which I like a lot even though it's as good as zsh's
