Approval notification previews: action details को सुरक्षित रखें

Approval notification previews को उस action की तरह ही threat modeling की ज़रूरत होती है जिसकी वे सूचना देते हैं। Code deploy करने, customer API call करने या remote command चलाने का अनुरोध, किसी के Approve दबाने से पहले ही संवेदनशील तथ्य उजागर कर सकता है। अगर वह तथ्य locked phone, shared desktop, conference-room display या mirrored wearable पर दिख जाए, तो approval system operation का एक हिस्सा पहले ही बता चुका है।

आमतौर पर गलती यह होती है कि notification को harmless plumbing समझ लिया जाता है। यह अपना audience, retention behavior और access controls रखने वाला एक output channel है। इसे protected decision surface में प्रवेश करने के लिए जानबूझकर सीमित prompt की तरह design करें। इसे approval screen का छोटा संस्करण न समझें।

Locked screen एक exposure boundary है

Locked screen सहकर्मियों, परिवार के सदस्यों, आगंतुकों, camera systems और डेस्क के पास से गुजरने वाले किसी भी व्यक्ति को दिख सकती है। Owner पास में हो सकता है, लेकिन पास होना authenticated होने के बराबर नहीं है। यह अंतर तब साफ होता है जब approval alert production hostname, customer name, incident label या shell command की पहली पंक्ति दिखा देता है।

कई teams notification को low sensitivity मानती हैं क्योंकि उसमें कोई secret value नहीं होती। यह जांच बहुत सीमित है। billing-prod.internal जैसा endpoint, /customers/28471/refund जैसा path या Rotate compromised access token जैसा message systems, relationships और operational state की जानकारी दे सकता है। ऐसे fragments इकट्ठा करने वाले attacker को बढ़त पाने के लिए bearer token की ज़रूरत नहीं होती।

सोचें कि observer हर field से क्या अनुमान लगा सकता है:

• Destination से customer, region, product या production service की पहचान हो सकती है।
• Operation बता सकता है कि account बदला जा रहा है, refund लंबित है या incident चल रहा है।
• Agent identity से पता चल सकता है कि developer किस repository या task पर काम कर रहा है।
• Reason field में अक्सर copied ticket text, user input या incident notes आ जाते हैं।
• Result से पता चल सकता है कि user के निर्णय लेने से पहले action ने कौन-सा data हासिल किया।

Lock screen पहली exposure boundary भर है। Operating systems device unlock होने के बाद भी वही text notification center में दिखा सकते हैं। Desktop notification किसी व्यक्ति के shared workstation छोड़ने के बाद भी history में रह सकती है। Watch उसे mirror कर सकती है। Screen recording, remote support software और video call उसे capture कर सकते हैं। Preview को इन सभी contexts में सुरक्षित रहना चाहिए।

Apple के Platform Security documentation में lock screen को protected device state बताया गया है और protected data तक पहुंच के केंद्र में user authentication को रखा गया है। यह model अपने आप notification text को protected data नहीं बना देता। Apps को तय करना होता है कि notification service को क्या भेजना है और व्यक्ति के authenticate करने से पहले क्या render करना है। Operating system की privacy setting को एक layer मानें, sensitive content को message में रखने की अनुमति नहीं।

Alert को ध्यान मांगना चाहिए, request उजागर नहीं करनी चाहिए

Safe preview किसी व्यक्ति को बताता है कि किसी action की review ज़रूरी है और उसे प्राथमिकता देने के लिए पर्याप्त urgency देता है। वह action को दोहराता नहीं है। यही वह स्पष्ट अंतर है जिसे teams अक्सर धुंधला कर देती हैं: notification context, approval context नहीं है।

Approval context operator को informed decision लेने देता है। उसमें exact destination, operation, credential scope, agent process, arguments, expected effect और expiry की ज़रूरत हो सकती है। Notification context का उद्देश्य सही व्यक्ति को उस protected view पर वापस लाना है। उसे इससे बहुत कम जानकारी चाहिए।

किसी सामान्य action के लिए locked-screen preview ऐसा हो सकता है:

Action approval needed
A development agent requests access to a protected service.
Expires in 4 minutes. Open the app to review.

यह text urgency और broad scope बताता है। यह नहीं बताता कि service payroll, source code, payments या internal incident से जुड़ी है। इसमें URL, method, command, branch, query या customer identity उजागर नहीं होती।

