Can whatever the next new image format for the web will be please have a JSON block at the start giving
- dimensions
- filetype
- minimum required decoder version
- lossless: true/false
- a list of alternative URLs and mimetypes to older image formats
And it doesn't have to be JSON, as long as it's in a fixed location (looking at you, AVIF and JPEG), extensible and can be decoded by just reading the first 8KB or 16KB.
Then any future image format is a simple drop-in without requiring complex processing on the server side or a lot of complexity in HTML (not to mention CSS)
Elastic/Opensearch uses GET requests with a body for search, which is complicated or forbidden (not exactly sure) with the HTTP spec. Not all HTTP clients are willing to submit a body with a GET.
So opensearch also allows you to POST search requests, but those are uncacheable
QUERY would fit here perfectly - it's probably trivial for opensearch to add but it will take some time for clients to catch up.
I disagree. I think the adoption (or dismissal) of QUERY will show.
First thing that comes to mind is that the idempotency of GET resources are easy to handle. URL's have a fixed size, they can be efficiently hashed, cached and are unambiguous about how they serve this purpose.
It is unclear how the ecosystem will deal with the QUERY requirements. It's easy for apps, but browsers, http caches and servers will take some time to figure out solutions.
Fixing GET would have the same amount of uncertainty in addition to the need to keep current expectations valid. It's not easier, it's harder.
The noise probably makes the lava lamp wall just as effective as pointing the camera at the Mona Lisa - the lamps themselves are not that unpredictable frame-to-frame.
For the record, the lamps and camera are present in their lobby afaik, so you can actually go there, stand in front of them, and slightly affect the entropy.
> But I like this review of techniques, even the simplest ones are very effective, that surprised me.
because harvesters don't care until one technique gets massive use. if you come up with a unique but simple enough scheme for your sites and keep a few dozen email addresses out of their reach.. they've still gathered a million addresses. it's not really worth their effort to get the last 0.0001% of extra email addresses
so it's best to just not advertise your solution and make sure it doesn't get n
any outside traction - if it gets popular the harvesters will defeat it
The author of the article mentioned that they are using it as a honeypot to detect when bots (or rather authors of the bots) implement a work-around for the obfuscation technique. Which is pretty smart!
At least the error goes away immediately, for everyone, once you fix the cert.
.net seems to serve DS records with at least 18 hours TTL. so worst case it takes your monitoring up 18 hours to notice your record was broken, and then another 18 hours before your fixed record is server everywhere.
I think the 'K-thing' was a big and helpful part of getting early volunteers onboard to build apps for KDE. They really seemed to enjoy rebuilding existing applications into a K-version.
So I guess you just have to live with it, but consider it a way to honor the original contributors who build all the K(DE)-versions of the common apps
Then any future image format is a simple drop-in without requiring complex processing on the server side or a lot of complexity in HTML (not to mention CSS)
reply