Hacker News Reader

ademarreon Were the Cuban sonic attack victims actually poisoned?

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.com/story/us-diplomats-sonic-attack-ototox...

ademarreon Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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 in the same way. Is that "acceptable" simply because it's more common for the default port 80 virtual host to be controlled by the hosting provider? That's not as robust as one would hope.

2. Wouldn't http-01 over TLS be made safe if the certificate was required to be valid for the domain being challenged? Granted, there's a TLS chicken and egg problem there, but that's beside the point.

[0] https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-...

ademarreon Issue with TLS-SNI-01 and Shared Hosting Infrastructure

> "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?

ademarreon Go’s hidden pragmas

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.

ademarreon Critique My Plan: API Key for Authentication

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 includeSubdomains from the root).

[0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se...

[1] https://www.usenix.org/conference/usenixsecurity15/technical...

ademarreon Choosing between names and identifiers in URLs

> 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 most web servers ignore unrecognized query params for routing. Examine this URL:

https://news.ycombinator.com/item?t=choosing-between-names-a...

Of course the difference is that Hacker News doesn't disseminate URLs of that form, but that doesn't mean someone couldn't pollute the internet with them.

ademarreon Choosing between names and identifiers in URLs

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.

ademarreon Energy Efficiency Across Programming Languages

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

ademarreon JavaScript string encoding

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 otherwise competent programmers to have funny ideas about what text is and isn't, as this entire thread demonstrates.

ademarreon Measuring Your Own Pupillary Distance

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 couple of other metrics that I think described the frame/lens position on my face.

I sent all those measurements to the vendor (https://www.warbyparker.com) and the second glasses were perfect.

These other self-measure methods look better than the ruler-mirror method that I did, but if I ever buy glasses online again, I'm going to take the trial frames straight to the optician's for proper measurements.

ademarreon I mean, why not tell everyone our password hashes?

Were this true, you would have achieved a pre-image attack.

ademarreon Horcrux: A Password Manager for Paranoids

Side note; I thought Yubikey was not open source. Am I mistaken?

https://www.yubico.com/2016/05/secure-hardware-vs-open-sourc...

ademarreon At The Dawn Of Recorded Sound, No One Cared

Stack Overflow?

ademarreon At The Dawn Of Recorded Sound, No One Cared

> 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 smaller scale, an approach I've played around with is taking attributes of existing technologies that have certain things in common, then diagramming them in different ways and looking for holes.

As a concrete example, let's go back to 2005. You might reason that e-mails and blog posts are both kinds of written messages, however blogs have an open audience, while e-mails are sent to specific recipients, so a closed audience. Separately, you might compare e-mails to text messages, and realize that they are very similar, but one is long form while the other is short form. You can draw this as a table:

        | short form | long form |
       -+------------+-----------+
   open |     ???    | blogs     |
       -+------------+-----------|
 closed |  SMS texts | e-mail    |
       -+------------+-----------+

Now try to figure out what fits in the missing box (short form, open). It's Twitter! (Or even better, decentralized micro blogging.)

ademarreon Authentication Techniques for APIs

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 they were issued before the epoch. This allows you to do mass token revocation (e.g. sign out all active sessions) without knowing the IDs of the tokens that have been issued.

ademarreon The tragedy of 100% code coverage (2016)

> 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.

ademarreon Ask HN: Google Doc email virus?

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 will only go so far. The main criticism I have with many OAuth authorization dialogs, not just Google's, is that they often don't show enough information for technical users to vet the authenticity of the app. It's like if a web browser didn't show the address bar.

ademarreon Ask HN: Google Doc email virus?

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 to abuse this sort of attack. Given this, we do not intend to perform validation that the URL matches the branding information."

That last part was in reference to one of my proposed mitigations, which they chose not to implement.

Here's the discussion on the IETF OAuth WG mailing list from that same time period: https://www.ietf.org/mail-archive/web/oauth/current/msg07625...

ademarreon Symantec CA Response to Google Proposal and Community Feedback

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.

ademarreon CodeStar – Quickly Develop, Build, and Deploy Applications on AWS

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 Cloud Platform at the same time to insulate yourself from major vendor outages.

Also, not all doomsday scenarios are terribly far fetched. AWS might one day have to discontinue a service after losing an intellectual property lawsuit, for example.

ademarreon How release canaries can save your bacon

They touched on this in their SRE post last week: https://cloudplatform.googleblog.com/2017/03/reliable-releas...

ademarreon Apollo 1, Challenger, and Columbia: Remembering NASA’s Lost Astronauts (2016)

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 should be capitalized [0] (e.g. Atlantis, Columbia, Discovery ). We also italicize lunar module and command module names (e.g. Eagle, Columbia, Odyssey, Aquarius). We do not italicize mission names (STS-44, Apollo 11). All ships should be italicized (e.g. the Hornet, the Enterprise). We do not italicize the names of probes and robotic spacecraft (e.g. Voyager, Cassini).

[0] I think "capitalized" is a typo here that should be "italicized".

ademarreon BlueCoat and other proxies hang up during TLS 1.3

> 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 headers: https://news.ycombinator.com/item?id=12655180

ademarreon Show HN: Godb is a simple Go ORM for PostgreSQL, MySQL, SQLite and SQL Server

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

ademarreon Why Does Moby-Dick Sometimes Have a Hyphen? (2015)

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 to write signin. Maybe they'll hyphenate it, but even then people seem less inclined to use sign-in as a verb compared to login.

ademarreon SHA-1 certificate error on Google.com

Not sure the best way to share it, so I'll paste it here...

It's a SHA-256 certificate which expires in January, and it was signed by a SHA-1 intermediate that expires 12/31/16.

ademarreon Why Does Moby-Dick Sometimes Have a Hyphen? (2015)

Personally I prefer sign in over log in. Partially because to sign seems to carry a stronger connection to the intended meaning, to authenticate, than to log does.

ademarreon Why Does Moby-Dick Sometimes Have a Hyphen? (2015)

You sound like you know more about this than I do, but I find login as a verb distasteful and believe such usage should be avoided. What would you do for the past tense? You'll decompose the word to its natural verb, log, and write logged in.

Also, I, for one, still favor e-mail, but I'm definitely in the minority there.

ademarreon OAuth 2.0 Hack Exposes 1B Mobile Apps to Account Hijacking

No, it is not a flaw in the OAuth core logic. From the paper's intro:

> "the OAuth2.0 standard does not cover or define the critical security requirements and protocol details to govern the interactions between the 3rd-party (client-side) mobile app and its corresponding backend server during the SSO process. As a result, various IdPs have developed different home-brewed extensions..."

ademarreon OAuth 2.0 Hack Exposes 1B Mobile Apps to Account Hijacking

These are implementation flaws, not flaws of the OAuth or OpenID Connect protocols themselves.

But the prevalence of implementation flaws indicates a bigger problem. We need better tools and libraries for app developers. Too many people are rolling their own ad hoc implementations, and they shouldn't have to do that.

Some think the spec is partially to blame. The core spec is deceptively approachable, and implementers don't know how to respect it properly. And it's only a primitive building block. On its own it's often not enough to be useful. Even if you implement the core successfully, the glue around it might be bad. That's why I believe we need a bigger ecosystem of vetted utilities for every niche.