2025 – Page 2

AI assistants misrepresent news content 45% of the time

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

New research coordinated by the European Broadcasting Union (EBU) and led by the BBC has found that AI assistants – already a daily information gateway for millions of people – routinely misrepresent news content no matter which language, territory, or AI platform is tested.

…

Key findings:

45% of all AI answers had at least one significant issue.

31% of responses showed serious sourcing problems – missing, misleading, or incorrect attributions.

20% contained major accuracy issues, including hallucinated details and outdated information.

…

BBC Media Centre, in Largest study of its kind shows AI assistants misrepresent news content 45% of the time – regardless of language or territory

In what should be as a surprise to nobody, but probably still is (and is probably already resulting in AI fanboys coming up with counterpoints and explanations): AI is not an accurate way for you to get your news.

(I mean: anybody who saw Apple Intelligence’s AI summaries of news probably knew this already, but it turns out that it gets worse.)

There are problems almost half the time and “major accuracy issues” a fifth of the time.

I guess this is the Universe’s way of proving that people getting all of their news from Facebook wasn’t actually the worst timeline to live in, after all. There’s always a worse one, it turns out.

…

Separately, the BBC has today published research into audience use and perceptions of AI assistants for News. This shows that many people trust AI assistants to be accurate – with just over a third of UK adults saying that they trust AI to produce accurate summaries, rising to almost half for people under-35.

…

BBC Media Centre, in Largest study of its kind shows AI assistants misrepresent news content 45% of the time – regardless of language or territory

Personally, I can’t imagine both caring enough about a news item to want to read it and not caring about it enough that I feed it into an algorithm that, 45% of the time, will mess it up. It’s fine to skip the news stories you don’t want to read. It’s fine to skim the ones you only care about a little. It’s even fine to just read the headline, so long as you remember that media biases are even easier to hide from noncritical eyes if you don’t even get the key points of the article.

But taking an AI summary and assuming it’s accurate seems like a really wild risk, whether before or after this research was published!

They Live (In Witney)

Feels a little They Live in the alley down the back of Witney Co-Op!

Note #27467

I reimplemented Al Sweigart‘s “Pipe Swap” scrolling-ASCII-art in plain-text-over-HTTP by exploiting the HTTP Refresh header:

https://textplain.blog/scroll-art-viewer/pipe-swap

This was a stupid idea, but it was about the level of code sophistication that my illness-brainfog can handle today.

Note #27464

Today, I can overhear the two guys who are digging a trench through my garden.

Guy 1: Does this look like a gas pipe to you?
Guy 2: Dunno. But we can’t dig round it soo…

😬

Best Viewed at: Your Resolution!

Way back in the day, websites sometimes had banners or buttons (often 88×31 pixels, for complicated historical reasons) to indicate what screen resolution would be the optimal way to view the site. Just occasionally, you still see these today.

Folks who were ahead of the curve on what we’d now call “responsive design” would sometimes proudly show off that you could use any resolution, in the same way as they’d proudly state that you could use any browser¹!

I saw a “best viewed at any size” 88×31 button recently, and it got me thinking: could we have a dynamic button that always shows the user’s current resolution as the “best” resolution. So it’s like a “best viewed at any size” button… except even more because it says “whatever resolution you’re at… that’s perfect; nice one!”

Turns out, yes²:

Anyway, I’ve made a website: best-resolution.danq.dev. If you want a “Looks best at [whatever my visitor’s screen resolution is]” button, you can get one there.

It’s a good job I’ve already done so many stupid things on the Web, or this would make me look silly.

Footnotes

¹ I was usually in the camp that felt that you ought to be able to access my site with any browser, at any resolution and colour depth, and get an acceptable and satisfactory experience. I guess I still am.

² If you’re reading this via RSS or have JavaScript disabled then you’ll probably see an “any size” button, but if you view it on the original page with JavaScript enabled then you should see your current browser inner width and height shown on the button.

It Is A War Out There – Take Control of Your Supply Lines with HtDTY

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

This post advocates minimizing dependencies in web pages that you do not directly control. It conflates dependencies during build time and dependencies in the browser. I maintain that they are essentially the same thing, that both have the same potential problems, and that the solution is the snappy new acronym HtDTY – Host the Damn Thing Yourself.

…

If your resources are large enough to cause a problem if you Host the Damn Things Yourself then consider finding ways to cut back on their size. Or follow my related advice – HtDToaSYHaBRW IMCYMbT(P)WDWYD : Host the Damn Thing on a Service You Have A Business Relationship With, It May Cost You Money But They (Probably) Won’t Dick With Your Data.

