The Foursquare Blog

Sometimes when watching this headlong race to AI, you might wonder why? Why spend so many millions, billions, (trillions?) of dollars on building data centers? Why risk the entire economy, and why go into so much debt?

These folks obviously think different. But it occurs to me that there is one perspective that most people are not seeing.

Cloud AI companies are gaining real intelligence from you by trading artificial intelligence back in return.

The cloud computers take your ideas, your questions, your real life problems, feed them into models, and return partially baked code, probabilistic answers, and hallucinated lies in return. Sure, a lot of it is useful, but it is artificial, and occasionally harmful.

Oh, you don't think they are storing everything you type into those boxes forever and ever? I strongly suspect they are. This is the gold they are mining, and spending so much to obtain. All the world's private thoughts and desires and plans and hopes and dreams are flooding into their data centers at record pace. For later analysis.

Take the story of Josh which you can watch on Youtube here: https://www.youtube.com/watch?v=w2fv664Ndf4. It's the story of a man who used AI to write a report he should have written, and then gets caught in court, where reportedly 350 pages of his entire ChatGPT history is read into the record.

Now, it doesn't explicitly say where this came from. Did they just open his personal account and copy everything out? Did they send a subpoena to the AI company for the details? Not sure. But anyone who knows how these things work would be shocked (shocked!) to learn that AI companies around the world are just throwing the baby out with the bathwater.

It is best to go into the agreement of using AI with your eyes wide open, and just assume that everything you type into the prompt is stored somewhere forever.

For example, ChatGPT's privacy policy states that they will retain your personal data until you delete it, in which case they will either delete it within 30 days, or de-identify and disassociate the data from you and use it to improve their models.

By that point, it doesn't matter if the prompt you use can be traced back to you. The gold is the prompt, the idea, the human intelligence or human experience behind it, which allows them to improve their mimicry of humanity and eliminate dependence on it.

Solution: run your own models locally so you own all your own data. How? I hope to blog more on this topic in the future as my friend and I have been recently working on Project Jarvis.

I've been working on getting some automated backups running for a server with significantly more data than I usually manage for my own personal purposes. This obviously means cloud storage for offsite backups, and smart attempts at minimizing the size and long term costs.

Step one is to figure out how to connect! Unfortunately OVH does not make it quite as easy as you expect. There are many pages of documentation, but there are some pitfalls along the way.

Pitfall #1

If you are using S3 compatible storage, make sure you don't accidentally use the user-level permissions. User-level passwords are alpha-numeric using the full range of lowercase and uppercase letters. They are generated in the Project Management | Users & Roles section, in the user's right side menu. This is the wrong secret.

S3 secrets are more like a SHA1 sum, alphanumeric with lowercase letters from a to f. You can obtain the S3 secret by opening the Object Storage area of the public cloud dashboard, click on the Users tab (important!), find the correct S3-compatible user. The access key is shown directly in the list, while the secret is hidden behind the side menu "View Secret Key" option.

The access keys appear to change in the dashboard from time to time as well, yet once you have a pair working, they continue to work even if the UI shows differently.

Pitfall #2

I'm also attempting to fine tune permissions, so in that direction I assumed I would need the "awscli" software package to fully access it. Fortunately, this is package on Debian already, so a quick "apt-get install awscli" was enough to get it installed along with all its dependencies.

Unfortunaely, I was using Debian Bookworm, with awscli version 2.9.19-1. This version has bugs somewhere between the config and the actual endpoint URL that gets used. I wanted to use s3.bhs.io.cloud.ovh.net as the region+domain, but the software insisted on using *.bhs.amazonaws.com.

I thought I was doing something wrong, but discovered it was just bugs when I tried from a Debian Trixie machine running awscli version 2.23.6-1.

In the end, I was able to successfully connect to OVH's S3 compatible object storage with these files:

My .aws/config file:

[profile ovh-bhs]
region = bhs
endpoint_url = https://s3.bhs.io.cloud.ovh.net/
services = ovh-bhs-services

[services ovh-bhs-services]
s3 =
  endpoint_url = https://s3.bhs.io.cloud.ovh.net/
  signature_version = s3v4

s3api =
  endpoint_url = https://s3.bhs.io.cloud.ovh.net/

My .aws/credentials file:

[ovh-bhs]
aws_access_key_id = sha1-access-key
aws_secret_access_key = sha1-secret-key

Allows the following command to work:

aws s3api list-buckets --profile ovh-bhs