What CoffeeScript did was lodge the idea in people's heads that JavaScript can be treated as an assembly language to compile higher-level languages into. I'll bet many programmers' attitudes toward ES6 are: someone will write a compiler for my language, and I'll just use that.
It seems better to treat JavaScript as admittedly not being the most powerful language in the world, and to treat the standard as a kind of RFC that only compiler writers have to think about. For most programmers it works to just use CoffeeScript (or Lisp or anything) without worrying about standards, just as JavaScript programmers don't need to worry about how their processor works.
In fact, maybe Javascript is too powerfull. It would be interesting to get a stack machine emulation in the browser, with an standard set of libraries/tools for native access to the DOM and emulators for most interpreted languages out there.
Kind of a Java plugin that runs on web, instead of just tunneling through it.
Couldn't you have omitted the last two sentences, which amount to a polite version of "we've already made this and theirs only looks nicer because they spent more time?"
I suppose I could have. I've no idea how much time they spent, perhaps it was a quick hack too. It was just unexpected to see someone else's implementation of the same idea, so it made me laugh at the strange coincidences of life in general. Certainly I meant nothing ill by my comment, I apologize if it turned out mean-spirited in any way.
Thanks for reading! I would love to go into more detail about what we talked about, but it varies so much from session to session. I could write an entire book on our conversations.
Mostly mobile from a risk perspective. If you connect to other people's WiFi networks or even have your own configured to auto-connect it's possible to use devices like the WiFi Pineapple and more to man-in-the-middle (MitM) your connection. If you aren't using a VPN, and lets face it, nobody really does, then a bad guy MitM could inject JavaScript of choice into the HTTP response for major sites, thus using them as a gateway to execute exploit code within the context of your browser. Many modern exploits don't rely on writing to disk and instead remain resident in memory so AV really doesn't even save you. If everyone on the web only supported HTTPS the risk of an evil MitM compromising your device while on WiFi goes down fairly significantly so long as you don't do something stupid and install a rogue root CA or accept browser crypto warnings and continue.
It also helps mitigate things like rogue advertisement injection by hotels, ISPs, etc.
It guarantees that the text you are seeing really comes from that website, that it hasn’t been tampered with by an actor between you and the server.
This means that Internet service providers and others between you and the website cannot insert ads in web pages. It also means that if you’re reading a newspaper online (for example), you can be sure that the articles you read really are from that newspaper, that all the articles are there and that they were not modified.
It also prevents URL or content-based censorship, since mans-in-the-middle cannot know what URLs you visit or what content you received from a website.
It does not prevent domain name or IP-based censorship, since the man-in-the-middle can know these, and it is also sometimes possible for a man-in-the-middle to know what page you are visiting by examining the length of the URL and content and comparing them with public information available on the website.
It guarantees that the text you are seeing really comes from that website, that it hasn’t been tampered with by an actor between you and the server.
That's what subresource integrity is for. (http://www.w3.org/TR/SRI/) Links with subresource integrity include the hash of the content to be delivered. Subresource integrity allows caching by content delivery networks and ISPs without allowing them to change the content.
Using HTTPS for general static content is that it breaks caching and CDNs. Because it breaks CDNs, many CDNs (especially Cloudflare) break HTTPS by terminating the HTTPS connection at the CDN. They may or may not encrypt from the CDN to the actual host. This makes big CDNs a central point of attack for snooping purposes.
While this is an unpopular opinion, I consider HTTPS Everywhere a form of security theater. We need really strong security on logins, financial data, and such. We do not need to encrypt newspapers or public cat videos.
Transport Layer Security guarantees, among other things, that the content really comes from the server it should come from¹. This means that the content was not manipulated by a man-in-the-middle.
However, it does not guarantee that the content was not manipulated by an attacker with access to the server. If a web application (say Gmail) includes a JavaScript library (say jQuery) served by a content delivery network (say code.jquery.com), it can use subresource integrity to have the browser verify that the library was not manipulated by an attacker.
This prevents the threat model where the content delivery network becomes compromised and an attacker replaces the library by malicious code that sends the private data of users to the attacker.
Subresource integrity can also prevent other attacks, but it complements end-to-end encryption. It does not replace it.
¹ This assumes that the certificate is valid, of course. There are problems with the current certificate authority model, but there are also solutions to these problems.
It's trivial to rewrite plaintext on the fly and the number of people in a position to do so is staggering. Like passing a note in class, it's basically about trust. You want to ensure the message hasn't been tampered with by the time it reaches you. HTTPS is one way, even if the recent past has backed it into a tiny corner (RIP SSLv2, SSLv3, TLSv1.0 and a long list of cipher suites).
