01What applies right now
Shasam Technologies does not currently publish a consumer application. No app of ours is available for you to install, so there is no live permission set to disclose here. What follows is the standard we hold ourselves to, published in advance so it can be held against us when an app does ship.
This page has a second audience: clients deciding whether to have us build a mobile application. The commitments below apply by default to every app we ship, including apps built for someone else.
02What we commit to for every permission
- Least privilege. We request the narrowest permission that does the job, and only when a feature you are using needs it. We do not request permissions for features that do not exist yet.
- Explained before the prompt. The app tells you in plain language what the permission is for, before the operating-system dialog appears. A system prompt with no context is a request to be denied.
- Declinable without dead ends. You can say no. The app tells you exactly what stops working, keeps working for everything else, and does not nag you on every screen.
- Revocable at any time. You can withdraw a permission in your device settings whenever you like, and the app handles that state properly rather than crashing or silently failing.
- Not repurposed. A permission granted for one purpose is not quietly used for another. A new use means asking again.
- Documented publicly. Every published app gets its own permission page listing each permission, what it powers, and what breaks if denied - matching what the store listing declares.
03How we treat each kind of permission
Our default position for the permissions an operational app most often needs. A product notice may narrow these further; it may not widen them without saying so explicitly.
| Permission | What it is typically for | Our rule |
|---|---|---|
| Location | Confirming service coverage, showing nearby work, recording where a job was completed | Requested only when a feature needs it. Background or continuous location is requested only where the job genuinely requires it, is disclosed prominently before the prompt, and is never enabled silently. |
| Camera | Capturing documents, proof of delivery, or site photographs at the point of upload | Used only for capture you initiate. No background capture, ever. Files go to private storage, never to a public URL. |
| Photos and media | Choosing an existing image instead of taking a new one | Scoped to the items you select. We do not enumerate or index your gallery. |
| Notifications | Telling you about work assigned to you, or a status change you are waiting on | Operational messages only. We do not use push notifications for marketing without separate, specific opt-in. |
| Storage and files | Attaching a document, or saving a receipt or report you asked for | Limited to the files you choose or the app itself creates. No general filesystem scanning. |
| Phone and contacts | Rarely needed; occasionally to call a counterparty from inside a workflow | We do not upload address books. Where a call feature exists it hands off to the dialler rather than reading your contacts. |
04Device and diagnostic data
Applications need some technical information to work and to be fixed when they break: device model, operating-system version, app version, and crash or error reports. We treat it as follows:
- It is used to operate the app, diagnose faults, and improve reliability - not to build a profile of you.
- Crash reports are scrubbed of personal content where we can, and are used for nothing but fixing the fault.
- We do not use advertising identifiers, and we do not embed advertising or cross-app tracking software in our applications.
05Apps we build for clients
When we build an application for a client, the client is the Data Fiduciary for the data it collects and publishes its own privacy notice and store declarations. Our part is to make sure the app asks for the minimum, discloses honestly, degrades gracefully when a permission is refused, and that the store declaration matches what the code actually does.
If we are asked to build something that collects more than its stated purpose needs, or to obscure what a permission is used for, we decline. That is a condition of the work, not a negotiating position.
06Questions about a permission
If a permission request in one of our apps is not clearly explained, that is a defect and we want to know about it. Write to support@shasamtechnologies.com. How the resulting data is handled is covered by the Privacy Policy, and how long it is kept by the Data Retention and Deletion Policy.
07Grievances and how to reach a person
If anything in this document, or anything we have done with your information, is not right, raise it with our Grievance Officer. You do not need to use any particular form of words.
- Grievance Officer: Peter Yogaesh J
- Email: support@shasamtechnologies.com
- Address: Chennai, Tamil Nadu, India
We acknowledge grievances within 48 hours and aim to resolve them within 15 days, in line with the Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021.
If you are not satisfied with our response on a personal-data matter, you may complain to the Data Protection Board of India under the Digital Personal Data Protection Act, 2023. Approaching us first is not a precondition, but it is usually faster.