HowNetWorks
Support traps serving .jpg, .png etc.
Support traps serving .jpg, .png etc. as some services and bots only watch for images.
Suggested by https://twitter.com/raimue/status/794558042255851520.
Perhaps any filename extension. Then it could be used to replace web bug type of Canarytokens (so there would be no need to change already planted tokens but just the server).
Yup. Would it be a good idea to make trap URLs return 404 (Not Found) instead of 200 (OK)? I don't know if it's needed at all, but maybe that way we would avoid unintentionally fuzzing JPG parsers and such :)
It would be unexpected if an URL with a .jpg extension returns text/html instead of image/jpeg. Although proper JPEG parsers would recognize this quickly as an invalid image, serving a 404 might have better effects for display on the client side of the trap receiver.
@raimue explained it well. I'm actually not too worried about JPEG, but some less battle-hardened parsers for more exotic formats might have problems.
Other status code choices include 401 (Unauthorized) and 403 (Forbidden).
Returning 451 (Unavailable For Legal Reasons) would be funny though ;)
Commit e842d4b is now deployed to the live site. It modifies trap URLs to return status code 404. Moreover we now support trap URL suffixes, which allows appending stuff to the trap URL path as long as the additional part starts with . or /. So if you have a trap URL https://uriteller.io/blah you can also use https://uriteller.io/blah.png or https://uriteller.io/blah/xyzzy.
The suffixes are stored for potential future use. For example https://uriteller.io/blah.png stores the suffix .png. Query string gets counted as a part of the suffix, so https://uriteller.io/blah/xyzzy?hello=world stores /xyzzy?hello=world.
Feel free to try it out! There is currently no particular support for this functionality in the UI side, but it's probably still useful.