And even if LLMs turn out to really be a net positive and a requirement for the job, they're antithetical to what most software developers appreciate and enjoy (precision, control, predictability, efficiency...).
There sure seems to be two kinds of software developers: those who enjoy the practice and those who're mostly in for the pay. If LLMs win it will be second ones who'll stay on the job, and that's fine; it won't mean that the first group was made of luddites, but that the job has turned into crap that others will take over.
The two categories of software developers you mention already existed pre ChatGPT and will likely continue to exist. If anything, AI's going to make those who're in it just for the money much less relevant.
Do you really think that Software Engineering is going to be less about precision, control, predictability, and efficiency? These are fundamental skills regardless of AI.
they called me an idiot in the other thread for pointing out AI is broader than just LLMs (after they called everyone that uses AI an idiot) lol they’re clearly very angry and bitter, and I believe this is not the first account they’ve made to bombard threads with insults. in another comment they advocate for insulting the “AI idiots”
it’s not bullying in that it’s more entertaining than insulting, but still
ah in another comment (I am enjoying reading these):
> Ruthlessly bully LLM idiots
quite openly advocating for “bullying” people that use the bad scary neural nets!
> Not to mention that a container ship’s deck is typically completely covered with, well, containers.
I guess in theory that could be solved either with huge removable panels around the containers (to be "put aside" somewhere during the loading operations), or placing containers with solar panels (and ways to deliver the energy to the ship) on the outer sides of the cargo.
Actually, maybe the batteries themselves could be loaded as containers on the sides of the cargo, with solar panels on them; that might increase the risk for the cargo if some catch fire, though
Anonymity should not be possible if you pay/receive money for it. Anonymity should be possible if it doesn't involve money / contracts with money. See my sibling post on my view.
For the reference implementation that will not actually be deployed as an official solution so far, yes. Although you could also go with an Apple account.
In fact, I don't think you technically need to be signed into a Google account for Play Verification to pass, though many phones do make completing the Google sign-in a requirement.
> For the reference implementation that will not actually be deployed as an official solution so far, yes
...or the IT-Wallet which is currently deployed, and who's developers stubbornly refuse to remove the requirement.
> In fact, I don't think you technically need to be signed into a Google account for Play Verification to pass
And you're wrong, Play Integrity checks that your phone's account really downloaded the app from the Play Store, and so requires a (signed-in) account.
> many phones do make completing the Google sign-in a requirement
I'm not aware of any such phone, although they sure make it seem like it's a requirement
> Although you could also go with an Apple account
With a cheap, and very open and privacy-respecting, iPhone
I wasn't a network engineer, but to my recollection "end-to-end encryption" was only used occasionally, probably by people not too knowledgeable in cryptography
Well respectfully your recollection is missing lots of references by people that were "knowledgeable in cryptography".
You can easily find these references in the literature, often comparing link encryption with end-to-end encryption. Some of the earliest papers outlining the plans for SSL in the 90s (Analysis of the SSL 3.0 Protocol) are based on this exact foundation from the 80s (End-To-End Arguments in System Design).
Hell, you can even go back to 1978 and see MITRE discussing this exact thing in "Limitations of end-to-end encryption in secure computer networks".
With three citations I was about to give in, and accept that my experience might have been limited, but then I checked those citations and... are you trolling? Or were those given you by an llm?
1. "End-To-End Arguments in System Design" (https://web.mit.edu/Saltzer/www/publications/endtoend/endtoe...) argues that it's appropriate to perform various functions at the high-level, application, ends, rather than for example leaving encryption to devices external to the hosts.
It's really a stretch to affirm that it considers "end-to-end encryption" a proper term for transport, client-server encryption.
Actually, I'd say that transport-level, origin-server -> server-destination encryption is precisely one of the things that the paper would not consider end-to-end.
a. it doesn't "outline the plans for ssl", it's an analysis of its third version???
b. It doesn't reference "End-To-End Arguments in System Design" anywhere, and doesn't even contain the expression "end-to-end"
3. "Limitations of end-to-end encryption in secure computer networks" is mostly concerned with warning about side-channels, that they can be used to disseminate information despite encryption.
Its usage of end-to-end encryption is defined in the paper that's being criticized (https://dl.acm.org/doi/pdf/10.1145/1499799.1499812):
«The term end to-end encryption refers to data being enciphered at the source and remaining unintelligible until it deciphered at its final destination.»
I'll take the hit on the loose phrasing regarding the SSL paper "outlining plans". That was a poor description of mine of an analysis paper and wasn't a good example of the point I was trying to make. However, you are focusing on the trees and missing the forest. The citations you analyzed actually prove the semantic shift I am describing, specifically the MITRE one.
You quoted the MITRE paper (or the older paper it references) defining end-to-end encryption as:
> "data being enciphered at the source and remaining unintelligible until it deciphered at its final destination."
This is the exact crux of the disagreement. In classic Client-Server architecture, the Server was the "final destination". The application processing the data lived on the server. Therefore, by the definition you just quoted, SSL/TLS from Client to Server was "End-to-End Encryption" because the network (routers/ISPs) could not decipher it.
The "modern" definition (post-Signal/WhatsApp) effectively redefined "final destination" to mean "another human user," relegating the Service Provider to a mere hop in the middle. That is a massive semantic shift.
re Saltzer's "End-to-End Arguments": The paper argues that functions (like reliability or encryption) should be moved from the lower network layers (links) to the "ends" (hosts/applications). SSL/TLS is the literal implementation of this argument: moving encryption out of the network links (Link Encryption) and into the application endpoints (Host-to-Host).
The term "End-to-End" in networking *has* historically meant Host-to-Host (Transport Layer), whereas the modern messaging usage means User-to-User. That is why a lot of folks from that era (and the RFCs) called SSL "End-to-End encryption" because relative to the network, it is.
> At this time all Internet Protocol (IP) packets must have most of their header information, including the "from" and "to" addresses, in the clear. This is required for routers to properly handle the traffic even if a higher level protocol fully encrypts all bytes in the packet after the IP header. This renders even *end-to-end encrypted* IP packets subject to traffic analysis if the data stream can be observed.
---
Regarding your claim that "no one really used the E2EE term before it got the current meaning," the IETF standards for the internet (albeit an informational RFC and not a standards RFC) explicitly list SSL and TLS as examples of End-to-End encryption. The definition of "End" has simply shifted from the Machine to the User.
> I'll take the hit on the loose phrasing regarding the SSL paper "outlining plans". That was a poor description of mine of an analysis paper and wasn't a good example of the point I was trying to make
I don't understand why you cited it at all; I didn't read it carefully, but I didn't find anything relevant to the discussion.
---
RFC4949 might indeed support your point; it says intended final destination, though: while SSL is listed among the examples, does that include the "SSL-server-SSL" of a non-E2EE messaging system?
I think there's a good chance that it doesn't, in the intentions of the RFC's authors.
---
> This is the exact crux of the disagreement. In classic Client-Server architecture, the Server was the "final destination"
The disagreement is on whether in a user-server-user system, encrypting the two user-server sides was ever considered sufficient to call it an end-to-end encrypted system.
I think it wasn't, and to my recollection, luckily, no one ever tried to call it that.
Keep in mind that it used to be rare both to use any kind of encryption, and to go through an intermediary server for real-time, one-to-one communication.
It's only when centralized messaging systems begun to use SSL that the possibility of confusion arose.
They should just never have called themselves encrypted, in my opinion; encrypting the traffic was sure a big improvement, but I'd only call a messaging system encrypted if no decryption occurs before reaching the recipient
---
> The definition of "End" has simply shifted from the Machine to the User.
The ends are actually machines in the current definition too, it's not like people decrypt stuff by hand ;)
---
You sure proved that E2EE was a term already in use, anyhow (although I don't think too widely)
reply