• 0 Posts
  • 10 Comments
Joined 3 days ago
cake
Cake day: September 14th, 2025

help-circle
  • After all, enterprise clients soon realized that the output of most AI systems was too unreliable and too frequently incorrect to be counted on for jobs that demand accuracy. But creative work was another story.

    I think that the current crop of systems is often good enough for a header illustration in a journal or something, but there are also a lot of things that it just can’t reasonably do well. Maintaining character cohesion across multiple images, for example, and different perspectives — try doing a graphic novel with diffusion models trained on 2D images, and it just doesn’t work. The whole system would need to have a 3D model of the world, be able to do computer vision to get from 2D images to 3D, and have a knowledge of 3D stuff rather than 2D stuff. That’s something that humans, with a much deeper understanding of the world, find far easier.

    Diffusion models have their own strong points where they’re a lot better than humans, like easily mimicking a artist’s style. I expect that as people bang away on things, it’ll become increasingly-visible what the low-hanging fruit is, and what is far harder.


  • At least some of this is due to the fact that we have really appallingly-bad authentication methods in a lot of places.

    • The guy was called via phone. Phones display Caller ID information. This cannot be trusted; there are ways to spoof it, like via VoIP systems. I suspect that the typical person out there — understandably — does not expect this to be the case.

    • The fallback, at least for people who you personally know, has been to see whether you recognize someone’s voice. But we’ve got substantially-improving voice cloning these days, and now that’s getting used. And now we’ve got video cloning to worry about too.

    • The guy got a spoofed email. Email was not designed to be trusted. I’m not sure how many people random people out there are aware of that. He probably was — he was complaining that Google didn’t avoid spoofing of internal email addresses, which might be a good idea, but certainly is not something that I would simply expect and rest everything else on. You can use X.509-based authentication (but that’s not normally deployed outside organizations) or PGP (which is not used much). I don’t believe that any of the institutions that communicate with me do so.

    • Using something like Google’s SSO stuff to authenticate to everything might be one way to help avoid having people use the same password all over, but has its own problems, as this illustrates.

    • Ditto for browser-based keychains. Kind of a target when someone does break into a computer.

    • Credentials stored on personal computers — GPG keys, SSH keys, email account passwords used by email clients, etc — are also kind of obvious targets.

    • Phone numbers are often used as a fallback way to validate someone’s identity. But there are attacks against that.

    • Email accounts are often used as an “ultimate back door” to everything, for password resets. But often, these aren’t all that well-secured.

    The fact that there isn’t a single “do this and everything is fine” simple best practice that can be handed out to Average Joe today is kind of disappointing.

    There isn’t even any kind of broad agreement on how to do 2FA. Service 1 maybe uses email. Service 2 only uses SMSes. Service 3 can use SMSes or voice. Service 4 requires their Android app to be run on a phone. Service 5 uses RFC 6238 time-based one-time-passwords. Service 6 — e.g. Steam — has their own roll-their-own one-time-password system. Service 7 supports YubiKeys.

    We should be better than this.






  • LLMs have non-deterministic outputs, meaning you can’t exactly predict what they’ll say.

    I mean…they can have non-deterministic outputs. There’s no requirement for that to be the case.

    It might be desirable in some situations; randomness can be a tactic to help provide variety in a conversation. But it might be very undesirable in others: no matter how many times I ask “What is 1+1?”, I usually want the same answer.


  • I would guess that it’s probably not viable. Like, the problem isn’t that a tool isn’t processing the webpage correctly, but rather that the website isn’t actually giving access to the video at all unless you sign in.

    In general, if you can view a video but just not download it, Firefox (using the desktop UI) will let you the URL of the video. You click on the lock icon by the URL bar -> Connection Secure -> More information -> Media. This also lets you download images and so forth that have ad-hoc website-level “DRM” and try to make it difficult to download images. cough Pinterest.

    Someone could create a service that logs in and then proxies the request, but I imagine that Threads would kill the account they’re using — I expect that they want to disallow video streams to not-logged-in users, or they wouldn’t have done what they did.

    One thing that could maybe be done technically is for some service to do a fuzzy hash of each frame of videos — kind of like TinEye does for static images — and then given a static frame like this, lists all the videos that it has indexed that contain something that looks like that frame. Assuming that some service hasn’t already started providing something along those lines. But that’d probably require more processing power, bandwidth, and storage than someone like TinEye is using, as I bet that there is more data going up to the Internet in the form of video frames than of static images.

    EDIT: I do see other videos further down in the thread playing. So not-logged-in viewers can see some video content, just not that. Hmm.

    That video has to be treated differently than the later videos — maybe it won’t play without in-browser DRM support or the like? Or maybe it’s above a certain size?

    EDIT2: I don’t think that it’s in-browser DRM. I just checked, and WideVine works in Firefox on this test page. And your URL doesn’t work in Firefox (or Chromium) on this system.

    Maybe it could be some sort of new codec? I can’t imagine that they wouldn’t have a fallback, though.

    EDIT3: This service can provide an mp4 link. Not sure if they’re proxying it or just digging through the guts more than yt-dlp does:

    https://threadster.app/download

    EDIT4: It looks like the actual mp4 link I get is from a “threadster”-specific CDN account, so my guess is that they may well be proxying it, else I’d think that they’d just be linking to the video on Threads directly.

    EDIT5: The downloaded .mp4 — which may or may not be identical to the original video stream — has a size of 6216038 bytes, so if Threads is restricting it based on size, it’s a pretty low restriction.

    One other thing occurred to me. A number of services block “adult” content for some definition of “adult”. This (a) conforms to laws in various jurisdictions about blocking children from seeing content, and (b) creates a hook to get people to create an account. YouTube, for example. It could be that Threads has flagged this as “not for children”, so it requires an “adult” account to see the thing. I could very readily see some white supremacy group marching as qualifying as “adult” for one of those definitions.

    EDIT6: It may be that Threads generates a unique video for each request, does a digital watermark or something, to try to track down what account entities like Threadster are using to pull videos from. Or it could be that Threadster is modifying the video. But I ran the video from from Threadster through rhash to generate a magnet URL, so if (a) neither service is modifying the video to make it distinct and (b) anyone has uploaded the file to a BitTorrent node with DHT enabled, then I imagine that this should get you to it; I generated a magnet URL for the file with all supported hashes.

    magnet URL
    $ rhash --magnet -a threadster_0ovs0ywp.mp4 
    magnet:?xl=6216038&dn=threadster_0ovs0ywp.mp4&xt=urn:crc32:ce0986c6&xt=urn:md4:7f1b446dafac136ef41d7c8211a153b2&xt=urn:md5:af199305ebd27c6ff34e890d36374d37&xt=urn:sha1:qjyppsc27vuazq6zgyr4vflkumpour64&xt=urn:tiger:bff86af09fa62a93c35a67902ffbca9bdab5cf52f4d41baf&xt=urn:tree:tiger:vrk7ux5qrfzip24d7su4fjavdbj5iadh5i4le5q&xt=urn:btih:7d08a14e90712580809379ddf43778e1440c8ee1&xt=urn:ed2k:7f1b446dafac136ef41d7c8211a153b2&xt=urn:aich:qikeur6cwalyy4qokt62raheyvg7a7nc&xt=urn:whirlpool:4d6ae4d5ba366c6a0ed783efdff5371b7e969e03905952abcec3a8f398af4f5d5bdb81e9eb3c1c522ab336dab155dd89729c533ddbe8c0d00e7ad1b7e411331b&xt=urn:ripemd160:6067eae597a4a5a0c077b8b934bd0609dcffbdb1&xt=urn:gost94:83e5f32ca72e8d7e78868fe7c40cf1488483a49feaad06565ce272976dca68c6&xt=urn:gost94-cryptopro:bad114d3021ac70074f4cf315d78825b40141faa6502dd25f90ae6097b4fb38a&xt=urn:has160:7b0d2f95b6bf9a2beb091ddb66fa58486a8e15ec&xt=urn:gost12-256:ef405a539e4c565119537fc927e8a437c570085161fba529395bee2470be1147&xt=urn:gost12-512:237d11bc5a7f3205988675d24ae59eae6fe9b5604ca9fefdce0007b2f1f3a322ee36b6a2268e0fd8a63a4b7eee631cec159125a34bad7640febca983e148616b&xt=urn:sha224:f2c43a2d1fcff46517805cae7b2704ffc307249e779f208156d78e38&xt=urn:sha256:10aa072e2a340490550b75a3b31cc7bc2477675a86545efe10485255aae52dc4&xt=urn:sha384:5baf49ca38a7520d83e32cd34ceff2307a9ab58a968b289f4af60c3ca4652f536cd37308c4399058172923766cab7d18&xt=urn:sha512:29a41cec78761ade9d4da49c16c2b24f62a437bd4eef97948a3ae8fdb4498f64783e66000b5d53ac46dc90ffe22d4dc0a43d3d108798663a97c46138efc72b5f&xt=urn:edon-r256:05b271edb1ee478361d2b8cf2c7e2b30a98e96dc07d05c9afff5f04313ea497c&xt=urn:edon-r512:8697ed76da42f16abe913bcc3c4b73b8511dbf6117db35e9373401d03e56853a4297eaa46a9aec1c32e050ca11b1c4da33869a06f758234dfd8a6178da2cacba&xt=urn:sha3-224:0ffb43bb4c352cc2b5ee8d1386ec8949eed32403130bf8bab71d3f02&xt=urn:sha3-256:835b2f4ffad2efad5fd67b84508dbc41b4d1f977aee2a76fcc47245681b68dc3&xt=urn:sha3-384:81cb38988764b1941f4d50cacbfa0e98989128319508940558c1665f3edddb79d475495cd9962b76b2409f35066fa8d6&xt=urn:sha3-512:d50d706b9cbdab52d1564f0f89013194c60e9d158ce6bf714f35742949bfa7cfc3f3716fd8f1577c3a4755b42a30091b113aa20d15608fccffde46c62494faa6&xt=urn:crc32c:86313da6&xt=urn:snefru128:5e2348a151afe2cd50cf46c36a265c05&xt=urn:snefru256:401be5eb26ad7ba6f75dbfab9d8b66692bca8f3090eb69b75657824d8cde09e5&xt=urn:blake2s:aaf9ad51bb34f13b934decdec05989012fb2d34641d4de901bda3cd217b2e64f&xt=urn:blake2b:92cec72f95822075735249de8bb4014386ba7a71c22428fd44e7a071ed372034c2b76bdefe45824d2ab7ba8d1fbaa726d5210aa10cec7510308528495cd2386d  
    $  
    


  • I have not done so in the traditional sense in quite some years. My experience was that it was an increasing headache due to crashing into a wide variety of anti-spam efforts. Get email past one and crash into another.

    Depending upon your use case – using the “forward to a smarthost” feature in some mail server packages to forward to a mailserver run by a SMTP service provider with whom you have an account might work for you. Then it still looks to local software like you have a local mailserver.

    If I were going to do a conventional, no-smarthost mailserver today, I think that I would probably start out by setting up a bunch of spam-filtering stuff — SpamAssassin, I dunno what-all gets used these days on a “regular” account — and then emailing stuff from my server and seeing what throws up red flags. That’d let me actually see the scoring and stuff that’s killing email. Once I had it as clean as I could get it, I’d get a variety of people I know on different mail servers and ask them to respond back to a test email, and see what made it out.