Tag: website

Posted on
by

I host most of my websites on a DreamHost VPS*. This morning I discovered that a new file had been added, agents.txt, to the root of each site, on May 7.

It was easy to confirm that this is a new default file similar to the default robots.txt and favicon.ico DreamHost puts in every new site to get you started. Apparently they retroactively added it to sites that don’t already have one. So it’s a host action, not a hack. That’s good at least.

The contents are simple, and sensible for a new website: Discourage LLM training and actions, allow on-the-fly “AI”-generated summaries, disallow access to some common folders that shouldn’t be used for any of the above.

Though I am annoyed that they added it retroactively, particularly since it includes what looks like an explicit opt-in to retrieval-augmented generation, even if it’s something that’s happening already and less of a problem than a model vacuuming up your entire website for regurgitation. (Guess who’s already in Common Crawl!)

# Data use policy
Allow-Training: no
Allow-RAG: yes
Allow-Actions: no

# Default rules for all agents
[Agent: *]
Allow: /
Disallow: /admin/
Disallow: /config/
Disallow: /tmp/
Disallow: /logs/
Disallow: /backup/
Disallow: /.env
Disallow: /wp-admin/
Disallow: /wp-includes/

Harder to find was what else goes in this file. The first agents.txt spec I found used a completely different syntax and a completely different purpose. I had to search for the policy directives (in quotation marks) to find the proposal it’s implementing, which turns out to have been renamed as agent-manifest.txt shortly after it was proposed in March. Apparently whoever DreamHost didn’t get the memo before it rolled out. Update: As Patryk points out below, it’s changed again to agents-brief.txt, just one day after the blog post was updated with the second name. .

Good: sensible defaults for new sites.
Bad: rolled out to existing sites without notice, half-baked implementation.

*Update: To clarify, this is on DreamHost’s managed VPS service, where they handle the OS and the webserver, but you have a flexible userspace all to yourself. It’s a middle ground between shared hosting (where other sites are on the same virtual machine and webserver) and fully run-your-own-OS cloud hosting, and the balance generally works for me (YMMV).

Posted on
by

Posting an Opera button on your website or blog is a great way to encourage people to try out the browser — but what if the visitor already uses Opera? It shows solidarity, but what if you could show them something else, something that is new to them?

You might want to replace your regular Opera banner with an ad for Opera Mini. Or show them another graphic of your own design. Or maybe not even a graphic, maybe post some sort of message, like “Opera spoken here!” or “Welcome, Opera visitors!”

It’s relatively simple to do this in PHP, or ASP, or some other server-side script…but sometimes you have to stick with static HTML. Well, client-side JavaScript can replace chunks of your page, and here’s how to do it.

1. Put the following script in a file called operalinks.js:

function replaceOperaLink(linkID) {

if(linkNode=document.getElementById(linkID)) {

if ( 0 <= navigator.userAgent.indexOf('Opera') ) {

var newButton=document.createElement('span');

newButton.innerHTML = '<a href="http://www.opera.com/">Glad to see you're using Opera!</a>';

var parentNode=linkNode.parentNode;

parentNode.replaceChild(newButton,linkNode);

}

}

}

For the innerHTML section, you can plug in a new link and banner, or a special message, or anything you want. (Just make sure that you put a backslash () in front of any apostrophes you use.)

2. Put a unique ID in the tag for your regular Opera button. Use the outermost tag that you want to replace. For example, let’s start it off with this:

<a id="OpLink" href="http://www.opera.com">Download Opera!</a>

3. Load the script in your document’s <head> section:

<script type="text/javascript" src="operalinks.js">

4. Call the function in the body onload event using the ID you chose in step 2:

<body onload="replaceOperaLink('OpLink')">

When the page loads, the script will check the visitor’s browser. If it’s Opera, it’ll replace the banner with whatever message you chose in step 1. It’s compatible with both HTML and XHTML, and you don’t need to worry about using <noscript> tags to make sure the banner still shows up for people with JavaScript disabled.

*This post originally appeared on Confessions of a Web Developer, my blog at the My Opera community.

ยปAll pages site-wide with this tag