I think he actually wants pipes. Instead of having to write:
f3(f2(f1(some data)))
it would be nice to write
some data |> f1 |> f2 |> f3
javascript has proposals for pipe operators because as soon as the simple .map /.filter/.reduce APIs don't suffice (ie. as soon as Promise.all is needed) the f3(f2(f1(data))) mess starts.
It has camera access. Voice for most other things. Without a touchscreen, it would be annoying (to me) to use the remote to move around multiple rooms and devices.
The EU/banner situation keeps confusing people because there are two different laws in play:
1) ePrivacy. the OG banner law. requires you to inform the user (but not consent, as I understand it) if you store data on a user's device. includes cookies, localStorage, indexedDB, etc. does not affect fingerprinting
2) gdpr. requires you to ask consent for any kind of user data processing, unless you can find another legal basis
eprivacy was about cookies, but forgot fingerprinting. gdpr was not specifically about cookies. but gdpr (or at least its past interpretation by the dutch privacy authority) didn't require consent for limited first party analytics.
which led to situations where you'd get the impression that you wouldn't need a banner for first party tracking using cookies .. well the gdpr didn't require it, but the older ePrivacy rules still did.
we still have the digital omnibus law package coming up which is supposed to simplify and resolve the overlap between the two above, and reduce banner requirements at least for SMB just analyzing their website visitors
It does. The current version says "storing of information, or the gaining of access to information already stored, in the terminal equipment". Reading e.g. navigator.userAgent is information already stored in the terminal equipment. If you then use that in any way that gets communicated to remote server (e.g. directly or calculating some fingerprint) you read that information in manner ePD describes.
The directive itself has been transposed incorrectly in many jurisdictions. For example from what I understand the Dutch law added an exception (roughly "for obtaining information about the quality or effectiveness of a supplied information-society service, provided this has no or only minor consequences for the user's privacy.") which is not permitted under ePD. ePD exception list is exhaustive and the only other exception can be done via Article 15. The exceptions done via that are related to things like national security and certain criminal prevention/investigation.
Of course that then raises the issue on how you get invalid exception invalidated. I don't know Dutch procedural law well enough to answer that.
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.
