**सुरक्षा र कमजोरी खुलासा — Telvio**

> सुरक्षा कमजोरी कसरी रिपोर्ट गर्ने, त्यसको बदलामा हामी के गर्ने प्रतिबद्धता जनाउँछौँ, कुन विषयहरू हाम्रो दायरामा पर्छन्, र सुरुदेखि नै सेवा कमभन्दा कम कुरा राख्ने गरी…

Source: https://telvio.app/ne/legal/security/ · language: ne · updated: 2026-09-04

1. [होम](https://telvio.app/ne/)
2. [विश्वास केन्द्र](https://telvio.app/ne/legal/)
3. सुरक्षा कमजोरी रिपोर्ट गर्ने

नीति

# सुरक्षा कमजोरी रिपोर्ट गर्ने

तपाईंले हाम्रो app, सर्भर वा यो वेबसाइटमा कुनै कमजोरी फेला पार्नुभएको छ भने हामीलाई जानकारी दिनुहोस्। जानकारी दिएको कारण हामी तपाईंलाई विरोधीका रूपमा लिने छैनौं।

- एकै ठेगानामा रिपोर्ट गर्नुहोस्
- सद्भावपूर्वक गरिएको अनुसन्धानका लागि कानुनी कारबाही हुँदैन
- 5 कार्यदिवसभित्र प्राप्त भएको पुष्टि

कसरी रिपोर्ट गर्ने

विषयमा **Security vulnerability** लेखेर [support@telvio.app](mailto:support@telvio.app?subject=Security%20vulnerability) मा इमेल पठाउनुहोस्। तपाईंले के, कहाँ फेला पार्नुभयो र त्यसलाई पुनः देखाउने चरणहरू उल्लेख गर्नुहोस्। प्रमाणका लागि नमुना उपयोगी हुने भए समावेश गर्नुहोस्; त्यसमा अरू कसैको data सम्बन्धित छ भने पठाउनुको सट्टा त्यसको वर्णन गर्नुहोस्।

हामी पाँच कार्यदिवसभित्र प्राप्त भएको जानकारीको पुष्टि गर्ने लक्ष्य राख्छौँ। समस्या सार्वजनिक गर्नुअघि त्यसलाई समाधान गर्न हामीलाई उचित समय दिनुहोस्, र अरूको data मा पहुँच नगर्नुहोस्, service को गुणस्तर नघटाउनुहोस् वा कुनै user लाई हानि पुग्ने तरिकाले काम नगर्नुहोस्।

लागू भएको मिति २०२६ सेप्टेम्बर ४

## हाम्रो प्रतिबद्धता

- **पाँच कार्यदिवसभित्र जवाफ**, स्वचालित reply होइन, कुनै व्यक्तिबाट।
- **इमानदार मूल्याङ्कन।** कुनै report vulnerability होइन भन्ने लागेमा हामी चुपचाप बन्द गर्नुको सट्टा किन होइन भनेर बुझाउँछौँ। सहमत भएमा, यसलाई कहिलेसम्म fix गर्ने अपेक्षा राखेका छौँ भन्नेबारे मोटामोटी जानकारी दिन्छौँ।
- **असल नियतले गरिएको security research का लागि कानुनी कारबाही नगर्ने**, तलको दायराभित्र रहेर गरिएको research का लागि। यो policy पालना गर्ने researcher विरुद्ध हामी कुनै दाबी अघि बढाउने वा समर्थन गर्ने छैनौँ, र report लाई attack नभई योगदानका रूपमा लिनेछौँ।
- **तपाईं चाहनुहुन्छ भने श्रेय।** fix उपलब्ध भएपछि तपाईंले रोजेको नाम वा handle बाट तपाईंलाई उल्लेख गर्नेछौँ, र तपाईं गुमनाम रहन चाहनुहुन्छ भने तपाईंको नाम राख्ने छैनौँ।
- **गोपनीयता।** कानुनी रूपमा बाध्य नभएसम्म, तपाईंको सहमतिबिना तपाईंको पहिचान कम्पनीबाहिर कसैसँग साझा गर्ने छैनौँ।
- **हामीले उपलब्ध गराउन नसक्ने कुरा:** सशुल्क bug bounty। यो सानो कम्पनी हो र कुनै reward programme छैन। उल्टो संकेत दिनुभन्दा यसबारे स्पष्ट रूपमा भन्नु हामीलाई उचित लाग्छ।

## दायरा

दायराभित्र: Telvio का mobile applications, तिनले communicate गर्ने API र servers, र यो website। कुनै प्रयोगकर्ताको call records, credit balance वा installation identifier बाहिर ल्याउन सक्ने, अरू कसैको खर्चमा call गर्न सक्ने, वा call मा देखाइने number परिवर्तन गर्न सक्ने कुनै पनि कुरा हाम्रो विशेष चासोको विषय हो।

दायराबाहिर: प्रमाणित प्रभाव नदेखाइएका automated scanner का findings; प्रयोग गर्न सकिने परिणाम नभएका missing security headers; unlocked device मा physical access आवश्यक पर्ने कुनै पनि कुरा; हाम्रा staff वा users लाई social engineering गर्ने कुरा; denial of service; हामीले प्रयोग गर्ने third-party services का issues, जुन सिधै सम्बन्धित service लाई पठाउनुपर्छ; र कुनै feature नभएकोबारेका reports — जस्तै अझ कडा हुन सक्ने rate limit वा हामीले उपलब्ध नगराएको option — विद्यमान feature को defect का reports होइनन्।

कृपया अरू मानिसलाई असर पर्ने तरिकाले test नगर्नुहोस्। आफ्नो नभएको data access, modify वा delete नगर्नुहोस्, users का लागि service कमजोर नबनाउनुहोस्, आफूले गर्न सक्छु भनेर प्रमाणित गर्न अरू user को खर्चमा call नगर्नुहोस्, र denial-of-service test बराबर हुने परिमाणमा automated tooling प्रयोग नगर्नुहोस्। कुनै कुरा देखाउन account वा credit आवश्यक भएमा सोध्नुहोस्, हामी त्यसको व्यवस्था गर्नेछौँ।

## कुनै breach ले बाहिर ल्याउन सक्ने कुरा service ले कसरी सीमित गर्छ

उपभोक्ता service का लागि उपलब्ध सबैभन्दा प्रभावकारी security control भनेको data सुरुमा नै नराख्नु हो, र यहाँ मुख्य रूपमा यही उपाय प्रयोग गरिएको छ। Registration छैन, त्यसैले user database पनि छैन: चोरी हुन सक्ने names, email addresses, phone numbers वा passwords छैनन्, र credentials नै नभएकाले credential stuffing ले attack गर्ने कुनै कुरा पनि छैन।

Payment पूर्ण रूपमा Apple र Google मार्फत process हुन्छ। हामीले कहिल्यै card number, expiry date, billing address वा अन्य कुनै payment credential प्राप्त गर्दैनौँ — केवल signed receipt identifier प्राप्त गर्छौँ। हाम्रा systems compromise भए पनि payment instrument बाहिर आउन सक्दैन, किनकि त्यस्तो कुनै कुरा store गरिएको छैन।

Call audio कहिल्यै record गरिँदैन। Call चल्दासम्म यो encrypted form मा पठाइन्छ र त्यसपछि कुनै पनि रूपमा रहँदैन। Contact lists कहिल्यै upload गरिँदैनन्: app लाई contacts access दिइएको छ भने number छान्नका लागि list device मै पढिन्छ र त्यहीँ रहन्छ। Precise location कहिल्यै collect गरिँदैन।

वास्तवमा रहेको र त्यसैले breach हुँदा बाहिर आउन सक्ने कुरा [privacy policy](https://telvio.app/ne/privacy/) मा स्पष्ट रूपमा दिइएको छ: balance राख्ने anonymous installation identifier, phone bill मा हुने किसिमका call records, purchase receipt identifiers, र IP addresses सहितको technical data। Call signalling र audio transit मा encrypted हुन्छन्, app र हाम्रा servers बीचको सबै traffic पनि encrypted हुन्छ, र call records मा access service सञ्चालन गर्न आवश्यक पर्ने मानिसहरूमा मात्र सीमित छ।

## vulnerabilities नभएका security questions

नियमित रूपमा report हुने तीनवटा कुरा intended रूपमा नै काम गरिरहेका छन्, र तीबारे यहाँ स्पष्ट लेख्दा सबैको समय बचत हुन्छ।

**हरेक call मा एउटै number देखिन्छ।** यो जानाजानी गरिएको हो, [यसको आफ्नै page](https://telvio.app/ne/caller-id/1-434-280-0044/) मा प्रकाशित छ, र caller ID को कमजोरीको ठीक उल्टो हो: app ले कुनै अर्को number देखाउने तरिका दिँदैन। यही विशेषताले यसलाई धेरै telephone fraud मा निर्भर हुने impersonation का लागि प्रयोग गर्न नसकिने बनाउँछ।

**Login छैन, र यो missing authentication control होइन।** Authenticate गर्नुपर्ने account नै छैन। Installation identifier credit balance का लागि bearer token हो र त्यसैअनुसार व्यवहार गरिन्छ; device बाट यसलाई पढ्न सक्ने जोसुकैले त्यो balance खर्च गर्न सक्छ, त्यसैले यो settings बाहेक कतै display गरिँदैन र device compromise दायराबाहिर पर्छ।

**App ले calls वा messages receive गर्न सक्दैन।** Inbound calls authenticated छैनन् भन्ने report, नभएको capability बारेको report हो। Inbound path नै छैन।

## उपयोगी report मा के हुन्छ

यीमध्ये कुनै कुरा अनिवार्य छैनन् र यी सबैले आदानप्रदान छोट्याउँछन्। हामी reproduce गर्न सक्ने report fix गर्न सक्छौँ; reproduce गर्न नसक्ने report कुराकानीमा परिणत हुन्छ, र समस्या पत्ता लगाउने व्यक्तिसहित सबैका लागि कुराकानी ढिलो हुन्छ।

- **यो कहाँ छ** — app र यसको version, API endpoint, वा यस website को URL। यी तीनवटाका आन्तरिक रूपमा फरक owners हुन्छन् र कुन हो भन्ने थाहा भएमा report तुरुन्तै सही ठाउँमा पुग्छ।
- **तपाईंले के गर्नुभयो, क्रमअनुसार।** त्यही कुरा देख्न अरू कसैले पालना गर्ने steps। Requests को sequence सबैभन्दा राम्रो हुन्छ; समस्याको स्वरूपको description पनि पर्याप्त हुन्छ।
- **तपाईंले के देख्नुभयो र यसको सट्टा के अपेक्षा गर्नुभएको थियो।** यही भागले finding लाई scanner को opinion बाट छुट्याउँछ।
- **Attacker ले यसबाट के गर्न सक्छ।** पूर्ण exploit chain को माग होइन — वास्तविक प्रभावबारे एउटा sentence, जसले यसलाई कति छिटो fix गर्ने भन्ने निर्णय गर्छ।
- **तपाईंलाई श्रेय चाहिन्छ कि चाहिँदैन**, र कुन नाम वा handle मा। तपाईंले जे भन्नुहुन्छ, केही पनि नभनेको अवस्थामा समेत, हामी त्यही प्रयोग गर्नेछौँ।
- **अरू मानिसको data होइन।** तपाईंको finding मा अरू कसैको records पर्छन् भने पठाउनुको सट्टा त्यसबारे description दिनुहोस्। हामीलाई त्यस्तो data चाहिँदैन र तपाईंले पनि आफूसँग राख्नु हुँदैन।

## तपाईंले पठाएपछि के हुन्छ

कुनै व्यक्तिले यसलाई पढेर पाँच कार्यदिवसभित्र, प्रायः त्योभन्दा चाँडै, reply गर्छ। पहिलो reply मा या त हामीले यसलाई reproduce गरेका छौँ र कहिलेसम्म fix हुन्छ भन्ने मोटामोटी जानकारी हुन्छ, या reproduce गर्न आवश्यक पर्ने एउटा प्रश्न सोधिन्छ, या हामीले यसलाई vulnerability नमान्नुको कारण बुझाइन्छ। हामी reports चुपचाप बन्द गर्दैनौँ, न त automated acknowledgement पठाएर त्यसपछि केही नगरी बस्छौँ।

वास्तविक प्रभाव भएको कुनै पनि कुराको fix उपलब्ध भएपछि हामी तपाईंलाई त्यसबारे बताउँछौँ। Publication अघि उचित समय पर्खन हामी अनुरोध गर्छौँ — fix र release गर्न पर्याप्त समय, जसमा mobile app का लागि हाम्रो नियन्त्रणबाहिरको app store review cycle पनि पर्छ — र सामान्यभन्दा बढी समय लाग्ने भए deadline चुपचाप बित्न नदिई इमानदारीपूर्वक बताउँछौँ।

हामी तपाईंसँग असहमत भएमा त्यसो भन्छौँ र कारण पनि बताउँछौँ, र तपाईं त्यो असहमति publish गर्न स्वतन्त्र हुनुहुन्छ। Researcher vendor सँग सहमत हुँदा मात्र काम गर्ने disclosure policy, policy होइन।

## निष्कर्ष

support@telvio.app मा विषय “Security vulnerability” राखी इमेल पठाउनुहोस्। तपाईंले के फेला पार्नुभयो र त्यसलाई कसरी पुनःउत्पादन गर्न सकिन्छ भन्ने विवरण दिनुहोस्। पाँच कार्यदिवसभित्र कुनै व्यक्तिबाट प्राप्तिको पुष्टि हुनेछ।

माथि उल्लेखित दायराभित्र गरिएको सद्भावनापूर्ण अनुसन्धानका लागि कानुनी कारबाही गरिने छैन, र तपाईंले चाहेमा तपाईंको योगदानको श्रेय दिनेछौँ। कुनै भुक्तानीसहितको बाउन्टी छैन, र त्यसको उल्टो संकेत दिनुभन्दा हामी स्पष्ट रूपमा यही भन्न रुचाउँछौँ।

यो सेवा अत्यन्त थोरै कुरा मात्र राख्ने गरी डिजाइन गरिएको छ: कुनै खाता, पासवर्ड, भुक्तानी विवरण, कल रेकर्डिङ, सम्पर्क सूची वा स्थानसम्बन्धी जानकारी छैन। अधिकांश काम गर्ने सुरक्षा नियन्त्रण यही हो।

## बारम्बार सोधिने प्रश्नहरू

Telvio लाई सुरक्षा कमजोरीबारे कसरी जानकारी गराउने?

Security vulnerability विषय राखेर support@telvio.app मा इमेल पठाउनुहोस्। तपाईंले के फेला पार्नुभयो, कहाँ फेला पार्नुभयो र त्यसलाई पुनः देखाउने चरणहरू उल्लेख गर्नुहोस्। हामी पाँच कार्यदिवसभित्र जानकारी पाएको पुष्टि गर्ने लक्ष्य राख्छौँ र कुनै समस्या सार्वजनिक गर्नुअघि त्यसलाई समाधान गर्न उचित समय दिन अनुरोध गर्छौँ।

के Telvio को bug bounty programme छ?

छैन। भुक्तानीसहितको पुरस्कार programme छैन। हामी कुनै व्यक्तिबाट प्राप्तिको पुष्टि, इमानदार मूल्याङ्कन, तपाईंले चाहेमा श्रेय, र तोकिएको दायराभित्र सद्भावपूर्वक गरिएको अनुसन्धानका लागि कानुनी कारबाही नगर्ने प्रतिबद्धता गर्छौँ।

के Telvio ले सुरक्षा अनुसन्धानकर्ताविरुद्ध कानुनी कारबाही गर्नेछ?

प्रकाशित दायराभित्र सद्भावपूर्वक गरिएको अनुसन्धानका लागि गर्दैनौँ। यो नीति पालना गर्ने र अरू मानिसको data मा पहुँच नगर्ने वा service को गुणस्तर नघटाउने अनुसन्धानकर्ताविरुद्ध हामी दाबी अघि बढाउने वा त्यसलाई समर्थन गर्नेछैनौँ।

Telvio का systems मा breach भएमा के कुरा खुल्न सक्छ?

Credit balance राख्ने एउटा anonymous installation identifier, फोन बिलमा हुने किसिमका call records, purchase receipt identifiers र IP addresses लगायतका technical data खुल्न सक्छन्। खुलासा हुनसक्ने अवस्थामा नाम, email addresses, phone numbers, passwords, payment details, call recordings, contact lists वा location data मध्ये कुनै पनि छैन।

के Telvio का calls encrypted हुन्छन्?

Call signalling र audio transit मा encrypted हुन्छन्, app र servers बीचको सबै traffic पनि त्यस्तै हुन्छ। कुनै call को सामान्य telephone number सम्म पुग्ने अन्तिम भाग traditional telephone network मार्फत जान्छ, जुन app को नियन्त्रणबाहिर हुन्छ र end to end encrypted हुँदैन — real phone मा dial गर्ने हरेक service का लागि यही कुरा लागू हुन्छ।

Telvio मा password किन छैन?

किनभने यसमा account नै छैन। केही पनि register गरिँदैन, त्यसैले सुरक्षित गर्नुपर्ने कुनै credential हुँदैन र credential stuffing ले आक्रमण गर्न सक्ने पनि केही हुँदैन। Installation identifier ले credit balance का लागि bearer token को काम गर्छ, त्यसैले device compromise लाई दायराबाहिर मानिन्छ।

कुनै vulnerability सार्वजनिक गर्नुअघि कति समय पर्खनुपर्छ?

Fix तयार गरेर release गर्न पर्याप्त समय पर्खनुहोस्। Mobile app का लागि यसमा हामीले नियन्त्रण गर्न नसक्ने app store review cycle पनि पर्छ। पहिलो जवाफमै हामीले अपेक्षा गरेको timeline बताउनेछौँ र त्यसमा ढिलाइ भएमा समयसीमा कुनै जानकारीबिना बित्न दिनुको सट्टा इमानदारीपूर्वक बताउनेछौँ।

रिपोर्ट गरिएको समस्या fix भएपछि Telvio ले मलाई बताउनेछ?

हो। हामी reports लाई चुपचाप बन्द गर्दैनौँ। पहिलो जवाफमा या त समस्या reproduce गरेको र मोटामोटी timeline सहित पुष्टि गर्छौँ, या त्यसलाई reproduce गर्न आवश्यक एउटा प्रश्न सोध्छौँ, या हामीले त्यसलाई vulnerability किन नमान्ने हो भनेर स्पष्ट गर्छौँ।

## सम्बन्धित कागजातहरू

- [Telvio केका लागि प्रयोग गर्न हुँदैन](https://telvio.app/ne/legal/acceptable-use/)
- [पहुँचयोग्यता](https://telvio.app/ne/legal/accessibility/)
- [Telvio बाट आपत्कालीन सेवामा फोन गर्न सकिँदैन](https://telvio.app/ne/legal/emergency-calls/)
- [कलको रिपोर्ट गर्नुहोस्](https://telvio.app/ne/legal/report-a-call/)

---

HTML version: https://telvio.app/ne/legal/security/
Structured data for this site: https://telvio.app/api/v1/openapi.json · https://telvio.app/llms.txt
Free to quote and reuse with a link back to the source URL above (CC BY 4.0).