…

Andrew Stephens, in It Is A War Out There – Take Control of Your Supply Lines with HtDTY

Host the Damn Thing Yourself (HtDTY) is an excellent suggestion; I’ve been a huge fan of the philosophy for ages, but I like this acronym. (I wish it was pronounceable, but you can’t have everything.)

Andrew’s absolutely right, but I’m not even sure he’s expressed all the ways in which he’s right. Here are my reasons to HtDTY, especially for frontend resources:

Security: As Andrew observes, you can’t protect against supply chain attacks if your supply chain wide open to exploitation. And I’m glad that he points out that version pinning doesn’t protect you from this (although subsource integrity can).
Privacy: Similarly, Andrew nailed this one. If you host your fonts on Google Fonts, for example, you’re telling one of the biggest data-harvesting companies on the Internet who’s accessing your website. Don’t do that (in that specific example, google-webfonts-helper is your friend).
Resilience: Every CDN and third-party service you depend upon is another single-point-of-failure. Sure, Azure has much better uptime than your site… but it still goes down and not necessarily at the same times as your site does! And it’s not just about downtime. What if your user’s government poisons the DNS to block the CDN? What if the user’s privacy tools block your CDN’s domain (whether rightly, for the privacy reasons described above, or wrongly)? What if, y’know, you were hosting your images on Imgur but that’s not available in your users’ country? These are all real examples that happen in the real world. Why would you choose to make your site less-reliable by loading jQuery from a CDN rather than just… downloading a copy?
Performance: Andrew rightly deconstructs the outdated argument that CDN caching improves your site’s performance. Edge caching might, in some circumstances, but still has the problems listed above. But this argument can go further than Andrew’s observation that CDNs aren’t that much of a benefit… because sticking to just one domain name means (a) fewer DNS lookups, (b) fewer TLS handshakes, (c) better compression, if e.g. your JavaScript assets are bundled or at least delivered in the same pipeline, and (d) all the benefits of HTTP/2 and HTTP/3, like early hints, pipelining, etc. Nowadays, it can often be faster to not-use a CDN (depending on lots of factors), in addition to all the above benefits.

So yeah: HtDTY. I dig it.

The Scroll Art Museum

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Scroll art is a form of ASCII art where a program generates text output in a command line terminal. After the terminal window fills, it begins to scroll the text upwards and create an animated effect. These programs are simple, beautiful, and accessible as programming projects for beginners. The SAM is a online collection of several scroll art examples.

Here are some select pieces:

Zig-zag, a simple periodic pattern in a dozen lines of code.

Orbital Travels, sine waves intertwining.

Toggler, a woven triangular pattern restricted to two characters.

Proton Stream, a rapid, chaotic lightning pattern.

There are two limitations to most scroll art:

Program output is limited to text (though this could include emoji and color.)

Once printed, text cannot be erased. It can only scroll up.

But these restrictions compel creativity. The benefit of scroll art is that beginner programmers can create scroll art apps with a minimal amount of experience. Scroll art requires knowing only the programming concepts of print, looping, and random numbers. Every programming langauge has these features, so scroll art can be created in any programming language without additional steps. You don’t have to learn heavy abstract coding concepts or configure elaborate software libraries.

…

Al Sweigart, in The Scroll Art Museum

Okay, so: scroll art is ASCII art, except the magic comes from the fact that it’s very long and as your screen scrolls to show it, an animation effect becomes apparent. Does that make sense?

Here, let me hack up a basic example in… well, QBASIC, why not:

Anyway, The Scroll Art Museum has lots of them, and they’re much better than mine. I especially love the faux-parallax effect in Skulls and Hearts, created by a “background” repeating pattern being scrolled by a number of lines slightly off from its repeat frequency while a foreground pattern with a different repeat frequency flies by. Give it a look!

1% Guild

vole.wtf’s 1% guild wasn’t the easiest club to gain membership of, but somehow keeping my phone alive for long enough to snap this screenshot was even harder.

Hive’s Password Policy Makes Me Cry

Hey, let’s set up an account with Hive. After the security scares they faced in the mid-2010s, I’m sure they’ll be competent at making a password form, right?

Your password must be at least 8 characters; okay.

Just 8 characters would be a little short in this day and age, I reckon, but what do I care: I’m going to make a long and random one with my password safe anyway. Here we go:

I’ve unmasked the password field so I can show you what I tried. Obviously the password I eventually chose is unrelated to any of my screenshots.

Now my password must be at least 12 characters long, not 8 as previously indicated. That’s still not a problem.

