Create your link
The same learner ID and password you use in the CDC app. They are encrypted in this browser first, and then the link is tried once, so you can see that it works before you subscribe. If you would rather know exactly what that means before typing anything, it is all set out below.
Your link is ready
Adding it by hand
iPhone or iPad. Settings, then Apps, then Calendar, then Calendar Accounts, then Add Account, then Other, then Add Subscribed Calendar. Paste the link.
Google Calendar. On a computer, open Other calendars, then From URL, and paste the link. Google refreshes subscribed calendars slowly, sometimes only once a day.
Outlook. Add calendar, then Subscribe from web.
Reminders. Each booking comes with an alert an hour ahead. Add
&alarm=120 to the link for two hours instead, or &alarm=0
for none.
Your password, as it leaves this page
Encrypting a sample in this browser now, with the same function the form above uses.
-
version
byte 0
-
A throwaway public key, generated for this one message
bytes 1–65
-
Random starting value for the cipher
bytes 66–77
-
The learner ID and password, encrypted
bytes 78 onward
Those four pieces, joined and text-encoded, are the whole
creds= value in your calendar link. There is no other copy of
your password in it.
What happens to your password
This page, in your browser
Reads your ID and password and encrypts them. This is the only place they are typed, and it happens before anything is sent.
the encrypted blob, in the link your calendar app re-sends hourly
This site's server
Decrypts the blob, signs in to CDC as you, builds the calendar, and forgets both. It holds one thing permanently: the private key.
your ID and password, as CDC expects them
ComfortDelGro Driving Centre
Answers with your bookings — the same list you see when you check them yourself.
The encryption, step by step
-
This page asks the server for its public key — a P-256 elliptic-curve key. A public key can only encrypt; the matching private key, which never leaves the server, is the only thing that can decrypt.
-
Your browser generates a second key pair of its own, used for this one message and then discarded, and combines its private half with the server's public key (ECDH). The server can compute the same shared secret from the other two halves. Nobody watching the link go past can compute it from either public key alone.
-
The shared secret is stretched into a 256-bit key (HKDF-SHA256), and your ID and password are encrypted under it with AES-256-GCM. GCM also signs the result, so an altered link fails to open rather than opening into something else.
-
The throwaway public key is folded into both the key derivation and that signature. So a blob cannot be lifted out of one link and re-attached to a different key — it only opens as the whole piece it was encrypted as.
In one line: ECIES over P-256, HKDF-SHA256, AES-256-GCM. The browser half is about a hundred lines of it, in /app.js.
What that buys you, and what it doesn't
What it buys you
-
The link is safe to keep lying around
It sits in your calendar app's subscription list, in your browser history, and in the logs of every network it crosses. Your password is not readable in any of those.
-
There is no account and no database
Nothing here has a record of you. The link is the only record, and you are holding it. Your bookings are cached for fifteen minutes, under a one-way hash of your credentials rather than the credentials, so a calendar app that refreshes eagerly doesn't hammer CDC on your behalf.
-
You can take a link back
Change your CDC password, and every link ever made from the old one stops working on its next refresh. Then come back here and make a new one.
What it doesn't
-
The server does read your password
It has to: signing in to CDC is the whole job, and CDC wants the real password. So this is not a design where nobody but you can ever see it — the server sees it in memory, for the second or two each refresh takes. What the encryption prevents is everywhere else seeing it.
-
Anyone holding your link can read your bookings
The link works for whoever has it — that is what makes a subscription possible without an account. It does not let them read your password, sign in to CDC, or book or cancel anything. Still, treat it like a password: don't post it anywhere public.
Don't take the page's word for it
Everything above is a claim, and a page that wanted your password would make the same claims. These are the parts you can check for yourself.
- Read the code that runs here
- Open /app.js. That is not a copy or a description:
it is the exact file your browser downloaded and ran, unminified, about a
hundred lines of it. The four steps above are the function
encryptCreds, and you can read it before you type anything. - Check the key your details were encrypted to
-
This is a SHA-256 fingerprint of the 65-byte public key your browser fetched a moment ago. It is the same on every visit and for every visitor, so a friend's browser, or your phone, should show these exact characters. A page serving you a key of its own would not match.
- Watch what the page sends
- Open your browser's network tab before you submit. The only requests this page makes are to this site, plus Google's font servers for the two typefaces. There are no analytics, no trackers and no cookies, and the request carrying your credentials carries them encrypted.
Read enough? Back to the form.