Hacker News Reader

Comment by a2128 | Hacker News Reader

I learned once of a quick workaround that's baffling - putting a dot at the end of the domain name (example.com/page becomes example.com./page)

Apparently this usually still resolves to the same page but the browser treats it as a different domain with separate cookies and localStorage, so it would bypass the limit, but if you kept doing it then it'd probably accumulate free articles still and stop working

View on HN

That kind of bug happens under the "everything is a string" software paradigm. Abstractions that have more than one string representation inadvertently end up treated as different.

They are semantically different—one is a relative domain name, the other is distinct. I'm not sure how this impacts localstorage or cookies but it might.

Localstorage and cookies are stored by domain. If the relative domain is kept relative then it will never be equal to the absolute domain.

    let map = HashMap::from_iter([
        "www.domain.com.": Cookiebag::new(),
        "www.domain.com": Cookiebag::new(),
    ]);

> so it would bypass the limit, but if you kept doing it then it'd probably accumulate free articles still and stop working

at which point one could perhaps try visiting example.com../page

The reason the trailing dot works is that it represents the implicit root DNS node. Browsers do the dumb thing and consider it a different domain, but AFAIK there's no good reason not to canonicalize the domain name.

All that to say, no, you sadly can't add another trailing dot.

I had never thought about having a local search domain so something like google.com.mynetwork. would resolve (the tailing dot prevents search domain lookups). Would a browser allow that internal site to access google.com cookies (since the lookup would be for google.com, no trailing dot). I suppose that would only work for unsecured traffic anyway so maybe not a huge attack vector.

Edit to add: if you have web services that are resolved via DNS, it may be a performance advantage to configure clients with the trailing dot. A lifetime ago we ran into intermittent latency issues when some DNS resolvers would try to search before checking the canonical entry.

That wouldn't work because Google would not return the proper content, since the host header would not match google.com. HTTPS would not work either, like you said, because the cert would not match the new domain.

If they didn't check host headers, then no, the browser would not send the cookies for google.com, since the browser has no idea about your DNS changes and is only looking at the domain name itself.

> Browsers do the dumb thing

I could use more browser dumb things like this.

Like when the browser won't ever forget that you once visited an HSTS server at this domain and now+forever won't let you visit the http server (at the same domain).

There's a string you can type in blind that bypasses HSTS. Works on Chromium browsers. I don't want to make to too easy to find so I won't say it here but you can look for it.

Don't be ridiculous. The string is 'thisisunsafe' just type it when the hsts whining page has focus, no text box.

You really think HN readers can't find the interstitial bypass keyword? It shows up in the very first Google search for it, I am not sure who you think you are protecting.

I also find it goes against the ethos of HN to try to prevent a user from controlling their own hardware... if I want to MITM myself, I should be able to.

I was more concerned about it becoming more prominent in Google search results but I was just having a moment, never mind :)

> Works on Chromium browsers.

Saw that a few days ago but I don't do Chromium browsers. Cest la vie.

Appreciate the attempt.

Reply on news.ycombinator.com