Security Practices

How we think about security

Arcline is a young service run by a small team. We build it with several layers, so that one mistake does not expose everything: protect the account, protect the secrets, keep data apart, keep changes small and checkable, and keep a record of what happened.

Everything on this page describes what the product actually does. We do not describe plans as if they were done. Where something is not there yet, we say so in the last section.

Protecting your account

• Passwords are never stored. We keep only a salted, one-way hash made with bcrypt. Nobody at Arcline can read your password.
• Password rules. Passwords must be at least 8 characters, and in the live service we reject very common ones.
• Sign-in throttling. Repeated failed sign-ins for an account or from a network address are counted, and further attempts are blocked for a while. The sign-in answer is the same whether the account exists or not, and takes the same amount of work, so it does not reveal which e-mail addresses have accounts.
• Limited sign-ups. Account creation is rate limited per network address.
• Short sessions. Your sign-in token is signed, and expires about 12 hours after you sign in. It is kept in your browser's local storage and sent in a request header, not in a cookie.
• A pause switch. One switch in Settings stops all automated work on your account.

Protecting the secrets you give us

• Encrypted at rest. GitHub tokens, WordPress Application Passwords, Ghost keys and Cloudflare tokens are encrypted with authenticated encryption before they are saved.
• Key kept apart. The encryption key lives in our application host's private settings, not in the database. Someone who only sees the database cannot read the secrets.
• Never sent back. The app and the API never return a saved secret. They show only that one exists.
• Used in memory, only when needed. A secret is decrypted for the moment a task needs it.
• Erased when you disconnect. Disconnecting, or removing the website, erases the stored secret.
• Least privilege is encouraged. We recommend a GitHub token for one repository with only the Contents and Pull requests permissions.
• Safe start-up. In the live service, the program refuses to start if its secrets or encryption key are missing or unsafe.

Keeping accounts and websites apart

Your data must never show up in someone else's account, and one website's data must never mix with another's, even inside your own account. We enforce this in the code, not by convention:

• Every stored record is tagged with its account, and every website's record is also tagged with its website.
• Every request for a website first checks that the signed-in account owns that website. Asking for a website or record that is not yours gives the same answer as one that does not exist.
• A record number from one website is refused if it is used under another website's address, even within the same account.
• Saved answers are kept per person, so one person's answers are never given to another.
• Automated tests use several accounts and websites and check all of this, including that removing a website leaves no records behind.

Making changes to your website safely

The most sensitive thing Arcline does is change your website, so this has the most safeguards:

• You set the limit. Changes happen only within the access level you chose, and sensitive changes need your explicit approval each time. See the Terms of Service for the six levels.
• Things it never does. Whatever the level, it never changes prices, inventory, checkout, orders, customers or payments.
• A review path. At the lower levels, a change waits for your approval. Every change shows what it will change and why.
• No direct pushes. For GitHub, a change goes to a new branch and a pull request. It never goes straight to your main branch, and your branch protection is never bypassed.
• No overwriting your edits. If the page changed since we read it, the change is refused. Only one change at a time can touch a page.
• Checked before sending. Values are validated: for example, we refuse script code, line breaks and markup in titles and descriptions.
• Checked live afterwards. After your host publishes, we check that the live page shows the change, and that nothing else on the page changed.
• Automatic undo. If that check fails, we try to put the page back as it was, and tell you.
• Limits on automation. There are limits on how many changes can be made per day and per page, and the automation backs off after failed attempts. It does not loop.

Protecting the website, the app and the API

• HTTPS everywhere. Traffic between your browser and our website and API is encrypted. Our website also tells browsers to insist on HTTPS.
• Browser protections. The website sends a strict content security policy that allows only our own scripts, refuses to be shown inside other pages, and turns off access to the camera, microphone and location.
• Rate limits. Requests are limited per person, per network address and per kind of action, with tighter limits on heavy actions such as scans and AI requests.
• Safe fetching. When the service fetches a website, it uses only public internet addresses and refuses private or internal ones, so nobody can use it to reach internal systems.
• Careful with AI. Website text is handed to the AI model as untrusted data. What comes back is checked against a strict format and is never run as code.
• A hardened tracker. The public tracker endpoint accepts only small requests, only for the website it belongs to, and is rate limited. Server reports need a separate secret key.
• Payments. We never see or store your card details: you pay on Polar's own checkout page. We decide which plan you are on on our servers, from notices that Polar sends us about your subscription, and we check the signature of every notice before we trust it. Your browser cannot change your plan, and the limits of your plan are applied on our servers.

Records and monitoring

• Activity log. Important actions are written to an append-only log: sign-ups, sign-ins and failed attempts, connections, access level changes and every step of every change. The program has no function to edit or delete a log entry.
• Request records. We keep short records of each request: a reference, the route, the response status and the time taken. They contain no passwords or secrets.
• CERT-In. We keep security-relevant logs for as long as the CERT-In Directions of 28 April 2022 require, to the extent they apply to us.

What you can do

Security is shared. These steps make a real difference:

• Use a long, unique password, ideally from a password manager.
• Create the most limited token you can: one repository, only the Contents and Pull requests permissions, with an expiry date.
• Turn on branch protection on your repository, so that a person can review pull requests if you want that.
• Start at “Look only” or “Ask me first” and raise the level when you are comfortable.
• Read your Activity screen now and then. It lists everything that was done.
• Revoke tokens at their source when you stop using Arcline, and sign out on shared computers.
• Keep your own website, CMS and plug-ins up to date.
• Manage your subscription only from inside the app (Profile, then Plan and billing). Its Manage billing button takes you to Polar's own customer portal.
• Never send tokens or passwords by e-mail, including to us.

Reporting a security weakness

If you find a weakness in Arcline, please tell us. Write to thescalelab10@gmail.com with “Security” in the subject, and include what you found, how to reproduce it, and what you think the impact is. Please do not include other people's data.

We will acknowledge your report within 3 working days, keep you updated, tell you when it is fixed, and credit you if you wish.

The rules:

• Test only with your own account and your own websites.
• Do not access, change or delete anyone else's data. If you reach personal data by accident, stop and tell us at once.
• Do not run denial-of-service tests, heavy automated scans, spam, social engineering or physical attacks.
• Give us a reasonable time to fix the problem before you share details publicly.

We do not run a bug bounty programme, so we cannot pay rewards. We are grateful for responsible reports all the same.

If something goes wrong

1. 1
   Contain

   We stop the problem, cut off access that should not exist and, where needed, rotate our own keys.

2. 2
   Find out what happened

   We work out what was affected, which accounts, and what data.

3. 3
   Tell the right people

   We tell the Data Protection Board of India and each affected person as the law requires. We report cyber incidents to CERT-In within six hours of noticing them, as the CERT-In Directions require.

4. 4
   Help you protect yourself

   If connection secrets could be affected, we tell you which to revoke and how.

5. 5
   Fix and learn

   We fix the cause, check for similar problems and improve our practices.

What we do not claim

To be fair to you, here is what is not in place today:

• We hold no security certification, such as ISO 27001 or SOC 2, and we do not claim any.
• We do not claim that we have never had, or will never have, a security incident.
• Two-step sign-in is not available yet.
• We run no bug bounty programme.
• We do not promise backups of your data (see the Privacy Policy).
• We cannot control the security of the tools you connect, such as GitHub, WordPress, your host or your own devices.

Questions about security can be sent to thescalelab10@gmail.com, or you can contact us. Complaints go to the Grievance Officer: see Grievance Redressal and Your Data Rights.