ਪਰਿਭਾਸ਼ਾ
Unknown ਵਰਗੀਕਰਨ ਉਹ ਨਤੀਜਾ ਹੈ ਜੋ actor intelligence system ਤਦ ਵਾਪਸ ਕਰਦੀ ਹੈ ਜਦੋਂ ਕਿਸੇ interaction ਲਈ ਉਪਲਬਧ ਸਬੂਤ ਭਰੋਸੇਯੋਗ ਨਿਰਧਾਰਣ ਨੂੰ ਸਮਰਥਨ ਨਹੀਂ ਦਿੰਦੇ। ਇਹ ਸਹੀ ਤੌਰ 'ਤੇ ਇਹ ਕਹਿੰਦਾ ਹੈ: ਅਸੀਂ ਜੋ ਵੇਖਿਆ ਹੈ ਉਸ ਤੋਂ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਇਹ ਕੋਈ ਵਿਅਕਤੀ ਹੈ, AI ਨਾਲ ਕੰਮ ਕਰਦਾ ਵਿਅਕਤੀ ਹੈ ਜਾਂ agent ਹੈ।
Unknown, Proof of Actor ਵਿੱਚ ਚਾਰ ਵਰਗਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, Human, Human + AI ਅਤੇ Agent ਦੇ ਨਾਲ। ਇਹ ਪਹਿਲੀ ਕਤਾਰ ਦਾ ਨਤੀਜਾ ਹੈ, ਨਾ ਕਿ error state ਅਤੇ ਨਾ ਹੀ "ਸ਼ਾਇਦ bot" ਕਹਿਣ ਦਾ ਨਰਮ ਤਰੀਕਾ। AI traffic ਨੂੰ ਵਰਗੀਕ੍ਰਿਤ ਕਰਦੇ ਸਮੇਂ Unknown ਕਿਉਂ ਵੈਧ ਨਤੀਜਾ ਹੈ ਬਾਰੇ ਸਾਡੀ post ਪੂਰਾ ਪੱਖ ਰੱਖਦੀ ਹੈ।
Unknown ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
ਉਹ classification systems ਜੋ ਹਮੇਸ਼ਾ ਇੱਕ ਉੱਤਰ ਚੁਣਨ ਲਈ ਮਜਬੂਰ ਹੁੰਦੀਆਂ ਹਨ, ਆਖ਼ਰਕਾਰ ਭਰੋਸੇ ਨਾਲ ਅਟਕਲਾਂ ਲਗਾਉਂਦੀਆਂ ਹਨ। ਉਹ ਅਟਕਲਾਂ data ਵਾਂਗ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ, dashboards ਅਤੇ policies ਵਿੱਚ ਚਲੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਚੁੱਪਚਾਪ ਨੁਕਸਾਨ ਕਰਦੀਆਂ ਹਨ: ਇੱਕ legitimate customer ਨੂੰ challenge ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਇੱਕ automated client ਨੂੰ sensitive route ਤੇ ਵਿਅਕਤੀ ਵਾਂਗ treat ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
Unknown ਰਿਪੋਰਟ ਕਰਨ ਨਾਲ teams ਨੂੰ ਤਿੰਨ ਚੀਜ਼ਾਂ ਮਿਲਦੀਆਂ ਹਨ:
- ਇਮਾਨਦਾਰ coverage. Unknown ਨਤੀਜਿਆਂ ਦਾ ਹਿੱਸਾ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ integration ਵਿੱਚ ਕਿੱਥੇ visibility ਹੈ ਅਤੇ ਕਿੱਥੇ ਨਹੀਂ।
- ਸੁਰੱਖਿਅਤ policies. ਇੱਕ policy ਹਰ route ਲਈ ਸਹੀ ਤੌਰ 'ਤੇ define ਕਰ ਸਕਦੀ ਹੈ ਕਿ Unknown ਦਾ ਕੀ ਅਰਥ ਹੈ, hidden guess ਨੂੰ inherit ਕਰਨ ਦੀ ਬਜਾਏ।
- ਸੁਧਾਰ ਦਾ ਰਸਤਾ. ਜੇ ਕਿਸੇ route ਤੇ Unknown rate ਉੱਚਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉੱਥੇ ਇੱਕ ਬਿਹਤਰ signal source ਜੋੜ ਸਕਦੇ ਹੋ, ਜਿਵੇਂ browser integration ਜਾਂ signed agent requests ਲਈ support।
Unknown ਦੇ ਆਮ ਕਾਰਨ
- ਉਸ route ਤੇ ਕੋਈ supported integration ਨਹੀਂ ਚੱਲਦੀ, ਉਦਾਹਰਨ ਵਜੋਂ browser collector ਮੌਜੂਦ ਨਹੀਂ ਹੈ।
- client JavaScript ਨਹੀਂ ਚਲਾਉਂਦਾ ਅਤੇ ਕੋਈ identity evidence ਨਹੀਂ ਭੇਜਦਾ।
- interaction signals ਬਹੁਤ ਘੱਟ ਦੇਖੇ ਗਏ, ਉਦਾਹਰਨ ਵਜੋਂ ਬਹੁਤ ਛੋਟੀ session।
- ਇੱਕ request signature ਬਿਨਾਂ ਅਤੇ ਇੱਕ generic ਜਾਂ ਗੁੰਮ client description ਨਾਲ ਆਈ।
- ਮੌਜੂਦ evidence ਆਪਸ ਵਿੱਚ ਟਕਰਾਉਂਦੀ ਹੈ, ਅਤੇ ਉਸਦਾ ਕੋਈ ਹਿੱਸਾ ਫੈਸਲਾ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਮਜ਼ਬੂਤ ਨਹੀਂ ਹੈ।
Applications ਨੂੰ Unknown ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਣਾ ਚਾਹੀਦਾ ਹੈ
Unknown ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ fallback ਨਾਲ map ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਸਨੂੰ application owner ਹਰ route ਲਈ ਚੁਣਦਾ ਹੈ:
- Public, ਘੱਟ-ਖਤਰੇ ਵਾਲੇ pages: ਬਿਨਾਂ ਕਿਸੇ ਵਾਧੂ friction ਦੇ allow ਕਰੋ।
- Read-only APIs: standard rate limits ਨਾਲ allow ਕਰੋ।
- Account ਬਦਲਾਵ ਅਤੇ ਹੋਰ ਉੱਚ-ਅਸਰ ਵਾਲੀਆਂ actions: application ਦੀਆਂ ਮੌਜੂਦਾ checks ਜਿਵੇਂ re-authentication ਨੂੰ ਬਰਕਰਾਰ ਰੱਖੋ, ਅਤੇ Unknown ਨਤੀਜੇ ਦੇ ਆਧਾਰ ਤੇ ਖੁਦ ਕੁਝ ਨਾ ਨਿਰਧਾਰਿਤ ਕਰੋ।
ਇਹੀ ਸੋਚ timeouts ਅਤੇ ਗੁੰਮ telemetry ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ। ਕੋਈ route fails open or fails closed ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਪਹਿਲਾਂ ਤੋਂ ਲਿਆ ਗਿਆ ਜਾਨ-ਬੁੱਝ ਕੇ ਫੈਸਲਾ ਹੁੰਦਾ ਹੈ, ਕੋਈ ਹਾਦਸਾ ਨਹੀਂ।
ਆਮ ਗਲਤ ਧਾਰਣਾਵਾਂ
"Unknown ਦਾ ਮਤਲਬ suspicious ਹੈ." ਇਸਦਾ ਮਤਲਬ ਹੈ ਸਬੂਤ ਅਪਰਿਆਪਤ ਹਨ। ਕਈ ਬਿਲਕੁਲ ਆਮ visitors Unknown ਨਤੀਜੇ ਪੈਦਾ ਕਰਦੇ ਹਨ।
"Unknown ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ Human ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ." ਕਦੇ ਨਹੀਂ। Unknown ਨੂੰ Human ਵਿੱਚ ਬਦਲਣਾ ਖਾਮੀ ਨੂੰ ਛੁਪਾਉਂਦਾ ਹੈ ਅਤੇ automation ਨੂੰ human-level trust ਦੇ ਸਕਦਾ ਹੈ।
"ਇੱਕ ਚੰਗੇ system ਵਿੱਚ ਕੋਈ Unknown ਨਹੀਂ ਹੁੰਦੇ." ਜਿਸ system ਵਿੱਚ ਕੋਈ Unknown ਨਹੀਂ ਹੁੰਦੇ, ਉਹ ਅਟਕਲ ਲਗਾ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ, ਸਮਝਾਇਆ ਗਿਆ Unknown rate ਇਮਾਨਦਾਰ classifier ਦੀ ਨਿਸ਼ਾਨੀ ਹੈ।
Proof of Actor ਵਿੱਚ Unknown
Proof of Actor ਹਮੇਸ਼ਾ Unknown ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਜਦੋਂ evidence basis ਕੋਈ determination ਸਮਰਥਨ ਨਹੀਂ ਦਿੰਦਾ, ਇਸਨੂੰ ਕਦੇ Human ਵਿੱਚ ਨਹੀਂ ਬਦਲਦਾ, ਅਤੇ analytics ਵਿੱਚ Unknown rate ਨੂੰ ਦਿਖਾਈ ਦੇਣ ਯੋਗ ਰੱਖਦਾ ਹੈ। Teams ਕੋਈ ਵੀ policy enable ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ observation mode ਵਿੱਚ ਹਰ route ਲਈ fallback define ਕਰਦੀਆਂ ਹਨ। ਪੂਰੇ model ਲਈ Detection & Limitations ਪੜ੍ਹੋ, ਜਾਂ early access ਲਈ apply ਕਰੋ.