इसकी तुलना real systems में दिखने वाले message से करें:

Approve POST https://payments.example.internal/v1/refunds/28471
Agent requests bearer token for customer refund. Reason: duplicate charge.

दूसरा alert bearer token तो नहीं दिखाता, फिर भी बहुत अधिक जानकारी उजागर करता है। इससे sensitive service, action, customer-linked object और financial event की पहचान हो जाती है। Preview पढ़ सकने वाले हर व्यक्ति ने ऐसी जानकारी जान ली है जिसे जानने का उसे अधिकार नहीं था।

Preview copy के लिए छोटी vocabulary रखें। «Approval needed», «access request waiting» और «review required» अक्सर पर्याप्त होते हैं। अगर इससे यह तय होता है कि व्यक्ति को कितनी जल्दी प्रतिक्रिया देनी चाहिए, तो coarse risk label जोड़ें: «external action», «production access» या «sensitive read»। Label इतना specific न हो कि उसका उद्देश्य ही खत्म हो जाए। «Production database export» coarse label नहीं है।

Authenticated screen पर इसका उलटा होना चाहिए। Request इतनी concrete हो कि operator सुरक्षित रूप से reject कर सके या पूरी जानकारी के साथ approve कर सके। Privacy के नाम पर वहां detail छिपाने से blind approval पैदा होता है, जो अलग तरह की failure है।

Notification app से बाहर जाने से पहले redaction होनी चाहिए

Notification payload का अपना schema होना चाहिए। Full approval record को आखिरी क्षण में काट-छांटकर न बनाएं और string replacement list पर निर्भर न रहें। Teams यह shortcut इसलिए लेती हैं क्योंकि full record पहले से मौजूद होता है और उसे render करना आसान लगता है। लेकिन नया field जुड़ने, URL के subtitle में चले जाने या reason string में copied sensitive data आने पर यह तरीका fail हो जाता है।

Action request से दो explicit projections बनाएं। एक authenticated approval view को feed करे और दूसरा preview को। Preview model में raw URLs, headers, command arguments, response snippets, secret names या free-form reasons के fields होने ही नहीं चाहिए।

यह pseudocode इसका ढांचा दिखाता है:

type ApprovalRecord {
  requestId
  agentAuthority
  destination
  operation
  arguments
  credentialReference
  userReason
  expiry
  riskClass
}

type NotificationPreview {
  requestId
  title
  body
  expiryText
  riskClass
}

function makePreview(record):
  return NotificationPreview(
    requestId = opaqueId(record.requestId),
    title = "Action approval needed",
    body = previewBody(record.riskClass),
    expiryText = formatExpiry(record.expiry),
    riskClass = record.riskClass
  )

महत्वपूर्ण बात wording नहीं, data का one-way shape है। NotificationPreview में destination गलती से शामिल नहीं हो सकता, क्योंकि वह field मौजूद ही नहीं है। Reviewer उस boundary को inspect कर सकता है। Test यह reject कर सकता है कि कोई नया preview field unbounded string ले रहा है।

Raw reason text को sanitizer से गुजारकर काम पूरा न मानें। Reasons में अक्सर issue titles, pasted commands, email addresses, account identifiers और internal names आ जाते हैं। Redaction patterns उन formats को नहीं पकड़ पाते जिनकी किसी ने कल्पना नहीं की थी। Enum से लिया गया fixed phrase, साफ किए गए user-controlled sentence से अधिक सुरक्षित है।

Opaque identifiers पर भी ध्यान दें। APR-10482 जैसा approval ID harmless लग सकता है, लेकिन predictable number observer को ऐसा record दे सकता है जिसे वह visible ticket या बाद की बातचीत से जोड़ सके। ऐसा identifier इस्तेमाल करें जिसका कोई business meaning न हो और जो authorization token की तरह काम न कर सके। बेहतर है कि support workflows में सचमुच ज़रूरत न हो तो इसे preview से हटा दें।

Complete request को encrypted application store या किसी दूसरे authenticated record में रखें, notification body में नहीं। Notification framework text को alert के दिखाई देने से कहीं अधिक समय तक बचाकर रख सकता है। अगर कोई दूसरा subsystem उसकी copy रखता है, तो आपकी data retention choices लागू नहीं होंगी।

Device privacy settings मदद करती हैं, लेकिन design का आधार नहीं बन सकतीं

