Owner and unit identifiers
Security observations are associated with a network owner and an owner-generated technical unit identifier. A unit can represent a device or a local network; it does not automatically identify one person.
PRIVACY IN TARASEC
Protect your information. Understand your threats. Keep control.
Privacy is essential to TaraSec. Cooperative security should protect people from intrusion and data theft while giving them access to threat information about their own technical unit and practical help to recover.
This page brings together TaraSec's privacy principles, app access, shared intelligence, AI architecture and safeguards. TaraSec is experimental: design goals are distinguished from available functions, and capabilities depend on deployment.
VISIBILITY & ASSISTANCE
Network intelligence should help the affected user.
The TaraSec App is intended to give users direct access to threat information about their own unit. Work on this is already underway: the app can inspect gateway assessments, including severity and assessment source, and use recovery functions where permitted. Approved owners and managers can access broader gateway assessments and management functions.
The gateway can combine its local evidence with intelligence from the TaraSec DB server and cooperating networks: independent sightings, previous incidents, corroboration and possible coordinated activity. The app is the user-facing route to this richer security picture.
The goal is timely AI assistance for users whose units may be infected: explain the evidence, help investigate and contain the problem, and guide recovery and reassessment. Earlier detection and useful assistance can reduce the time an intruder has to access private information.
Current boundary: status and assessment interfaces are being developed alongside gateway AI. Immediate interactive AI assistance for every infected user is a development goal, not a service guaranteed on every participating network today. Access must be authenticated and limited to the user's own unit or an approved management relationship.
TECHNICAL IDENTITY
Identify the responsible unit without requiring the person's identity.
The network keeps the mapping
The ISP or responsible network owner retains the mapping to its subscriber or internal user. TaraSec's security model does not require subscriber names, addresses or email addresses. App accounts and manager authentication may separately require personal information.
Pseudonymous is not untraceable
Persistent identifiers can link observations over time, and the responsible network may identify the subscriber. IP addresses and linkable unit identifiers therefore require privacy protection even when no name is shared.
AI & ACCESS BOUNDARIES
The owner chooses detailed AI. Evidence remains open to reassessment.
The gateway owner can choose whether to enable detailed AI and which provider or local model to use. The architecture keeps the owner's AI credential at the gateway and excludes it from assessment reports sent to TaraSec. The app uses authorised endpoints rather than unrestricted global database credentials; privileged manager access requires verification and gateway approval.
A remote AI provider receives the evidence included in its assessment request. Keeping the API credential local does not by itself keep that evidence local. Operators must review the provider's data handling and minimize sensitive input; a local model is an architectural option.
AI findings should retain evidence, confidence and uncertainty. Suspected compromise, corroborated activity and confirmed infection must remain distinguishable. Wider opt-in global AI supervision is a research direction, not continuous monitoring of every server today.
CORRECTION & RETENTION
A temporary security judgment must be correctable.
TaraSec's design includes reassessment when new evidence contradicts an earlier attribution. Corrected status should propagate through the network while proportionate audit records support accountability. Accepted traffic can contribute contradictory evidence, but one accepted packet does not prove a unit is clean.
Current threat state and retained history serve different purposes. Retention should be limited to what is needed for protection, accountability, dispute resolution and applicable obligations. Preserving an audit trail does not justify unlimited retention or access.
This overview does not establish a verified, network-wide deletion schedule. Specific retention periods, access controls and correction procedures need to be documented and validated for each deployed service. Users should have a practical route to report an incorrect assessment and seek assistance.
Read about reassessment · Contact TaraSec about an incorrect assessment or privacy concern
ACCOUNTS, ID & YOUR CHOICES
Find the policy for the feature you use.
App privacy and account control
The app policy explains account, authentication, hotspot usage, technical information, nearby Wi-Fi permissions and retention. It also provides routes to request access, correction and deletion.
TaraSec ID and merit
The ID research proposes holder-controlled disclosure and separation of human identity from security telemetry. Contributor evidence should have appropriate public, reviewer-only or private visibility. These are research and design commitments, not a claim that every proposed credential feature is deployed.
Responsibility and concerns
TaraSec is developed by Taransvar, a Norwegian nonprofit. Participating operators remain responsible for their own networks and local records. Contact TaraSec for concerns about its services, and your network operator for local attribution or records.
REVIEW & RESEARCH
Privacy claims need evidence.
Cooperative protection and informed user control can improve privacy. Extra reporting, persistent identifiers and central intelligence also introduce risks. Data minimization, restricted access, secure transport, proportionate retention, correction and independent review must be demonstrated in running deployments.
Researchers and participants are invited to examine these assumptions and help improve them. This page is an overview of the model and its development boundaries; the app policy describes the app's specific data handling.