Signal — चैनल भरोसा
धोखेबाज़ WhatsApp और Telegram पर बैंक, कुरियर या स्टोर बनकर आते हैं। Signal सेकंडों में बताता है कि संदेश आधिकारिक चैनल से है या नहीं।
तकनीकी हक़ीक़त: असममित रणनीतियाँ
WhatsApp Cloud API: जब कोई संदेश किसी बिज़नेस नंबर पर फ़ॉरवर्ड होता है, तो webhook में सिर्फ़ फ़ॉरवर्ड करने वाले का नंबर आता है, context.forwarded और सामग्री — मूल भेजने वाला कभी नहीं. फ़ॉरवर्ड किए गए WhatsApp की जाँच सिर्फ़ सामग्री और लिंक का विश्लेषण कर सकती है; चैनल का श्रेय भेजने वाले पक्ष के दावों से आता है।
Telegram Bot API: forward_origin में मूल भेजने वाला शामिल होता है (गोपनीयता की स्थिति को छोड़कर → MessageOriginHiddenUser)। तीसरे पक्ष का सत्यापन पाने वाले की ओर से असली श्रेय और एक नेटिव बैज संभव बनाता है।
Brand Claim Boundary (आधारशिला)
हर ब्रांड अपनी आधिकारिक परिधि: घोषित करता है और उस पर हस्ताक्षर करता है: वही डोमेन, WhatsApp नंबर, Telegram चैनल और छोटे लिंक जो वह इस्तेमाल करता है। इंजन एक हस्ताक्षरित allowlist के विरुद्ध पूछता है कि वह चीज़ परिधि के भीतर है या बाहर । परिधि वही प्रविष्टि है जो यहाँ प्रकाशित होती है: Official Channel Log ।
स्वर्णिम नियम: रजिस्ट्री के तथ्य, मंशा नहीं
SecureStamp कभी मंशा का दावा नहीं करता। verdict तथ्यों का एक बंद समुच्चय है:
PERTENECEवह चैनल ब्रांड की घोषित और हस्ताक्षरित परिधि के भीतर है।NO_PERTENECEवह चैनल परिधि के बाहर है, वैकल्पिक रूप से देखे गए संकेतों के साथ।COUNTERSTAMPब्रांड ने उस चैनल के विरुद्ध पुष्ट counter-stamp जारी किया है।DISPUTEDमामला विवाद में है और उचित प्रक्रिया से गुज़र रहा है।UNKNOWNब्रांड ने SecureStamp में कोई परिधि घोषित नहीं की है।
ये 5 स्थितियाँ L1–L5 से मेल खाती हैं। मज़बूत L1 स्थिति के लिए ब्रांड-हस्ताक्षरित counter-stamp का इस स्थिति में होना ज़रूरी है: confirmed; एल्गोरिद्मिक मामला कभी मंशा नहीं थोपता।
दो लॉग (TLP मॉडल) + पारदर्शिता
Official Channel Log — TLP:CLEAR: ब्रांड के अपने चैनलों के बारे में पहले पक्ष के कथन। सार्वजनिक खोज, इतिहास और निरस्तीकरण।
Abuse Transparency Log — TLP:AMBER: तीसरे पक्ष के कथन। सार्वजनिक सिर्फ़ क्रिप्टोग्राफ़िक प्रतिबद्धताएँ और समुच्चय गणनाएँ होती हैं; विवरण प्रतिबंधित रहता है। कोई ठोस मामला सार्वजनिक ट्री हेड के विरुद्ध Merkle समावेशन प्रमाण से सिद्ध होता है।
counter-stamp का जीवनचक्र
यह मनमानी ब्लैकलिस्ट नहीं है: इसमें स्थितियाँ और उचित प्रक्रिया है।
L1 सिर्फ़ confirmed से सक्षम होता है; disputedचैनल के स्वामी के लिए विवाद का रास्ता है।
Trust Receipt (ES256, साझा JWKS)
हर सत्यापन एक Trust Receipt: पैदा करता है: ES256 से हस्ताक्षरित, टाइमस्टैम्प सहित, जिसकी idSSF-EV-…है और जिसे कोई भी दोबारा जाँच सकता है। यह SecureStamp की नोटरी कुंजी दोबारा इस्तेमाल करता है, इसलिए कोई तीसरा पक्ष उसी/.well-known/jwks.json से receipt जाँचता है जो ईमेल स्टैम्प के लिए इस्तेमाल होती है। हेडर typ: SSCT-receipt.
API
| POST | /api/signal/verify | इंजन चलाता है और एक रजिस्ट्री तथ्य + हस्ताक्षरित Trust Receipt लौटाता है। |
| GET | /api/signal/receipts/{id} | सार्वजनिक JWKS के विरुद्ध किसी Trust Receipt को दोबारा जाँचता है। |
| POST | /api/signal/brands | ब्रांड परिधि घोषित/अद्यतन करता है। |
| POST | /api/signal/counter-stamps | एक counter-stamp खोलता है। |
| PATCH | /api/signal/counter-stamps | counter-stamp की स्थिति बदलता है। |
Disclaimer: SecureStamp यह प्रमाणित करता है कि कोई चैनल किसी ब्रांड की घोषित आधिकारिक परिधि में आता है, और receipt की अखंडता। यह भेजने वाले की मंशा या संदेश की सामग्री की सच्चाई प्रमाणित नहीं करता।