Privacy Policy

The short version

Sub40 is a sublease noticeboard for UT Austin students, run by two people in the United States. Here is the whole policy in six lines, each of which is expanded on below.

• We collect what you type in — your UT email, your profile, your listings, and your messages — and not much else.
• There is no analytics, no advertising, and no third-party tracker anywhere on the site. Nobody is buying your data because we are not selling it.
• Your exact street address is not public. Signed-out visitors see a deliberately fuzzed pin and a building name.
• Your messages are readable only by you and the person you are talking to.
• Photos are the exception, and it is an important one: anything you upload sits in public storage, so anyone with the direct link can open it. Read section 6.
• You can see, correct, or delete your data. Ask us through the contact form.

1. Who this policy is from

Sub40 is a student-to-student sublease marketplace built for UT Austin, and only for UT Austin. It is a two-person project, not a company with a privacy department, and it has not launched yet.

A finished policy has to name the entity that is legally responsible for your data, and give you somewhere to write to. Neither is settled. [1] TO CONFIRM: what legal entity operates Sub40 — an individual, a general partnership, an LLC? If an entity exists or will be formed, its exact registered name and home state. [2] TO CONFIRM: the mailing address and the email address where Sub40 accepts formal legal notice. This is usually required, and it is a real-world address, so decide deliberately.

Sub40 is operated from the United States and its data is stored in the United States. It is built for students at one campus in Texas, and it is not aimed at people outside the US. If you use it from somewhere else, your information is handled here, under US law.

2. What we collect, and why

Almost everything here is something you typed. We do not buy data about you, and we do not build a profile of you from anywhere other than what you enter and what you do on the site.

Your account

• Your UT email address. It is required, and it is the whole basis of the "verified student" idea: signup is checked on the server against a list of UT domains — utexas.edu, my.utexas.edu, and eid.utexas.edu — and an account with an address outside that list does not get created.
• A password, or nothing at all if you sign in with a link emailed to you. We never see your password in readable form; our authentication provider stores a hash of it, not the password itself.
• Your name, and optionally a bio, a phone number, a graduation year, and a profile photo. Only the email is required. Everything else is there so another student can tell who they are talking to, and you can leave it blank.
• Three notification preferences, which is simply a record of which emails you asked us to send.
• Which school your account belongs to — currently there is only one.

Your listings

• The title, price, unit type, lease start and end dates, description, amenities, and photos you enter.
• The street address you enter, plus the latitude and longitude derived from it, plus a normalised version of the address and, where we have it, the building name. Section 5 explains exactly which parts of this a stranger can see, because the answer is not all of them.
• The listing’s status — whether it is awaiting review, live, rejected, or leased — and, if it was rejected, the reason.

What you do on the site

• Listings you bookmark, and any note you attach to a bookmark.
• Messages you send, including the text, who they were between, which listing they are about, and when they were read. Messages are capped at 4,000 characters.
• Reports you file about a listing: the reason, any detail you write, and the outcome once we have looked at it.
• A small amount of bookkeeping about whether a notification email has already been sent to you, so we do not send it twice.

When you write to us

• What you type into the contact form: your name, an email address, which subject you picked, and the message itself, which is capped at 4,000 characters. The form works signed out and does not require a UT address, so the email you give may be the only way we have of answering you.
• A link to your account, if you happened to be signed in when you sent it, so we can see who wrote in without having to ask.
• A salted hash of the IP address the message came from. We store the hash and never the address itself, and it is used for exactly one thing: rate-limiting the form so that one person cannot flood it. It is not shown to whoever reads your message.

Technical information

Our hosting and database providers keep server logs in the ordinary course of running a website, which typically include IP addresses and browser information. We do not use those logs to build a profile of you, and we do not add any tracking of our own on top of them. The exact retention of those provider logs is set by the providers, not by us.

3. What we do with it

• Run the service: show listings, run search, deliver your messages, keep you signed in.
• Keep the UT-only gate honest, which is the entire point of collecting a school email.
• Review listings before they go live, and act on reports — which sometimes means reading a specific listing or a specific conversation.
• Send you the emails you asked for: message notifications, and the authentication emails you need to sign in at all.
• Read and answer what you send through the contact form, including access and deletion requests.
• Fix things when they break, and keep the site secure.

We do not sell your personal information, and we do not share it for advertising. There is no advertising on Sub40.

We do not use your messages or your listings to train machine-learning models.

4. The emails we send

Two kinds. Authentication emails — confirming your address, sign-in links, password resets — which you cannot turn off, because without them you cannot get into your account. And notification emails when someone messages you, which you can turn off in your settings.