Oh, and must contain at least one of four different character classes: uppercase, lowercase, numbers, and special characters. But wait… my proposed password already does contain all of those things!

Let’s simplify.

The password 1111AAAAaaaa!!!! is valid… but S1dfCeg7!Ex;C$Ngban9-A is not. I guess my password is too strong?

Composition rules are bullshit already. I’d already checked to make sure my surname didn’t appear in the password in case that was the problem (on a few occasions services have forbidden me from using the letter “Q” in random passwords because they think that would make them easier to guess… wot?). So there must be something else amiss. Something that the error message is misleading about…

A normal person might just have used the shit password that Hive accepted, but I decided to dig deeper.

Using the previously-accepted password again but with a semicolon in it… fails. So clearly the problem is that some special characters are forbidden. But we’re not being told which ones, or that that’s the problem. Which is exceptionally sucky user experience, Hive.

At this point it’s worth stressing that there’s absolutely no valid reason to limit what characters are used in a password. Sometimes well-meaning but ill-informed developers will ban characters like <, >, ' and " out of a misplaced notion that this is a good way to protect against XSS and injection attacks (it isn’t; I’ve written about this before…), but banning ; seems especially obtuse (and inadequately explaining that in an error message is just painfully sloppy). These passwords are going to be hashed anyway (right… right!?) so there’s really no reason to block any character, but anyway…

I wondered what special characters are forbidden, and ran a quick experiment. It turns out… it’s a lot:

Characters Hive forbids use of in passwords include - , . + = " £ ^ # ' ( ) { } * | < > : ` – also space
“Special” characters Hive they allow: ! @ $ % & ?

What the fuck, Hive. If you require that users add a “special” character to their password but there are only six special characters you’ll accept (and they don’t even include the most common punctuation characters), then perhaps you should list them when asking people to choose a password!

Or, better yet, stop enforcing arbitrary and pointless restrictions on passwords. It’s not 1999 any more.

I eventually found a password that would be accepted. Again, it’s not the one shown above, but it’s more than a little annoying that this approach – taking the diversity of punctuation added by my password safe’s generator and swapping them all for exclamation marks – would have been enough to get past Hive’s misleading error message.

Having eventually found a password that worked and submitted it…

…it turns out I’d taken too long to do so, so I got treated to a different misleading error message. Clearly the problem was that the CSRF token had expired, but instead they told me that the activation URL was invalid.

If I, a software engineer with a quarter of a century of experience and who understands what’s going wrong, struggle with setting a password on your site… I can’t begin to image the kinds of tech support calls that you must be fielding.

Do better, Hive.

Note #27434

Somebody just called me and quickly decided it was a wrong number. The signal was bad and I wasn’t sure I’d heard them right, so I followed up by replying by text.

It turns out they asked Siri to call Three (the mobile network). Siri then presumably searched online, found Three Rings, managed to connect that to my mobile number, and called me.

If Siri’s decided that I represent Three, this could work out even worse than that time Google shared my phone number.

Dogspinner

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Lu Wilson and Flora Caulton, in Dogspinner

Dogspinner is the Monday morning distraction you didn’t know you needed. Get that dog up to full speed! (It’s worth it for the sound effects alone.)

I had some difficulty using it on desktop because I use the Forbidden Resolutions. But it probably works fine for most people and is probably especially great on mobile.

I’d love to write a longer review to praise the art style and the concept, but there’s not much to say. Just… go and give it a shot; it’ll improve your day, I’m sure.

Lowriders & websites

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

…

I think of ElonStan420 standing in that exhibit hall, eyeing those cars with disdain because all that time, energy, care, and expression “doesn’t really matter”. Those hand-painted pinstripes don’t make the car faster or cheaper. Chrome-plated everything doesn’t make it more efficient. No one is going to look under the hood anyway.

…

Adam Stoddard, in Lowriders & websites

Don’t read the comments on HackerNews, Adam! (I say this, but I’ve yet to learn not to do so myself, when occasionally my writing escapes from my site and finds its way over there.)

But anyway, this is a fantastic piece about functionalism. Does it matter whether your website has redundant classes defined in the HTML? It renders the same anyway, and odds are good that nobody will ever notice! I’m with Adam: yes, of course it can matter. It doesn’t have to, but coding is both a science and an art, and art matters.

…

Should every website be the subject of maximal craft? No, of course not. But in a industry rife with KPI-obsessed, cookie-cutter, vibe-coded, careless slop, we could use more lowriders.

Well said, Adam.

Hot Boxes

I’d never put much thought into it before but a slow cooker is basically the opposite of an air frier.