Operating systems आमतौर पर locked device पर notification previews छिपाने देते हैं। यह setting उपयोगी है, लेकिन approval product यह मानकर नहीं चल सकता कि यह हर device पर enabled, समझी हुई और एक जैसी लागू है।

कुछ लोगों को messages को triage करने के लिए visible previews चाहिए। कुछ organizations settings manage करती हैं। कुछ devices में lock code नहीं होता। कुछ users desktop पर alerts पढ़ते हैं, जहां screen unlocked होती है और कोई colleague उनके पीछे खड़ा हो सकता है। Sensitive text भेजकर यह कहना कि «users previews बंद कर सकते हैं», system setup के सबसे अविश्वसनीय क्षण पर security decision छोड़ देना है।

तीन conditions के लिए build करें:

1. Operating system locked display पर full notification दिखाता है।
2. Operating system body छिपाता है, लेकिन title या app name दिखाता है।
3. Display unlocked है, लेकिन दूसरे लोग उसे देख सकते हैं।

पहली condition आपका payload तय करती है। अगर text वहां सुरक्षित है, तो बाकी दो conditions को समझना आसान हो जाता है। अगर वहां text unsafe है, तो user setting केवल flaw को intermittent बनाती है।

Device state से बहुत अधिक अनुमान न लगाएं। Application को अपनी window unlocked होने का पता हो सकता है, लेकिन notification कौन देख रहा है, यह अक्सर पता नहीं होता। Locked-state signal भरोसेमंद होने पर भी projector, external monitor या screen sharing का समाधान नहीं होता। Safe preview authentication के बाद भी सुरक्षित रहना चाहिए, क्योंकि physical viewing conditions app के नियंत्रण से बाहर हैं।

एक अपवाद ध्यान देने योग्य है: application window के अंदर local, authenticated notification approval view जितनी detail दिखा सकती है, क्योंकि app उस window का access नियंत्रित करती है। यह system notification नहीं है। Protected in-app inbox को lock-screen banner से केवल इसलिए न मिलाएं कि दोनों के नाम में notification शब्द है।

Notifications में approval buttons decision boundary को कमजोर करते हैं

Notification में Approve button efficient लगता है। लेकिन यह accidental confirmation, coerced approval और context खोने का आसान रास्ता भी है। व्यक्ति truncated banner देखता है, परिचित button दबाता है और actual target या effect देखे बिना action authorize कर देता है।

Notification में केवल वही actions होने चाहिए जो decision boundary को बनाए रखें। «Open for review» सुरक्षित है, क्योंकि यह operator को authenticated app तक ले जाता है। «Dismiss» भी सुरक्षित है, अगर dismiss करने से request deny, approve या चुपचाप extend न होती हो। Meaningful actions के लिए «Approve» button सुरक्षित नहीं है, भले ही operating system उसे चलाने से पहले device unlock मांगता हो।

Authentication और informed consent अलग checks हैं। Device authentication यह साबित करता है कि ऐसा व्यक्ति जिसने device unlock कर सकता है, उसने button दबाया। यह साबित नहीं करता कि उसने पूरी request देखी या उसका आकलन करने के लिए समय लिया। Approval screen को decision को request details से bind करना चाहिए, यह दिखाना चाहिए कि alert आने के बाद कुछ बदला है या नहीं, और sensitive action के लिए fresh confirmation मांगनी चाहिए।

Agent requests में यह और महत्वपूर्ण है। कोई agent कई ऐसे actions बना सकता है जो दूर से एक जैसे दिखते हों। «SSH access request» जैसा notification title read-only status check और destructive command के बीच अंतर नहीं बताता। Operator action जारी करने से पहले protected view में concrete intent देख सके, यह ज़रूरी है।

Sallyport का authorization flow actual action decision को authenticated app के अंदर रखता है। वह operating-system notification को agent access के remote control में नहीं बदलता। यह one-tap approval से कम आकर्षक लग सकता है, लेकिन consequential requests में बेहतर टिकता है।

Notification में «remember this choice» control भी न दें। Persistent permission changes के लिए अपना explicit surface, स्पष्ट scope और उन्हें देखने या revoke करने का तरीका होना चाहिए। Lock screen पर नींद में किया गया tap स्थायी authority बनाने के लिए खराब जगह है।

Risk labels consequences बताएं, assets के नाम नहीं

