arnarbi
Joined 14 years ago
Joined 14 years ago
I always assumed, probably incorrectly, that there would be too much jitter in the actual timing so I had built a few prototypes of e.g. an esp8266 controlled relay, where you would give the MCU a duration rather than separate on/off commands. But I guess that was wildly over-optimizing. In your case, how stable is the delay from the app sending a command until the switch operates?
I'd add voice mode for color printing in total darkness.
The restaurant fee isn’t a fee for something “extra”, it’s just a blanket extra charge on everything.
It’d be like the airline sold you a ticket for $500, but as you step off the plane at the destination they say “actually it was $550”, because it said so in the fine print.
These are arguments for including the fees that make the customer __still pay the same higher price__, implying that the whole point is that they won’t notice. And reporters don’t seem to even register the absurdity of those remarks or question them in any way.
https://www.sfgate.com/food/article/sf-restaurants-junk-fees...
https://www.kqed.org/news/11992412/californias-junk-fee-ban-...
It's in general a very newcomer friendly hobby, which is both important as a newcomer yourself as well as for meeting new people once you are into it. It's naturally collaborative so you have to communicate, not very intense so there's a good amount of chill time, and in the cases where small-talk doesn't turn up interesting topics you can always talk about sailing itself.
I don’t think they mean scrapers necessarily driven by LLMs, but scrapers collecting data to train LLMs.
We had as many people come test as we could, and we found that 90% of them didn’t get a sense of depth, likely because it lacked stereo-vision cues. It only worked for folks with some form of monocular vision, incl myself, who were used to relying primarily on other cues like parallax.
However, DBSC as an API and protocol is similarly agnostic about key storage. There is no attestation and the User Agent is fully responsible for selecting key storage that provides the best protection.
That is effectively what Token Binding does. That was unfortunately difficult to deploy because the auth stack can be far removed from TLS termination, providing consistency on the client side to avoid frequent sign outs was very difficult, and (benign) client side TLS proxies are a fairly common thing.
Some more on this in the explainer: https://github.com/w3c/webappsec-dbsc#what-makes-device-boun...
The important point being made in this discussion is that this is already a common thing with OAuth, but mostly unheard of with web sessions and cookies.
In the short term it's about economics: Infostealer malware today scales really well because it can a) exfiltrate cookies quickly and clean it self up, mostly evading any client based detection, and b) sit on large stashes of long-lived cookies and carefully "cash them in" in ways that evade server side detections.
A short-lived cookie forces different behavior for b, which we think will make it more detectable server side, and binding in general will force malware to act more locally, which will make it (far) more detectable locally.
In the long term, DBSC also is designed so that the session management and key registration is somewhat decoupled from that short-term cookie business. If and when we can sign more often (perhaps every request), I believe the DBSC API will still be useful for websites to manage the session key and lifetime.
[ my public key: https://keybase.io/arnar; my proof: https://keybase.io/arnar/sigs/lf4Zbpd04PZPXu_eZyGhPVoef2BuJ0p5VUuzV8ZXD4I ]