Comment by JoshTriplett
1 day ago
> entering the characters http://www.longbets.org/601 into the address bar of a web browser or command line tool (like curl)
The part of this that's most likely to fail at some point is the "http://".
1 day ago
> entering the characters http://www.longbets.org/601 into the address bar of a web browser or command line tool (like curl)
The part of this that's most likely to fail at some point is the "http://".
In my mind, the part that is most likely to fail is "return an HTML document that still contains the following text." Nowadays, more and more "HTML documents" do not contain any content at all, just some JavaScript that is responsible for then fetching and displaying the content.
You two have just spelled out a very specific bet. Care to put a wager on it? :)
If the text was returned using a staged process, whereby the server first returns an instruction (JavaScript), and the web browser then executes that instruction, which is what transfers the text, then that doesn't actually change anything. Those are just technical details of the transfer. You are viewing an HTML document on-screen; it makes no difference to this bet if it was returned to you by a different mechanism than originally conceived, since the bet doesn't specify any transfer mechanism, just that the URL was entered into a browser.
I understand that this isn't entirely clear-cut and that people will interpret it differently, but in my opinion, there is a significant difference between "a webpage that contains text X" and "an HTML document that contains text X." "Webpage" and "HTML document" are not synonyms - "HTML document" has a much narrower meaning.
> or command line tool (like curl)
Even if you interpreted the bet generously to allow for a browser to render the content using JavaScript, if I understand the bet correctly, the condition of working with a command-line tool like curl would fail.
3 replies →
I used to be someone, man, I was a dreamer, a programmer, a man!
Now I'm a human slave copying text from web browsers to chat windows to get around JS rendering bullshit.
The preferred term is meat proxy ;)
2 replies →
One of those things is true
The detailed terms of the bet include this:
> A 301 redirect from www.longbets.org/601 to a different URL containing that text would also fulfill those conditions.
I assume this would cover the HTTP->HTTPS redirect scenario.
I think the parent is referring to the possibility that one day, browsers might put up a blanket security warning for HTTP URLs instead of following redirects. Or they might try to be a little too clever with HTTPS upgrades.
In particular, the automatic upgrade feature in modern browsers is based on several heuristics rather than explicit configuration like HSTS, so there's always a bit of room for breakage there. For example, they don't even check if the server returns a 301 redirect, which can be problematic if the server wants to redirect to HTTPS on a different host/port or make some changes to the path.
> Or they might try to be a little too clever with HTTPS upgrades.
They're not going to get any cleverer than they are now. In October we'll finally be done with heuristics or central databses of https-first websites used by the various browsers or the half a dozen of headers that you must dance around to get the upgrade to work securely and reliably. They will just default to https first.
https://blog.google/security/https-by-defau/
Yes this is about Chrome, but all others will follow.
1 reply →
Yeah that was a clever bit of foresight there.