Sure, I agree, and the problem is absolutely magnified by AI. If a back door gets into Thunderbird, or Google decides to start scanning and sharing all of your email, that’s one point of failure.
An MCP may connect to any number of systems that require a level of trust, and if any one thing abuses that trust it puts the entire system at risk. Now you’re potentially leaking email, server keys, recovery codes, private documents, personal photos, encrypted chats - whatever you give your AI access to becomes available to a single rogue actor.
> For Jane Street’s technical rank-and-file, particularly the many hired straight out of university, non-compete agreements may be surplus to requirements. A scan of jobs listed by Millennium, a rival fund that has recently clashed with Jane Street in court, shows the strength of the latter’s position in the job market. Millennium wants engineers experienced in c++, Go, Java and Python, languages that are commonly used across finance and tech. OCaml developers, it seems, are Jane Street’s to keep.
If someone worked with OCaml at Jane Street I would just take this as a signal that they are smart enough to quickly learn Go, Python, whatever they need, and will probably be more successful after 6 months than a “Python developer” would be.
The retention factor is *not* that other companies wouldn't want to hire them, but rather that these employees are likely to dislike being forced to use something other than OCaml.
You could create an interesting payload with this, especially given it can be done via PoSh.
Get payload on machine -> enable Full memory dumps -> execute payload/BSOD -> upon recovery, exfiltrate memory dump.
Secrets galore.
Fix was previously included in https://support.microsoft.com/en-us/topic/june-27-2017-kb402....
> Addressed issue (Error 0x7F) with Windows Forms (WinForms) that causes the system to crash after upgrading to the Creators Update.
The idea was just that if your language could directly express constraints on your document types in its native type system, the compiler could directly type-check statically complex transformations and make sure they produce documents from the expected output schema (assuming the input complies with the announced input schema). This is more direct than having to rely on mapping between XML and "native" data types, which (usually) don't fully preserve constraints imposed by XML schema languages, and are themselves tedious and fragile to write. This works well for XML->XML transformations. Of course, in most applications, XML parsing and/or generation is just a tiny part, which shouldn't affect the choice of an implementation language. With OCamlDuce, I explored the idea of extending OCaml to include XML types. The combination felt a bit ad hoc, but was ok. Today, it could be rebuilt indeed about PPX extension points + some type-checking hooks in the OCaml compiler.
“There are additional complications in certain languages, where the comparison is context sensitive and depends on more than just single characters compared directly against one another,
[…]
Numbers. A customization may be desired to allow sorting numbers in numeric order. If strings including numbers are merely sorted alphabetically, the string “A-10” comes before the string “A-2”, which is often not desired. This behavior can be customized, but it is complicated by ambiguities in recognizing numbers within strings (because they may be formatted according to different language conventions). Once each number is recognized, it can be preprocessed to convert it into a format that allows for correct numeric sorting, such as a textual version of the IEEE numeric format.”*
I think those file browsers made the right choice, even given that they don’t (as in this example) always do the right thing.