NotAfter™ tracks continuing education credits for certifications from CompTIA®, ISC2®, and EC-Council, and helps you report them. This page is the technical account of how: what the in-app browser does, what it refuses to do, and what the app sends over the network. The last section lists what you can check yourself.
The privacy policy is the authoritative text. If this page disagrees with it, the policy governs, and we want to hear about the difference at support@notafter.app.
NotAfter opens your provider's own website in a browser inside the app. You sign in yourself, in your own session. NotAfter does not perform the login, and it refuses to read any page it recognizes as a sign-in page. You also get to the form yourself: NotAfter never clicks Continue, Next, or any other button that takes you from one step of the provider's site to the next.
When you tap Fill, NotAfter writes values from an entry already on your device, such as the course title, the date, and the credit hours, into the fields it recognizes on the form, and fires the input and change events a page listens for. To choose from the form's own menus and radio buttons, it opens the menu if it has to and clicks the choice. It sends no synthetic keystrokes and never reads what is typed in a field. Two narrow checks do look at a field before writing: before choosing in a menu, a script may look at which choice is already showing, so that it can leave a choice already made in place, and a script may check whether a required question is still unanswered, without learning what any answer is. Automated tests check each kind of script the fill engine builds for reads of what is typed in a field, and fail if a script contains a call that submits the form.
You read what was filled, fix anything that is wrong, and tap Submit on the provider's page. NotAfter has no way to press that button for you. Afterward you tell the app what you filed, and that is the only way it learns. It does not know whether you submitted, what you submitted, or whether the provider accepted it.
The reason is practical. A wrong credit category filed on your behalf is yours to answer for in an audit, so the last step stays with you. The support page has the longer version.
NotAfter never asks for, receives, stores, or transmits your provider password or one-time code. It never reads credentials or session tokens out of the provider's own website data, which the next paragraph describes. If you send a password or a code to support, we will not accept it, and we will ask you to change it.
Sessions are the part worth reading closely. So that you are not signing in every time, the in-app browser keeps each provider's website data (cookies and site storage) in a separate store for that provider, inside the app's sandbox on your device. The provider's site sets that data. It survives closing the app, and it is never sent to us. We do not read credentials or session tokens out of it. The app does count that provider's cookies and read their expiry dates, to show you in Settings whether there is a session to sign out of. To clear it, open Settings, tap the provider under Providers, and tap Sign Out, which shows only while there is a session to clear.
Before NotAfter reads a page in that browser, a check runs. NotAfter refuses to read any page it recognizes as a sign-in page or where it finds a visible password box, and a refused read captures nothing. The check looks for a visible password field in the page, inside page components that let it look in, and inside embedded frames. Where it cannot see inside a frame that is showing on the page, it refuses rather than assumes, with two exceptions. A small, roughly square frame, under 100 pixels each way, is skipped only when it comes from a site the app's form definitions list as one the provider's own pages use for a widget such as a chat button. A Google reCAPTCHA frame is skipped at any size, matched by an exact address prefix rather than by a guess about what it holds, because a captcha is a challenge widget and not somewhere a password is typed. Any other frame showing on the page that the app cannot see into means the page is refused.
That is a mechanism with limits, two of which we have just written down, and it makes no promise about every page anyone could build.
You choose the image in your device's own photo picker. The picker runs outside NotAfter and hands over only the image you picked, so the app has no access to your photo library and never asks for it. NotAfter has no camera feature and no camera permission request.
Text recognition is the operating system's own and runs on your device. The image is not uploaded to us or to any third-party OCR service. It is held in memory while you review what was read, never written to a file or a cache, and released when the review closes. What gets saved is the text you confirm: course name, date, credit hours.
A screenshot of your own provider account page, imported instead of signing in, takes the same path.
While the submission browser is open, each time a page loads or its address changes, NotAfter asks the page short questions, such as whether a password box is showing and whether the provider is showing a message that the app's form definitions list as blocking you, like a maintenance notice. The questions are answered inside the page, and only the answers come back: which listed message is showing, if any, and, when the page is refused, the kind of thing that caused it, such as a password box or a frame, its rounded size where it has one, and, for a frame, the site it comes from. No text from the page comes back. NotAfter asks again when you tap Fill. There is no timer. To spot a listed message, NotAfter reads the page's visible text, on your device, inside the page itself. That is a real read of page content, and we would rather write that down than have you discover it. The password check above comes first, and if it finds a visible password box, nothing more on the page is checked or read. The checks keep nothing and send nothing, and the app has no upload path for them to travel on.
Two reads do keep something. Both happen because of a choice you made, and both stay on your device. Capture This Page reads the page you are on, once per tap, and keeps the credit totals and cycle dates it finds there. When a provider's form asks which of your certifications an entry is for and NotAfter cannot work out the match, it asks you and saves the list of options, in the provider's wording, keeping the last ten per provider, together with the answer you gave, so that it does not ask again. Deleting the certification removes the answer, and so does tapping None of these is mine if the app asks you again. The Sync from Provider screen performs no automatic reads at all. The fill itself keeps one more thing on your device: a short diagnostic note saying whether each expected field was found, what kind of element it was, and a scrambled eight-character fingerprint of its label, along with the page's address cut down to the parts the app's own form definitions already name, and the hour it was recorded. It never contains the page's text or anything you typed, and the app keeps the last ten per provider. The app never sends it. If you choose Report a Problem, the latest note goes into an email that you read, can edit, and send yourself. After a Fill, where the form states a daily credit limit NotAfter has on record, the app checks that the form's activity menu still shows the activity the Fill chose, then reads the form's information and help notes, inside the page, looking for that limit. It keeps, on your device, whether the form still says it, and the form's own line if it says something different. It never sends either.
NotAfter points its browser at the addresses on the destinations page, for the provider you are visiting. That list is compiled into the app, and downloaded form definitions cannot change it.
The list says where NotAfter aims the browser. It is not a fence around where the browser can end up. A link on a provider's page can lead to another website outside the list, and NotAfter does not stop you following it. Some destinations do leave the in-app browser: when the browser is headed to a checkout or payment page it recognizes, NotAfter hands that page to Safari, and a link meant for another app, such as an email or phone link, opens that app on your device. Provider pages also load pieces from other companies, such as a chat widget or a CAPTCHA, the way they would in any browser. Embedded payment forms are the exception: NotAfter's browser does not load the ones it recognizes.
Three files, fetched only when you open the app, plus a form-definitions check you can start by hand in Settings, which fetches the third file too. The first two are plain HTTPS requests with no request body, for public files that are the same for every user.
The first two carry no account (there is none), no device or advertising identifier, no certification or credit data, and no analytics event. The third carries that key's identifier and a signature, or, when the app makes a new key, Apple's attestation of it, and nothing else about you. The server keeps a standard access log: a shortened IP address, the time, the file requested, and the user-agent string. Our hosting provider deletes old entries on its own weekly schedule, within about 9 weeks, and its backups of our account can keep a copy for up to about two weeks more, so none is kept for longer than about 11 weeks.
Apart from those requests, the app sends nothing to us, because it contains no other upload or form-submission path of any kind. Apple may pass us crash reports and usage figures from its own collection, not from code in the app, and if you test a beta through TestFlight, Apple shares crash logs, usage information and any feedback you send, as the privacy policy describes. The app also contains no analytics, attribution, or advertising code and no third-party code of any kind. Reminders are scheduled on the device, and there is no push server. Your browser traffic goes wherever the pages you open send it, and purchases go through Apple.
Report a Problem, in the browser's toolbar, shows you the whole report first, lets you edit or delete any of it, and loads it into your own Mail app. Nothing sends until you press Send.
You can watch the in-app browser yourself, with tools Apple already ships. The ability to audit it is built into the app: NotAfter leaves its browser open to Safari's Web Inspector in every build, so all it takes is an iPhone, a Mac and a cable. The app's About this browser sheet puts it in one line: "With a Mac, you can watch this browser's scripts run live: enable Web Inspector in this device's Safari settings, then attach from the Develop menu in Safari on the Mac." In full:
NotAfter:.Every script NotAfter runs in a provider's page starts with a one-line comment naming its purpose, so a search for NotAfter: finds them among the provider's own. On a page NotAfter recognizes as a sign-in page by its address, it runs none. Where a provider's sign-in page shares its address with other pages, NotAfter cannot tell them apart that way, so it runs its password check there instead, and you will see that check among the scripts.
If what you see contradicts something on this page, write to support@notafter.app with what you saw. Please never send a provider password, a one-time code, or a screenshot of a sign-in page. We will not accept them.
NotAfter is an independent app and is not affiliated with, endorsed by, sponsored by, authorized by, or certified by CompTIA, ISC2, EC-Council, or any other certification body. All certification names and marks are the property of their respective owners and are used here only to describe which certifications NotAfter works with.