Notification emails are written to give away as little as possible, on purpose. They contain no message text at all — not even a preview — and they use the sender’s first name only, never a full name, and never the listing’s address. Email gets forwarded, synced to phones, and sits in inboxes for years, so a conversation about where a student lives does not get copied out of the app into it. The message body is not even loaded from the database when the email is built.

5. What other people can see

This is the section worth reading properly. Listing pages are public and are indexed by search engines, which is how students find a sublease at all — but what a stranger sees is deliberately narrower than what a signed-in student sees.

A signed-out visitor, or a search engine, sees

• The listing itself: title, price, unit type, lease dates, description, amenities, and photos.
• The building name and the city — not the street address.
• A map pin that is deliberately wrong. The published coordinate is offset from the real one by up to about 200 metres, so the pin shows the neighbourhood without showing the door.
• That the host is a verified UT student. Not their name, not their email, not their photo, not their year.

The last point is enforced in the database rather than in the interface: a signed-out visitor has no read access to the profiles table at all, so a request for the host’s name is refused rather than quietly answered. The same is true of the exact address — the precise coordinates and the street address are simply not among the columns an anonymous visitor is allowed to read.

A signed-in UT student additionally sees

• The exact street address and the true map location.
• The host’s name, and whatever else they chose to put on their profile — bio, graduation year, phone number, photo.

So: anything you put on your profile is visible to any signed-in UT student who opens one of your listings. If you would rather not share your phone number with everyone who clicks, leave the field empty.

Nobody else sees

• Your messages. Only the two people in a conversation can read them.
• Your bookmarks. Only you.
• That you reported a listing. The report is not shown to the listing’s owner and they are not told who filed it — on one campus, a reporting system that exposes the reporter is a reporting system nobody uses.

One honest limitation on all of the above: this is our own data sitting in our own database, so we can technically reach it, and we may read a specific conversation to investigate a report or because the law requires it. We do not read messages routinely.

6. Photos are public — please read this one

The rest of the site restricts things carefully, so it would be easy to assume photos are restricted too. They are not, and telling you that plainly is more useful than a policy that implies otherwise. Practically:

• Do not upload a photo showing something you would not want a stranger to see — mail with your name on it, a visible unit number, documents, other people who did not agree to be photographed.
• A photo link keeps working while the file exists, even after the listing comes down. Deleting the listing does not by itself guarantee the file is gone.
• If you have already uploaded something you regret, ask us and we will delete the underlying file, not just the listing.

This is a known trade-off rather than an oversight — public files are what makes photos load quickly on a listing page a search engine can see — but it is a trade-off students should get to make knowingly. [3] TO CONFIRM: do you want to keep photos in public storage, or move to signed links that expire? Signed links are meaningfully more private and meaningfully more work, and the answer changes what this section has to say.

7. The companies that help us run this

Sub40 does not run its own servers. The list below is every outside service that touches your data, what it gets, and why. It is exhaustive as of the date at the top of this page.

Supabase — authentication, database, and file storage

Effectively everything: your account, your profile, your listings, your bookmarks, your messages, your reports, and your uploaded photos are stored with Supabase. If you want a single answer to "where does my data live", this is it.

Vercel — hosting

Serves the site. Requests to Sub40 pass through Vercel, which keeps the ordinary server logs any web host keeps.

Resend — email delivery

Sends the authentication emails, the message notifications, and the alert to our support inbox when someone writes in through the contact form, so it necessarily receives your email address and the contents of those emails. As section 4 says, the notification contents are deliberately thin. A contact message is not — what you type into that form is what we need to read in order to answer it.

OpenStreetMap Nominatim — turning an address into a map point

This one deserves to be spelled out. When you create a listing, the street address you type is sent to Nominatim, a service run by the OpenStreetMap Foundation, to convert it into coordinates and a tidied-up address label. That means the exact address leaves our systems at the moment you post, even though it is never published to signed-out visitors afterwards.

The same service is used when you type a destination into the commute tool on a listing page — for example your workplace or your lab — so that address is sent to Nominatim too.

OSRM and OpenFreeMap — routing and map tiles

The commute times and the route line on a listing page are calculated by OSRM at router.project-osrm.org, which receives the listing’s coordinates and your destination’s coordinates. The map imagery itself comes from OpenFreeMap, which receives the coordinates of the area you are looking at, in the normal way any online map works.

Stripe — not in use

Payments are not live on Sub40. No card details are collected anywhere on the site today and no payment processor holds anything about you. If paid listing promotion launches, this policy will be updated before it does.

Each of these companies has its own privacy policy governing what it does with what it receives. We chose them, so this list is our responsibility, and it changes only when the code does.

8. How long we keep things

The honest answer today is that no retention schedule has been set, and inventing one here would be worse than admitting it. What is true is that data you delete yourself — a listing, a bookmark, your account — is deleted from the live database, and that deleting an account cascades: the profile, its listings, its bookmarks, and its messages go with it.