Vague alert लोगों को हर notification खोलने की आदत डालता है। बहुत detailed alert protected asset को leak कर देता है। Risk labels इस तनाव का कुछ समाधान देते हैं, जब वे resource के बजाय consequence category बताते हैं।

Categories इस आधार पर बनाएं कि action क्या कर सकता है। कोई action protected information पढ़ सकता है, internal service बदल सकता है, external request भेज सकता है या ऐसा operation कर सकता है जिसे आसानी से reverse न किया जा सके। ये categories reviewer को अपना काम रोकने का कारण देती हैं, बिना database, customer या hostname उजागर किए।

ऐसे labels से बचें जो access sensitivity और operational urgency को मिला दें। «High priority» व्यक्ति को approval के effect के बारे में बहुत कम बताता है। «Production write» अधिक जानकारी देता है, लेकिन यह भी बता सकता है कि production system शामिल है। यह wording सुरक्षित है या नहीं, यह environment पर निर्भर करता है। Personal device पर अकेले काम करने वाला व्यक्ति इसे स्वीकार कर सकता है, लेकिन shared support desk को broader label इस्तेमाल करना चाहिए।

Vocabulary को लिखित रूप में define करें और notification rendering से पहले उसे action से जोड़ें। अगर developers title text खुद बना सकते हैं, तो दुनिया का सबसे सावधान schema भी आपकी रक्षा नहीं करेगा। एक सरल review rule हो सकता है: agent, user, URL, command, request body या remote response से आने वाली कोई भी string preview में forbidden है।

Practical mapping कुछ ऐसा दिख सकता है:

यह table writers और engineers के लिए policy है, यह वादा नहीं कि हर action चार boxes में ठीक से fit हो जाएगा। जब action के mixed effects हों, तो अधिक गंभीर category चुनें। Attention थोड़ा जल्दी मांगने वाली notification एक क्षण का खर्च है। «Access request» के पीछे external transfer छिपाने वाली notification खराब decision कराती है।

Notification history और mirrored devices की अलग review चाहिए

Teams अक्सर पहला banner test करके रुक जाती हैं। पूरी exposure path में retained notifications, notification summaries, wearable mirrors, desktop relays और वही account alerts पाने वाला हर managed device शामिल है।

एक real request से शुरुआत करें जिसमें जानबूझकर पहचानने योग्य test data हो: fake customer name, fake internal host, fake email address और fake command argument। Privacy testing के लिए actual production values का इस्तेमाल न करें। Request trigger करें और फिर हर उस जगह को inspect करें जहां text दिख सकता है।

Release से पहले यह test sequence चलाएं:

1. Primary device को lock करें और approval request trigger करें।
2. Banner, lock-screen list और unlock करने के बाद notification center जांचें।
3. Configured notification relay या wearable mirror enable करें और उसकी history देखें।
4. Team द्वारा इस्तेमाल किए जाने वाले remote-support और screen-sharing paths से screen capture करें।
5. Request expire या resolve करें, फिर देखें कि stale text दिखाई देता रहता है या नहीं।

हर जगह rendered title और body को ठीक-ठीक record करें। Successful test का अर्थ «मेरे phone पर preview hidden है» नहीं है। इसका अर्थ है «authenticated app के बाहर कोई test marker दिखाई नहीं दिया»। इससे localization bugs भी पकड़े जाते हैं। Safe English template translated string लंबी होने पर unsafe बन सकती है और internal identifier visible line में आ सकता है।

Grouped notifications पर खास ध्यान दें। System सबसे recent message, count या कई alerts से बना summary दिखा सकता है। अगर हर individual preview safe है, तो group भी safe होना चाहिए। अगर grouping code «three refund requests» जैसा action name इस्तेमाल करता है, तो उसने side path से sensitive detail फिर ला दी है।

Notification persistence incident response को भी बदलती है। Agent session revoke करने से future requests रुकती हैं, लेकिन user की notification history या mirrored device में पहले से copied text वापस नहीं लिया जा सकता। इसीलिए preview minimization authorization और audit review से पहले होनी चाहिए, incident के बाद नहीं।

Audit records में detail चाहिए, previews में संयम

Security teams कभी-कभी previews को vague इसलिए बनाती हैं क्योंकि उन्होंने audit records भी vague रखे हैं। उन्हें डर होता है कि detailed records leak हो जाएंगे। इससे दो अलग systems और उनके अलग audiences आपस में मिल जाते हैं।

