Why is 418 the particular target? Just because of RFC2324?
IANA should also typographically distinguish “Unassigned” and “Reserved” in the registry descriptions, to prevent confusion.
This I can get onboard with. Honestly, I've never seen a 418 easter egg, but I'd think it would be an HTTP spec violation if it didn't at least conform to the higher level 4xx definition (Client Error) :)
Nope. Actually, there was a paper published recently on using a phone's gyro / accelerometer (through the HTML5 APIs) in order to keylog users; because the API is precise enough for you to detect subtle motion of the phone as you press on the software keyboard.
Apparently in some mobile browsers, you can continue to poll the API even when your tab is not on focus.
Oh, that's really nice. So if you have a fix (and even if you don't) you can use dead reckoning and tie any points where the GPS is accessible and then re-create the path the phone took. That's a bit of a leak. Wonder how long after or before a GPS fix this would be effective, those phone accelerometers probably aren't all that accurate but you might be able to calibrate the one in a specific phone if you have data available for both of them for some stretch of trajectory.
Even using calibrated and temperature controlled consumer level accel/gyro sensors for dead reckoning results in estimated velocity error reaching few meters/s in a second or two.
Current consumer level sensor quality is enough for:
a) attitude estimation;
b) smooth interpolation between GPS updates if they arrive often enough;
IIRC the accelerometers are way to imprecise to correctly detect starts and stops. Errors compound so quickly that any kind of useful accuracy for dead reckoning is a long ways out.
The use of smartphones is becoming ubiquitous in modern society, these very personal devices store large amounts of personal information and we use these devices to access everything from our bank to our social networks, we communicate using these devices in both open one-to-many communications and in more closed, private one-to-one communications. In this paper we have created a method to infer what is typed on a device purely from how the device moves in the user’s hand. With very small amounts of training data (less than the size of a tweet) we are able to predict the text typed on a device with accuracies of up to 90%. We found no effect on this accuracy from how fast users type, how comfortable they are using smartphone keyboards or how the device was held in the hand. It is trivial to create an application that can access the motion data of a phone whilst a user is engaged in other applications, the accessing of motion data does not require any permission to be granted by the user and hence represents a tangible threat to smartphone users.
Because Mark Nottingham (co-chair of the HTTP WG) first tried to get libraries/stdlibs to remove support for 418 (as part of builtins, since it's not a formally standardised code, he had no issue with application-specific support, everyone is free to return whatever status codes they wish) and faced some pushback, he switched to the alternate tack of getting it into a standard.
It's a response to this story (https://news.ycombinator.com/item?id=14987460), where a contributor has been going to many different projects and attempting to remove language support for the 418 error code.
EDIT: Ah, so it's the same person. In which case it's more of a continuation, and I anticipate that the intention is to make implementations that allow 418 non-compliant.
Note that the "contributor" (Mark Nottingham) is also the author of the document in OP, and deserves a lot of credit for taking this approach. Given that his area of work is HTTP standards, I think he initially started removing 418 to tidy up and make things compliant and isn't just some bore who hates fun. Now he's managed to make everyone happy in a standards-compliant way.
It was interesting reading the threads on /r/webdev about this whole debacle. The threads were full of people saying that he's an arsehole with too much time on his hands who must hate fun.
Nobody actually stopped to read the guys bio and realise that he's more than qualified to be bringing up these issues. It doesn't help that the guy who made save418.com is literally 14 (which seems to be about the average age of /r/webdev).
The /r/webdev thread (https://www.reddit.com/r/webdev/comments/6stdcj/http_error_c...) remained quite respectful actually, afaik there were no real hostile remarks directed towards Mark Nottingham within it. In fact, it's ironic - the very comment I'm replying to is probably more distasteful and antagonistic than anything that could be found in the Reddit thread.
He probably confused it with the /r/programming thread [0], where the top comments with hundreds of votes were stupid insults like "What a dick","miserable bastard", "the most boring man in the universe", "standards committee troll", "he had fun once and hated it", "Soulless, joyless, heathens":
Often reddit threads read more respectful after-the-fact; the less respectful comments either get downvoted enough that they aren't displayed unless you look for them, or are moderated away. Often they are much harsher early in the thread. I'm not sure if that ways the case here, but it is common enough that I wouldn't doubt it.
When comments are removed by mods on Reddit, they're replaced with the text "[REMOVED]", which doesn't appear once in the referenced thread (insults would not be removed in the first place though, they break no /r/webdev rules). And you can scroll to the bottom of the thread to see all the downvoted comments, none of which are are condescending towards Mark. So no, that isn't the case here.
Why should it matter that the guy who made save418.com is literally 14? Let's look at what he's accomplishing - in spite of his age - rather than whether or not he is substantially older or younger than the opposition in this argument. It seems like that's a pretty cheap argument to bring to the table.
It's weird though. The origin spec is specifically a discrete protocol called HTCPCP, not HTTP, so it has nothing to do with HTTP standards. They can do whatever they want with 418 in HTTP.
They can, but they believe in rough consensus and working code and in being conservative in what they do and liberal in what they accept from others.
It's clear that a lot of real-world HTTP implementations are using HTTP 418 to mean I'm A Teapot, whether or not they should, and that reassigning it would cause practical difficulties.
That's not clear to me. Nobody relies on the feature, it's a tiny piece of code, only some vendors support it, and it's not even part of the spec. (It also can't be reassigned because it was never assigned to begin with)
If they like 418, they can add it to the spec. But this idea that it's been "consumed" is weird. It's like saying <blink> was "consumed" in HTML because two browsers used to support it. It was just an unofficial feature of popular vendor software, and is now officially disavowed.
Basically what we're saying is we're not going to implement 418 in the spec, but at the same time, we're not going to let anyone use it?
It's like saying <blink> was "consumed" in HTML because two browsers used to support it.
Which is accurate. Reintroducing a tag named "blink" into HTML to mean something other than "blinking text" would be a really bad idea for compatibility reasons.
So we're trying to avoid breaking the internet by committing to people expecting an error when they're talking to a teapot? So that past implementations of clients connecting to teapots won't break?
Like I say, we could also just add it to the spec... But that would be ridiculous, because why would you support telling someone you were a teapot in an HTTP protocol, when the feature is only useful in a protocol for brewing coffee? That would be like taking a programming language's syntax for assigning data objects and turning it into it's own standard for a text file format.
Maybe a time traveler set this whole thing up 19 years ago just to troll people on standards boards.
It's a miniscule bit of humour that consumes 1 of 31 used slots in a 100-slot block, in an area of tech that isn't even remotely drowning in 'fun stuff'. What does it really matter? There are plenty of perfectly serious RFCs that are even less implemented than 418.
It's not like this RFC ratifying a 20-year-old joke that 'made it' is going to generate a cavalcade of lookalikes.
You never know. Some people used to think 4 billion slots would be more than enough for addressing every host in the world, and so they allocated the addresses haphazardly. Now look at the sorry state of IPv6 adoption 20 years after it's been designed.
Some people used to think 65536 code points would be more than enough to encode every character in every language. Later it turned out not to be the case. Expanding that space necessitated the creation of hacks of various degrees of awfulness like UTF-16, CESU-8, WTF-8; today nearly every Unicode-aware environment has to be prepared to deal with unpaired surrogates somehow.
Expanding a fixed-size namespace is a pain. Who knows if HTTP status codes won't become scarce some day. They better not be wasted on frivolities.
Having been around for the creation of Unicode, there were plenty of people who argued that 16 bits was insufficient for encoding all the characters and fought for the competing ISO standard which was 32 bits. A final compromise made Unicode a subset of ISO-10646 and now the two character sets are synchronized and act as parallel standards. UTF-8/16/32 were part of things from the beginning not because of the 16-bit assumption behind Unicode 1.0, but for the sake of keeping data reasonably sized. UTF-8 allows for 7-bit ascii files (which were the majority of text files back in the day) to be compliant without change and kept the default size of text files from being doubled or quadrupled in an era in which that was a serious concern for both bandwidth (dial-up connections at 2400baud or lower were quite common) and storage (20MB was considered a HUGE amount of storage).
Several discussions have included anecdotes from people about how they are using the 418 code for various things, so I don't know how you can be sure that nobody relies on it.
Say you want to add some feature critical to correctness. "Request can't be committed until resent to other quorum members." Something serious like that. You can't use 418 for that feature because some non-conforming servers are already returning it as a joke. You'd have to triage new RFCs until you get one that isn't important enough to work reliably, and sacrifice it to use up the tainted code.
The 400-block is 69% free, after 28 years of development. If we're ever in the position where we need to free up just one more code, then we're already consuming beyond our capacity and will need to sort out an alternative anyway.
Exactly. If we run out of 400-codes without an alternative having been set out, such as e.g. designating one or more of the remaining 400 codes to specify extended formats for, somebody is not doing their jobs.
E.g. once (if ever) we're down to 10 or so free ones, assign them as broad categories and specify that the response text needs to contain an additional, longer status code (so, say, "499 1234 some text" and "499 4242 some text").
It's not as if tech doesn't have a long history of including extension fields like that, and it still works with the existing grammar
...and seems aware that this is simply "tidying up" as opposed to someone from the "No-Fun League"... see the working title: draft-nottingham-thanks-larry-00
Comments
Why is 418 the particular target? Just because of RFC2324?
This I can get onboard with. Honestly, I've never seen a 418 easter egg, but I'd think it would be an HTTP spec violation if it didn't at least conform to the higher level 4xx definition (Client Error) :)
An example of an existing easter egg (for reference): https://www.google.com/teapot
It looks as if the teapot is responsive to my phone's gyros. I would've thought it would need special permission for that.
What a terribly clever Easter egg.
Nope. Actually, there was a paper published recently on using a phone's gyro / accelerometer (through the HTML5 APIs) in order to keylog users; because the API is precise enough for you to detect subtle motion of the phone as you press on the software keyboard.
Apparently in some mobile browsers, you can continue to poll the API even when your tab is not on focus.
Oh, that's really nice. So if you have a fix (and even if you don't) you can use dead reckoning and tie any points where the GPS is accessible and then re-create the path the phone took. That's a bit of a leak. Wonder how long after or before a GPS fix this would be effective, those phone accelerometers probably aren't all that accurate but you might be able to calibrate the one in a specific phone if you have data available for both of them for some stretch of trajectory.
Even using calibrated and temperature controlled consumer level accel/gyro sensors for dead reckoning results in estimated velocity error reaching few meters/s in a second or two.
Current consumer level sensor quality is enough for: a) attitude estimation; b) smooth interpolation between GPS updates if they arrive often enough;
IIRC the accelerometers are way to imprecise to correctly detect starts and stops. Errors compound so quickly that any kind of useful accuracy for dead reckoning is a long ways out.
For once a bad sensor is good news.
More proof that Javascript and HTML5 are cancer for privacy on the internet
link the paper please?
https://doi.org/10.1007/978-3-319-58460-7_15
Keystroke Inference Using Smartphone Kinematics
The use of smartphones is becoming ubiquitous in modern society, these very personal devices store large amounts of personal information and we use these devices to access everything from our bank to our social networks, we communicate using these devices in both open one-to-many communications and in more closed, private one-to-one communications. In this paper we have created a method to infer what is typed on a device purely from how the device moves in the user’s hand. With very small amounts of training data (less than the size of a tweet) we are able to predict the text typed on a device with accuracies of up to 90%. We found no effect on this accuracy from how fast users type, how comfortable they are using smartphone keyboards or how the device was held in the hand. It is trivial to create an application that can access the motion data of a phone whilst a user is engaged in other applications, the accessing of motion data does not require any permission to be granted by the user and hence represents a tangible threat to smartphone users.
I was worried that page would actually return a 200 OK response, but curl confirmed it actually returns a 418 code
Is there a scenario where people end up there?
Yes, ^this^ one.
Probably when it's linked to, for fun, like above.
Because Mark Nottingham (co-chair of the HTTP WG) first tried to get libraries/stdlibs to remove support for 418 (as part of builtins, since it's not a formally standardised code, he had no issue with application-specific support, everyone is free to return whatever status codes they wish) and faced some pushback, he switched to the alternate tack of getting it into a standard.
It's a response to this story (https://news.ycombinator.com/item?id=14987460), where a contributor has been going to many different projects and attempting to remove language support for the 418 error code.
EDIT: Ah, so it's the same person. In which case it's more of a continuation, and I anticipate that the intention is to make implementations that allow 418 non-compliant.
Note that the "contributor" (Mark Nottingham) is also the author of the document in OP, and deserves a lot of credit for taking this approach. Given that his area of work is HTTP standards, I think he initially started removing 418 to tidy up and make things compliant and isn't just some bore who hates fun. Now he's managed to make everyone happy in a standards-compliant way.
It was interesting reading the threads on /r/webdev about this whole debacle. The threads were full of people saying that he's an arsehole with too much time on his hands who must hate fun.
Nobody actually stopped to read the guys bio and realise that he's more than qualified to be bringing up these issues. It doesn't help that the guy who made save418.com is literally 14 (which seems to be about the average age of /r/webdev).
The /r/webdev thread (https://www.reddit.com/r/webdev/comments/6stdcj/http_error_c...) remained quite respectful actually, afaik there were no real hostile remarks directed towards Mark Nottingham within it. In fact, it's ironic - the very comment I'm replying to is probably more distasteful and antagonistic than anything that could be found in the Reddit thread.
He probably confused it with the /r/programming thread [0], where the top comments with hundreds of votes were stupid insults like "What a dick","miserable bastard", "the most boring man in the universe", "standards committee troll", "he had fun once and hated it", "Soulless, joyless, heathens":
[0] https://www.reddit.com/r/programming/comments/6sxea0/http_er...
Often reddit threads read more respectful after-the-fact; the less respectful comments either get downvoted enough that they aren't displayed unless you look for them, or are moderated away. Often they are much harsher early in the thread. I'm not sure if that ways the case here, but it is common enough that I wouldn't doubt it.
When comments are removed by mods on Reddit, they're replaced with the text "[REMOVED]", which doesn't appear once in the referenced thread (insults would not be removed in the first place though, they break no /r/webdev rules). And you can scroll to the bottom of the thread to see all the downvoted comments, none of which are are condescending towards Mark. So no, that isn't the case here.
I believe the [removed] only appears in place of comments with replies that have not been deleted.
Though yeah, that still makes it rather implausible.
In the default sort mode ("best"), sufficiently downvoted comments won't be displayed at all, even if you do scroll all the way to the bottom.
Why should it matter that the guy who made save418.com is literally 14? Let's look at what he's accomplishing - in spite of his age - rather than whether or not he is substantially older or younger than the opposition in this argument. It seems like that's a pretty cheap argument to bring to the table.
For those that may not know, Mark is also co-chair of the HTTP Working Group on the IETF[1].
[1]: https://datatracker.ietf.org/wg/httpbis/charter/
It's weird though. The origin spec is specifically a discrete protocol called HTCPCP, not HTTP, so it has nothing to do with HTTP standards. They can do whatever they want with 418 in HTTP.
They can, but they believe in rough consensus and working code and in being conservative in what they do and liberal in what they accept from others.
It's clear that a lot of real-world HTTP implementations are using HTTP 418 to mean I'm A Teapot, whether or not they should, and that reassigning it would cause practical difficulties.
That's not clear to me. Nobody relies on the feature, it's a tiny piece of code, only some vendors support it, and it's not even part of the spec. (It also can't be reassigned because it was never assigned to begin with)
If they like 418, they can add it to the spec. But this idea that it's been "consumed" is weird. It's like saying <blink> was "consumed" in HTML because two browsers used to support it. It was just an unofficial feature of popular vendor software, and is now officially disavowed.
Basically what we're saying is we're not going to implement 418 in the spec, but at the same time, we're not going to let anyone use it?
Which is accurate. Reintroducing a tag named "blink" into HTML to mean something other than "blinking text" would be a really bad idea for compatibility reasons.
So we're trying to avoid breaking the internet by committing to people expecting an error when they're talking to a teapot? So that past implementations of clients connecting to teapots won't break?
Like I say, we could also just add it to the spec... But that would be ridiculous, because why would you support telling someone you were a teapot in an HTTP protocol, when the feature is only useful in a protocol for brewing coffee? That would be like taking a programming language's syntax for assigning data objects and turning it into it's own standard for a text file format.
Maybe a time traveler set this whole thing up 19 years ago just to troll people on standards boards.
Looking at you, JSON...
It's a miniscule bit of humour that consumes 1 of 31 used slots in a 100-slot block, in an area of tech that isn't even remotely drowning in 'fun stuff'. What does it really matter? There are plenty of perfectly serious RFCs that are even less implemented than 418.
It's not like this RFC ratifying a 20-year-old joke that 'made it' is going to generate a cavalcade of lookalikes.
You never know. Some people used to think 4 billion slots would be more than enough for addressing every host in the world, and so they allocated the addresses haphazardly. Now look at the sorry state of IPv6 adoption 20 years after it's been designed.
Some people used to think 65536 code points would be more than enough to encode every character in every language. Later it turned out not to be the case. Expanding that space necessitated the creation of hacks of various degrees of awfulness like UTF-16, CESU-8, WTF-8; today nearly every Unicode-aware environment has to be prepared to deal with unpaired surrogates somehow.
Expanding a fixed-size namespace is a pain. Who knows if HTTP status codes won't become scarce some day. They better not be wasted on frivolities.
Having been around for the creation of Unicode, there were plenty of people who argued that 16 bits was insufficient for encoding all the characters and fought for the competing ISO standard which was 32 bits. A final compromise made Unicode a subset of ISO-10646 and now the two character sets are synchronized and act as parallel standards. UTF-8/16/32 were part of things from the beginning not because of the 16-bit assumption behind Unicode 1.0, but for the sake of keeping data reasonably sized. UTF-8 allows for 7-bit ascii files (which were the majority of text files back in the day) to be compliant without change and kept the default size of text files from being doubled or quadrupled in an era in which that was a serious concern for both bandwidth (dial-up connections at 2400baud or lower were quite common) and storage (20MB was considered a HUGE amount of storage).
As frivolous as you think 418 is, people use it.
You honestly can't, in this situation, be the judge of what is "frivolous use" and what is not.
It's literally an error designed to tell a client that an operation occurred on a teapot and not a coffee machine. It is the definition of frivolous.
I appreciate your view point.
Olive oil was used as lantern fuel before it was ingested.
Some swear by it, some want it banned.
Only the user can judge!
Except blink is a string that means what it is. 418 is one of a small set of codes to use and has no purpose as it exists other than nonsense.
Several discussions have included anecdotes from people about how they are using the 418 code for various things, so I don't know how you can be sure that nobody relies on it.
Say you want to add some feature critical to correctness. "Request can't be committed until resent to other quorum members." Something serious like that. You can't use 418 for that feature because some non-conforming servers are already returning it as a joke. You'd have to triage new RFCs until you get one that isn't important enough to work reliably, and sacrifice it to use up the tainted code.
The 400-block is 69% free, after 28 years of development. If we're ever in the position where we need to free up just one more code, then we're already consuming beyond our capacity and will need to sort out an alternative anyway.
Exactly. If we run out of 400-codes without an alternative having been set out, such as e.g. designating one or more of the remaining 400 codes to specify extended formats for, somebody is not doing their jobs.
E.g. once (if ever) we're down to 10 or so free ones, assign them as broad categories and specify that the response text needs to contain an additional, longer status code (so, say, "499 1234 some text" and "499 4242 some text").
It's not as if tech doesn't have a long history of including extension fields like that, and it still works with the existing grammar
The contributor trying to remove 418 and the author of this RFC are the same person (Mark Nottingham[1])
[1] https://en.wikipedia.org/wiki/Mark_Nottingham
...and seems aware that this is simply "tidying up" as opposed to someone from the "No-Fun League"... see the working title: draft-nottingham-thanks-larry-00
For context: "Larry" is the author of the April Fools' RFC that introduced 418.
Because:
1st: RFC2324 mentioned it
and
2nd: too many people then implemented it.
It is implemented as a valid HTTP code in the java Spring framework for everyone to support. That's how I learned about it first.
Same with the standard Go http package (https://golang.org/src/net/http/status.go?s=2540:2600).
https://github.com/requests/requests/blob/3c5ecfc9f5f6fd2953...