909 karma · joined September 4, 2013
[ my public key: https://keybase.io/robison; my proof: https://keybase.io/robison/sigs/Vs1MsNRJR9wR9ux_h6I-PLapP-TCppHvAdOUojx0Q9U ]
edit: Found it, uws.js in resources/bootstrap/discord_rpc.zip
edit2: This is arguably worse, but the argument may be "it's a compiled binary":
-bash-4.1$ strings discord_rpc.node | grep uws.*cpp$
../../discord_common/native/third_party/uws/nodejs/addon.cpp
../../discord_common/native/third_party/uws/nodejs/addon.cpp
../../discord_common/native/third_party/uws/src/EventSystem.cpp
../../discord_common/native/third_party/uws/src/Extensions.cpp
../../discord_common/native/third_party/uws/src/HTTPSocket.cpp
../../discord_common/native/third_party/uws/src/Network.cpp
../../discord_common/native/third_party/uws/src/Server.cpp
../../discord_common/native/third_party/uws/src/UTF8.cpp
../../discord_common/native/third_party/uws/src/WebSocket.cpp
../../discord_common/native/third_party/uws/nodejs/addon.cpp
../../discord_common/native/third_party/uws/src/HTTPSocket.cpp
../../discord_common/native/third_party/uws/src/WebSocket.cpp
../../discord_common/native/third_party/uws/src/EventSystem.cpp
../../discord_common/native/third_party/uws/src/Extensions.cpp
../../discord_common/native/third_party/uws/src/Network.cpp
../../discord_common/native/third_party/uws/src/Server.cpp
../../discord_common/native/third_party/uws/src/UTF8.cpp
-bash-4.1$Happy now?
Much like fish, the head tends to rot first.
0: https://www.usatoday.com/story/news/politics/2016/09/20/fami...
Nice theme on the blog.
* stateless operation (via UDP)
* no reliance on SSL/TLS or PKI
* ability to catch incorrect servers (assuming no collusion)
I think it's a very interesting take on time services, without being something quite as heavy as PTP/IEEE1588. The stated goals of fixing wildly incorrect clocks over ultraprecise timing [0], preventing clock-source tampering, and keeping largely in-line with the original design concepts of ntp (while solving a number of security shortcomings) seems to be targeted squarely at user devices, and much less so at service providers or operators that require precision timing for log stamping and the like.
Additionally, if you need a roughly-correct clock for validating HTTPS certificates, and you have to connect to an HTTPS server to update your time to be roughly correct, how do you trust the server? Sure, you can simply connect to something with a self-signed cert, but then you're putting the trust squarely back in the hands of that single server, without any method of verifiability. Turtles all the way down.
[0]: "The Roughtime creators state that 25% of Chrome’s certificate errors are caused by incorrect local clocks (off by days or more). A local clock within a few seconds of reference time is good enough."
https://whois.arin.net/rest/net/NET-18-145-0-0-1.html
edit: Looks like a lot more than just 18.145/16, based on https://whois.arin.net/rest/org/AT-88-Z/nets
$ IFS=":$IFS";for i in $( openssl ciphers 'ALL:!ADH:@STRENGTH:!EXP' | sed -E -e 's/(-(MD5|SHA)|(DHE|DSS|EDH-DSS|EDH|RSA)-|3)//g' ); do openssl enc -$i -d -in bf.txt -k Billforward; done
edit: if anyone likes meat, potatoes, and whisky, get in touch.
ACM handles all aspects of SSL/TLS certificates for _custom domains_;
you no longer have to purchase certificates, or worry about their
expiration or renewal.
Emphasis mine. -bash-4.1$ curl -vkLs https://wind-river-5693.herokuapp.com 2>&1 | grep certificate
* Server certificate: *.herokuapp.com
* Server certificate: DigiCert SHA2 High Assurance Server CA
* Server certificate: DigiCert High Assurance EV Root CA
-bash-4.1$