toolcrow.app
Try Toolcrow
All topics

How your tools are protected

From open to invite only: who can reach a tool at each access level, where its data goes, and the protection that is always on.

Last updated

lighter → heavier

tool xyzTool XYZ
no door
elsewhere

Found on Google

Toolcrow never does this.

Anyone who searches.

  • Many hosts let search engines list your page.
  • Then anyone can find your tool and use all of it.
+Under the hood
  • Every response from a tool's address sends the HTTP header X-Robots-Tag: noindex, nofollow: the HTML, the password and private screens, every file, and the redirect that leads there.
  • It's a header, not just a <meta> tag, so it also covers files that aren't HTML and pages that never load your code.
  • robots.txt doesn't block tool addresses on purpose. A blocked address can still be listed from links elsewhere; a crawled address with noindex can't.
  • The sitemap lists only Toolcrow's own pages. A free tool's landing page on /tools can be indexed; the tool inside it still sends noindex.
?no linkthe linknot in searchTool XYZ
light
level 1

Open

Anyone you give the link to.

  • The address is long and random, so nobody stumbles on it.
  • Search engines don't list it.
  • A share button and a link preview make it easy to pass on.
+Under the hood
  • Each tool lives on <label>.toolcrow.live. The label is 16 bytes from a cryptographic random generator, written as 26 base32 characters: 2^128 options, so guessing is not a realistic attack.
  • Share links on toolcrow.app carry a 22-character base64url slug (also 128 bits) and answer with a 307 redirect to the tool's address.
  • Open Graph tags (name, description) and the share panel are only added for Open tools, so a link preview never leaks the name of a locked tool.
  • A tool's address only answers for its own host name.
Tool XYZpassword
medium
level 2

Password

People with the link and the password.

  • Without the password, our server only sends the password screen. Your code never leaves the server.
  • After the right password, that browser gets a pass for 12 hours.
  • Change the password and every pass stops working.
+Under the hood
  • The gate runs on the server before your code is fetched from storage. Without a valid pass the response is only the password screen; the tool's other files answer 404.
  • The password is checked with bcrypt (cost 10) against a hash in a separate table with row-level security that only the server can read. Passwords are 8 to 200 characters.
  • A second copy is stored encrypted with AES-256-GCM, so you can see your password again and send it in an invite. It is decrypted only on the server.
  • The form posts to the tool's own address. On success the server sets a pass: an HMAC-SHA256 signature tied to the tool and the current password hash, as an HttpOnly; Secure; SameSite=Lax cookie that lasts 12 hours and only works on that one address.
  • Because the signature includes the hash, a new password makes every old pass invalid at once.
  • Failed tries are counted per network and per tool. Too many and the door locks for a while.
  • You, the maker, are recognised by your own signed owner pass (see Private) and skip the password.
Tool XYZyou, signed innobody else
heavy
level 3

Private

Only you, signed in to Toolcrow.

  • Every new tool starts here.
  • Everyone else sees a "this tool is private" screen.
  • Your Toolcrow login never touches the tool's own address.
+Under the hood
  • Your Toolcrow session lives on toolcrow.app and can't be read by toolcrow.live, a different site. So a handover is needed.
  • Opening your tool from Toolcrow checks your session there and adds a one-time token to the redirect: your user id, an expiry of 60 seconds and an HMAC-SHA256 signature.
  • The tool's address verifies the token, swaps it for an HttpOnly; Secure owner cookie with its own signed 12-hour expiry, and answers with a 303 redirect so the token disappears from the address bar and the browser history.
  • On every request the server checks again that you own the tool, or belong to the workspace that owns it.
  • Toolcrow never sets account cookies on toolcrow.live, so code in a tool can't touch your login.
guest listanna@acmetom@acmeTool XYZanna?
heaviest
level 4

Invite only

coming soon

Only people on your guest list, each with their own login.

  • You add people by email. They sign in with their own account.
  • Toolcrow checks the guest list on every visit.
  • Take someone off the list and they're out.

Today, sharing by email only sends an invite (with the password, for password tools). It doesn't give access on its own yet.

+Under the hood
  • Built as portals: you group tools and invite people to them. Each guest gets an account with the role "end user", set on the server inside their signed login token, so they can't change it.
  • End users are kept out of every maker and admin page and API, and have no workspace of their own.
  • Opening a tool works like the owner handover: a 60-second signed token, swapped for a 12-hour cookie. Membership is checked again on every request.
  • Access is tied to the account, not to an email address typed in a form.
  • Built, not switched on yet.

Side step: where does the data go?

Once someone is through the door, you choose per tool what happens to what they type. The door still decides who can reach it: on a password tool, only people with the password get to the data.

Tool XYZmy notesstays here

Only on the visitor's device

Saved in that visitor's own browser. Nobody else sees it, not even you.

entrySubmissionsno reading back

Sent to you

Entries land on your Submissions page or in your own Google Sheet. Visitors can't read them back, unless you switch on "Visitors can read submissions".

one list for all

Shared by everyone inside

Everyone who got through the door reads and writes the same data. Good for a team list, not for anything private.

+Under the hood
  • On the device: localStorage and sessionStorage are swapped for a shim on IndexedDB. Browsers keep storage per origin, and every tool has its own origin, so tools can't read each other's data.
  • Sent to you: Tooldrop.opslaan() appends a row. Reading rows back with Tooldrop.lezen() is refused unless you switched it on. Shared: window.storage with shared: true reads and writes keys.
  • Shared and sent data go through one server route. The tool can't talk to the database directly and never holds a database key.
  • Every call carries a data pass that the server only hands out after the door: the tool id, a 12-hour expiry and an HMAC-SHA256 signature over the tool's current access (open, password hash or private). Each call checks it against the database again, so a new password, switching to private, switching off or a takedown cancels every pass.
  • The route only accepts calls from tool addresses on toolcrow.live (CORS allowlist).
  • The server decides where data lands: your Google Sheet if you picked one, otherwise Toolcrow's own tables. Those have row-level security with no public policies, so only the server can reach them. Google tokens stay encrypted on the server.
  • Limits per tool: 1,000 data calls a day, 5,000 entries, 1,000 shared keys, 50,000 characters per value.

Always on, at every level

You don't switch these on. They come with every tool.

Never in search engines

Not listed on Google or anywhere else, not even Open tools.

An address nobody can guess

Long and random, so the only way in is the link you share.

Every tool in its own space

Its storage and cookies can't reach your other tools or your Toolcrow account.

Secret keys stay on our server

AI keys and your Google connection are never sent to the tool.

No copying into other sites

Other websites can't show your tool inside their own page.

A tool can go offline

You can switch a tool off. If one is reported for abuse, Toolcrow can block it.

PreviousSharing and accessNextLimits
Something missing or unclear? Email hello@toolcrow.app. We answer personally.