Backups are the caveat that applies to any database. A copy of deleted data can persist in routine backups for a period after deletion, and that period is set by our database provider’s backup configuration rather than by us.

The specifics need deciding before launch, and they are separate decisions rather than one. [4] TO CONFIRM: how long is an account kept once it is inactive, and is it ever deleted automatically? [5] TO CONFIRM: how long are expired or leased listings kept after their lease end date? [6] TO CONFIRM: how long are messages kept — indefinitely, or deleted some period after a conversation goes quiet? [7] TO CONFIRM: how long are listing reports and their outcomes kept after they are resolved? These are records about another student, so keeping them forever is a choice worth making on purpose. [8] TO CONFIRM: what is the backup retention window at the database provider, so this page can state a real number for how long deleted data can survive in backups?

9. Your data, and how to get at it

Some of this you can do yourself, right now, without asking anyone.

• Correct your profile, or empty out any field you would rather not share, in your account settings.
• Edit or delete any listing you posted, from My Listings.
• Turn notification emails off in settings.
• Delete your bookmarks.

For the rest — a copy of everything we hold about you, deletion of your account and its contents, deletion of a photo file from public storage, or a question about how any of this works — ask us and we will do it. There is no bureaucracy to get through and nothing unreasonable to prove; we will just want to be confident you are the person whose account it is, which normally means the request coming from the UT email on the account.

The route is the contact form at /contact. Pick "Privacy or data request" from the subject list — that option exists so a deletion request arrives recognisable as a request with a clock on it, rather than sitting in the same pile as a suggestion about the search filters. What you send is recorded before any email is attempted, so your request does not depend on our outbound mail working, and it lands in a queue a person works through. The reply comes by email to the address you put in the form.

The form deliberately does not require you to be signed in or to use a UT address, because a student who has lost access to their utexas.edu inbox still needs a way to ask us to delete their account. If you write in from some other address, expect us to ask a question or two before we delete anything, for the reason in the paragraph above.

Two things about this route are still open. [9] TO CONFIRM: the real support mailbox to publish alongside the /contact form — a working address a person can write to directly, and who reads it. [10] TO CONFIRM: how quickly do you commit to answering an access or deletion request? Pick a window you can actually hit with two people, and note that some state privacy laws impose their own deadline once they apply to you.

Texas has its own data privacy law, and whether it applies to a project this size depends on thresholds and on what the business ends up doing. That is a question for the review rather than something to assert here. [11] TO CONFIRM: does the Texas Data Privacy and Security Act apply to Sub40, and does the answer change once paid promotion launches? If it applies, this page needs a specific rights-and-appeals section rather than the general commitment above.

10. Security, described accurately

What is actually in place: access to every table is restricted at the database level rather than only in the interface, so a request for data you should not see is refused by the database itself. Traffic to the site is encrypted. Passwords are stored hashed, by our authentication provider, and are never visible to us. The specific privacy behaviours described in section 5 — the host’s name, the exact address, message contents, reporter identity — are enforced there too, not merely hidden in the UI.

What is not in place, and should not be implied: Sub40 has no security certification and has never been through a SOC 2 or any other audit. We follow practices modelled on that standard, which is a deliberate choice and is not the same thing as having been audited. Our providers hold their own certifications; we do not inherit them.

No system is perfectly secure, and this one is built by two people. If the worst happens we will tell affected users, but this draft does not name a deadline for that, because a number nobody has committed to is not a commitment. [12] TO CONFIRM: how quickly does Sub40 commit to notifying affected users after discovering a data breach? Note that Texas breach-notification law sets its own deadline regardless of what this page says, so check that first and do not promise something slower.

11. Younger users

Sub40 is for university students and is not directed at children. Because an account requires a UT email address, in practice accounts belong to people connected to the university.

Some entering students are 17, which is why the age question is a real one rather than boilerplate. [13] TO CONFIRM: the minimum age for a Sub40 account. 18 is the usual answer in Texas because that is when someone can be held to a contract, but some first-year students are 17 — decide whether they are excluded, and say so consistently on the signup page.

If we learn we have collected information from someone below whatever minimum is set, we will delete it.

12. Changes to this policy

This policy describes the code as it exists on the date at the top of the page. It will change, and this draft is expected to change substantially before launch.

The rule we intend to hold ourselves to is simple: if a change to the product changes what happens to your data, this page changes at the same time, not later. Adding an analytics tool, moving photos out of public storage, turning on payments, or adding any new company to the list in section 7 all count.

When something material changes, we will update the date at the top and give notice. [14] TO CONFIRM: how are users notified of material changes to these terms — an email to every account, a banner in the app on next sign-in, or notice on this page only — and how much warning do they get before the change takes effect?