They’re both relatively small (compared to an oven) hot boxes for cooking food. But an air frier uses the small space to contain as much energy as possible in thir vicinity of the food, while the slow cooker aims to maintain as low a temperature as possible until the food finally cooks itself out of boredom.

Anyway, this is going to be pulled pork in like 8-10 hours. 😋

Do Contact Forms Attract More Spam than Email Addresses?

There’s a question being floated around my corner of the blogosphere, but I think my experience of the answer differs from other bloggers:

It started when David Bushell observed that, despite having his email address unobscured on his website, he gets more spam via his contact form. Luke Harris followed-up, providing a potential explanation which basically boils down to the idea that it’s both more cost-effective and provides better return-on-investment to spam contact forms than email addresses. And then Kev Quirk described his experience of switching from contact forms to “bare” email addresses and the protections he put in place (like plus-addressing), only to discover that he didn’t need it at all.

Disappearing Contact Forms

It makes me sad to see the gradual disappearance of the contact form from personal websites. They generally feel more convenient than email addresses, although this is perhaps part of the reason that they come under attack from spammers in the first place! But also, they provide the potential for a new and different medium: the comments area (and its outdated-but-beautiful cousin the guestbook).

Comments are, of course, an even more-obvious target for spammers because they can result in immediate feedback and additional readers for your message. Plus – if they’re allowed to contain hyperlinks – a way of leeching some of the reputability off a legitimate site and redirecting it to the spammers’, in the eyes of search engines. Boo!

But I’ve got to admit: there have been many times that I’ve read an interesting article and not interacted with it simply because the bar to interaction (what… I have to open my email client!?) was too high. I’d prefer to write a response on my blog and hope that webmention/pingback/trackback do their thing, but will they? I don’t know in advance, unless the other party says so openly or I take a dive into their source code to check.

Your Experience May Vary

I’ve had both contact/comment forms and exposed email addresses on my website for many years… and I feel like I get aproximately the same amount of spam on both, after filtering. The vast majority of it gets “caught”. Here’s what works for me:

My contact/comments forms use one of a variety of unobtrustive “honeypot”-style traps. These “reverse CAPTCHAs” attempt to trick bots into interacting with them in some particular way while not inconveniencing humans.

Antispam Bee provides the first line of defence, but I’ve got a few tweaks of my own to help counteract the efforts of determined spammers.
Once you’ve fallen into a honeypot it becomes much easier to block subsequent contacts with the same/similar content, address, (short-term) IP, or the poisoned cookie you’re given.
Keyword filtering provides a further line of defence. E.g. for contact forms that post directly back to the Web (i.e. comment forms, and perhaps a future guestbook form), content with links goes into a moderation queue unless it shares a sender email with a previously-approved sender. For contact forms that result in an email, I’ve just got a few “scorer” rules relating to geo IP, keywords, number and density of links, etc. that catch the most-insidious of spam to somehow slip through.

I also publish email addresses all over the place, but they’re content-specific. Like Kev, I anticipated spam and so use unique email addresses on different pieces of content: if you want to reply-by-email to this post, for example, you’re encouraged to use the address b27404@danq.me. But this approach has actually provided secondary benefits that are more-valuable:

The “scrapers” that spam me by email would routinely send email to multiple different @danq.me addresses at the same time. Humans don’t send the same identical message to me to different addresses published on my site and from different senders, so my spam filter picks up on this rightaway.
As a fringe benefit, this helps me determine the topic on an email where it’s unclear. E.g. I’ve had humans email me to say “I tried to follow the guide on your page but it didn’t work for me” and I wouldn’t have had a clue which page had they not reached out via a page-specific email alias.
I enjoy the potential offered by rotating the email address generation mechanism and later treating all previously-exposed addresses as email honeypots.

Works For Me!

This strategy works for me: I get virtually no comment/contact form spam (though I do occasionally get a false positive and a human gets blocked as-if they were a robot), and very little email spam (after my regular email filters have done their job, although again I sometimes get false positives, often where humans choose their subject lines poorly).

It might sound like my approach is complicated, but it’s really not. Adding a contact form honeypot is not significantly more-difficult than exposing automatically-rotating email aliases, and for me it’s worth it: I love the convenience and ease-of-use of a good contact/comments form, and want to make that available to my visitors too!

(I also allow one-click reactions with emoji: did you see? Scroll down and send me a bumblebee! Nobody seems to have found a way to spam me with these, yet: it’s not a very expressive medium, I guess!)

Note #27400

Did I just rank my LPG provider 10/10, or 1/10? I genuinely don’t know.