ਵਰਤਣਯੋਗ ਇਨਕ੍ਰਿਪਸ਼ਨ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਲੋਕ ਉਸ ਸੁਰੱਖਿਆ ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਲੈਂਦੇ ਹਨ ਜੋ ਉਨ੍ਹਾਂ ਨੂੰ ਸਲੋ ਕਰੇ। ਪ੍ਰਮਾਣਿਕਤਾ, ਸਾਂਝੇਦਾਰੀ ਅਤੇ ਕੀ-ਮੈਨੇਜਮੈਂਟ ਲਈ ਅਮਲ-ਯੋਗ UX ਪੈਟਰਨ ਜਾਣੋ ਜੋ ਲੋਕ ਅਸਲ ਵਿੱਚ ਵਰਤਣਗੇ।
ਇੱਕ ਪ੍ਰਣਾਲੀ ਕਾਗਜ਼ ’ਤੇ “ਸੁਰੱਖਿਅਤ” ਹੋ ਸਕਦੀ ਹੈ ਤੇ ਫਿਰ ਵੀ ਅਸਲ ਜ਼ਿੰਦਗੀ ਵਿੱਚ ਅਸੁਰੱਖਿਅਤ ਰਹਿ ਸਕਦੀ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਡਿਜ਼ਾਈਨ ਇਸ ਗੱਲ فرض ਕਰਦੇ ਹਨ ਕਿ ਹਰ ਕੋਈ ਚੇਤਾਵਨੀਆਂ ਪੜھےਗਾ, ਹਰ ਕਦਮ ਫਾਲੋ ਕਰੇਗਾ, ਤੇ ਗਲਤੀਆਂ ਨਹੀਂ ਕਰੇਗਾ। ਜਦੋਂ ਲੋਕ ਵਿਅਸਤ, ਤਣਾਅ ਵਾਲੇ ਜਾਂ ਕੰਮ ਖਤਮ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ, ਉਹ ਇਨ੍ਹਾਂ ਉਮੀਦਾਂ ਅਨੁਸਾਰ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ।
ਇਹੀ ਫਰਕ ਹੈ ਜਿੱਥੇ ਸੁਰੱਖਿਆ ਚੁਪਕੇ-ਚੁਪਕੇ ਟੁੱਟਦੀ ਹੈ। ਜੇ ਇਕ ਇਨਕ੍ਰਿਪਟਡ ਸੁਨੇਹਾ ਖੋਲ੍ਹਣ ਲਈ ਪੰਜ ਉਲਝਾਣ ਭਰੇ ਕਦਮ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਲੋਕ ਹੋਰ ਸੰਭਾਲ ਵਾਲੇ ਨਹੀਂ ਬਣਦੇ; ਉਹ ਇੱਕ ਛੋਟਾ ਰਾਹ ਲੱਭਦੇ ਹਨ ਜੋ ਭਰੋਸੇਮੰਦ ਲੱਗਦਾ ਹੈ, ਭਾਵੇਂ ਉਹ ਸੁਰੱਖਿਆ ਨੂੰ ਕਮਜ਼ੋਰ ਕਰੇ।
ਇਹ ਵਰਕਅਰਾਉਂਡ ਆਮ ਤੌਰ 'ਤੇ ਨਜ਼ਰਅੰਦਾਜ਼ ਲਾਇਕ ਨਹੀਂ ਲੱਗਦੇ, ਪਰ ਉਹ ਇਨਕ੍ਰਿਪਸ਼ਨ ਦਾ ਮਕਸਦ ਹੀ ਖਤਮ ਕਰ ਦਿੰਦੇ ਹਨ। ਲੋਕ ਸਕਿਊਰ ਵੀਅਰ ਦੀ ਥਾਂ ਸਕਰੀਨਸ਼ਾਟ ਭੇਜਦੇ ਹਨ, ਰਾਜ਼ ਨੋਟਾਂ ਜਾਂ ਚੈਟ ਵਿੱਚ "ਸਿਰਫ ਇਕ ਪਲ ਲਈ" ਪੇਸਟ ਕਰਦੇ ਹਨ, ਇੱਕੋ ਪਾਸਵਰਡ ਵੱਖ-ਵੱਖ ਟੂਲਾਂ ਲਈ ਵਾਪਰਦੇ ਹਨ, ਕਿਸੇ ਫੀਚਰ ਨੂੰ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ ਜੋ "ਰੁਕਾਵਟ ਪੈਦਾ ਕਰ ਰਿਹਾ ਹੈ" ਜਾਂ ਇੱਕ ਖਾਤਾ ਸਾਂਝਾ ਕਰ ਲੈਂਦੇ ਹਨ ਕਿਉਂਕਿ ਐਕਸੈਸ ਕੰਟਰੋਲ ਬਹੁਤ ਧੀਮੇ ਲੱਗਦੇ ਹਨ।
ਵਰਤਣਯੋਗ ਇਨਕ੍ਰਿਪਸ਼ਨ ਦਾ ਮਤਲਬ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਸਿੱਖਾਉਣਾ ਨਹੀਂ ਹੈ। ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਸੁਰੱਖਿਅਤ ਰਾਹ ਨੂੰ ਸਭ ਤੋਂ ਆਸਾਨ ਰਾਹ ਬਣਾਉਣਾ, ਘੱਟ ਫੈਸਲਿਆਂ ਅਤੇ ਘੱਟ ਫਸਣ ਵਾਲੀਆਂ ਸਥਿਤੀਆਂ ਨਾਲ। ਜਦੋਂ ਲੋਕ ਤੇਜ਼ ਅਤੇ ਯਕੀਨ ਨਾਲ ਕੰਮ ਮੁਕੰਮਲ ਕਰ ਸਕਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਛੋਟੇ ਰਾਹਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਰਹਿੰਦੀ।
Moxie Marlinspike ਦਾ ਕੰਮ ਇੱਕ ਸਧਾਰਨ ਸੱਚਾਈ ਵੱਲ ਉੰਗਲੀ ਕਰਦਾ ਹੈ: ਸੁਰੱਖਿਆ ਤਦੋਂ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਉਹ ਅਸਲ ਮਨੁੱਖੀ ਵਰਤਾਰਾ ਵਿੱਚ ਫਿੱਟ ਹੋਵੇ। ਲੋਕ ਵਿਅਸਤ, ਧਿਆਨ ਭਟਕਣ ਵਾਲੇ ਅਤੇ ਅਕਸਰ ਦਬਾਅ ਵਿੱਚ ਹੁੰਦੇ ਹਨ। ਜੇ ਕੋਈ ਸੁਰੱਖਿਅਤ ਫਲੋ ਘਣੀ ਰੁਕਾਵਟ ਜੋੜੇਗਾ, ਤਾਂ ਉਹ ਤੇਜ਼ ਰਾਹ ਲੱਭ ਲੈਂਦੇ ਹਨ, ਭਾਵੇਂ ਉਹ ਉਸ ਸੁਰੱਖਿਆ ਨੂੰ ਚੁਪਕੇ-ਚੁਪਕੇ ਟੁੱਟਾ ਦੇਣ।
ਇਸੇ ਲਈ "ਉਪਭੋਗੀ ਸਤਾਉਣ ਵਾਲੇ ਹਨ" ਵਾਲਾ ਪੁਰਾਣਾ ਰਵੈਆ ਖਰਾਬ ਉਤਪਾਦ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਆਮ ਵਰਤਾਰਾ ਨੂੰ ਸਬੋਟਾਜ਼ ਸਮਝਦਾ ਹੈ। ਨਤੀਜਾ ਉਹ ਡਿਜ਼ਾਇਨ ਹੁੰਦੇ ਹਨ ਜੋ ਫਟਕਾਰ ਅਤੇ ਸਜ਼ਾ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ: ਜਟਿਲ ਨਿਯਮ, ਡਰਾਉਣੇ ਪੌਪਅੱਪਸ, ਅਤੇ "ਇਹ ਨਾ ਕਰੋ" ਸੰਦੇਸ਼। ਇਹ ਚੋਣਾਂ ਲੋਕਾਂ ਨੂੰ ਕਲਿੱਕ ਕਰਨ, ਪਾਸਵਰਡ ਸਾਂਝੇ ਕਰਨ, ਕੋਡ ਦੁਹਰਾਉਣ ਜਾਂ ਫੀਚਰਾਂ ਨੂੰ ਬੰਦ ਕਰਨ ਦੀ ਆਦਤ ਸਿਖਾਉਂਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਸੁਰੱਖਿਅਤ ਨਤੀਜੇ ਨਹੀਂ ਮਿਲਦੇ, ਸਿਰਫ਼ ਸ਼ਾਂਤ ਅਸਫਲਤਾਵਾਂ ਮਿਲਦੀਆਂ ਹਨ।
ਇਨਕ੍ਰਿਪਟਿਡ ਮੈਸਜਿੰਗ ਇਸ ਨੂੰ ਬਿਨਾਂ ਜ਼ਿਆਦਾ ਤਕਨੀਕੀ ਜਾਣਕਾਰੀ ਦੇ ਸਾਬਤ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਲੋਕਾਂ ਨੂੰ ਲੰਬੀਆਂ ਫਿੰਗਰਪ੍ਰਿੰਟਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨੀ ਪੈਂਦੀ ਸੀ, ਹੱਥੋਂ ਚਾਬੀਆਂ ਸੰਭਾਲਣੀਆਂ ਪੈਂਦੀਆਂ ਸਨ, ਜਾਂ ਅਸਪਸ਼ਟ ਸੁਰੱਖਿਆ ਚੇਤਾਵਨੀਆਂ ਨੂੰ ਸਮਝਣਾ ਪੈਂਦਾ ਸੀ, ਤਾਂ ਬਹੁਤ ਸਾਰੇ ਚੈੱਕ ਛੱਡ ਦਿੱਤੇ ਜਾਂਦੇ। ਟੂਲ ਕਾਗਜ਼ 'ਤੇ "ਸੁਰੱਖਿਅਤ" ਸੀ, ਪਰ ਰੋਜ਼ਾਨਾ ਵਰਤੋਂ ਵਿੱਚ ਸੁਰੱਖਿਆ ਜ਼ਿੰਦਾ ਨਹੀਂ ਰਹੀ।
ਵਰਤਣਯੋਗ ਇਨਕ੍ਰਿਪਸ਼ਨ ਕਮਜ਼ੋਰ ਇਨਕ੍ਰਿਪਸ਼ਨ ਨਹੀਂ ਹੈ। ਇਹ ਇਨਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਐਸੇ ਫਲੋ ਵਿੱਚ ਲਪੇਟਣਾ ਹੈ ਜੋ ਲੋਕ ਹਰ ਵਾਰੀ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਪੂਰਾ ਕਰ ਸਕਣ।
ਅਮਲ ਵਿੱਚ "ਵਰਤਣਯੋਗ" ਅਕਸਰ ਚਾਰ ਲੱਛਣਾਂ ਤੇ ਆਮ ਹੁੰਦਾ ਹੈ:
ਕਲਾ-ਘਟਨਾ ਦੱਸੋ: ਕੋਈ ਵਿਅਕਤੀ ਨਵਾਂ ਫੋਨ ਵਰਤਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਜੇ ਇੱਕੋ ਰਿਕਵਰੀ ਰਾਹ "ਪੁਰਾਣੇ ਡਿਵਾਈਸ ਨੂੰ ਲੱਭੋ ਅਤੇ ਚਾਬੀਆਂ ਐਕਸਪੋਰਟ ਕਰੋ" ਹੀ ਹੈ, ਤਾਂ ਕਈ ਲੋਕ ਕੋਡਾਂ ਦੀ ਸਕਰੀਨਸ਼ਾਟ ਲੈ ਲੈਣਗੇ, ਗੁਪਤ ਜਾਣਕਾਰੀ ਨੋਟਾਂ ਵਿੱਚ ਰੱਖ ਦੇਣਗੇ, ਜਾਂ ਸੁਰੱਖਿਅਤ ਨਾ ਹੋਣ ਵਾਲੇ ਚੈਨਲ ਤੇ ਵਾਪਸ ਜਾਵਣਗੇ। ਇੱਕ ਵਰਤਣਯੋਗ ਡਿਜ਼ਾਈਨ ਉਸ ਪਲ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ ਅਤੇ ਸੁਰੱਖਿਅਤ ਰਾਹ ਸਪਸ਼ਟ ਬਣਾਉਂਦਾ ਹੈ।
ਇਨਕ੍ਰਿਪਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਪਲਾਂ ਤੇ ਫੇਲ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਅਸਲ ਲੋਕ ਇਸ ਨਾਲ ਛੂੰਹਦੇ ਹਨ। ਨਾ ਕਿ ਇਸ ਲਈ ਕਿ ਉਹ_PRIVACY ਨੂੰ ਨਾ ਚਾਹੁੰਦੇ, ਪਰ ਇਸ ਲਈ ਕਿ "ਸੁਰੱਖਿਆ ਦੀ ਕਿਮਤ" ਉਹਨਾਂ ਨੂੰ ਵਿਅਸਤ, ਤਣਾਅ ਵਿੱਚ ਜਾਂ ਕਿਸੇ ਨੂੰ ਮਦਦ ਕਰਦੇ ਸਮੇਂ ਮਿਲਦੀ ਹੈ।
ਦਰਦ ਵਾਲੇ ਬਿੰਦੂ ਪੂਰੇ ਤੌਰ 'ਤੇ ਅਨੁਮਾਨਯੋਗ ਹਨ: ਪਹਿਲੀ ਵਾਰੀ ਸੈਟਅੱਪ ਜੋ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਉਹ ਚੋਣਾਂ ਦਿੰਦਾ ਹੈ ਜੋ ਉਹ ਸਮਝਦੇ ਨਹੀਂ, ਲੌਗਿਨ ਫਲੋ ਜੋ ਬਿਨਾਂ ਸਮਝਾਏ ਕਦਮ ਵਧਾਉਂਦਾ ਹੈ, ਡਿਵਾਈਸ ਬਦਲਣ ਤੇ ਅਚਾਨਕ ਐਕਸੈਸ ਗੁੰਮ ਹੋ ਜਾਣਾ, ਤੇਜ਼ੀ ਨਾਲ ਕੁਝ ਸਾਂਝਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਸਮੇਂ ਉਲਝਣ ਭਰੀ ਪਰਮਿਸ਼ਨਸ ਆਉਣ, ਅਤੇ ਖੋਇਆ ਹੋਇਆ ਡਿਵਾਈਸ ਜਾਂ ਭੁੱਲਿਆ ਪਾਸਵਰਡ ਤੋਂ ਬਾਅਦ ਰਿਕਵਰੀ।
ਜਦੋਂ ਰੁਕਾਵਟ ਜ਼ਿਆਦਾ ਹੋਏ, ਲੋਕ ਉਹੀ ਕਰਦੇ ਹਨ ਜੋ ਚੱਲਦਾ ਹੈ। ਉਹ ਪਾਸਵਰਡ ਦੁਹਰਾਉਂਦੇ ਹਨ, ਸੈਸ਼ਨਾਂ ਨੂੰ ਹਮੇਸ਼ਾ ਲੌਗਡ-ਇਨ ਰੱਖਦੇ ਹਨ, ਵਾਧੂ ਜਾਂਚਾਂ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ, ਜਾਂ "ਸੁਰੱਖਿਅਤ" ਗੱਲ-ਬਾਤ ਨੂੰ ਤੇਜ਼ ਐਪ 'ਤੇ ਸ਼ਿਫਟ ਕਰ ਦਿੰਦੇ ਹਨ।
ਸੰਗਿਆਤਮਕ ਓਵਰਲੋਡ ਇੱਕ ਵੱਡਾ ਕਾਰਕ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਸੁਰੱਖਿਅਤ ਉਤਪਾਦ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਅਜੇਹੇ ਸਵਾਲ ਪੁੱਛਦੇ ਹਨ: "ਤੁਸੀਂ ਕਿਸ ਕੀ ਨੂੰ ਟਰੱਸਟ ਕਰਨਾ ਚਾਹੋਗੇ?" ਜਾਂ "ਤੁਹਾਨੂੰ ਲੋਕਲ ਜਾਂ ਸਰਵਰ-ਸਾਈਡ ਇਨਕ੍ਰਿਪਸ਼ਨ ਚਾਹੀਦੀ ਹੈ?" ਜ਼ਿਆਦਾਤਰ ਲੋਕਾਂ ਕੋਲ ਇਹਨਾਂ ਲਈ ਕੋਈ ਮਾਨਸਿਕ ਮਾਡਲ ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਲਈ ਉਹ ਅਨੁਮਾਨ ਲਗਾਂਦੇ ਹਨ। ਜੇ UI ਡਰਾਉਣੀਆਂ ਚੇਤਾਵਨੀਆਂ ਦਿਖਾਉਂਦੀ ਹੈ, ਤਾਂ ਅਨੁਮਾਨ ਘਬਰਾ ਦੇਣ ਵਾਲਾ ਹੋ ਜਾਂਦਾ ਹੈ।
ਕੁਝ ਚੇਤਾਵਨੀ ਪੈਟਰਨ ਲਗਭਗ ਗਾਰੰਟੀ ਦੇ ਸਕਦੇ ਹਨ ਕਿ ਲੋਕ ਅਨੁਸਰਨ ਛੱਡ ਦੇਣਗੇ:
ਸਮਾਂ ਦਾ ਦਬਾਅ ਇਸਨੂੰ ਹੋਰ ਵੀ ਖਰਾਬ ਕਰ ਦਿੰਦਾ ਹੈ। ਜੇ ਕੋਡ ਕਿਸੇ ਮੀਟਿੰਗ ਵਿੱਚ ਜੁੜਦਿਆਂ ਵਿਚ ਮਿਆਦ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਲੋਕ ਸੁਰੱਖਿਆ ਦੀ ਥਾਂ ਤੇਜ਼ੀ ਚੁਣਦੇ ਹਨ। ਸਮਾਜਿਕ ਦਬਾਅ ਬਾਕੀ ਕੁਝ ਕਰ ਦਿੰਦਾ: ਜਦੋਂ ਕੋਲੀਗ ਕਹਿੰਦਾ ਹੈ "ਫਟਾਫਟ ਭੇਜੋ", ਤਾਂ ਸੁਰੱਖਿਅਤ ਸਾਂਝੇਦਾਰੀ ਇਕ ਆਦਤ ਨਹੀਂ ਰਹਿੰਦੀ, ਇੱਕ ਦੌੜ ਬਣ ਜਾਂਦੀ ਹੈ।
ਸੁਰੱਖਿਆ ਉਸ ਵੇਲੇ ਟੁੱਟਦੀ ਹੈ ਜਦੋਂ ਲੋਕਾਂ ਨੂੰ ਅਨੁਮਾਨ ਲਾਉਣਾ ਪੈਂਦਾ ਹੈ। ਚੰਗੀ ਇਨਕ੍ਰਿਪਸ਼ਨ UX ਅਨੁਮਾਨ ਨੂੰ ਘਟਾ ਕੇ ਸੁਰੱਖਿਅਤ ਰਾਹ ਸਭ ਤੋਂ ਆਸਾਨ ਰਾਹ ਬਣਾਉਂਦੀ ਹੈ। ਜੇ ਸੁਰੱਖਿਅਤ ਚੋਣ ਲਈ ਸਹਾਇਤਾ ਪੇਜ ਪੜ੍ਹਨੀ ਪਵੇ ਜਾਂ IT ਨੂੰ ਪੁੱਛਣਾ ਪਵੇ, ਤਾਂ ਬਹੁਤ ਸਾਰੇ ਉਪਭੋਗੀ ਕੁਝ ਹੋਰ ਚੁਣ ਲੈਂਦੇ ਹਨ।
ਫੈਸਲਿਆਂ ਨੂੰ ਘਟਾਉਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਜ਼ਿਆਦਾਤਰ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਇੱਕ ਸਪੱਸ਼ਟ, ਸੁਝਾਈ ਗਈ ਚੋਣ ਅਤੇ ਛੋਟੀ ਵਜ੍ਹਾ ਦਿਖਾਉਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਕਿਉਂ ਇਹ ਸੁਝਾਈ ਗਈ ਹੈ। ਅਡਵਾਂਸਡ ਸੈਟਿੰਗ्स ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਉਹ ਮੁੱਖ ਪ੍ਰਵਾਹ ਵਿੱਚ ਸਿਰਫ਼ ਤਦ ਦਿਖਣ ਜਦੋਂ ਕਿਸੇ ਨੂੰ ਵਾਕਈ ਲੋੜ ਹੋਵੇ।
ਖਤਰਾ ਦਿਖਾਓ, ਪਰ ਸ਼ਾਂਤ ਢੰਗ ਨਾਲ। ਡਰਾਉਣੀਆਂ ਚੇਤਾਵਨੀਆਂ ਦੀ ਜਗ੍ਹਾ ਉਹ ਨਤੀਜੇ ਦਿਖਾਓ ਜੋ ਲੋਕ ਅੰਦਾਜ਼ੇ ਨਾਲ ਸਮਝ ਸਕਣ: "Anyone with this link can view the file" ਇਹਨਾਂ ਲੇਬਲਾਂ ਨਾਲੋਂ ਵੱਧ ਮਦਦਗਾਰ ਹੈ। ਲੋਕ ਨਤੀਜਿਆਂ 'ਤੇ ਕਦਮ ਉਠਾਉਂਦੇ ਹਨ, ਨਾਂ ਕਿ ਟੈਗਾਂ 'ਤੇ।
ਗਲਤੀਆਂ ਨੂੰ ਆਮ ਮਾਮਲਾ ਸਮਝੋ। ਵਰਤਣਯੋਗ ਇਨਕ੍ਰਿਪਸ਼ਨ ਵਿੱਚ ਰਿਕਵਰੀ ਸੁਰੱਖਿਆ ਦਾ ਹਿੱਸਾ ਹੈ, ਨਾਹ ਕਿ ਇੱਕ ਐਡ-ਆਨ। ਮਨ ਲਵੋ ਕਿ ਕੋਈ ਗਲਤ ਚੀਜ਼ ਸਾਂਝੀ ਕਰ ਦੇਵੇਗਾ, ਡਿਵਾਈਸ ਖੋ ਜਾਵੇਗਾ, ਜਾਂ ਗਲਤ ਵਿਅਕਤੀ ਨੂੰ ਸੁਨੇਹਾ ਭੇਜ ਦੇਵੇਗਾ।
ਇੱਕ ਛੋਟੀ ਸੈੱਟ ਨੀਤੀਆਂ ਅਸਲ ਉਤਪਾਦਾਂ ਵਿੱਚ ਵੀ ਮਦਦਗਾਰ ਰਹਿੰਦੀਆਂ ਨੇ:
ਪ੍ਰੋਗ੍ਰੈਸਿਵ ਡਿਸਕਲੋਜ਼ਰ "ਫੀਚਰਾਂ ਦੀ ਕੰਧ" ਵਾਲੀ ਥਕਾਵਟ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ। ਸਿਰਫ਼ ਉਹੀ ਦਿਖਾਓ ਜੋ ਮੌਜੂਦਾ ਕਦਮ ਮੁਕੰਮਲ ਕਰਨ ਲਈ ਲੋੜੀਂਦਾ ਹੈ, ਅਤੇ ਹੋਰ ਸਾਰਾ ਕੁਝ ਮੁਲਤਵੀ ਕਰੋ। ਜਦੋਂ ਵਾਧੂ ਵੇਰਵਾ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ, ਉਸਨੂੰ ਸੰਦੇਭ ਦੇ ਕੇ ਵਿਕਲਪ ਵਜੋਂ ਪੇਸ਼ ਕਰੋ, ਨਾਕਿ ਇੱਕ ਅਚਾਨਕ ਚੋਣ ਦੇ ਤੌਰ ਤੇ।
ਭੁੱਲਭੁਲੇਖੇ ਨੂੰ ਇੱਕ ਹਮਲਾ-ਸਥਲ ਸਮਝੋ। ਜੇ ਸਪੋਰਟ ਵਾਰ-ਵਾਰ ਸੁਣਦਾ ਹੈ "ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ ਇਹ ਦਾ ਕੀ ਮਤਲਬ ਹੈ", ਤਾਂ ਲੋਕ ਫੀਚਰ ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਦੇਣਗੇ: ਗੈਰ-ਇੰਕ੍ਰਿਪਟਡ ਨਕਲ ਭੇਜ ਕੇ, ਸਕਰੀਨਸ਼ਾਟ ਲੈ ਕੇ, ਜਾਂ ਜ਼ਰੂਰਤ ਤੋਂ ਕਮਜ਼ੋਰ ਪਾਸਵਰਡ ਵਰਤ ਕੇ। ਤੇਜ਼ੀ ਨਾਲ ਠੀਕ ਕਰਨ ਲਈ ਜ਼ਿਆਦਾ ਚੇਤਾਵਨੀ ਨਹੀਂ, ਸਗੋਂ ਇੱਕ ਸਧਾਰਨ ਫਲੋ ਅਤੇ ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ ਜ਼ਰੂਰੀ ਹੁੰਦੇ ਹਨ।
ਕਈ "ਸੁਰੱਖਿਅਤ" ਸਿਸਟਮ ਮੁੱਖ ਦਰਵਾਜ਼ੇ ਤੇ ਫੇਲ ਹੁੰਦੇ ਹਨ। ਜੇ ਸਾਈਨ-ਇਨ ਪੀੜਦਾਇਕ ਹੈ, ਤਾਂ ਲੋਕ ਕਮਜ਼ੋਰ ਪਾਸਵਰਡ ਵਾਪਰਦੇ ਹਨ, ਰਾਖੀਆਂ ਬੰਦ ਕਰਦੇ ਹਨ, ਜਾਂ ਤੇਜ਼ ਰਾਹ ਚੁਣ ਲੈਂਦੇ ਹਨ। ਵਰਤਣਯੋਗ ਇਨਕ੍ਰਿਪਸ਼ਨ ਲਈ, ਪ੍ਰਮਾਣਿਕਤਾ ਟੁੱਟਣਾ ਮੁਸ਼ਕਿਲ ਅਤੇ ਵਰਤਣ ਲਈ ਆਸਾਨ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ, ਪਾਸਵਰਡ ਹਟਾਓ। ਪਾਸਕੀ (passkeys) ਅਤੇ ਹੋਰ passwordless ਵਿਕਲਪ ਫ਼ਿਸ਼ਿੰਗ ਦਾ ਖ਼ਤਰਾ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਭੁੱਲ ਜਾਣ ਵਾਲੇ ਕ੍ਰੇਡੈਂਸ਼ਲ ਸਹਾਰਿਆਂ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ। ਫਿਰ ਵੀ, ਤੁਹਾਨੂੰ ਇੱਕ ਫਾਲਬੈਕ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਜਦੋਂ ਆਸਾਨ ਰਾਹ ਫੇਲ ਹੋਵੇ (ਨਵਾਂ ਡਿਵਾਈਸ, ਖੋਇਆ ਫੋਨ, ਲੌਕਡ-ਆਊਟ ਖਾਤਾ)। ਉਹ ਫਾਲਬੈਕ ਸਮਝਣ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਚੱਕਰਦਾਰ ਸਵਾਲਾਂ ਦਾ ਮੇਜ਼ਾਨਾ।
ਸੈਸ਼ਨ ਹੋਰਾਂ ਨੂੰ ਨੁਕਸਾਨ ਸੀਮਤ ਕਰਨ ਲਈ ਕਾਫੀ ਛੋਟੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਪਰ ਐਨਾ ਛੋਟੇ ਨਹੀਂ ਕਿ ਹਰ ਘੰਟੇ ਲੋਗਿਨ ਕਰਨਾ ਪਵੇ। ਇੱਕ ਚੰਗਾ ਮੱਧ ਰਸਤਾ ਰੋਜ਼ਮਰਰਾ ਕੰਮ ਲਈ ਆਮ ਸੈਸ਼ਨ ਹੈ, ਨਾਲ ਹੀ ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈਆਂ ਲਈ ਚੁਪਚਾਪ ਦੁਬਾਰਾ ਪ੍ਰਮਾਣਿਕਤਾ। ਜਿਹੜੇ ਵੀ ਦਫ਼ਾ-ਉਪਰਾਲੇ ਬਾਰ-ਬਾਰ ਹੋਣਗੇ, ਉਪਭੋਗੀ ਉਸ ਵੇਲੇ ਦੁਬਾਰਾ ਪ੍ਰਮਾਣਿਕਤਾ ਸਵੀਕਾਰ ਕਰ ਲੈਂਦੇ ਹਨ ਜਦੋਂ ਇਹ ਕਿਸੇ ਸਪੱਸ਼ਟ ਕਾਰਨ ਨਾਲ ਜੁੜਿਆ ਹੋਵੇ।
ਜਿਨ੍ਹਾਂ ਕਾਰਵਾਈਆਂ ਨਾਲ ਸੁਰੱਖਿਆ ਦੀ ਕਹਾਣੀ ਬਦਲਦੀ ਹੈ, ਉਨ੍ਹਾਂ ਲਈ "ਸਟੈਪ-ਅਪ" ਪ੍ਰਮਾਣਿਕਤਾ ਵਰਤੋ: ਡਾਟਾ ਨਿਰਯਾਤ, ਨਵਿਆਂ ਮੈਂਬਰਾਂ ਨੂੰ ਬੁਲਾਉਣਾ, ਸਾਂਝੇ ਕਰਨ ਦੀਆਂ ਪਰਮੀਸ਼ਨ ਬਦਲਣਾ, ਐਡਮਿਨ ਸੈਟਿੰਗਸ (ਬਿੱਲਿੰਗ, ਰੋਲ, ਰਿਕਵਰੀ ਮੈਥਡ) ਸੋਧਣਾ, ਨਵਾਂ ਡਿਵਾਈਸ ਜੋੜਨਾ, ਜਾਂ ਡਿਪਲੋਇਮੈਂਟ ਅਤੇ ਡੋਮੇਨ ਬਦਲਣਾ ਮਨੁੱਖੀ-ਜਿੰਮੇਵਾਰੀ ਵਾਲੇ ਵੇਲੇ।
ਦੋ-ਕਾਰਕ (2FA) ਪ੍ਰਭਾਵੀ ਹੋ ਸਕਦੀ ਹੈ ਬਿਨਾਂ ਰੋਜ਼ਾਨਾ ਸਜ਼ਾ ਬਣਣ ਦੇ। ਲੋਕਾਂ ਨੂੰ ਟਰੱਸਟਡ ਡਿਵਾਈਸ ਦਰਜ ਕਰਨ ਦਿਓ ਅਤੇ ਫਿਰ ਸਿਰਫ਼ ਜੋਖਮ ਬਦਲੇ ਤਾਂ ਹੀ ਦੁਬਾਰਾ ਪੁੱਛੋ (ਨਵਾਂ ਸਥਾਨ, ਨਵਾਂ ਬ੍ਰਾਊਜ਼ਰ, ਅਸਧਾਰਣ ਵਰਤਾਰਾ)। ਜੇ ਤੁਹਾਨੂੰ ਬਾਰ-ਬਾਰ ਚੈਲੈਂਜ ਕਰਨਾ ਪੈਣਾ ਹੈ, ਤਾਂ ਉਹ ਛੇਤੀ ਹੋਵੇ।
ਮੁਹੱਈਆ ਕਰਵਾਉਣਾ ਕਿ ਬਲਬਲ ਆਧਾਰਿਤ ਬਦਲਾਅਾਂ ਦੀ ਮਿਆਦ 'ਤੇ ਫੋਰਸਡ ਪਾਸਵਰਡ ਬਦਲਾਅ ਨਾ ਰੱਖੋ — ਇਹ ਲੋਕਾਂ ਨੂੰ ਪੈਟਰਨ ਬਣਾਉਣ ਤੇ ਮਜਬੂਰ ਕਰਦਾ ਹੈ ਅਤੇ ਅਣਸੁਰੱਖਿਅਤ ਥਾਵਾਂ 'ਤੇ ਪਾਸਵਰਡ ਸਟੋਰ ਕਰਨ ਦੀ ਪ੍ਰੇਰਣਾ ਦਿੰਦਾ ਹੈ। ਬਦਲੇ ਵਿੱਚ ਸਮਝਦਾਰ ਰਿਪੋਰਟਿੰਗ ਤੇ ਰਿਕਵਰੀ 'ਤੇ ਧਿਆਨ ਦਿਓ: ਨਵੇਂ ਸਾਈਨ-ਇਨ 'ਤੇ ਸੁਚੇਤਨਾ, ਸਰਗਰਮ ਸੈਸ਼ਨਾਂ ਦੀ ਸੂਚੀ, ਅਤੇ ਇੱਕ ਥਾਂ ਤੇ ਐਕਸੈਸ ਰੱਦ ਕਰਨ ਦੀ ਸਹੂਲਤ।
ਜਿਵੇਂ ਕਿ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ 'ਤੇ, ਇਹ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਰੋਜ਼ਮਰਰਾ ਬਿਲਡਿੰਗ ਲਈ ਸਾਈਨ-ਇਨ ਤੇਜ਼ ਰੱਖੋ, ਪਰ ਜਦੋਂ ਕੋਈ ਸੋर्स ਕੋਡ ਨਿਰਯਾਤ ਕਰੇ, ਕਸਟਮ ਡੋਮੇਨ ਬਦਲੇ, ਜਾਂ ਟੀਮ ਰੋਲ ਸੋਧੇ ਤਾਂ ਤਾਜ਼ਾ ਰੀ-ਆਥ ਦੀ ਮੰਗ ਕਰੋ — ਉਹ ਪਲ ਜਿੱਥੇ ਇਕ ਚੋਰੀ ਹੋਇਆ ਸੈਸ਼ਨ ਅਸਲ ਨੁਕਸਾਨ ਕਰ ਸਕਦਾ ਹੈ।
ਛੇਤੀ-ਵਰਤਣਯੋਗ ਕੀ-ਮੈਨੇਜਮੈਂਟ ਦੇ ਤਿੰਨ ਲਕੜੀ-ਕਿਲੇ ਹਨ ਜੋ ਉਪਭੋਗੀ ਸਮਝ ਸਕਣ: ਡੇਟਾ ਨਿੱਜੀ ਰੱਖੋ, ਸਹੀ ਲੋਕਾਂ ਨੂੰ ਐਕਸੈਸ ਦਿਓ, ਅਤੇ ਜੇ ਕੁਝ ਗਲਤ ਹੋਵੇ ਤਾਂ ਵਾਪਸ ਆ ਸਕੋ। ਜੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਬੇਠਰਾ ਲੱਗੇ, ਲੋਕ اپنا ਆਪਣੇ ਰਸਤੇ ਬਣਾਉਂਦੇ ਹਨ, ਜਿਵੇਂ ਨੋਟਾਂ ਵਿੱਚ ਰਾਜ਼ ਸਾਂਭ ਕੇ ਰੱਖਣਾ ਜਾਂ ਸਕਰੀਨਸ਼ਾਟ ਸਾਂਝੇ ਕਰਨਾ।
ਜ਼ਿਆਦਾਤਰ ਵਰਤੋਂਕਾਰਾਂ ਲਈ, ਚਾਬੀਆਂ ਆਟੋਮੈਟਿਕ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲੀਆਂ ਜਾਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਉਤਪਾਦ ਚਾਬੀਆਂ ਬਣਾਉਂਦਾ ਹੈ, ਉਨ੍ਹਾਂ ਨੂੰ ਡਿਵਾਈਸ ਦੀ ਸੁਰੱਖਿਅਤ ਸਟੋਰੇਜ ਵਿੱਚ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਲੋੜ ਤੇ ਉਹਨਾਂ ਨੂੰ ਰੋਟੇਟ ਕਰਦਾ ਹੈ। ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਲੰਬੀਆਂ ਸਤਰਾਂ ਕਾਪੀ ਕਰਨ, ਫ਼ਾਇਲਾਂ ਨਾਂ ਕਰਨ, ਜਾਂ ਉਲਝਣ ਵਾਲੇ ਫਾਰਮੈਟਾਂ ਵਿਚੋਂ ਚੁਣਨ ਲਈ ਨਹੀਂ ਪੁੱਛਣਾ ਚਾਹੀਦਾ।
ਪਾਵਰ ਯੂਜ਼ਰ ਅਤੇ ਟੀਮਾਂ ਨੂੰ ਕੰਟਰੋਲ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਇਸ ਕਰਕੇ "ਅਡਵਾਂਸਡ" ਰਾਹ ਨਿਰਯਾਤ ਜਾਂ ਐਡਮਿਨ-ਮੇਨੇਜਡ ਚਾਬੀਆਂ ਲਈ ਵਾਜਬ ਹੈ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਹਰ ਕਿਸੇ ਨੂੰ ਉਹ ਮੋਡ ਫੋਰਸ ਨਾ ਕੀਤਾ ਜਾਏ।
ਡਿਵਾਈਸ ਬਦਲਣ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਟਰੱਸਟ ਟੁੱਟਦੀ ਹੈ। ਨਤੀਜੇ ਨੂੰ ਪੂਰਨ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਜੇ ਫੋਨ ਖੋ ਗਿਆ, ਤਾਂ ਉਪਭੋਗੀ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਰਿਕਵਰੀ ਸੰਭਵ ਹੈ ਜਾਂ ਨਹੀਂ, ਉਹਨਾਂ ਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੋਏਗਾ, ਅਤੇ ਕੀ ਸਥਾਈ ਤੌਰ ਤੇ ਗੁੰਮ ਹੋ ਜਾਵੇਗਾ। ਇਹ ਸਭ ਕੁਝ ਬਾਅਦ ਵਿੱਚ ਡਰਾਉਣੀ ਚੇਤਾਵਨੀ ਦੇ ਪਿੱਛੇ ਨਾ ਲੁਕਾਓ।
ਇੱਕ ਸਹਾਇਕ ਮਾਨਸਿਕ ਮਾਡਲ ਹੈ: ਸਾਇਨ-ਇਨ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ کون ਹੋ, ਡਿਕ੍ਰਿਪਟਿੰਗ ਡੇਟਾ ਨੂੰ ਖੋਲ੍ਹਦਾ ਹੈ। ਤੁਸੀਂ ਸਕਰੀਨਾਂ ਨੂੰ ਸਧਾਰਨ ਰੱਖ ਸਕਦੇ ਹੋ, ਪਰ ਇਹ ਨਾ ਦਿਖਾਓ ਕਿ ਇੱਕ ਪਾਸਵਰਡ ਅਕਸਰ ਹਰ ਚੀਜ਼ ਨੂੰ ਵਾਪਸ ਲਿਆ ਸਕਦਾ ਹੈ। ਜੇ ਡਿਕ੍ਰਿਪਸ਼ਨ ਕਿਸੇ ਦੂਜੇ ਚੀਜ਼ (ਜਿਵੇਂ ਟਰੱਸਟਡ ਡਿਵਾਈਸ ਜਾਂ ਰਿਕਵਰੀ ਕੋਡ) 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਦੱਸੋ।
ਲੋਕਾਂ ਨੂੰ ਜਾਣੂ ਨਾਮਾਂ ਵਰਤੋ ਅਤੇ ਇਕਸਾਰ ਰੱਖੋ। "Recovery code", "trusted device", ਅਤੇ "lost device" ਇੱਕ ਮਿਲਦੇ-ਜੁਲਦੇ ਅਰਥ ਰੱਖਦੇ ਹਨ ਅਤੇ ਸਕਰੀਨ ਤੋਂ ਸਕਰੀਨ ਤੱਕ ਬਦਲਣ ਨਾ ਦੱਸਦੇ।
ਉਦਾਹਰਨ: ਕੋਈ ਆਪਣਾ ਫੋਨ ਬਦਲਦਾ ਹੈ। ਸਾਇਨ-ਇਨ ਤੋਂ ਬਾਅਦ ਉਹ ਵੇਖਦਾ ਹੈ: "Approve on a trusted device" ਜਾਂ "Use recovery code." ਜੇ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਨਾ ਹੋਵੇ, ਐਪ ਸਪਸ਼ਟ ਕਹਿੰਦਾ ਹੈ: "ਅਸੀਂ ਤੁਹਾਡਾ ਅਕਾਊਂਟ ਰੀਸੈਟ ਕਰ ਸਕਦੇ ਹਾਂ, ਪਰ ਪੁਰਾਣਾ ਇਨਕ੍ਰਿਪਟਡ ਡੇਟਾ ਦੁਬਾਰਾ ਮਿਲੇਗਾ ਨਹੀਂ." ਸਪਸ਼ਟ ਸੱਚਾਈ ਖਤਰਨਾਕ ਛੋਟੇ ਰਾਹਾਂ ਨੂੰ ਰੋਕਦੀ ਹੈ।
ਸ਼ੇਅਰਿੰਗ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਚੰਗੀ ਸੁਰੱਖਿਆ ਅਕਸਰ ਘਟਦੀ ਹੈ। ਜੇ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਧੀਮਾ ਜਾਂ ਉলਝਣ ਭਰਿਆ ਲੱਗੇ, ਤਾਂ ਲੋਕ ਸਕਰੀਨਸ਼ਾਟ ਭੇਜਦੇ ਹਨ, ਫਾਇਲਾਂ ਨਿੱਜੀ ਈਮੇਲ 'ਤੇ ਅੱਗੇ ਭੇਜ ਦਿੰਦੇ ਹਨ, ਜਾਂ ਗੁਪਤ ਜਾਣਕਾਰੀ ਚੈਟ ਵਿੱਚ ਪੇਸਟ ਕਰ ਦੇਂਦੇ ਹਨ। ਵਰਤਣਯੋਗ ਇਨਕ੍ਰਿਪਸ਼ਨ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਾਂਝਾ ਕਰਨ ਦਾ ਫਲੋ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਹੋਵੇ, ਨਾ ਕਿ ਇੱਕ ਡਰਾਉਣਾ ਪੌਪਅੱਪ।
invite flow ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਸਾਫ-ਸੁਥਰੇ ਲੋੜੀਂਦੇ ਵਿਕਲਪਾਂ ਨਾਲ — ਨਾਂ ਕਿ ਇੱਕ ਖ਼ਾਲੀ ਲਿੰਕ। ਇੱਕ invite ਕਿਸੇ ਵਿਅਕਤੀ ਜਾਂ ਟੀਮ ਨਾਲ ਜੋੜੀ ਜਾ ਸਕਦੀ ਹੈ, ਸਪਸ਼ਟ ਰੋਲਾਂ ਅਤੇ ਇਕ ਖਤਮ ਹੋਣ ਦੀ ਮੀਅਦ ਨਾਲ। ਚੋਣਾਂ ਸਾਦੀਆਂ ਰੱਖੋ: "Can view", "Can edit", ਅਤੇ "Can manage access." ਸੰਵੇਦਨਸ਼ੀਲ ਆਈਟਮਾਂ ਲਈ ਸਮਾਂ ਸੀਮਾ ਆਮ ਰੱਖੋ (ਉਦਾਹਰਣ: ਠੇਕੇਦਾਰ ਲਈ ਇੱਕ ਹਫਤੇ ਬਾਅਦ ਖ਼ਤਮ ਹੋ ਜਾਵੇ)।
ਰੱਦ ਕਰਨਾ ਤੇਜ਼ ਅਤੇ ਵਿਖਾਈ ਦੇਣਯੋਗ ਬਣਾਓ। ਐਕਸੈਸ ਨੂੰ ਇੱਕ ਥਾਂ ਤੇ ਰੱਖੋ, ਇੱਕ ਕਾਰਵਾਈ ਨਾਲ ਕਿਸੇ ਨੂੰ ਹਟਾਉਣ, ਚਾਬੀਆਂ ਰੋਟੇਟ ਕਰਨ, ਅਤੇ ਪੁਰਾਣੀਆਂ ਸੈਸ਼ਨਾਂ ਨੂੰ ਅਮਾਨ ਕੀਤਾ ਜਾ ਸਕੇ। ਜੇ ਲੋਕਾਂ ਨੂੰ ਸੈਟਿੰਗਜ਼ ਵਿੱਚ ਖੋਜ ਕਰਨੀ ਪੈਂਦੀ ਹੈ, ਤਾਂ ਉਹ ਅਗਲੀ ਵਾਰੀ ਸੁਰੱਖਿਅਤ ਸਾਂਝੇਦਾਰੀ ਨੂੰ ਟਾਲਣਗੇ।
ਸਪਸ਼ਟਤਾ ਚੇਤਾਵਨੀਆਂ 'ਤੇ ਜਿੱਤਦੀ ਹੈ। ਵਰਤੋ ਸਪੱਸ਼ਟ ਲੇਬਲ ਜੋ ਮੁਰਾਦ ਨਾਲ ਮਿਲਦੇ ਹਨ: ongoing access ਲਈ ਖਾਤੇ ਨਾਲ ਸਾਂਝਾ ਕਰੋ, ਇੱਕ ਵਿਅਕਤੀ ਦੇ ਇੱਕ ਮਸ਼ੀਨ ਲਈ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਡਿਵਾਈਸ ਨਾਲ ਸਾਂਝਾ ਕਰੋ, ਅਤੇ ਲਿੰਕ ਰਾਹੀਂ ਸਾਂਝਾ ਕਰਨ ਸਮੇਂ ਸਿਰਫ਼ ਜਦੋਂ ਸਚਮੁਚ ਲੋੜ ਹੋਵੇ।
ਖਤਰਨਾਕ ਕਾਰਵਾਈਆਂ ਲਈ ਗਾਰਡਰੇਲ ਦਿਓ ਬਿਨਾਂ ਨਾਗ ਕਰਨ ਦੇ। ਜੇ ਆਰਗਨਾਈਜੇਸ਼ਨ ਤੋਂ ਬਾਹਰ ਸਾਂਝਾ ਕਰਨਾ ਹੈ, ਤਾਂ ਕਾਰਨ ਅਤੇ ਸਮਾਂ ਸੀਮਾ ਲੋੜੀਦਾ ਕਰੋ। ਪਬਲਿਕ ਲਿੰਕ ਲਈ, ਪੀਸ਼ਕਸ਼ ਦਿਖਾਓ ਕਿ ਕੀ ਪਬਲਿਕ ਹੋ ਜਾਵੇਗਾ। ਨਿਰਯਾਤਾਂ ਲਈ, ਦਿਖਾਓ ਕਿ ਕੀਤਾ ਕੁਝ ਸ਼ਾਮਲ ਹੈ (ਡੇਟਾ, ਰਾਜ਼, ਇਤੀਹਾਸ) ਅਤੇ ਇੱਕ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਦਿਓ।
ਅਖੀਰਕਾਰ, ਵਰਤੋਂਕਾਰ ਪੜ੍ਹ ਸਕਣ ਵਾਲੀ ਐਕਟਿਵਿਟੀ ਹਿਸਟਰੀ ਦਿਖਾਓ: "Ava opened it", "Ben changed permissions", "Public link created" — ਕਿਸ ਨੇ, ਕੀ, ਅਤੇ ਕਦੋਂ। ਜੇ ਤੁਸੀਂ Koder.ai ਤੇ ਐਪ ਬਣਾਓ, ਇਹੀ ਵਿਚਾਰ deployments, source exports, ਜਾਂ snapshots ਲਈ ਲਾਗੂ ਕਰੋ: ਐਕਸੈਸ ਨੂੰ ਵਿਖਾਈ ਦੇਣਯੋਗ, ਸਮੇਂ-ਬਾਧਿਤ, ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਉਲਟਾਉਣਯੋਗ ਬਣਾਓ।
ਉਪਭੋਗੀ ਯਾਤਰਾ ਨੂੰ ਇਕ ਸਧਾਰਨ ਕਹਾਣੀ ਵਜੋਂ ਲਿਖੋ, ਨਾਂ ਕਿ ਇਕ ਡਾਇਗ੍ਰਾਮ ਵਜੋਂ। ਉਹ ਲਮਹੇ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਆ ਨੂੰ ਤੋੜਦੇ ਹਨ: ਸਾਈਨ-ਅੱਪ, ਜਦੋਂ ਕੋਈ ਪਹਿਲੀ ਵਾਰੀ ਕੁਝ ਸੰਵੇਦਨਸ਼ੀਲ ਸਾਂਝਾ ਕਰਦਾ ਹੈ, ਨਵਾਂ ਡਿਵਾਈਸ ਜੋੜਨਾ, ਅਤੇ ਖੋਏ ਫੋਨ ਜਾਂ ਲੈਪਟਾਪ ਤੋਂ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਹਰ ਲਮ੍ਹੇ ਨੂੰ ਇੱਕ ਜਾਂ ਦੋ ਵਾਕਾਂ ਵਿੱਚ ਸਮਝਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਉਪਭੋਗੀ ਵੀ ਨਹੀਂ ਸਮਝ ਪਾਵੇਗਾ।
ਫਿਰ bypass points ਲੱਭੋ: ਉਹ ਥਾਵਾਂ ਜਿੱਥੇ ਇੱਕ ਆਮ ਵਿਅਕਤੀ ਛੋਟਾ ਰਾਹ ਲੈਂਦਾ ਹੈ ਕਿਉਂਕਿ ਸੁਰੱਖਿਅਤ ਰਾਹ ਧੀਮਾ ਜਾਂ ਉਲਝਣ ਭਰਾ ਲੱਗਦਾ ਹੈ। "ਅਸਥਾਈ" ਕੋਡਾਂ ਦੀ ਸਕਰੀਨਸ਼ਾਟ, ਨੋਟਾਂ ਵਿੱਚ ਗੁਪਤਾਂ ਦੀ ਕਾਪੀ, ਇੱਕੋ ਪਾਸਵਰਡ ਦੀ ਦੁਹਰਾਈ, ਜਾਂ ਐਪ ਤੋਂ ਬਾਹਰ ਫਾਇਲ ਭੇਜਣਾ — ਇਹ ਸਾਰੇ feedback ਹਨ। ਬਾਈਪਾਸ ਨੂੰ ਉਪਭੋਗੀ ਦੀ ਗਲਤੀ ਨਾ ਸਮਝੋ, ਬਲਕਿ ਡਿਜ਼ਾਈਨ ਬਾਰੇ ਫੀਡਬੈਕ ਸਮਝੋ।
ਇੱਕ ਵਿਹਾਰਕ ਬਣਾਉਣ ਦਾ ਆਰਡਰ:
ਰਿਕਵਰੀ ਅਤੇ ਰੋਲਬੈਕ ਨੂੰ ਖਾਸ ਧਿਆਨ ਦਿਓ ਕਿਉਂਕਿ ਉਹ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਲੋਕ ਸਿਸਟਮ 'ਤੇ ਭਰੋਸਾ ਕਰਨਗੇ। "ਕੋਈ ਰਾਹ ਵਾਪਸ ਨਹੀਂ" ਫਲੋ ਲੋਕਾਂ ਨੂੰ ਅਸੁਰੱਖਿਅਤ ਵਰਕਅਰਾਉੰਡ ਵੱਲ ਧਕਕਾ ਦਿੰਦਾ ਹੈ। ਜੇ ਸਾਂਝਾ ਗਲਤ ਵਿਅਕਤੀ ਨੂੰ ਹੋ ਜਾਂਦਾ ਹੈ, ਕੀ ਇਹ ਰੱਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ? ਜੇ ਕੋਈ ਡਿਵਾਈਸ ਖੋ ਜਾਂਦਾ ਹੈ, ਕੀ ਮਲਕੀਅਤ ਤੇਜ਼ੀ ਨਾਲ ਰੋਕੀ ਜਾ ਸਕਦੀ ਹੈ ਬਿਨਾਂ ਅਸਲ ਮਾਲਿਕ ਨੂੰ ਦਿਨਾਂ ਲਈ ਬਾਹਰ ਰੱਖਣ ਦੇ?
ਜੇ ਤੁਹਾਡਾ ਉਤਪਾਦ snapshots ਅਤੇ rollback ਨੂੰ ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ (ਜਿਵੇਂ Koder.ai ਕਰਦਾ ਹੈ), ਤਾਂ ਸੁਰੱਖਿਆ ਕਾਰਵਾਈਆਂ 'ਤੇ ਵੀ ਉਹੀ ਸੋਚ ਲਾਉ: ਅਪਰਿਵਰਤਨੀ ਕਦਮ ਦਰਦਨਾਕ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ "undo" ਆਸਾਨ ਹੋਵੇ ਜਦੋਂ ਇਹ ਸੁਰੱਖਿਅਤ ਹੋ ਸਕੇ।
ਆਖਿਰਕਾਰ, ਗੈਰ-ਟੈਕਨੀਕੀ ਉਪਭੋਗਤਾਵਾਂ ਨਾਲ ਟੈਸਟ ਕਰੋ ਅਤੇ ਦੇਖੋ ਕਿ ਉਹ ਕਿੱਥੇ ਰੁਕਦੇ ਹਨ। "ਕੀ ਤੁਸੀਂ X ਕਰਦੇ?" ਪੁੱਛਣ ਦੀ ਬਜਾਏ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਟਾਰਗੇਟ ਦਿਓ ਅਤੇ ਚੁੱਪ ਰਹੋ।
ਵੇਖੋ ਕਿ ਉਹ ਕਿੱਥੇ ਹਿੱਚਕਿੰਦੇ ਹਨ, ਟੈਕਸਟ ਦੋਹਰਾਉਂਦੇ ਹਨ, ਐਪਾਂ ਬਦਲਦੇ ਹਨ (ਨੋਟ, ਕੈਮਰਾ, ਈਮੇਲ), ਗਲਤ ਅਨੁਮਾਨ ਲਗਾਉਂਦੇ ਹਨ ਤੇ ਖੁਦ ਨੂੰ ਦੋਸ਼ੀ ਮੰਨਦੇ ਹਨ, ਜਾਂ ਸੁਰੱਖਿਅਤ ਰਾਹ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਉਹ ਲਹਿਰਾਂ ਟ੍ਰੈਕ ਕਰੋ, ਫਲੋ ਸਧਾਰੋ, ਅਤੇ ਫਿਰ ਫੇਰ ਟੈਸਟ ਕਰੋ।
ਸੁਰੱਖਿਆ ਸਭ ਤੋਂ ਵੱਧ ਉਸ ਵੇਲੇ ਫੇਲ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਸੁਰੱਖਿਅਤ ਰਾਹ ਉਲਝਣ ਭਰਾ, ਧੀਮਾ, ਜਾਂ ਜੋਖਮ-ਭਰਿਆ ਲੱਗੇ। ਲੋਕ ਨੀਤੀ ਭੰਗ ਕਰਨ ਲਈ ਜਾਗਰੂਕ ਨਹੀਂ ਹੁੰਦੇ; ਉਹ ਸਿਰਫ਼ ਕੰਮ ਖਤਮ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ, ਅਤੇ ਉਹ ਉਹੀ ਚੋਣ ਕਰਦੇ ਹਨ ਜੋ ਨਿਸ਼ਚਿਤ ਲੱਗਦੀ ਹੈ।
ਉਹ ਆਮ ਫੰਦ ਜੋ ਲੋਕਾਂ ਨੂੰ ਅਸੁਰੱਖਿਅਤ ਵਰਕਅਰਾਉਂਡ ਵੱਲ ਧਕਕਾ ਦਿੰਦੇ ਹਨ:
ਸਧਾਰਣ ਉਦਾਹਰਨ: ਇਕ ਮੈਨੇਜਰ ਨੂੰ ਮੀਟਿੰਗ ਦੌਰਾਨ ਨਵੇਂ ਠੇਕੇਦਾਰ ਨਾਲ ਇੱਕ ਸੰਵਿਧਾਨ ਸਾਂਝਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਜੇ ਠੇਕੇਦਾਰ ਨੂ ਜੋੜਨ ਲਈ ਕੋਡ ਸਕੈਨ ਕਰਨ, ਲੰਬੀਆਂ ਸਤਰਾਂ ਤੁਲਨਾ ਕਰਨ, ਅਤੇ "ਅਣਜਾਣ ਪਛਾਣ" ਬਾਰੇ ਚੇਤਾਵਨੀ ਪੜ੍ਹਨੀਆਂ ਪੈਣ, ਉਹ ਸ਼ਾਇਦ ਫਾਇਲ ਈਮੇਲ ਕਰ ਦੇਵੇਗਾ ਜਾਂ ਚੈਟ 'ਤੇ ਪੇਸਟ ਕਰ ਦੇਵੇਗਾ। ਸੁਰੱਖਿਅਤ ਟੂਲ ਕ੍ਰਿਪਟੋ ਕਮਜ਼ੋਰ ਹੋਣ ਕਾਰਨ ਨਹੀਂ ਹਾਰਿਆ; ਉਹ ਇਸ ਲਈ ਹਾਰਿਆ ਕਿ ਉਹ ਅਣਵਿਸ਼ਵਾਸਤਾਪੂਰਣ ਲੱਗਦਾ ਸੀ।
ਹੱਲ ਅਕਸਰ ਵਧੇਰੇ ਸਿੱਖਿਆ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਸਪੱਸ਼ਟ, ਤੇਜ਼ ਰਾਹ ਹੁੰਦਾ ਹੈ ਜੋ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਹੋਵੇ, ਰਿਕਵਰੀ ਅਤੇ ਟਰੱਸਟ ਫੈਸਲੇ ਸ਼ੁਰੂ ਵਿੱਚ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਦਿਖਾਏ ਜਾ ਰਹੇ ਹੋਣ।
ਵਰਤਣਯੋਗ ਇਨਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਇੱਕ ਚੈਕਆਉਟ ਫਲੋ ਵਾਂਗ ਸਮਝੋ: ਇਸਨੂੰ ਸਮਾਂ ਮਾਪੋ, ਅਸਲੀ ਲੋਕਾਂ ਨੂੰ ਕਰਵਾਓ, ਅਤੇ ਮੰਨੋ ਕਿ ਉਹ ਕੋਈ ਵੀ ਚੀਜ਼ ਛੱਡ ਦੇਣਗੇ ਜੋ ਉਲਝਣ ਭਰੀ ਲੱਗੇ।
ਨਵਾਂ ਉਪਭੋਗੀ ਦੋ ਮਿੰਟ ਤੋਂ ਘੱਟ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਸੈਟਅੱਪ ਖਤਮ ਕਰ ਲੈਵੇ ਬਿਨਾਂ ਡੌਕਸ ਪੜ੍ਹੇ ਜਾਂ ਛੁਪੀਆਂ ਚੋਣਾਂ ਲੱਭਣ ਤੋਂ। ਜੇ ਤੁਹਾਡਾ ਫਲੋ "ਇਸ ਕੋਡ ਨੂੰ ਸੁਰੱਖਿਅਤ ਥਾਂ ਤੇ ਸੇਵ ਕਰੋ" ਤੇ ਨਿਰਭਰ ਹੈ ਬਿਨਾਂ ਮਦਦ ਦੇ, ਤਾਂ ਉਮੀਦ ਕਰੋ ਕਿ ਲੋਕ ਇਸਦੀ ਸਕਰੀਨਸ਼ਾਟ ਲੈ ਲੈਣਗੇ, ਗੁੁੰਮ ਕਰ ਦੇਣਗੇ, ਜਾਂ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦੇਣਗੇ।
ਡਿਵਾਈਸ ਬਦਲਣ ਪੈਰਾਂ 'ਤੇ ਘਬਰਾਹਟ ਨਹੀਂ ਉਤਪੰਨ ਹੋਣੀ ਚਾਹੀਦੀ। ਪੁੱਛੋ ਕਿ ਪੁਸ਼ਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਪਸ਼ਟ ਕੀ ਹੋਵੇਗਾ: ਕਿਹੜਾ ਡੇਟਾ ਚਲਦਾ ਹੈ, ਕਿਹੜਾ ਨਹੀਂ, ਅਤੇ ਇਸਨੂੰ ਕਿਵੇਂ ਉਲਟਣਾ ਹੈ। "ਤੁਸੀਂ ਕਦੇ ਵਾਪਸ ਨਹੀਂ ਪਾ ਸਕੋਗੇ" ਵਰਗੀਆਂ ਅਚਾਨਕ ਘੜੀਆਂ ਤੋਂ ਬਚੋ।
ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੁਝ ਮੁੱਖ ਚੀਜ਼ਾਂ ਨੂੰ ਜਾਂਚੋ:
ਨਿਰਯਾਤਾਂ ਤੋਂ ਬਾਅਦ, ਐਕਟਿਵਿਟੀ ਹਿਸਟਰੀ ਵਿੱਚ ਸਪਸ਼ਟ ਨਿਸ਼ਾਨ ਛੱਡੋ: ਕੀ ਨਿਰਯਾਤ ਕੀਤਾ ਗਿਆ, ਕਦੋਂ, ਤੇ ਕਿਹੜੇ ਡਿਵਾਈਸ ਤੋਂ। ਇਹ ਦੋਸ਼ ਲਗਾਉਣ ਲਈ ਨਹੀਂ, ਬਲਕਿ ਗਲਤੀਆਂ ਨੂੰ ਜਲਦੀ ਪਕੜਨ ਅਤੇ ਭਰੋਸਾ ਬਣਾਉਣ ਲਈ ਮਦਦ ਕਰਦਾ ਹੈ।
ਆਪਣੇ ਐਰਰ ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਉਚਕਾਰ ਕੇ ਪੜ੍ਹੋ। ਜੇ ਉਹ "invalid key" ਜਾਂ "handshake failed" ਵਰਗੇ ਜਰਗਨ ਰੱਖਦੇ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਕਾਰਵਾਈ-ਕੇਂਦਰਤ ਕੈਸੇ ਦੁਬਾਰਾ ਲਿਖੋ: ਕੀ ਹੋਇਆ, ਇਸਦਾ ਉਪਭੋਗੀ ਲਈ ਕੀ ਮਤਲਬ ਹੈ, ਅਤੇ ਅਗਲਾ ਸੁਰੱਖਿਅਤ ਕਦਮ ਕੀ ਹੈ।
ਇੱਕ ਤਿੰਨ-ਨਜ਼ਦੀਕੀ ਏਜੰਸੀ ਕਲਾਇੰਟ ਦੇ ਸੰਵਿਧਾਨ ਅਤੇ ਡਿਜ਼ਾਇਨ ਫਾਇਲਾਂ ਦਾ ਸੰਭਾਲਦੀ ਹੈ। ਉਹ ਘਰ ਤੋਂ ਲੈਪਟਾਪ ਤੇ ਅਤੇ ਰਸਤੇ 'ਤੇ ਫੋਨ ਤੋਂ ਕੰਮ ਕਰਦੇ ਹਨ। ਉਹ ਰਾਤ ਨੂੰ ਕੰਟਰੋਲ-ਕਮਿਉਨਿਕੇਸ਼ਨ ਕਰਨ ਲਈ ਸਾਰੇ-ਸਾਦਾ ਤਰੀਕੇ ਨਾਲ ਇਕ ਦੂਜੇ ਨਾਲ ਸੰਦੇਸ਼ ਭੇਜਣੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਉਹ "ਸੁਰੱਖਿਅਤ" ਸੈਟਅੱਪ ਅਜ਼ਮਾਉਂਦੇ ਹਨ ਜੋ ਕਾਗਜ਼ 'ਤੇ ਚੰਗਾ ਦਿਖਦਾ ਹੈ ਪਰ ਮੰਹਗਾ ਲੱਗਦਾ ਹੈ। ਹਰ ਕੋਈ ਹਰ ਵਾਰੀ ਲੰਬੇ ਪਾਸਵਰਡ ਟਾਈਪ ਕਰਦਾ ਹੈ, ਐਪ ਬਹੁਤ ਵਾਰੀ ਲੌਗ ਆਊਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਫੋਲਡਰ ਸਾਂਝਾ ਕਰਨ ਲਈ ਇੱਕ ਡਿਵਾਈਸ ਤੋਂ ਦੂਜੇ ਡਿਵਾਈਸ ਤੇ ਕੀ ਸਟ੍ਰਿੰਗ ਕਾਪੀ ਕਰਨੀ ਪੈਂਦੀ ਹੈ। ਹਫਤੇ ਵਿੱਚ ਹੀ ਵਰਕਅਰਾਉਂਡ ਆ ਜਾਣ: ਇੱਕ ਹੀ ਪਾਸਵਰਡ ਹਰ ਜਗ੍ਹਾ, ਇੱਕ ਸਾਂਝਾ ਖਾਤਾ "ਤਾਂ ਜੋ ਅਸੀਂ ਲੌਕ ਆਊਟ ਨਾ ਹੋਈਏ", ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਸਮੱਗਰੀ ਸਕਰੀਨਸ਼ਾਟ ਵਿੱਚ ਆ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਨਿਰਯਾਤ ਅਤੇ ਦੁਬਾਰਾ-ਇਨਕ੍ਰਿਪਟ ਕਰਨ ਤੋਂ ਤੇਜ਼ ਹੈ।
ਹੁਣ ਉsame flow ਨੂੰ ਵਰਤਣਯੋਗ ਇਨਕ੍ਰਿਪਸ਼ਨ ਨਾਲ ਦੁਬਾਰਾ ਲਿਖੋ।
Alice Ben ਅਤੇ Priya ਨੂੰ ਪਛਾਣ ਦੁਆਰਾ ਸੱਦਾ ਦਿੰਦੀ ਹੈ, ਇੱਕ ਸਪਸ਼ਟ ਟੀਮ ਨਾਂ ਅਤੇ ਕਲਾਇੰਟ ਨਾਂ ਦੇ ਨਾਲ। ਹਰ ਵਿਅਕਤੀ ਆਪਣੇ ਟਰੱਸਟਡ ਡਿਵਾਈਸ 'ਤੇ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। ਰੋਲ ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਸਪਸ਼ਟ ਹਨ: Priya ਠੇਕੇਦਾਰ ਹੈ ਜਿਸਦੀ ਸੀਮਤ ਪਹੁੰਚ ਹੈ, Ben ਮੈਂਬਰ ਹੈ, Alice ਐਡਮਿਨ ਹੈ। ਟਰੱਸਟਡ ਡਿਵਾਈਸ ਲਗਾਤਾਰ re-login ਘਟਾਉਂਦੇ ਹਨ, ਅਤੇ re-auth ਸਿਰਫ਼ ਉਹਨਾਂ ਉੱਚ-ਖਤਰੇ ਵਾਲੇ ਕਾਰਜਾਂ ਲਈ ਹੁੰਦੀ ਹੈ ਜਿਵੇਂ ਡਾਟਾ ਨਿਕਾਸ, ਡਿਵਾਈਸ ਜੋੜਨਾ ਜਾਂ ਰਿਕਵਰੀ ਸੋਧਣਾ।
ਰਿਕਵਰੀ ਹਕੀਕਤ-ਜੀਵਨ ਦੇ ਅਨੁਕੂਲ ਹੈ: ਹਰ ਮੈਂਬਰ ਇੱਕ ਵਾਰੀ ਸੈਟਅੱਪ ਦੌਰਾਨ ਇਕ recovery code ਸੇਵ ਕਰਦਾ ਹੈ, ਸਾਧਾਰਣ ਭਾਸ਼ਾ ਨਾਲ ਕਿਹਾ ਕਿ ਇਹ ਕਦੋਂ ਲੋੜ ਆਵੇਗਾ। ਸਾਂਝਾ ਕਰਨਾ ਤੇਜ਼ ਰਹਿੰਦਾ ਹੈ: "Share to client" ਇੱਕ ਵੱਖਰਾ client space ਬਣਾਉਂਦਾ ਹੈ ਸਪਸ਼ਟ ਲੇਬਲ ਅਤੇ ਮਿਆਦੀ ਵਿਕਲਪਾਂ ਨਾਲ।
ਇਕ ਮਹੀਨੇ ਬਾਅਦ Priya ਨੌਕਰੀ ਛੱਡ ਦਿੰਦੀ ਹੈ। Alice Priya ਦੀ ਪਹੁੰਚ ਰੱਦ ਕਰ ਦਿੰਦੀ ਹੈ। ਸਿਸਟਮ ਡਿਵਾਈਸ ਟਰੱਸਟ ਰੱਦ ਕਰਦਾ ਹੈ, ਸਰਗਰਮ ਸੈਸ਼ਨਾਂ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ, ਅਤੇ client spaces ਦੀਆਂ ਚਾਬੀਆਂ ਉਨ੍ਹਾਂ ਤੇ ਹੱਕ ਰੱਖਣ ਵਾਲੇ ਲੋਕਾਂ ਲਈ ਮੁੜ-ਕੀ ਕਰ ਦਿੰਦਾ ਹੈ। Ben ਅਤੇ Alice ਨੂੰ ਛੋਟੀ ਪੁਸ਼ਟੀ ਮਿਲਦੀ ਹੈ ਟਾਈਮਸਟੈਂਪਾਂ ਸਮੇਤ ਤਾਂ ਜੋ ਉਹਨੂੰ ਸ਼ੱਕ ਨਾ ਰਹੇ ਕਿ ਇਹ ਹੋ ਗਿਆ।
ਛੋਟੀ-ਛੋਟੀ ਚੀਜ਼ਾਂ ਬਾਈਪਾਸ ਰੋਕਦੀਆਂ ਹਨ: ਨਾਮ ਜਿਹਨੇ ਲੋਕ ਬੋਲਦੇ ਹਨ ("Acme - Contracts"), ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ (ਘੱਟ ਪਹੁੰਚ ਪਹਿਲਾਂ), ਅਤੇ ਐਸੇ ਸਮੇਂ ਜਦSetup ਇੱਕ ਹੀ ਵਾਰੀ ਹੁੰਦਾ ਹੈ ਤੇ ਫਿਰ ਬਰਾਮਦ।
ਇੱਕ ਉੱਚ-ਖਤਰੇ ਵਾਲਾ ਫਲੋ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਆਖ਼ਰੀ ਤੱਕ ਠੀਕ ਕਰੋ। ਲੌਗਿਨ, ਸਾਂਝੇਦਾਰੀ, ਅਤੇ ਖਾਤਾ ਰਿਕਵਰੀ ਉਹ ਥਾਵਾਂ ਹਨ ਜਿੱਥੇ ਲੋਕ ਰੁਕਦੇ ਹਨ, ਅਤੇ ਓਥੇ ਉਹ ਅਕਸਰ ਰਾਜ਼ ਨੋਟਾਂ 'ਚ ਪੇਸਟ ਕਰਦੇ, ਪਾਸਵਰਡ ਦੁਹਰਾਉਂਦੇ, ਜਾਂ ਰੱਖਿਆ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ।
ਜਿੱਥੇ ਦਰਦ ਹੈ ਓਥੇ ਮਾਪੋ, ਨਾ ਕਿ ਜਿੱਥੇ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ। ਟ੍ਰੈਕ ਕਰੋ ਜੋ ਕਦਮ ਲੋਕ ਦੁਹਰਾ ਰਹੇ ਹਨ, ਥਾਵਾਂ ਜਿੱਥੇ ਛੱਡਦੇ ਹਨ, ਅਤੇ ਉਹ ਲੱਛੇ ਜਿੱਥੇ ਉਹ ਸਹਾਇਤਾ ਖੋਲ੍ਹਦੇ ਹਨ ਜਾਂ ਸਪੋਰਟ ਨਾਲ ਸੰਪਰਕ ਕਰਦੇ ਹਨ। ਇਹ ਤੁਹਾਡੇ ਸੁਰੱਖਿਆ ਬਾਈਪਾਸ ਹੌਟਸਪਾਟ ਹਨ।
ਫਿਰ ਸਕਰੀਨ ਤੇ ਲਫ਼ਜ਼ ਐਸੇ ਲਿਖੋ ਜੋ ਉਪਭੋਗੀ ਦੇ ਲਕੜਾਂ ਨਾਲ ਮੈਚ ਕਰਦੇ ਹੋਣ। ਚੰਗੀ ਮਾਈਕਰੋਕਾਪੀ ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਵਰਤੋਂਕਾਰ ਕੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ, ਨਾਂ ਕਿ ਕਿਵੇਂ ਕ੍ਰਿਪਟੋ ਕੰਮ ਕਰਦੀ ਹੈ। "Confirm it’s really you to keep your account safe" "Verify your key" ਨਾਲੋਂ ਵੱਧ ਸਪਸ਼ਟ ਹੈ।
ਇੱਕ ਕਾਰਜ-ਚੱਕਰ ਜੋ ਕੰਮ ਕਰਦਾ ਹੈ:
ਜੇ ਤੁਸੀਂ ਇੱਕ ਐਪ ਬਣਾ ਰਹੇ ਹੋ ਅਤੇ ਇਨ੍ਹਾਂ ਫਲੋਜ਼ ਦਾ ਪ੍ਰੋਟੋਟਾਇਪ ਤਿਆਰ ਕਰਨ ਲਈ ਤੇਜ਼ ਤਰੀਕਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai ਤੁਹਾਨੂੰ auth ਅਤੇ sharing ਦੇ ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਸਹਾਇਤਾ ਕਰ ਸਕਦਾ ਹੈ, ਫਿਰ snapshopts ਅਤੇ rollback 'ਤੇ ਨਿਰਭਰ ਹੋ ਕੇ ਤੁਸੀਂ ਅਸਲ ਉਪਭੋਗਤਾਵਾਂ ਨਾਲ ਸੁਰੱਖਿਅਤ UX ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ।
"Usable encryption" ਦਾ ਮਤਲਬ ਹੈ ਕੇ ਇਨਕ੍ਰਿਪਸ਼ਨ ਅਜਿਹੇ ਫਲੋ ਵਿੱਚ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਜਿਸਨੂੰ ਲੋਕ ਅਸਲ ਹਾਲਾਤਾਂ (ਵਿਆਸਤ, ਤਣਾਅ ਵਿੱਚ, ਨਵੇਂ ਡਿਵਾਈਸ ਤੇ, ਜਲਦੀ ਵਿੱਚ) ਵਿੱਚ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਪੂਰਾ ਕਰ ਸਕਣ।
ਕ੍ਰਿਪਟੋ ਕਾਬਲ-ਏ-ਤਾਕਤ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਜੇ ਕਦਮ ਉਲਝਣ ਭਰੇ ਹਨ, ਲੋਕ ਸਕਰੀਨਸ਼ਾਟ ਲੈ ਕੇ, ਗੁਪਤ ਕੌੜੀਆਂ ਕਾਪੀ ਕਰਕੇ ਜਾਂ ਅਸੁਰੱਖਿਅਤ ਚੈਨਲਾਂਤੇ ਜਾਣ ਦੇ ਰਾਹ ਲੈ ਲੈਂਦੇ ਹਨ।
ਝੰਝਟ ਲੋਕਾਂ ਨੂੰ ਛੋਟੇ-ਰਸਤੇ ਲੈ ਜਾਂਦੀ ਹੈ। ਆਮ ਕਾਰਜ:
ਇਹ
ਜ਼ਿਆਦਾਤਰ ਵਾਰ ਚੇਤਾਵਨੀਆਂ ਲੋਕਾਂ ਨੂੰ ਅਗਲਾ ਕਦਮ ਨਹੀਂ ਦੱਸਦੀਆਂ।
ਇੱਕ ਵਧੀਆ ਨਮੂਨਾ ਇਹ ਹੈ: ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਅਸਲੀ ਨਤੀਜਾ ਅਤੇ ਫਿਰ ਸਪਸ਼ਟ ਕਾਰਵਾਈ। ਉਦਾਹਰਨ: “Anyone with this link can view the file. Share with specific people instead.”
ਮੁੱਖ ਰਾਹ ਵਿੱਚ ਇੱਕ ਸਿਫਾਰਸ਼ੀ ਚੋਣ ਰੱਖੋ, ਅਤੇ ਅਗਲੇ ਵਿਕਲਪਾਂ ਨੂੰ ਉਸ ਵੇਲੇ ਲਿਖੋ ਜਦੋਂ ਵਰਤੋਂਕਾਰ ਨੂੰ ਲੋੜ ਹੋਵੇ।
ਜੇ ਤੁਸੀਂ ਵਿਕਲਪ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਚੋਣ ਇਕ ਸਧਾਰਨ ਵਾਕ ਵਿੱਚ ਸਮਝਾਓ ਅਤੇ ਸੁਰੱਖਿਅਤ ਚੋਣ ਹੋਸਤੀ ਆਸਾਨ ਬਣਾਓ।
ਰਿਕਵਰੀ ਸੁਰੱਖਿਆ ਦਾ ਹਿੱਸਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਵਰਤਣਯੋਗ ਸਿਸਟਮ:
ਇਹ ਸਪਸ਼ਟਤਾ خطرناک ਹੈਕਸ ਨੂੰ ਰੋਕਦੀ ਹੈ, ਜਿਵੇਂ ਨੋਟਾਂ ਵਿੱਚ ਗੁਪਤ ਸਟੋਰ ਕਰਨਾ।
ਦੈਨ੍ਹਾਂ ਕੰਮਾਂ ਲਈ ਉਦਯੋਗੀ ਚੈੱਕ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ ਜਦੋਂ ਸੁਰੱਖਿਆ ਦਾ ਨਕਸ਼ਾ ਬਦਲਦਾ ਹੈ।
ਚੰਗੇ ਟ੍ਰਿਗਰਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ: ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਨਿਰਯਾਤ, ਨਵਾਂ ਡਿਵਾਈਸ ਜੋੜਨਾ, ਸਾਂਝੇ ਕਰਨ ਦੀਆਂ ਪਰਮੀਸ਼ਨ ਬਦਲਣਾ, ਰਿਕਵਰੀ ਤਰੀਕੇ ਬਦਲਣਾ, ਜਾਂ ਐਡਮਿਨ ਰੋਲ ਬਦਲਣਾ। ਜਦੋ ਰੀ-ਆਥ ਦੀ ਲੋੜ ਹੋਵੇ, ਉਪਭੋਗੀ ਉਸਨੇਵੇਂ ਕਾਰਨ ਨਾਲ ਸਹਿਮਤ ਹੁੰਦੇ ਹਨ।
ਕਿਸੇ ਨੂੰ ਅਮੰਤ੍ਰਿਤ ਕਰਕੇ ਸ਼ੇਅਰ ਕਰਨ ਦੀ ਥਾਂ, ਸ਼ੁਰੂ ਕਰੋ ਇੱਕ invite flow ਨਾਲ।
ਪਰਮੀਸ਼ਨ ਸਪਸ਼ਟ ਰੱਖੋ (view/edit/manage), ਸੰਵੇਦਨਾ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਲਈ ਅਵਧੀ ਨਿਰਧਾਰਤ ਰੱਖੋ, ਅਤੇ ਰੱਦ ਕਰਨ ਦੀ ਕਾਰਵਾਈ ਤੇਜ਼ ਅਤੇ ਸਪਸ਼ਟ ਹੋਵੇ।
ਜੇ ਗਲਤ ਮਨੁੱਖ ਨੂੰ ਸਾਂਝਾ ਹੋ ਜਾਵੇ ਤਾਂ ਉਸਨੂੰ ਰੱਦ ਕਰਨਾ ਤੇਜ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਚਾਬੀਆਂ (keys) ਹੱਥੋਂ ਸੰਭਾਲਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।
ਸਿਸਟਮ ਸਵੈ-ਚਾਲਿਤ ਤਰੀਕੇ ਨਾਲ ਚਾਬੀਆਂ ਬਣਾਏ, ਇਹਨਾਂ ਨੂੰ ਡਿਵਾਈਸ ਦੀ ਸੁਰੱਖਿਅਤ ਸਟੋਰੇਜ ਵਿੱਚ ਰੱਖੇ, ਅਤੇ ਜਰੂਰਤ ਪੈਣ 'ਤੇ ਰੋਟੇਟ ਕਰੇ। ਅਡਵਾਂਸ ਪਾਵਰ ਯੂਜ਼ਰਾਂ ਲਈ ਨਿਰਯਾਤ ਜਾਂ ਐਡਮਿਨ-ਮੇਨੇਜਡ ਚਾਬੀਆਂ ਦਾ ਵਿਕਲਪ ਰੱਖੋ, ਪਰ ਹਰ ਕਿਸੇ ਨੂੰ ਉਹ ਮੋਡ ਫੋਜ਼ ਨਾ ਕਰੋ।
ਪ੍ਰੋਗ੍ਰੈਸਿਵ ਡਿਸਕਲੋਜ਼ਰ: ਸਿਰਫ਼ ਉਹੀ ਦਿਖਾਓ ਜੋ ਮੌਜੂਦਾ ਕਦਮ ਪੂਰਾ ਕਰਨ ਲਈ ਲੋੜੀਦਾ ਹੈ, ਅਤੇ ਵੇਰਵੇ ਤਦ ਹੀ ਦਿਖਾਓ ਜਦੋਂ ਉਪਭੋਗੀ ਮੰਗੇ ਜਾਂ ਜਦੋਂ ਖਤਰਾ ਬਦਲੇ।
ਇਸ ਨਾਲ settings ਦੀ ਭਾਰੀ ਕੰਧ ਤੋਂ ਬਚਾਅ ਹੋਦਾ ਹੈ ਅਤੇ ਲੋਕ ਬਿਨਾਂ ਸੋਚੇ-ਸਮਝੇ ਵਿਕਲਪ ਨਹੀਂ ਟੌਗਲ ਕਰਦੇ।
ਗੈਰ-ਟੈਕਨੀਕੀ ਉਪਭੋਗਤਾਵਾਂ ਨਾਲ ਟੈਸਟ ਕਰੋ ਅਤੇ ਰਵੱਈਏ ਨੂੰ ਦੇਖੋ, ਰਾਏ ਨਹੀਂ।
ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਟਾਰਗੇਟ ਦਿਓ (ਸੰਵੇਦਨਸ਼ੀਲ ਫਾਇਲ ਸਾਂਝੀ ਕਰੋ, ਡਿਵਾਈਸ ਜੋੜੋ, ਖਾਤਾ ਰਿਕਵਰ ਕਰੋ) ਅਤੇ ਖਾਮੋਸ਼ ਰਹੋ। ਜਿੱਥੇ ਉਹ ਹਿੱਚਕਿਓਂਦੇ ਹਨ, ਟੈਕਸਟ ਦੁਬਾਰਾ ਪੜ੍ਹਦੇ ਹਨ, ਕੈਮਰਾ/ਨੋਟ/ਈਮੇਲ ਵਰਗੀਆਂ ਐਪਾਂ 'ਤੇ ਜਾਦਾ ਜਾਂਦੇ ਹਨ, ਉਹ ਤੁਹਾਡੇ ਬਾਈਪਾਸ ਪੁਆਇੰਟ ਹਨ।
