Privacy

The short version

• You give this server one secret: your dining auth key. It keeps the key encrypted and uses it only to call the mess portal for you.
• It doesn't save your menus, registrations, bills, name or roll number, or anything you ask your app.
• Whoever runs this server can technically decrypt your key. Only connect if you trust them.
• You can end the connection yourself at any time. See Deleting your data.

What this server stores

• Your dining key, encrypted. It is sealed with AES-256-GCM, using a key derived from a secret in the server's configuration (the secret is not in the database). It is saved with a random connection ID, which app you connected from, and when. To call the portal for you, the server decrypts it in memory for each request.
• Fingerprints of sign-in codes and tokens. When an app connects it gets a one-time code, then an access token and a refresh token. The server keeps only a SHA-256 hash of each, with the connection ID and when it expires. Reading the database doesn't reveal the tokens themselves.
• App registrations. Some apps register themselves with the server before they connect. The server saves the app's name, a random ID and its return addresses. This is about the app, not about you.
• Usage statistics (turned on for this server). Daily totals only: how many times each tool was used and how often it failed, how many sign-ins worked or failed, and how many connections were ended because the portal rejected a key. To count active users it also keeps a list of which connection IDs made a request on each day. Those IDs are random and aren't tied to your name or roll number.

What it does not store

• What you ask your app, and what the tools send or return (menus, registrations, bills, preferences). These pass through the server's memory on their way between your app and the portal. They are not saved.
• Your name or roll number. When you sign in, the server asks the portal whether the key works and throws the answer away.
• Keys or tokens in logs. The server keeps no request log. It writes only start-up lines and short error messages, never keys, tokens or what you asked for.
• Network addresses. They are held briefly in memory to slow down abuse and are not saved.

Anything in front of the server, such as a proxy, may keep its own logs. See below.

How long things are kept

• Sign-in codes last 5 minutes. Access tokens last 1 hour. Refresh tokens last 60 days; your app gets a new one each time it uses one, so the clock restarts whenever your app connects. Expired tokens are cleaned up hourly.
• Your encrypted key is kept until the connection ends. That happens when your app tells the server you disconnected, when the portal rejects the key and your app next uses the connector, if an old refresh token is used again more than 30 seconds after it was replaced (a sign it was copied), or automatically once your app hasn't connected for 60 days and its last token has expired. A sign-in that was never finished is removed within a couple of hours.
• App registrations stay until the person running the server removes them.
• Usage statistics: the daily lists of connection IDs are deleted after 90 days, and the daily totals after a little over a year.
• Backups: the person running the server may back up its database. A backup made before you disconnected still holds your encrypted key. If you have deleted the key on the dining portal, that copy no longer works.

Who can see your key

The server has to decrypt your key to use it, so whoever runs it can do the same: they control the secret and the code. They could read your key, or use it to see your bill, registrations and preferences and to register, cancel and change meals on your account. You can't check this from outside. The source code is public on GitHub, but that doesn't show what code a particular server is running.

Only connect if you trust whoever runs this server. Make a key just for this, and delete it on the dining portal when you're done.

Where it runs, and who can see the traffic

The mess portal can only be reached from the IIIT Hyderabad network, so a server like this runs on a machine on campus. Apps such as claude.ai connect over the internet, so the server is made reachable through a relay. What the relay can see depends on how it works:

• A tunnel that only passes encrypted traffic along, such as Tailscale Funnel, can't read it. The connection is decrypted on the server itself.
• A proxy that ends the secure connection itself, such as Cloudflare, can see everything that passes through, including the dining key you paste on the sign-in page and the portal's answers.

The person running this server hasn't described its setup here. Ask them if you need to know.

The mess portal and your app

The dining portal is run by the institute. It sees every request this server makes with your key, and what it logs or keeps is outside this server's control. Those requests come from the server's address, not from your device.

Your app (Claude, ChatGPT, Cursor and so on) receives everything the tools return, such as menus and bills, and handles it under its own privacy policy.

Deleting your data

1. Remove the connector in your app.
2. Delete the key on dining.iiit.ac.in under Settings → Auth Keys. This is the step that matters most: it makes every copy of the key useless straight away, including any in backups.

The server deletes its own copy when your app tells it you disconnected (not every app does), the next time anything uses the key after the portal has stopped accepting it, or automatically about 60 days after your app last connected. There is no account on this server to delete, and no way to see or export what it holds. To have your connection removed sooner, ask whoever runs the server.

Questions

If something here is unclear or looks wrong, open an issue on GitHub. Never paste your dining key or any token into an issue, or anywhere else public. For questions about a particular server, ask whoever runs it.