Audit record इतना complete होना चाहिए कि authorization decision को फिर से बनाया जा सके: किस agent process ने action शुरू किया, वह किस authority के तहत चला, destination, operation, time, decision और result क्या थे। Sensitive values को फिर भी सावधानी से संभालना होगा, लेकिन investigators को factual detail चाहिए। Preview में यह सब नहीं होना चाहिए, जब तक व्यक्ति app में authenticate न कर ले।

Failure के समय यह अंतर महत्वपूर्ण होता है। मान लें कोई agent remote command का अनुरोध करता है। Alert में «Approval needed» दिखता है और reviewer app खोलता है। Protected view command, host, session identity और expiry दिखाता है। Reviewer उसे reject कर देता है। बाद में engineer जांच करता है कि ऐसा क्यों हुआ और उसे संबंधित record चाहिए। Audit trail इस सवाल का जवाब दे सकता है, बिना original notification में command को हर display surface तक ले जाए।

Sallyport अपने session और activity journals को notification handling से अलग रखता है। दोनों journals encrypted, hash-chained audit log से project होते हैं। इससे operator actions inspect कर सकता है और lock-screen previews को evidence का विकल्प बनाए बिना audit chain को offline verify कर सकता है।

Notification में audit hashes, record excerpts या raw correlation IDs न रखें। Protected interface और investigation tooling में ये उपयोगी हैं। Public surface पर observers इन्हें इकट्ठा करके आपस में जोड़ सकते हैं।

Underlying decision expire होने पर notification भी expire होनी चाहिए और protected record में expiry साफ लिखी होनी चाहिए। अगर कोई व्यक्ति पुराना alert खोलता है, तो app को current request state fetch करनी चाहिए। Cached notification body को कभी यह विश्वास न दिलाने दें कि व्यक्ति उसी request को approve कर रहा है जो पांच मिनट पहले मौजूद थी।

Preview rules को tests के रूप में लिखें, फिर उन्हें तोड़ने की कोशिश करें

«Sensitive content से बचें» जैसी prose guideline delivery pressure में fail हो जाएगी। इसे notification builder के साथ चलने वाली assertions और reviewers के पढ़ने योग्य test cases में बदलें।

सबसे उपयोगी test words की brittle denylist नहीं, बल्कि data origins की denylist है। ऐसे किसी भी preview field को reject करें जो URL, host, command text, header, body, credential label, free-form reason, remote response, email address या account identifier से आया हो। फिर केवल fixed templates और bounded category values की छोटी सूची allow करें।

Compact test fixture ऐसा दिख सकता है:

record.destination = "https://claims-prod.internal/cases/FAKE-784"
record.arguments = "--account [email protected] --export"
record.userReason = "Customer Northstar reports a disputed claim"
record.riskClass = EXTERNAL_ACTION

preview = makePreview(record)

assert preview.title == "Action approval needed"
assert preview.body == "An external action requires review."
assert preview doesNotContain "claims"
assert preview doesNotContain "FAKE-784"
assert preview doesNotContain "fake.person"
assert preview doesNotContain "Northstar"

Positive assertions negative assertions जितनी ही महत्वपूर्ण हैं। वे बाद में होने वाले ऐसे edit को रोकती हैं जिसमें safe fixed message की जगह vague blank alert आ जाए और users उसे dismiss करना सीख लें। Expiry wording, localization, grouped alerts और accessibility rendering को भी test करें। Screen readers ऐसा content पढ़ सकते हैं जिसे visual truncation छिपा देती है, इसलिए accessibility output को भी उसी constrained preview model का उपयोग करना चाहिए।

अंत में किसी ऐसे व्यक्ति से previews पढ़वाएं जिसने feature नहीं लिखा है और उससे operational clues खोजने को कहें। वह वह सब देख लेगा जिसे author सामान्य मानने लगता है: project codename, familiar environment label या internal service nickname। अगर कोई informed outsider protected action का अनुमान लगा सकता है, तो notification में बहुत अधिक जानकारी है।

Default preview को ऐसा least specific message रखें जो समय पर human response पाने के लिए फिर भी पर्याप्त हो। Real approval के लिए ज़रूरी evidence authentication के पीछे रखें और हर shortcut को उसी evidence तक वापस ले जाएं। इससे एक tap अधिक लग सकता है, लेकिन हर locked screen को quiet disclosure channel बनने से रोका जा सकता है।