Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
ademarre
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
11 ms
·
61.
▲
by
ademarre
9y ago
The public suffix is more correct than the TLD; however the fact that publicsuffix.org accepts private domains at the domain owners request weakens the mitigation.
62.
▲
by
ademarre
9y ago
https://tools.ietf.org/html/rfc8265
63.
▲
by
ademarre
9y ago
An interesting Wired article [0] considered a hybrid cause: > "Possibly [...] inaudible infra- and ultrasound could be synergistic with an ototoxin just as industrial factory noise can be." [0] https://www.wired.co
64.
▲
by
ademarre
9y ago
Thanks for expanding. That's interesting. So they disabled http-01 over TLS [0]. Two questions: 1. Isn't the default virtual host practice still a problem even without TLS/SNI? Apache chooses a default virtual host on port 80
65.
▲
by
ademarre
9y ago
> "Let's Encrypt already disabled a feature of http-01 validation before going live" I'm curious what this was. Can you elaborate or point me somewhere I can read about that?
66.
▲
by
ademarre
9y ago
The cost of complexity in a programming language is paid not only by the developers of the language but also by the programmers that use it.
67.
▲
by
ademarre
9y ago
Use the "__Host-" name prefix. [0] This prevents cookies from being set at the root domain by a subdomain. Which in turn prevents non-TLS MITM cookie injection [1] as long as the application uses HSTS (even without includeSubdomai
68.
▲
by
ademarre
9y ago
> 1) there are now an infinite number of URLs for every one of your pages that may end up separately stored on various services Sometimes I call this a URL black hole. In all fairness, black holes are everywhere when you consider that
69.
▲
by
ademarre
9y ago
This used to be a serious problem. It may be fixed now, but Firefox would eternally cache 301s unless explicitly told not to. This is why I configure all of my servers to disallow caching of 301s.
70.
▲
by
ademarre
9y ago
I can't speak to the Java comparison, but the site says they used Go 1.6.3. The SSA back end introduced in Go 1.7 (amd64) came with a nice performance boost. https://blog.golang.org/go1.7
71.
▲
by
ademarre
9y ago
Sometimes I think we would be better off if our languages didn't have string as a data type at all. The text encodings themselves (e.g. UTF-8, UTF-32) ought to be proper data types. Strings are a leaky abstraction that cause otherwis
72.
▲
by
ademarre
9y ago
I once tried to measure my own pupillary distance using the ruler-mirror method. I failed and the glasses I ordered were unusable. In the end I brought them in to my optician's office where they precisely measured not only my PD but a
73.
▲
by
ademarre
9y ago
Were this true, you would have achieved a pre-image attack.
74.
▲
by
ademarre
9y ago
Side note; I thought Yubikey was not open source. Am I mistaken? https://www.yubico.com/2016/05/secure-hardware-vs-open-sourc...
75.
▲
by
ademarre
9y ago
Stack Overflow?
76.
▲
by
ademarre
9y ago
> It makes one wonder what currently isn't being invented simply because it doesn't fit into our conceptual framework. It's fun to think up thought exercises to try and help break out of our conceptual framework. On a sm
77.
▲
by
ademarre
9y ago
In addition to single token revocation, you can use the account epoch approach (at least that's what I call it): Store an "epoch" date in the database for each account. Tokens issued for that subject are considered invalid if
78.
▲
by
ademarre
9y ago
> a false sense of security Yes. Code coverage should not be the primary measure of quality of your tests. That thinking leads to tests designed to cover lines, not use cases.
79.
▲
by
ademarre
9y ago
To be clear, I'm not criticizing Google. Just presenting an interesting piece of information that shows the approach they've taken on this type of phishing attack in the past. Phishing is a hard problem, and any technical solution
80.
▲
by
ademarre
9y ago
I reported this attack vector to Google back in 2012. They awarded a modest bounty, and then a few months later I heard this: > "We're deploying some abuse detection and reactive measures to deal with impostors that might try
81.
▲
by
ademarre
9y ago
I think the point there is that if Chrome doesn't trust that CA, then the servers will need to be updated to use a different CA, which will break clients that pinned the old CA.
82.
▲
by
ademarre
9y ago
It's not just the doomsday scenario. It's smart to avoid vendor lock-in because eventually a competing cloud vendor could offer better pricing or more reliable service. Or you could run redundant infrastructure on AWS and Google C
83.
▲
by
ademarre
10y ago
They touched on this in their SRE post last week: https://cloudplatform.googleblog.com/2017/03/reliable-releas...
84.
▲
Style Guide for NASA History Authors and Editors
(history.nasa.gov)
1 points
by
ademarre
10y ago
|
1 comments
85.
▲
by
ademarre
10y ago
On a lighter note, being curious why they italicized Challenger and Columbia but not Apollo 1, I found this, which I had not seen before: https://history.nasa.gov/styleguide.html > Italics: All orbiter names shoul
86.
▲
by
ademarre
10y ago
> It sounds like a perfectly reasonable behaviour if the goal is to "fail closed", to provide more security in a fashion similar to a whitelist. This reminds me of firewalls that weaken security by filtering unrecognized HTTP
87.
▲
by
ademarre
10y ago
Coincidentally, something called "GodBolt" [0] is on the front page at the same time. At first glance I almost thought they were related posts. [0] https://news.ycombinator.com/item?id=13182726
88.
▲
Marketing the Blockchain
(avc.com)
1 points
by
ademarre
10y ago
|
0 comments
89.
▲
by
ademarre
10y ago
Good point, it is the same metaphor, but signing is the essential action. What do you do with the log book? You sign it. Another reason I prefer sign in is because there's less discord about its usage. I have never seen anyone try
90.
▲
by
ademarre
10y ago
Not sure the best way to share it, so I'll paste it here... -----BEGIN CERTIFICATE----- MIIEgDCCA2igAwIBAgIILLVnxACV9P8wDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl cm5ldCBBdXRob3Jpd
More ›