3 ms·

> Of course users are going to use javascript more, the more the internet demands it, the more people will be willing to allow it. I think you have this backwa

> Of course users are going to use javascript more, the more the internet demands it, the more people will be willing to allow it. I think you have this backwards; the vast majority of users like the benefits of js-enabled sites, so they get built. That ship has sailed long ago.

dijit 8y ago
Even so, making the assertion that: "javascript adoption in the browser will increase in future, therefore we will enforce javascript" is like saying: "more people will have passports in future, therefore we require passports to get a bus pass". By doing that; you make it true.
- horsawlarway 8y ago
  It's already true. You can quibble over who's fault it was, but it really doesn't matter at this point. The web serves code that users run. That's because the web is the best distribution medium for code we've ever seen. I bet you've also installed client side applications that came from the web, on a vendor installed OS that came from the web, and drivers for your machine that came from the web.
  - dijit 8y ago
    You're equating my signed/sealed/delivered package management to javascript?? ?? ?????? Really? You honestly don't see a difference? I have a chain of trust with my OS manufacturer (apple) and a defecto trust with a centralised entity for most of my applications (IE; my company for things that we build, or the home-brew project for most other packages) I should not have that trust with any idiot who manages to get a signed SSL certificate; IE: the whole internet.
    - horsawlarway 8y ago
      You mean like the signed/sealed/delivered csp policies that browsers have supported for years? https://developers.google.com/web/fundamentals/security/csp/ https://developers.google.com/web/fundamentals/security/csp/ To quote the signature section: '<hash-algorithm>-<base64-value>' A sha256, sha384 or sha512 hash of scripts or styles. The use of this source consists of two portions separated by a dash: the encryption algorithm used to create the hash and the base64-encoded hash of the script or style. When generating the hash, don't include the <script> or <style> tags and note that capitalization and whitespace matter, including leading or trailing whitespace. See unsafe inline script for an example. In CSP 2.0 this applied only to inline scripts. CSP 3.0 allows it in the case of script-src for external scripts.

dijit 8y ago

Even so, making the assertion that: "javascript adoption in the browser will increase in future, therefore we will enforce javascript" is like saying: "more people will have passports in future, therefore we require passports to get a bus pass". By doing that; you make it true.

horsawlarway 8y ago
It's already true. You can quibble over who's fault it was, but it really doesn't matter at this point. The web serves code that users run. That's because the web is the best distribution medium for code we've ever seen. I bet you've also installed client side applications that came from the web, on a vendor installed OS that came from the web, and drivers for your machine that came from the web.
- dijit 8y ago
  You're equating my signed/sealed/delivered package management to javascript?? ?? ?????? Really? You honestly don't see a difference? I have a chain of trust with my OS manufacturer (apple) and a defecto trust with a centralised entity for most of my applications (IE; my company for things that we build, or the home-brew project for most other packages) I should not have that trust with any idiot who manages to get a signed SSL certificate; IE: the whole internet.
  - horsawlarway 8y ago
    You mean like the signed/sealed/delivered csp policies that browsers have supported for years? https://developers.google.com/web/fundamentals/security/csp/ https://developers.google.com/web/fundamentals/security/csp/ To quote the signature section: '<hash-algorithm>-<base64-value>' A sha256, sha384 or sha512 hash of scripts or styles. The use of this source consists of two portions separated by a dash: the encryption algorithm used to create the hash and the base64-encoded hash of the script or style. When generating the hash, don't include the <script> or <style> tags and note that capitalization and whitespace matter, including leading or trailing whitespace. See unsafe inline script for an example. In CSP 2.0 this applied only to inline scripts. CSP 3.0 allows it in the case of script-src for external scripts.