ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ

• ਇਸ ਸਾਈਟ ਦਾ ਮਾੜਾ ਅਨੁਵਾਦ ਕਿਉਂ ਕੀਤਾ ਗਿਆ ਹੈ? ⎃
• ਇਹ ਸੇਵਾ ਕਿੰਨੀ ਸੁਰੱਖਿਅਤ ਹੈ?
• ਮੈਨੂੰ ਇੱਕ ਸੁਨੇਹਾ ਡਿਕ੍ਰਿਪਟ ਕਰਨ ਦੇ ਵਿਕਲਪ ਦੇ ਨਾਲ ਇੱਥੇ ਇੱਕ ਲਿੰਕ ਕਿਉਂ ਮਿਲਿਆ?
• ਕੀ ਤੁਸੀਂ ਇਸ ਸਾਈਟ ਤੇ ਜਮ੍ਹਾਂ ਕੀਤੀ ਹਰ ਚੀਜ ਨੂੰ ਮਿਟਾਉਂਦੇ ਹੋ?
• ਇਸ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਿਉਂ ਕਰੀਏ?
• ਕੀ ਇਹ ਇੱਕ ਸੁਨੇਹਾ ਦੇਣ ਵਾਲੀ ਸੇਵਾ ਹੈ?
• ਵਰਤੋਂ ਦੇ ਉਦੇਸ਼ ਕੀ ਹਨ?
• ਇਹ ਸੇਵਾ ਕਿਸ ਲਈ ਨਹੀਂ ਵਰਤੀ ਜਾ ਸਕਦੀ?
• ਕਿਉਂ ਨਾ ਸਿਰਫ ਪੀਜੀਪੀ / ਸਿਗਨਲ / ਓਮੇਮੋ / ਮੈਟ੍ਰਿਕਸ / ਆਦਿ ਦੀ ਵਰਤੋਂ ਕਰੋ.
• ਕਿਹੜੀਆਂ ਲੋੜਾਂ ਹਨ?
• ਕੀ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਸੁਨੇਹੇ ਦੀ ਇੱਕ ਕਾਪੀ ਬਣਾ ਸਕਦੇ ਹਨ?
• ਕੀ ਕੋਈ ਨਿੱਜੀ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕੀਤੀ ਗਈ ਹੈ?
• ਕਿਹੜੀ ਜਾਣਕਾਰੀ ਲੌਗ ਕੀਤੀ ਗਈ ਹੈ?
• ਤੁਸੀਂ ਸਰਵਰਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ ਕੀ ਕਰ ਰਹੇ ਹੋ?
• ਇਸ ਸਾਈਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਕਿਹੜੇ ਸੁਰੱਖਿਆ ਜੋਖਮ ਮੌਜੂਦ ਹਨ?
• ਮੈਨ-ਇਨ-ਦ-ਮਿਡਲ (ਐਮਆਈਟੀਐਮ) ਹਮਲਿਆਂ ਬਾਰੇ ਤੁਸੀਂ ਕੀ ਕਰ ਰਹੇ ਹੋ?
• ਬ੍ਰਾ browserਜ਼ਰ ਐਕਸਟੈਂਸ਼ਨ ਕਿਹੜੇ ਫਾਇਦੇ ਪੇਸ਼ ਕਰਦੇ ਹਨ?
• ਮੈਂ ਕਿਵੇਂ ਪੱਕਾ ਜਾਣ ਸਕਦਾ ਹਾਂ ਕਿ ਜਮ੍ਹਾਂ ਕੀਤੀ ਗਈ ਕੋਈ ਵੀ ਚੀਜ਼ ਅੰਤ ਤੋਂ ਟੂ-ਐਂਡ੍ਰਿਪਟਡ ਹੈ?
• ਇਸ ਸਾਈਟ ਤੇ ਐਂਡ-ਟੂ-ਐਂਡ ਇਨਕ੍ਰਿਪਸ਼ਨ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ?
• ਡੀਕ੍ਰਿਪਸ਼ਨ ਪਾਸਵਰਡ ਯੂਆਰਐਲ ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ?
• ਪਰ ਡੀਕ੍ਰਿਪਸ਼ਨ ਪਾਸਵਰਡ URL ਵਿੱਚ ਹੋਣਾ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ?
• ਇਹ ਸੇਵਾ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਨੂੰ ਲਿੰਕ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦੀ?
• ਇਸ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰਦਿਆਂ ਮੈਂ ਆਪਣੀ ਗੋਪਨੀਯਤਾ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਸੁਰੱਖਿਅਤ ਕਿਵੇਂ ਕਰ ਸਕਦਾ ਹਾਂ?
• ਜੇ ਮੈਂ ਸੰਯੁਕਤ ਰਾਜ ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦਾ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?
• ਤੁਸੀਂ ਸਪੈਮ ਨੂੰ ਰੋਕਣ ਲਈ ਕੀ ਕਰ ਰਹੇ ਹੋ?
• ਇੱਥੇ ਇੱਕ ਵਿਕਲਪ ਕਿਉਂ ਹੈ ਕਿ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਨੂੰ ਕੈਪਟਚਾ ਪੂਰਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ?
• ਇਹ ਸੇਵਾ ਕੌਣ ਚਲਾ ਰਿਹਾ ਹੈ ਅਤੇ ਇਹ ਮੁਫਤ ਕਿਉਂ ਹੈ?
• ਮੈਂ ਉਪਰੋਕਤ ਪ੍ਰਸ਼ਨਾਂ ਦੇ ਉੱਤਰਾਂ ਤੇ ਕਿਵੇਂ ਭਰੋਸਾ ਕਰ ਸਕਦਾ ਹਾਂ?

ਇਸ ਸਾਈਟ ਦਾ ਮਾੜਾ ਅਨੁਵਾਦ ਕਿਉਂ ਕੀਤਾ ਗਿਆ ਹੈ? ⎃

ਮੁਆਫ ਕਰਨਾ, ਪਰ ਮੌਜੂਦਾ ਲੇਖਕ ਸਿਰਫ ਅੰਗ੍ਰੇਜ਼ੀ ਬੋਲਦੇ ਹਨ. ਸਾਨੂੰ ਇਸ ਪ੍ਰੋਜੈਕਟ ਦਾ ਦੂਜੀ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਨ ਵਿੱਚ ਮਦਦ ਦੀ ਲੋੜ ਹੈ. ਇਸ ਸੇਵਾ ਨੂੰ ਉਹਨਾਂ ਲੋਕਾਂ ਲਈ ਉਪਲਬਧ ਕਰਾਉਣ ਦੇ ਇੱਕ ਸਧਾਰਣ ਅਤੇ ਸਸਤੇ ਸਾਧਨਾਂ ਵਜੋਂ ਜੋ ਅਸੀਂ ਅੰਗ੍ਰੇਜ਼ੀ ਨਹੀਂ ਬੋਲਦੇ, ਅਸੀਂ ਮਸ਼ੀਨ ਅਨੁਵਾਦ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ. ਨਤੀਜੇ ਆਮ ਤੌਰ ਤੇ ਸਵੀਕਾਰੇ ਜਾਂਦੇ ਹਨ, ਪਰ ਨਤੀਜੇ ਵਜੋਂ ਅਜੀਬੋ ਗਰੀਬ ਸ਼ਬਦਾਂ ਜਾਂ ਪੂਰੀ ਗਲਤ ਜਾਣਕਾਰੀ ਹੋ ਸਕਦੀ ਹੈ. ਤੁਸੀਂ ਹਰੇਕ ਲਈ ਤਜ਼ਰਬੇ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਵਿੱਚ ਸਾਡੀ ਸਹਾਇਤਾ ਕਰ ਸਕਦੇ ਹੋ - ਕਿਰਪਾ ਕਰਕੇ ਸਹੀ ਅਨੁਵਾਦ ਕਰੋ .

ਇਹ ਸੇਵਾ ਕਿੰਨੀ ਸੁਰੱਖਿਅਤ ਹੈ?

ਅਸੀਂ ਇਸ ਸੇਵਾ ਨੂੰ ਇਸਦੀ ਵਰਤੋਂ ਲਈ ਸੁਰੱਖਿਅਤ ਬਣਾਉਣ ਲਈ ਬਹੁਤ ਸਾਰੇ ਕਦਮ ਚੁੱਕੇ ਹਨ. ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਅਸੀਂ ਇਨ੍ਹਾਂ ਕਦਮਾਂ ਨੂੰ ਪਾਰ ਕਰੀਏ, ਹੇਠ ਲਿਖਿਆਂ ਨੂੰ ਸਮਝਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ:

• ਜਦੋਂ ਕਿ ਅਸੀਂ ਤੁਹਾਡੇ ਸੁਨੇਹੇ ਨੂੰ ਐਂਡ-ਟੂ-ਐਂਡ ਇਨਕ੍ਰਿਪਸ਼ਨ ਦੇ ਕਾਰਨ ਪੜ੍ਹਨ ਦੇ ਅਯੋਗ ਹੁੰਦੇ ਹਾਂ , ਪਹਿਲਾਂ ਤਿਆਰ ਲਿੰਕ ਵਿੱਚ ਡਿਸਕ੍ਰਿਪਸ਼ਨ ਪਾਸਵਰਡ / ਕੁੰਜੀ ਹੁੰਦੀ ਹੈ ; ਅਤੇ ਇਸ ਲਈ, ਲਿੰਕ ਦੇ ਕਬਜ਼ੇ ਵਿਚ ਕੋਈ ਵੀ ਤੁਹਾਡਾ ਸੰਦੇਸ਼ ਪੜ੍ਹ ਸਕਦਾ ਹੈ - ਜਿਸ ਵਿੱਚ ਕੋਈ ਵੀ ਇਸ ਨੂੰ ਰੋਕਣ ਦੇ ਯੋਗ ਹੁੰਦਾ ਹੈ.
• ਇਹ ਸੇਵਾ ਸਿਰਫ ਇਕ ਸੰਦ ਹੈ ਜੋ ਘੱਟ ਸਥਾਈ ਸੰਚਾਰ (ਜਿਵੇਂ ਕਿ ਇਕ੍ਰਿਪਟਡ ਸੁਨੇਹੇ ਜੋ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ 'ਤੇ ਮਿਟਾਏ ਗਏ ਹਨ) ਰਵਾਇਤੀ ਟ੍ਰਾਂਸਪੋਰਟਾਂ ਦੁਆਰਾ ਵਧੇਰੇ ਸਥਾਈ (ਜਿਵੇਂ ਕਿ ਈਮੇਲ / ਟੈਕਸਟ / ਇੰਸਟੈਂਟ-ਮੈਸੇਜਿੰਗ / ਵੈੱਬ ਸਾਈਟ / ਆਦਿ) ਭੇਜਣ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ. ਇਸਦਾ ਅਰਥ ਇਹ ਹੈ ਕਿ ਚੁਣੀ ਟ੍ਰਾਂਸਪੋਰਟ (ਜਿਵੇਂ ਕਿ ਈਮੇਲ) ਦੇ ਅੰਦਰਲੀ ਕੋਈ ਸੁਰੱਖਿਆ / ਗੁਪਤਤਾ ਦੇ ਮੁੱਦੇ ਵਿਰਾਸਤ ਵਿੱਚ ਆਉਂਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਇਸ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ .
• ਇੱਥੇ ਹੋਰ ਹੱਲ ਉਪਲਬਧ ਹਨ ਜੋ ਤੁਹਾਡੀਆਂ ਜ਼ਰੂਰਤਾਂ ਅਤੇ ਵਾਤਾਵਰਣ ਦੇ ਅਧਾਰ ਤੇ ਬਿਹਤਰ ਸੁਰੱਖਿਆ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ. ਦੂਜਿਆਂ ਦੇ ਮੁਕਾਬਲੇ ਇਹ ਸੇਵਾ ਜੋ ਮੁੱਖ ਲਾਭ ਪੇਸ਼ ਕਰਦੀ ਹੈ, ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਿਆਂ ਲਈ ਬਹੁਤ ਘੱਟ ਜ਼ਰੂਰਤਾਂ ਹਨ (ਭਾਵ ਉਹਨਾਂ ਨੂੰ ਸਿਰਫ ਇੱਕ ਵੈੱਬ ਬਰਾ browserਜ਼ਰ ਅਤੇ ਇੱਕ ਲਿੰਕ ਤੇ ਕਲਿਕ ਕਰਨ ਦੀ ਯੋਗਤਾ ਦੀ ਜਰੂਰਤ ਹੈ).
• ਜਦੋਂ ਕਿ ਡਿਫੌਲਟ ਸੈਟਿੰਗ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਤੇ ਸੁਨੇਹਿਆਂ ਨੂੰ ਮਿਟਾਉਣਾ ਹੈ, ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਨੂੰ ਇੱਕ ਕਾੱਪੀ ਬਣਾਉਣ ਤੋਂ ਰੋਕਣ ਲਈ ਕੁਝ ਵੀ ਨਹੀਂ ਹੈ . ਯਾਦ ਰੱਖੋ ਕਿ ਇਹ ਸਾਰੇ ਅਸਥਾਈ ਸੰਦੇਸ਼ ਹੱਲਾਂ ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ - ਜੇ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ ਸੁਨੇਹਾ ਵੇਖ ਸਕਦਾ ਹੈ, ਤਾਂ ਇਸਦੀ ਨਕਲ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ.
• ਸਾਰੇ ਇੰਟਰਨੈਟ ਸੰਚਾਰ ਤੁਹਾਡੀ ਗੋਪਨੀਯਤਾ ਨਾਲ ਸਮਝੌਤਾ ਕਰ ਸਕਦੇ ਹਨ - ਤੁਸੀਂ ਸਹੂਲਤ ਲਈ ਕੁਝ ਸੁਰੱਖਿਆ ਦਾ ਵਪਾਰ ਕਰ ਰਹੇ ਹੋ.
• ਵੈੱਬ ਇੱਕ ਚੁਣੌਤੀ ਭਰਪੂਰ ਮਾਹੌਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੁਝ ਬੁਨਿਆਦੀ ਮੁੱਦਿਆਂ ਦੇ ਕਾਰਨ ਸੁਰੱਖਿਆ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ - ਇਹ ਸਾਰੀਆਂ ਵੈਬ ਸਾਈਟਾਂ ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ. ਹਾਲਾਂਕਿ, ਵੈਬ-ਬੇਸਡ ਹੋਣਾ ਸਾਡੇ ਦਾਅਵੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਅਸੀਂ ਤੁਹਾਡੇ ਸੰਦੇਸ਼ ਨੂੰ ਵਧੇਰੇ ਸੌਖਾ ਨਹੀਂ ਪੜ੍ਹ ਸਕਦੇ .
• ਇਹ ਵੈੱਬ ਸਾਈਟ ਅਤੇ ਇਸਦਾ ਡੇਟਾਬੇਸ ਸੰਯੁਕਤ ਰਾਜ ਅਮਰੀਕਾ ਵਿੱਚ ਹੋਸਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ. ਅਸੀਂ ਕਲਾਉਡਫਲੇਅਰ, ਯੂਨਾਈਟਿਡ ਸਟੇਟ ਵਿੱਚ ਅਧਾਰਤ ਇੱਕ ਕੰਪਨੀ, ਸਾਡੇ ਸਮਗਰੀ-ਸਪੁਰਦਗੀ-ਨੈਟਵਰਕ ਦੇ ਤੌਰ ਤੇ ਇਸਤੇਮਾਲ ਕਰਦੇ ਹਾਂ (ਸਾਰੇ ਵੈਬ ਟ੍ਰੈਫਿਕ ਇਸ ਨੈਟਵਰਕ ਨੂੰ ਪਾਰ ਕਰਦੇ ਹਨ).

ਸਾਡਾ ਉਦੇਸ਼ ਇਸ ਸੇਵਾ ਨੂੰ ਇਸ .ੰਗ ਨਾਲ ਪੇਸ਼ ਕਰਨਾ ਹੈ ਜੋ ਤੁਹਾਡੀ ਗੋਪਨੀਯਤਾ ਅਤੇ ਸੁਰੱਖਿਆ ਨੂੰ ਵਧਾਉਣ ਲਈ ਵਿਕਲਪ ਪੇਸ਼ ਕਰਦਾ ਹੈ. ਤੁਹਾਡੀ ਜਾਣਕਾਰੀ ਦੀ ਰਾਖੀ ਲਈ ਅਸੀਂ ਕੁਝ ਕਦਮ ਚੁੱਕੇ ਹਨ:

• ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਕਿਸੇ ਵਿਅਕਤੀਗਤ ਜਾਣਕਾਰੀ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ (ਉਦਾ. ਨਾਮ / ਈਮੇਲ / ਫੋਨ / ਆਦਿ). ਇੱਥੇ ਕੋਈ ਖਾਤਾ ਪ੍ਰਣਾਲੀ ਨਹੀਂ ਹੈ (ਜਿਵੇਂ ਕਿ ਲੌਗਇਨ / ਪਾਸਵਰਡ / ਆਦਿ); ਇਸ ਲਈ, ਕੋਈ ਵੀ ਡਾਟਾ ਦੀ ਉਲੰਘਣਾ ਇਸ ਜਾਣਕਾਰੀ ਨੂੰ ਲੀਕ ਨਹੀਂ ਕਰ ਸਕਦੀ.
• ਸਾਰੀ ਸੁਨੇਹਾ ਸਮਗਰੀ ਅੰਤ ਤੋਂ ਅੰਤ ਇਨਕ੍ਰਿਪਟਡ ਹੈ . ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿਚ, ਡਿਕ੍ਰਿਪਸ਼ਨ ਕੁੰਜੀ / ਪਾਸਵਰਡ ਕਦੇ ਵੀ ਸਾਨੂੰ ਨਹੀਂ ਭੇਜਿਆ ਜਾਂਦਾ. ਇਸ ਲਈ, ਸਾਡੇ ਕੋਲ ਜਾਂ ਕੋਈ ਹੋਰ ਡਾਟਾਬੇਸ ਦੇ ਕਬਜ਼ੇ ਵਿਚ ਹੈ, ਸੁਨੇਹੇ ਦੀ ਸਮੱਗਰੀ ਨੂੰ ਡਿਕ੍ਰਿਪਟ ਕਰਨ ਅਤੇ ਦੇਖਣ ਦਾ ਕੋਈ ਸਾਧਨ ਨਹੀਂ ਹਨ.
• ਸਾਡੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਹਰ ਇੰਦਰਾਜ਼ ਦਾ ਇੱਕ ਸਮਾਂ-ਤੋਂ-ਲਾਈਵ ਲਾਈਵ 1 ਮਿੰਟ ਤੋਂ 2 ਹਫ਼ਤਿਆਂ ਤੱਕ ਹੁੰਦਾ ਹੈ (ਡਿਫਾਲਟ 1 ਹਫਤੇ ਤੋਂ). ਇੱਕ ਵਾਰ ਜਦੋਂ ਇਹ ਸਮਾਂ ਲੰਘ ਗਿਆ, ਰਿਕਾਰਡ ਆਪਣੇ ਆਪ ਹੀ ਮਿਟਾ ਦਿੱਤਾ ਜਾਵੇਗਾ. ਇਸ ਲਈ, ਸਾਡੇ ਡੇਟਾਬੇਸ ਵਿਚਲੀ ਕੋਈ ਵੀ ਜਾਣਕਾਰੀ ਇਸ ਦੇ ਬਣਨ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਮਿਟਾ ਦਿੱਤੀ ਜਾਏਗੀ .
• ਅਸੀਂ ਸਿਰਫ ਪਿਛਲੇ 24 ਘੰਟਿਆਂ ਦੇ ਵੈਬ ਸਰਵਰ ਲੌਗਸ ਨੂੰ ਬਣਾਈ ਰੱਖਦੇ ਹਾਂ . ਡਾਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕੀਤੀ ਕੋਈ ਵੀ ਆਈਪੀ ਜਾਣਕਾਰੀ ਸੁਰੱਖਿਅਤ ਰੂਪ ਵਿੱਚ ਹੈਸ਼ ਕੀਤੀ ਗਈ ਹੈ ਜਿਸ ਨਾਲ ਅਸਲ ਆਈ ਪੀ ਨੂੰ ਐਕਸਟਰੈਕਟ ਕਰਨਾ ਅਸੰਭਵ ਹੋ ਗਿਆ ਹੈ.
• ਇਸ ਸੇਵਾ ਨੂੰ ਚਲਾਉਣ ਵਾਲਾ ਸਾਰਾ ਕੋਡ ਓਪਨ ਸੋਰਸ ਹੈ ਅਤੇ ਸਮੀਖਿਆ ਲਈ ਉਪਲਬਧ ਹੈ. ਤੁਸੀਂ ਆਸਾਨੀ ਨਾਲ ਉਹ ਕੋਡ ਵੇਖ ਸਕਦੇ ਹੋ ਜੋ ਐਨਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ - ਜੋ ਜਾਣਬੁੱਝ ਕੇ ਛੋਟਾ, ਸੰਖੇਪ ਅਤੇ ਟਿੱਪਣੀ ਕੀਤਾ ਗਿਆ ਹੈ.
• ਸੁਰੱਖਿਆ ਨੂੰ ਮਜ਼ਬੂਤ ਬਣਾਉਣ ਵਿਚ ਸਹਾਇਤਾ ਲਈ ਕਈ ਤਕਨੀਕੀ ਸਾਵਧਾਨੀ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ - ਜਿਨ੍ਹਾਂ ਵਿਚੋਂ ਕੁਝ ਸ਼ਾਮਲ ਹਨ:
  • / ਏਪੀਆਈ ਤੋਂ ਇਲਾਵਾ ਇਹ ਪੂਰੀ ਵੈੱਬ ਸਾਈਟ ਸਥਿਰ ਹੈ ਅਤੇ ਪੇਜਾਂ ਵਿੱਚ ਸਰਵਰ ਕੋਡ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੀ (ਉਦਾਹਰਣ ਲਈ ਪੀਐਚਪੀ / ਜੇਐਸਪੀ / ਏਐਸਪੀ / ਆਦਿ).
  • ਵੈੱਬ ਕ੍ਰਿਪਟੋ ਏਪੀਆਈ , ਜੋ ਕਿ ਬ੍ਰਾ .ਜ਼ਰ ਦਾ ਹਿੱਸਾ ਹੈ, ਦੀ ਵਰਤੋਂ ਸਾਰੇ ਸੰਦੇਸ਼ ਸਮੱਗਰੀ ਨੂੰ ਏਨਕ੍ਰਿਪਟ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ.
  • ਟੀਐਲਐਸ ਦੀ ਵਰਤੋਂ ਤੁਹਾਡੇ ਬ੍ਰਾ .ਜ਼ਰ ਅਤੇ ਸਾਡੇ ਸਰਵਰਾਂ ਵਿਚਕਾਰ ਸੰਚਾਰ ਨੂੰ ਇਕ੍ਰਿਪਟ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ. ਇਹ ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰਨ ਵਿੱਚ ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ ਕਿ ਕੋਡ ਆਵਾਜਾਈ ਵਿੱਚ ਰੁਕਾਵਟ ਜਾਂ ਸੰਸ਼ੋਧਿਤ ਨਹੀਂ ਹੋ ਸਕਦਾ. TLS 1.3 ਸਹਿਯੋਗੀ ਹੈ, ਪਰ ਅਸੀਂ ਪੁਰਾਣੇ ਉਪਕਰਣਾਂ ਲਈ TLS 1.2 ਦਾ ਸਮਰਥਨ ਵੀ ਕਰਦੇ ਹਾਂ. ਟੀਐਲਐਸ ਦੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਅਯੋਗ ਹਨ ਕਿਉਂਕਿ ਉਹ ਇੰਨੇ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹਨ.
  • ਸਰਟੀਫਿਕੇਟ ਦੀ ਪਾਰਦਰਸ਼ਤਾ ਲੌਗ ਨੂੰ ਸਰਟੀਫਿਕੇਟ ਦੀ ਗ਼ਲਤ ਜਾਣਕਾਰੀ ਲਈ ਨਿਗਰਾਨੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ. ਇਸ ਤੋਂ ਇਲਾਵਾ ਅਸੀਂ ਅਣਚਾਹੇ ਜਾਂ ਖਰਾਬ ਸਰਟੀਫਿਕੇਟ ਦੀ ਗ਼ਲਤਫਹਿਮੀ ਦੇ ਜੋਖਮ ਨੂੰ ਘਟਾਉਣ ਲਈ ਇਕ ਪ੍ਰਮਾਣੀਕਰਣ ਅਥਾਰਟੀ ਅਧਿਕਾਰ (CAA) ਨੀਤੀ ਪ੍ਰਕਾਸ਼ਤ ਕਰਦੇ ਹਾਂ.
  • ਅਸੀਂ ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰਨ ਲਈ HTTP ਸਟੀਕ ਟ੍ਰਾਂਸਪੋਰਟ ਸਿਕਿਓਰਿਟੀ (HSTS) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ ਤਾਂ ਜੋ ਬ੍ਰਾਉਜ਼ਰ ਹਮੇਸ਼ਾਂ TLS ਪਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸਾਡੇ ਸਰਵਰਾਂ ਨਾਲ ਸੰਚਾਰ ਕਰਦੇ ਹਨ. ਇਸਦੇ ਇਲਾਵਾ, ਅਸੀਂ ਆਪਣੇ ਡੋਮੇਨਾਂ ਨੂੰ ਪ੍ਰੀਲੋਡ ਲੋਡ ਸੂਚੀ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਦੇ ਹਾਂ.
  • ਕਰਾਸ ਸਾਈਟ ਸਕ੍ਰਿਪਟਿੰਗ (ਐਕਸਐਸਐਸ) ਦੇ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਇਕ ਸਖਤ ਸਮੱਗਰੀ ਸੁਰੱਖਿਆ ਨੀਤੀ ਲਾਗੂ ਕੀਤੀ ਗਈ ਹੈ.
  • ਕਰਾਸ-ਓਰੀਜਨ ਆਰਸੋਰਸ ਪਾਲਿਸੀ , ਇੱਕ ਕਰਾਸ-ਆਰਜੀਨ ਏਮਬੇਡਰ ਪਾਲਿਸੀ , ਅਤੇ ਇੱਕ ਕਰਾਸ-ਓਰੀਜਿਨ ਓਪਨਰ ਪਾਲਿਸੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ , ਅਸੀਂ ਸਪੈਸਟਰ ਅਤੇ ਮੇਲਟਡਾਉਨ ਵਰਗੇ ਸੱਟੇਬਾਜ਼ੀ ਵਾਲੇ ਸਾਈਡ-ਚੈਨਲ ਹਮਲਿਆਂ ਦੇ ਵਿਰੁੱਧ ਘਟਾਉਣ ਵਿੱਚ ਸਹਾਇਤਾ ਕਰਨ ਲਈ ਕ੍ਰਾਸ ਓਰੀਜਨ ਕੋਡ ਨੂੰ ਵਰਜਦੇ ਹਾਂ. ਇਹ ਬਰਾ sameਜ਼ਿੰਗ ਦੇ ਪ੍ਰਸੰਗ ਨੂੰ ਇਕੋ-ਇਕੋ ਮੂਲ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿਚ ਅਲੱਗ ਕਰਕੇ ਹੋਰ ਮੂਲ ਤੋਂ ਸੰਭਾਵਿਤ ਤੌਰ ਤੇ ਗਲਤ ਬੇਨਤੀਆਂ ਦੇ ਵਿਰੁੱਧ ਸੁਰੱਖਿਆ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ.
  • ਬ੍ਰਾਉਜ਼ਰ ਨੂੰ ਸਰੋਤਾਂ ਨੂੰ ਲੋਡ ਕਰਨ ਤੋਂ ਰੋਕਣ ਲਈ ਅਸੀਂ ਇਕ ਅਨੁਮਤੀ ਨੀਤੀ ਲਗਾਉਂਦੇ ਹਾਂ ਜੋ ਤੁਹਾਡੀ ਗੋਪਨੀਯਤਾ ਜਿਵੇਂ ਕਿ ਤੁਹਾਡੀ ਸਥਿਤੀ, ਵੈਬ-ਕੈਮ, ਮਾਈਕ੍ਰੋਫੋਨ, ਆਦਿ ਨਾਲ ਸਮਝੌਤਾ ਕਰ ਸਕਦਾ ਹੈ.
  • DNS- ਅਧਾਰਤ MITM ਹਮਲਿਆਂ ਨੂੰ ਘਟਾਉਣ ਵਿੱਚ ਸਹਾਇਤਾ ਲਈ ਸਾਡੇ ਸਾਰੇ ਡੋਮੇਨਾਂ ਤੇ DNSSEC ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ.
  • ਅਸੀਂ ਸਰਵਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ ਬਹੁਤ ਸਾਰੀਆਂ ਸਾਵਧਾਨੀਆਂ ਲੈਂਦੇ ਹਾਂ.
  • ਕੋਈ ਤੀਜੀ ਧਿਰ ਕੋਡ ਲੋਡ ਨਹੀਂ ਕੀਤਾ ਗਿਆ (ਭਾਵ jQuery) ਅਤੇ ਬਹੁਤ ਘੱਟ ਸਰੋਤ ਲੋਡ ਕੀਤੇ ਗਏ ਹਨ (ਅੱਗੇ ਜਾਣ ਲਈ ਅਤੇ ਚੈੱਕ ਕਰਨ ਲਈ ਦੇਵ ਟੂਲਜ਼ ਵਿੱਚ ਨੈਟਵਰਕ ਟੈਬ ਖੋਲ੍ਹੋ) - ਇਹ ਆਡਿਟ ਕਰਨ ਲਈ ਲੋੜੀਂਦੇ ਯਤਨ ਨੂੰ ਘੱਟ ਕਰਦਾ ਹੈ. ਇੱਕ ਅਪਵਾਦ ਇਹ ਹੈ ਕਿ ਜੇ ਇੱਕ ਕੈਪਟਚਾ ਲੋੜੀਂਦਾ ਹੈ - ਉਹ ਐਚਕੈਪਚਾ ਤੋਂ ਤੀਜੀ ਧਿਰ ਕੋਡ ਲੋਡ ਕਰਦਾ ਹੈ. ਹਾਲਾਂਕਿ, ਐਚਕੈਪਚਾ ਕੋਡ ਆਪਣੇ ਖੁਦ ਦੇ ਸੀਆਰਪੀ ਨਿਯਮਾਂ ਦੇ ਅੰਦਰ ਇਸ ਦੇ ਆਪਣੇ ਯੂਆਰਐਲ ਤੇ ਲੋਡ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਵੀ ਸਮੇਂ ਕਿਸੇ ਸੁਨੇਹੇ ਨਾਲ ਕਰਨ ਵਾਲੀ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਦੀ ਪਹੁੰਚ ਨਹੀਂ ਹੁੰਦੀ.
  • ਐਮਆਈਟੀਐਮ ਹਮਲਿਆਂ ਤੋਂ ਬਚਾਅ ਲਈ ਇਕ ਸਾਧਨ ਵਜੋਂ, ਬ੍ਰਾ browserਜ਼ਰ ਐਕਸਟੈਂਸ਼ਨਾਂ ਉਪਲਬਧ ਹਨ .

ਮੈਨੂੰ ਇੱਕ ਸੁਨੇਹਾ ਡਿਕ੍ਰਿਪਟ ਕਰਨ ਦੇ ਵਿਕਲਪ ਦੇ ਨਾਲ ਇੱਥੇ ਇੱਕ ਲਿੰਕ ਕਿਉਂ ਮਿਲਿਆ?

ਜੇ ਇਸ ਅਨੁਵਾਦ ਵਿੱਚ ਕੋਈ ਗਲਤੀਆਂ ਹਨ ਤਾਂ ਅਸੀਂ ਮੁਆਫੀ ਚਾਹੁੰਦੇ ਹਾਂ. ਇਹ ਸੇਵਾ ਇਕ ਐਨਕ੍ਰਿਪਟਡ ਸੰਦੇਸ਼ ਨੂੰ ਇਕ ਬਿੰਦੂ ਤੋਂ ਦੂਸਰੇ ਪਾਸੇ ਭੇਜਦੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਪ੍ਰਾਪਤਕਰਤਾ ਹੋ. ਸੁਨੇਹਾ ਜਲਦੀ ਹੀ ਮਿਟਾ ਦਿੱਤਾ ਜਾਵੇਗਾ. ਇਸ ਸੇਵਾ ਦੇ ਸੰਚਾਲਕਾਂ ਕੋਲ ਸੰਦੇਸ਼ ਸਮੱਗਰੀ ਨੂੰ ਪੜ੍ਹਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ. ਆਮ ਤੌਰ 'ਤੇ ਕੋਈ ਇਹ ਸੇਵਾ ਇਸਤੇਮਾਲ ਕਰਦਾ ਹੈ ਜਦੋਂ ਉਹ ਨਹੀਂ ਚਾਹੁੰਦੇ ਕਿ ਸੁਨੇਹੇ ਦੇ ਭਾਗ ਵੱਖ-ਵੱਖ ਡੇਟਾਬੇਸ / ਡਿਵਾਈਸਿਸ / ਸੇਵਾਵਾਂ / ਫਾਈਲਾਂ / ਆਦਿ ਦੇ ਅੰਦਰ ਰਹਿਣ. ਜਿਵੇਂ ਕਿ ਈਮੇਲ / ਇੰਸਟੈਂਟ-ਮੈਸੇਜ / ਟੈਕਸਟ / ਆਦਿ ਭੇਜਣ ਸਮੇਂ ਆਮ ਹੁੰਦਾ ਹੈ. ਜੇ ਤੁਹਾਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਰਪਾ ਕਰਕੇ ਹੇਠਾਂ ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ:

• ਇਹ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਸੁਨੇਹਾ ਤੁਰੰਤ ਇਸ ਨੂੰ ਡਿਕਰਿਪਸ਼ਨ ਲਈ ਤੁਹਾਡੇ ਉਪਕਰਣ ਨੂੰ ਭੇਜਣ ਤੋਂ ਬਾਅਦ ਮਿਟਾ ਦਿੱਤਾ ਜਾਏਗਾ. ਇਸਦਾ ਅਰਥ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ ਦੁਆਰਾ ਸੁਨੇਹੇ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਨ ਲਈ ਬਟਨ ਨੂੰ ਦਬਾਉਣ ਤੋਂ ਬਾਅਦ, ਸਾਡੇ ਕੋਲ ਤੁਹਾਨੂੰ ਬਾਅਦ ਵਿਚ ਦੁਬਾਰਾ ਭੇਜਣ ਲਈ ਕੋਈ ਕਾੱਪੀ ਨਹੀਂ ਬਚੇਗੀ.
• ਅਸੀਂ ਪ੍ਰਾਪਤ ਹੋਈ ਸਾਰੀ ਜਾਣਕਾਰੀ ਨੂੰ ਯੋਜਨਾਬੱਧ deleteੰਗ ਨਾਲ ਮਿਟਾਉਂਦੇ ਹਾਂ. ਇਸ ਦੇ ਬਣਨ ਤੋਂ ਬਾਅਦ ਸੁਨੇਹੇ ਇਕ ਮਿੰਟ ਤੋਂ ਦੋ ਹਫ਼ਤਿਆਂ ਦਰਮਿਆਨ ਕਿਤੇ ਵੀ ਮਿਟਾ ਦਿੱਤੇ ਜਾਣਗੇ - ਇਸ ਗੱਲ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਕਿ ਸੁਨੇਹਾ ਕਦੇ ਵੀ ਡਿਕ੍ਰਿਪਟ ਕੀਤਾ ਗਿਆ ਹੈ. ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿਚ, ਜੇ ਤੁਹਾਨੂੰ ਸੁਨੇਹਾ ਪੜ੍ਹਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਨ ਲਈ ਬਹੁਤ ਦੇਰ ਦੀ ਉਡੀਕ ਨਾ ਕਰੋ.
• ਭੇਜਣ ਵਾਲਾ ਸ਼ਾਇਦ ਮੰਨਦਾ ਹੈ ਕਿ ਸੁਨੇਹੇ ਦੀਆਂ ਸਮੱਗਰੀਆਂ ਨੂੰ ਧਿਆਨ ਨਾਲ ਸੰਭਾਲਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ. ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਨੇ ਇਸ਼ਾਰਾ ਵੀ ਕੀਤਾ ਹੋਵੇ ਕਿ ਉਹ ਕਾਪੀਆਂ ਨਹੀਂ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ. ਕ੍ਰਿਪਾ ਕਰਕੇ ਉਨ੍ਹਾਂ ਦੀਆਂ ਇੱਛਾਵਾਂ ਦਾ ਸਤਿਕਾਰ ਕਰੋ.
• ਜੇ ਤੁਹਾਨੂੰ ਕਿਸੇ ਸੁਨੇਹੇ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਨ ਲਈ ਪਾਸਵਰਡ ਬਾਰੇ ਪੁੱਛਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਬ੍ਰਾ browserਜ਼ਰ ਵਿੰਡੋ / ਟੈਬ ਨੂੰ ਬੰਦ ਨਾ ਕਰੋ. ਇਸ ਸੂਚੀ ਦੇ ਪਹਿਲੇ ਬੁਲੇਟ ਪੁਆਇੰਟ ਦੇ ਅਨੁਸਾਰ, ਇਹ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਅਸੀਂ ਬਾਅਦ ਵਿਚ ਇਕ ਹੋਰ ਕਾਪੀ ਨਹੀਂ ਭੇਜ ਸਕਦੇ. ਬਰਾ theਜ਼ਰ ਵਿੰਡੋ / ਟੈਬ ਨੂੰ ਉਦੋਂ ਤਕ ਖੁੱਲਾ ਛੱਡੋ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਪਾਸਵਰਡ ਦਰਜ ਨਹੀਂ ਕਰ ਸਕਦੇ. ਜੇ ਤੁਸੀਂ ਗਲਤ ਪਾਸਵਰਡ ਦਾਖਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਦੁਬਾਰਾ ਪੁੱਛਿਆ ਜਾਵੇਗਾ. ਪਾਸਵਰਡ ਵਿੱਚ ਸਹੀ ਤਰ੍ਹਾਂ ਦਾਖਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. ਇਹ ਯਾਦ ਰੱਖੋ ਕਿ ਵੱਖ ਵੱਖ ਭਾਸ਼ਾਵਾਂ ਅਤੇ ਪਾਸਵਰਡ ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਅਨੁਕੂਲ ਕਰਨ ਲਈ, ਅਸੀਂ ਪਾਸਵਰਡਾਂ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਵੱਖਰੇ ਅੱਖਰਾਂ ਨੂੰ ਸਵੀਕਾਰਦੇ ਹਾਂ.

ਕੀ ਤੁਸੀਂ ਇਸ ਸਾਈਟ ਤੇ ਜਮ੍ਹਾਂ ਕੀਤੀ ਹਰ ਚੀਜ ਨੂੰ ਮਿਟਾਉਂਦੇ ਹੋ?

ਸਾਡੇ ਰੱਦੀ ਵਿਚਲਾ ਲੋਗੋ ਸਹੀ ਹੈ ... ਹਰ ਚੀਜ਼ ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਮਿਟਾ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ. ਹਰ ਚੀਜ ਨੂੰ ਮਿਟਾਉਣਾ ਸਵੈਚਾਲਿਤ ਹੈ - ਸਰਵਰ ਵਿੱਚ ਲਿਖਿਆ ਹੋਇਆ ਹੈ. ਇਸ ਬਾਰੇ ਇਸ ਬਾਰੇ ਸੋਚੋ - ਇੱਥੇ ਜਾਣਕਾਰੀ ਦੀਆਂ ਦੋ ਸ਼੍ਰੇਣੀਆਂ ਜਮ੍ਹਾਂ ਹਨ:

• ਇਨਕ੍ਰਿਪਟਡ ਸੰਦੇਸ਼ ਜਿਸ ਲਈ ਸਾਡੇ ਕੋਲ ਸਮੱਗਰੀ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਨ ਦਾ ਕੋਈ ਸਾਧਨ ਨਹੀਂ ਹਨ
• ਵੈਬ ਤੇ ਕੁਝ ਵੀ ਜਮ੍ਹਾਂ ਕਰਨ ਵਿੱਚ ਸਹਿਜ ਹੋਰ ਜਾਣਕਾਰੀ (ਜਿਵੇਂ ਤੁਹਾਡਾ ਆਈ ਪੀ ਐਡਰੈੱਸ, ਆਦਿ)

ਸੰਦੇਸ਼ਾਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਤੁਸੀਂ ਨਿਯੰਤਰਣ ਕਰ ਸਕਦੇ ਹੋ ਜਦੋਂ ਅਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਕੇ ਮਿਟਾਉਂਦੇ ਹਾਂ:

• ਸਾਨੂੰ ਇਸ ਸੰਦੇਸ਼ ਨੂੰ ਕਿੰਨਾ ਚਿਰ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਜੇ ਕੋਈ ਇਸ ਨੂੰ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰਦਾ (1 ਮਿੰਟ ਤੋਂ 2 ਹਫ਼ਤੇ ਤਕ - ਡਿਫਾਲਟ 1 ਹਫਤੇ ਤੱਕ).
• ਸੰਦੇਸ਼ ਨੂੰ ਕਿੰਨੀ ਵਾਰ ਮੁੜ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (1 ਤੋਂ 100 ਵਾਰ ਤੱਕ - ਮੂਲ ਰੂਪ ਵਿੱਚ 1 ਵਾਰ)

ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ, ਇੱਕ ਸੰਦੇਸ਼ ਬਾਰੇ ਸਭ ਕੁਝ ਇਕ ਵਾਰ ਪ੍ਰਾਪਤ ਕਰਨ ਜਾਂ 1 ਹਫ਼ਤੇ ਪੁਰਾਣਾ ਹੋਣ ਤੋਂ ਬਾਅਦ ਮਿਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ - ਜੋ ਵੀ ਪਹਿਲਾਂ ਹੁੰਦਾ ਹੈ. ਜਦੋਂ ਵੈਬ ਤੇ ਕੁਝ ਵੀ ਜਮ੍ਹਾਂ ਕਰਨ ਦੇ ਅੰਦਰਲੀ ਸਾਰੀ ਸਾਰੀ ਜਾਣਕਾਰੀ ਨੂੰ ਮਿਟਾਉਣ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ (ਜਿਵੇਂ ਕਿ ਤੁਹਾਡਾ ਆਈ ਪੀ ਐਡਰੈੱਸ, ਆਦਿ), ਅਸੀਂ ਤੁਹਾਨੂੰ ਇਸ 'ਤੇ ਕੋਈ ਨਿਯੰਤਰਣ ਨਹੀਂ ਦਿੰਦੇ ਹਾਂ ਕਿ ਇਹ ਕਦੋਂ ਜਾਂ ਕਿਵੇਂ ਮਿਟਾਇਆ ਜਾਂਦਾ ਹੈ - ਅਸੀਂ ਸਿਰਫ ਹਰ 24 ਘੰਟੇ ਇਸ ਨੂੰ ਮਿਟਾਉਂਦੇ ਹਾਂ .

ਇਸ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਿਉਂ ਕਰੀਏ?

ਇਹ ਸੇਵਾ ਤੁਹਾਡੇ ਦੁਆਰਾ ਭੇਜੇ / ਘੱਟ ਪੱਕੇ ਪ੍ਰਾਪਤ ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਬਣਾਉਣ ਵਿੱਚ ਸਹਾਇਤਾ ਕਰਨ ਲਈ ਇੱਕ ਸਾਧਨ ਹੈ. ਇੰਟਰਨੈੱਟ 'ਤੇ ਜੋ ਤੁਸੀਂ ਗੱਲਬਾਤ ਕਰਦੇ ਹੋ ਉਸ ਵਿਚੋਂ ਬਹੁਤ ਸਾਰੀਆਂ (ਗੱਲਾ, ਟੈਕਸਟ, ਈਮੇਲਾਂ, ਆਦਿ) ਸਟੋਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਬਹੁਤ ਹੀ ਘੱਟ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ. ਅਕਸਰ, ਜਦੋਂ ਤੁਸੀਂ ਕੋਈ ਚੀਜ਼ ਮਿਟਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਅਸਲ ਵਿੱਚ ਮਿਟਾਈ ਨਹੀਂ ਜਾਂਦੀ ਬਲਕਿ ਮਿਟਾਏ ਹੋਏ ਦੇ ਰੂਪ ਵਿੱਚ ਚਿੰਨ੍ਹਿਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਪ੍ਰਦਰਸ਼ਤ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ. ਤੁਹਾਡੇ ਕੁਲ ਸੰਚਾਰ ਡੇਟਾਬੇਸ ਅਤੇ ਡਿਵਾਈਸਿਸ ਵਿੱਚ ਸਾਲ ਬਾਅਦ ਇੱਕਠੇ ਹੁੰਦੇ ਹਨ ਜਿਸਦਾ ਤੁਹਾਡਾ ਕੋਈ ਨਿਯੰਤਰਣ ਨਹੀਂ ਹੁੰਦਾ. ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ, ਤੁਹਾਡੇ ਸੰਚਾਰਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਵਾਲੀਆਂ ਇੱਕ ਜਾਂ ਵਧੇਰੇ ਸੰਸਥਾਵਾਂ / ਲੋਕ / ਉਪਕਰਣ ਹੈਕ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਤੁਹਾਡੀ ਜਾਣਕਾਰੀ ਲੀਕ ਹੋ ਜਾਂਦੀ ਹੈ. ਇਹ ਸਮੱਸਿਆ ਇੰਨੀ ਵਿਆਪਕ ਹੈ ਕਿ ਹੁਣ ਬਹੁਤ ਸਾਰੀਆਂ ਵੈਬ ਸਾਈਟਾਂ ਅਜਿਹੀਆਂ ਸੰਸਥਾਵਾਂ ਨੂੰ ਟਰੈਕ ਕਰਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਉਪਭੋਗਤਾ ਡੇਟਾ ਲੀਕ ਹੋਇਆ ਹੈ. ਐਂਡ-ਟੂ-ਐਂਡ ਇਨਕ੍ਰਿਪਟਡ ਅਸਥਾਈ ਸੰਦੇਸ਼ ਤੁਹਾਡੇ ਕੁਝ ਸੰਚਾਰਾਂ ਨੂੰ ਸਥਾਈ ਬਣਾਉਣ ਵਿੱਚ ਸਹਾਇਤਾ ਲਈ ਇੱਕ ਸਧਾਰਣ ਹੱਲ ਹਨ. ਇਸ ਸਾਈਟ ਤੇ ਜਮ੍ਹਾ ਕੀਤਾ ਗਿਆ ਹਰੇਕ ਸੰਦੇਸ਼ ਦਾ 1 ਮਿੰਟ ਤੋਂ 2 ਹਫ਼ਤਿਆਂ ਤੱਕ ਦਾ ਸਮਾਂ-ਜੀਵਤ ਸਮਾਂ ਹੁੰਦਾ ਹੈ - ਇੱਕ ਵਾਰ ਜਦੋਂ ਸਮਾਂ ਲੰਘ ਜਾਂਦਾ ਹੈ ਤਾਂ ਸੁਨੇਹਾ ਮਿਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਡਿਫੌਲਟ ਸੈਟਿੰਗ ਕਿਸੇ ਵੀ ਸੁਨੇਹੇ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਬਾਅਦ ਇਸ ਨੂੰ ਮਿਟਾਉਣਾ ਹੈ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਾਰੇ ਸੁਨੇਹੇ ਤੁਹਾਡੀ ਡਿਵਾਈਸ ਤੋਂ ਪ੍ਰਾਪਤਕਰਤਾ ਦੇ ਜੰਤਰ ਤੱਕ ਸਾਰੇ ਤਰੀਕੇ ਨਾਲ ਇਕ੍ਰਿਪਟਡ ਹੁੰਦੇ ਹਨ. ਐਂਡ-ਟੂ-ਐਂਡ ਇਨਕ੍ਰਿਪਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਮੁੱਖ ਟੀਚਾ ਹੈ ਕੋਈ ਵੀ ਜਮ੍ਹਾ ਹੋਏ ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਸਾਡੀ ਯੋਗਤਾ ਨੂੰ ਦੂਰ ਕਰਨਾ, ਜਿਸ ਨਾਲ ਕੁਝ ਭਰੋਸੇ ਦੀ ਜ਼ਰੂਰਤ ਨੂੰ ਦੂਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ. ਆਖਰੀ ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਹੁਣ ਇਕ ਸਧਾਰਨ ਲਿੰਕ ਦੁਆਰਾ ਇਕ ਇਨਕ੍ਰਿਪਟਡ ਸੁਨੇਹਾ ਭੇਜਣਾ ਸੌਖਾ ਹੈ. ਉਹ ਸੁਨੇਹਾ ਭੇਜਣ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਜਾਂ ਮੁੜ ਪ੍ਰਾਪਤ ਹੋਣ 'ਤੇ ਮਿਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ. ਤੁਹਾਨੂੰ ਵਿਸ਼ੇਸ਼ ਸਾੱਫਟਵੇਅਰ ਨੂੰ ਸਥਾਪਤ / ਕੌਂਫਿਗਰ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ. ਤੁਹਾਨੂੰ ਕੋਈ ਖਾਤਾ ਬਣਾਉਣ ਦੀ ਜਾਂ ਕੋਈ ਨਿਜੀ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ. ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਨੂੰ ਤੁਹਾਡੇ ਸੰਪਰਕਾਂ ਵਿਚ ਹੋਣਾ ਜਾਂ ਇਸ ਸੇਵਾ ਬਾਰੇ ਜਾਣਨਾ ਵੀ ਨਹੀਂ ਪੈਂਦਾ - ਸਿਰਫ ਇਕੋ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਉਹ ਕਿਸੇ ਲਿੰਕ ਤੇ ਕਲਿੱਕ ਕਰ ਸਕਣ.

ਕੀ ਇਹ ਇੱਕ ਸੁਨੇਹਾ ਦੇਣ ਵਾਲੀ ਸੇਵਾ ਹੈ?

ਨਹੀਂ. ਇਹ ਸੇਵਾ ਮੌਜੂਦਾ ਮੈਸੇਜਿੰਗ ਸੇਵਾਵਾਂ ਜਿਵੇਂ ਕਿ ਇੰਸਟੈਂਟ-ਮੈਸੇਜਿੰਗ / ਈਮੇਲ / ਟੈਕਸਟ / ਆਦਿ ਦੇ ਪੂਰਕ ਲਈ ਤਿਆਰ ਕੀਤੀ ਗਈ ਹੈ. ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਭੇਜੇ ਸੁਨੇਹਿਆਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਤੋਂ ਰੋਕਣ ਦੀ ਯੋਗਤਾ ਜੋੜ ਕੇ. ਅਸੀਂ ਤਿਆਰ ਕੀਤੇ ਲਿੰਕ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਨੂੰ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦੇ .

ਵਰਤੋਂ ਦੇ ਉਦੇਸ਼ ਕੀ ਹਨ?

ਤਾਂ ਫਿਰ ਕੁਝ ਦ੍ਰਿਸ਼ ਕੀ ਹਨ ਜਿਥੇ ਇਸ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਉਚਿਤ ਹੈ? ਜਦੋਂ ਕਿ ਹਰੇਕ ਦੀ ਵੱਖੋ ਵੱਖਰੀਆਂ ਜ਼ਰੂਰਤਾਂ ਅਤੇ ਜ਼ਰੂਰਤਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਇਹ ਉਨ੍ਹਾਂ ਦੀ ਗੋਪਨੀਯਤਾ ਅਤੇ ਸੁਰੱਖਿਆ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ, ਮੈਂ ਨਿੱਜੀ ਤੌਰ 'ਤੇ ਹੇਠ ਦਿੱਤੇ ਦ੍ਰਿਸ਼ਾਂ ਨੂੰ appropriateੁਕਵੇਂ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਵਜੋਂ ਪਾਇਆ ਹੈ:

• ਤੁਸੀਂ ਇੱਕ ਸਥਾਨਕ ਵੈਬ ਫੋਰਮ ਦੁਆਰਾ ਖੇਤਰ ਵਿੱਚ ਪਹਾੜੀ ਬਾਈਕਿੰਗ ਪਥਰਾਵਾਂ ਬਾਰੇ ਸੰਚਾਰ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਕਈ ਵਾਰ ਫੋਰਮ ਤੇ ਲੋਕਾਂ ਨਾਲ ਮਿਲ ਕੇ ਨਵੀਂਆਂ ਟ੍ਰੇਲਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਮਿਲਦੇ ਹੋ. ਫੋਰਮ ਦਾ ਕੋਈ ਵਿਅਕਤੀ ਇਸ ਹਫਤੇ ਦੇ ਅੰਤ ਵਿੱਚ ਤੁਹਾਨੂੰ ਤੁਹਾਡੀ ਜਗ੍ਹਾ ਤੇ ਕਾਰਪੂਲ ਕਰਨ ਲਈ ਲੈਣਾ ਚਾਹੁੰਦਾ ਹੈ. ਤੁਸੀਂ ਆਪਣੇ ਘਰ ਦਾ ਪਤਾ ਇਸ ਵੈਬ ਸਾਈਟ ਫੋਰਮ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਦਾ ਲਈ ਨਹੀਂ ਚਾਹੁੰਦੇ. ਇਸ ਸੇਵਾ ਰਾਹੀਂ ਸਿੱਧਾ ਪਤਾ ਭੇਜੋ - ਲਿੰਕ ਉਹ ਹੈ ਜੋ ਵੈਬ ਸਾਈਟ ਫੋਰਮ ਦੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਪਰੰਤੂ ਇੱਕ ਵਾਰ ਜਦੋਂ ਇਸ ਨੂੰ ਪ੍ਰਾਪਤਕਰਤਾ ਦੁਆਰਾ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸੁਨੇਹਾ / ਪਤਾ ਮਿਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ.
• ਤੁਹਾਨੂੰ ਆਪਣੇ ਭਰਾ ਨੂੰ ਆਪਣਾ ਨੈੱਟਫਲਿਕਸ ਲੌਗਇਨ ਭੇਜਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿਉਂਕਿ ਤੁਹਾਡੀ ਭਤੀਜੀ ਉਸ ਨੂੰ ਪਾਗਲ ਕਰ ਰਹੀ ਹੈ COVID ਲੌਕਡਾਉਨ ਕਾਰਨ ਅਤੇ ਅਜੇ ਵੀ ਉਸਦਾ ਆਪਣਾ ਖਾਤਾ ਨਹੀਂ ਹੈ. ਤੁਸੀਂ ਇਸ ਲੌਗਇਨ ਬਾਰੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦੇ, ਪਰ ਤੁਹਾਡਾ ਭਰਾ ਖ਼ਾਸਕਰ ਇਸ ਗੱਲੋਂ ਮਾੜਾ ਹੈ ਕਿ ਮੈਂ ਸਿਰਫ "ਡਿਜੀਟਲ ਸਫਾਈ" ਕਹਾਂਗਾ ਅਤੇ ਸਮਝੌਤਾ ਕੀਤੇ ਲੌਗਿਨਸ ਅਤੇ ਮਾਲਵੇਅਰ ਨਾਲ ਬਹੁਤ ਸਾਰੀਆਂ ਅਜ਼ਮਾਇਸ਼ਾਂ ਆਈਆਂ ਹਨ. ਅਗਲੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਉਸ ਨੂੰ ਆਪਣੇ ਕੰਮ ਨੂੰ ਸਾਫ ਕਰਨ ਲਈ ਅਤੇ ਇੱਥੋਂ ਤਕ ਕਿ ਉਸ ਲਈ ਸੁਰੱਖਿਅਤ ਮੈਸੇਜਿੰਗ ਸਥਾਪਤ ਕਰਨ ਵਿਚ ਅਸਫਲ ਰਹੇ. ਬਸ ਇਸ ਨੂੰ ਟੈਕਸਟ ਸੰਦੇਸ਼ ਦੁਆਰਾ ਭੇਜਣਾ ਸ਼ਾਇਦ ਸਭ ਤੋਂ ਵਧੀਆ ਵਿਕਲਪ ਹੈ (ਅਫ਼ਸੋਸ ਦੀ ਗੱਲ ਹੈ), ਪਰ ਤੁਸੀਂ ਪਿਛਲੇ ਤਜ਼ਰਬੇ ਦੇ ਕਾਰਨ ਉਸ ਦੇ ਸੰਦੇਸ਼ ਦੇ ਇਤਿਹਾਸ ਵਿੱਚ ਲੌਗਇਨ ਬੈਠਣ ਤੋਂ ਅਸਹਿਜ ਹੋ. ਇਸ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਟੈਕਸਟ ਮੈਸੇਜ ਦੇ ਲਿੰਕ ਰਾਹੀਂ ਲੌਗਇਨ ਭੇਜਣ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਸੰਤੁਸ਼ਟੀ ਹੈ ਕਿ ਲਾਗਇਨ ਨੂੰ ਉਸਦੇ ਗੱਲਬਾਤ ਦੇ ਇਤਿਹਾਸ ਵਿੱਚ ਸਦਾ ਲਈ ਲਟਕਣ ਨਹੀਂ ਦੇਵੇਗਾ.
• ਤੁਸੀਂ ਕਈ ਵਾਰ ਇੱਕ ਦਫਤਰ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹੋ ਜਿਸ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਸਾਂਝੇ ਕਿਰਾਏਦਾਰ ਹੁੰਦੇ ਹਨ ਜੋ ਆਉਂਦੇ ਅਤੇ ਜਾਂਦੇ ਹਨ. ਇੱਥੇ ਵਰਤਣ ਲਈ ਵਾਈਫਾਈ ਉਪਲਬਧ ਹੈ, ਪਰ ਪਾਸਵਰਡ ਹਰ ਹਫ਼ਤੇ ਘੁੰਮਾਇਆ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਦੁਰਵਰਤੋਂ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਆਈਆਂ ਹਨ. ਬਹੁਤ ਸਾਰੇ ਕਿਰਾਏਦਾਰ ਈ-ਮੇਲ / ਟੈਕਸਟ ਨੂੰ ਫਾਈ ਪਾਸਵਰਡ ਦੀ ਮੰਗ ਕਰ ਰਹੇ ਹਨ ਭਾਵੇਂ ਇਹ ਫਰੰਟ ਡੈਸਕ ਤੇ ਹੈ ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਮੁੱਖ ਦਰਵਾਜ਼ੇ ਦੁਆਰਾ ਦਾਖਲ ਨਹੀਂ ਹੁੰਦੇ. ਇਸ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰਦਿਆਂ, ਦਫਤਰ ਦਾ ਮੈਨੇਜਰ ਇੱਕ ਈਮੇਲ / ਟੈਕਸਟ ਜਵਾਬ ਵਿੱਚ ਇੱਕ ਲਿੰਕ ਰਾਹੀਂ WiFi ਪਾਸਵਰਡ ਭੇਜ ਸਕਦਾ ਹੈ ਅਤੇ ਪਾਸਵਰਡ ਨੂੰ ਲੰਮਾ ਨਾ ਹੋਣ ਦੀ ਤਸੱਲੀ ਕਰਵਾਉਂਦਾ ਹੈ, ਅਤੇ ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਤੁਰੰਤ ਕਾੱਪੀ ਬਟਨ ਦੁਆਰਾ ਪਾਸਵਰਡ ਦੀ ਕਾੱਪੀ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜੋ ਮੋਬਾਈਲ ਡਿਵਾਈਸਾਂ ਤੇ ਘੱਟ ਅਨੌਖਾ ਹੈ.
• ਤੁਹਾਡੇ ਹੋਸਟਿੰਗ ਪ੍ਰਦਾਤਾ ਵਿੱਚੋਂ ਇੱਕ ਤੁਹਾਡੇ ਤੋਂ ਇੱਕ ਸਰਵਰ ਬਾਰੇ ਵੇਰਵੇ ਪੁੱਛ ਰਿਹਾ ਹੈ ਜਿਸਦੀ ਤੁਸੀਂ ਰਿਪੋਰਟ ਕੀਤੀ ਹੈ ਇੱਕ ਹਾਰਡ ਡ੍ਰਾਇਵ ਦੇ ਸੰਕੇਤ ਦਿਖਾ ਰਹੇ ਹਨ ਜੋ ਖਰਾਬ ਜਾਪਦਾ ਹੈ. ਉਹਨਾਂ ਨੂੰ ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਥੋੜੀ ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ - ਤੁਸੀਂ ਨਹੀਂ ਚਾਹੁੰਦੇ ਕਿ ਉਹ ਇਸ ਨੂੰ ਤੀਜੀ ਧਿਰ ਦੀ ਟਿਕਟ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਸਦਾ ਲਈ ਬੈਠੇ ਰਹਿਣ. ਇਸ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਤੁਸੀਂ ਇਸ ਦੀ ਜਾਣਕਾਰੀ ਟਿਕਟ ਪ੍ਰਣਾਲੀ ਵਿਚ ਬਣੇ ਬਿਨਾਂ ਸਹਾਇਤਾ ਟੈਕਨੀਸ਼ੀਅਨ ਨੂੰ ਭੇਜ ਸਕਦੇ ਹੋ. ਕਿਉਂਕਿ ਕਈ ਤਕਨੀਸ਼ੀਅਨਾਂ ਨੂੰ ਜਾਣਕਾਰੀ ਨੂੰ ਕਈ ਵਾਰ ਵੇਖਣ ਦੀ ਜ਼ਰੂਰਤ ਹੋ ਸਕਦੀ ਹੈ, ਰੀਡ-ਟੂ-ਲਾਈਵ 1 ਤੋਂ ਵੱਧ ਸੈੱਟ ਕਰੋ (ਭਾਵ ਸ਼ਾਇਦ 20) ਤਾਂ ਜੋ ਸੁਨੇਹਾ ਪਹਿਲੇ ਪ੍ਰਾਪਤੀ ਤੇ ਮਿਟਾਇਆ ਨਾ ਜਾਵੇ.
• ਤੁਹਾਨੂੰ ਰੈਡਿਟ 'ਤੇ ਕਿਸੇ ਹੋਰ ਉਪਭੋਗਤਾ ਨੂੰ ਨਿੱਜੀ ਸੁਨੇਹਾ ਭੇਜਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਤਾਂ ਜੋ ਉਨ੍ਹਾਂ ਨੂੰ ਆਪਣਾ ਫੋਨ ਨੰਬਰ ਦੱਸੋ ਤਾਂ ਜੋ ਉਹ ਤੁਹਾਨੂੰ ਕਾਲ ਕਰ ਸਕਣ. ਰੇਡਿਟ, ਬਹੁਤ ਸਾਰੇ ਹੋਰ ਪ੍ਰਦਾਤਾਵਾਂ ਦੀ ਤਰ੍ਹਾਂ, ਪਿਛਲੇ ਸਮੇਂ ਵਿੱਚ ਉਪਭੋਗਤਾ ਦੀ ਜਾਣਕਾਰੀ ਲੀਕ ਹੋ ਗਈ ਹੈ ਅਤੇ ਤੁਸੀਂ ਨਹੀਂ ਚਾਹੁੰਦੇ ਕਿ ਤੁਹਾਡਾ ਫੋਨ ਨੰਬਰ ਅਗਲੇ ਸਾਲ ਲੀਕ ਹੋਣ ਤੱਕ ਸਾਲਾਂ ਤੋਂ ਰੈਡਿਟ ਦੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਬੈਠਾ ਰਹੇ. ਇਸ ਸੇਵਾ ਰਾਹੀਂ ਆਪਣੇ ਫੋਨ ਨੰਬਰ ਨੂੰ ਸਿੱਧਾ ਭੇਜੋ.
• ਤੁਹਾਡਾ ਜੀਵਨ ਸਾਥੀ ਤੁਹਾਨੂੰ ਸੁਨੇਹਾ ਭੇਜਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਕੰਮ ਤੇ ਹੁੰਦੇ ਹੋ ਸਹੂਲਤ ਲਈ ਲੌਗਇਨ ਚਾਹੁੰਦੇ ਹੋ ਕਿਉਂਕਿ ਉਸਦੀ ਸਹੇਲੀ ਨੇ ਇੱਕ ਨਵਾਂ ਪ੍ਰੋਗਰਾਮ ਅਜ਼ਮਾਇਆ ਜਿਸਨੇ ਉਸਦੇ ਬਿਜਲੀ ਦੇ ਬਿੱਲ ਤੇ ਉਸਦੇ ਪੈਸੇ ਦੀ ਬਚਤ ਕੀਤੀ ਅਤੇ ਉਹ ਇਸਦੀ ਜਾਂਚ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ. ਇੱਥੇ ਇੱਕ ਸਾਂਝਾ ਪਰਿਵਾਰਕ ਪਾਸਵਰਡ ਪ੍ਰਬੰਧਕ ਹੈ ਜਿਸ ਬਾਰੇ ਤੁਸੀਂ ਉਸਨੂੰ ਯਾਦ ਦਿਵਾਉਂਦੇ ਹੋ, ਪਰ ਉਹ ਚਾਹੁੰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਲੌਗਇਨ ਭੇਜੋ. ਓ.ਐੱਮ.ਐੱਮ.ਓ. ਤੁਹਾਡੇ ਪਤੀ / ਪਤਨੀ ਨਾਲ ਤਤਕਾਲ ਮੈਸੇਜ ਕਰਨ ਲਈ ਲਗਾਇਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਸ ਲਈ ਤੁਸੀਂ ਬਹੁਤ ਵਿਸ਼ਵਾਸ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ ਕਿ ਸੁਨੇਹਾ ਆਵਾਜਾਈ ਸੁਰੱਖਿਅਤ ਹੈ; ਹਾਲਾਂਕਿ, ਚੈਟ ਇਤਿਹਾਸ ਆਪਣੇ ਆਪ ਹੀ ਬਿਨਾਂ ਇੰਕ੍ਰਿਪਟਡ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ. ਤੁਹਾਡਾ ਜੀਵਨਸਾਥੀ ਹਮੇਸ਼ਾ ਡਾਉਨਲੋਡਸ, ਈਮੇਲਾਂ ਆਦਿ ਬਾਰੇ ਸੁਚੇਤ ਨਹੀਂ ਹੁੰਦਾ ਅਤੇ ਉਪਯੋਗਤਾ ਬਿੱਲ ਥੋੜੇ ਸੰਵੇਦਨਸ਼ੀਲ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਦੀ ਪਛਾਣ ਚੋਰੀ ਲਈ ਰਿਹਾਇਸ਼ੀ ਸਾਬਤ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ. ਤੁਸੀਂ ਉਸ ਦੀ ਕੰਪਿ serviceਟਰ ਤੇ ਕਾੱਪੀ ਨੂੰ ਸਟੋਰ ਕਰਨ ਤੋਂ ਬਚਾਉਣ ਲਈ ਇਸ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲੌਗਇਨ ਵੇਰਵੇ ਭੇਜ ਸਕਦੇ ਹੋ.

ਇਹ ਸੇਵਾ ਕਿਸ ਲਈ ਨਹੀਂ ਵਰਤੀ ਜਾ ਸਕਦੀ?

ਇਸ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਬਹੁਤ ਹੀ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਲਈ ਇਸ FAQ ਵਿੱਚ ਵਰਣਿਤ ਸਾਰੇ ਕਾਰਨਾਂ ਕਰਕੇ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ. ਹੇਠਾਂ ਕੁਝ ਉਦਾਹਰਣਾਂ ਹਨ ਜੋ ਨਾ ਕਰੋ:

• ਅਣਉਚਿਤ ਸੰਦੇਸ਼ ਆਵਾਜਾਈ ਨੂੰ "ਵਧੇਰੇ ਸੁਰੱਖਿਅਤ" ਬਣਾਉਣ ਲਈ ਇਸ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ. ਕਿਉਂਕਿ ਮੂਲ ਸੈਟਿੰਗ ਨੂੰ ਯੂਆਰਐਲ ਵਿੱਚ ਪਾਸਵਰਡ ਸ਼ਾਮਲ ਕਰਨਾ ਹੁੰਦਾ ਹੈ ਜੋ ਸੁਨੇਹਾ ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਲਿੰਕ ਵਾਲਾ ਕੋਈ ਵੀ ਸੁਨੇਹਾ ਪੜ੍ਹ ਸਕਦਾ ਹੈ. ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਚੁਣੀ ਗਈ ਟ੍ਰਾਂਸਪੋਰਟ (ਜਿਵੇਂ ਕਿ ਇੱਕ ਟੈਕਸਟ) ਦੇ ਅੰਦਰੂਨੀ ਕੋਈ ਵੀ ਸੁਰੱਖਿਆ / ਗੋਪਨੀਯਤਾ ਦੇ ਮੁੱਦੇ ਵਿਰਾਸਤ ਵਿੱਚ ਆਉਂਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਇਸ ਸਾਧਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ. ਇਸ ਲਈ, ਉਦਾਹਰਣ ਵਜੋਂ, ਜੇ ਤੁਸੀਂ ਕਦੇ ਵੀ ਇਸ ਦੇ ਸੰਵੇਦਨਸ਼ੀਲ ਸੁਭਾਅ ਕਾਰਨ ਖਾਸ ਜਾਣਕਾਰੀ ਭੇਜਣ ਲਈ ਈਮੇਲ ਦੀ ਵਰਤੋਂ ਬਾਰੇ ਨਹੀਂ ਸੋਚਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ ਇਸ ਸੇਵਾ ਨੂੰ ਈਮੇਲ ਦੇ ਉਸ ਹਿੱਸੇ ਨੂੰ "ਸੁਰੱਖਿਅਤ" ਕਰਨ ਲਈ ਨਹੀਂ ਵਰਤਣਾ ਚਾਹੀਦਾ.
• ਇਸ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਇਹ ਨਾ ਕਰਨ ਲਈ ਕਰੋ ਕਿ ਸੁਨੇਹੇ ਦੀ ਕੋਈ ਕਾਪੀ ਨਹੀਂ ਬਣਦੀ. ਬੱਸ ਇਸ ਲਈ ਕਿ ਅਸੀਂ ਇਨਕ੍ਰਿਪਟਡ ਸੰਦੇਸ਼ ਦੀ ਆਪਣੀ ਕਾੱਪੀ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਮਿਟਾ ਦਿੰਦੇ ਹਾਂ ਅਤੇ ਸਾਨੂੰ ਇਸਦੀ ਨਕਲ ਕਰਨਾ ਹੋਰ ਮੁਸ਼ਕਲ ਬਣਾ ਦਿੰਦਾ ਹੈ, ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਸੁਨੇਹੇ ਨੂੰ ਕਾਪੀ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ. ਉਦੋਂ ਕੀ ਜੇ ਪ੍ਰਾਪਤਕਰਤਾ ਆਪਣੀ ਸਕ੍ਰੀਨ ਦੀ ਫੋਟੋ ਲਵੇ? ਕੀ ਜੇ ਉਹ ਸਿਰਫ ਸੰਦੇਸ਼ ਲਿਖੋ? ਆਖਰਕਾਰ, ਜੇ ਪ੍ਰਾਪਤਕਰਤਾ ਸੁਨੇਹਾ ਪੜ੍ਹ ਸਕਦਾ ਹੈ - ਇੱਕ ਕਾਪੀ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ.
• ਇਹ ਸੇਵਾ ਇਸਤੇਮਾਲ ਨਾ ਕਰੋ ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰਨ ਲਈ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸੁਨੇਹਾ ਵਾਪਸ ਨਹੀਂ ਲਿਆ ਜਾ ਸਕਦਾ. ਇਹ ਸੇਵਾ ਸੁਨੇਹੇ ਨੂੰ ਇਕ ਬਿੰਦੂ ਤੋਂ ਦੂਜੇ ਤਕ ਪਹੁੰਚਾਉਣ ਲਈ ਇਕ ਹੋਰ ਸੰਦੇਸ਼ ਟ੍ਰਾਂਸਪੋਰਟ ਪ੍ਰਦਾਤਾ (ਜਿਵੇਂ ਕਿ ਈਮੇਲ, ਚੈਟ, ਆਦਿ) ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ. ਨਿਯੁਕਤ ਮੈਸੇਜ ਟ੍ਰਾਂਸਪੋਰਟ ਬਹੁਤ ਵਧੀਆ theੰਗ ਨਾਲ ਤੁਹਾਨੂੰ ਸੁਨੇਹੇ ਦਾ ਪਤਾ ਲਗਾ ਸਕਦਾ ਹੈ.
• ਇਸ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕੁਝ ਵੀ ਭੇਜਣ ਲਈ ਨਾ ਕਰੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਭੇਜਣ ਤੋਂ ਇਨਕਾਰ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ. ਸਿਰਫ ਕਿਉਂਕਿ ਸੁਨੇਹਾ ਆਪਣੇ ਆਪ ਮਿਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਮਿਟਾਏ ਗਏ ਸੰਦੇਸ਼ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਲਿੰਕ ਮਿਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ. ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਦੋਸਤ ਨੂੰ ਇਕ ਈਮੇਲ ਭੇਜਦੇ ਹੋ ਅਤੇ ਉਸ ਈਮੇਲ ਦੇ ਕੁਝ ਹਿੱਸੇ ਦਾ ਇਸ ਸੇਵਾ ਦੇ ਸੰਦੇਸ਼ ਦਾ ਲਿੰਕ ਹੈ, ਤਾਂ ਇਕ ਆਮ ਪਾਠਕ ਨੂੰ ਪਤਾ ਹੋਵੇਗਾ ਕਿ ਸੁਨੇਹੇ ਵਿਚ ਕੁਝ ਹੋਰ ਸੀ. ਭਾਵੇਂ ਕਿ ਲਿੰਕ ਦੁਆਰਾ ਜ਼ਿਕਰ ਕੀਤਾ ਸੁਨੇਹਾ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਖਤਮ ਹੋ ਗਿਆ ਹੈ - ਇਹ ਸਪਸ਼ਟ ਹੈ ਕਿ ਕੁਝ ਹੋਰ ਭੇਜਿਆ ਗਿਆ ਸੀ ਅਤੇ ਇਹ ਤੁਹਾਡੇ ਦੁਆਰਾ ਤੁਹਾਡੇ ਦੋਸਤ ਨੂੰ ਭੇਜਿਆ ਗਿਆ ਸੀ.

ਕਿਉਂ ਨਾ ਸਿਰਫ ਪੀਜੀਪੀ / ਸਿਗਨਲ / ਓਮੇਮੋ / ਮੈਟ੍ਰਿਕਸ / ਆਦਿ ਦੀ ਵਰਤੋਂ ਕਰੋ.

ਜੇ ਤੁਸੀਂ ਉਸ ਵਿਅਕਤੀ ਨੂੰ ਜਾਣਦੇ ਹੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਸੁਰੱਖਿਅਤ ਆਰਜ਼ੀ ਸੰਦੇਸ਼ ਭੇਜਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਉਨ੍ਹਾਂ ਨੂੰ ਅਕਸਰ ਭੇਜੋ, ਇੱਕ ਚੈਟ ਵਰਗਾ ਇੰਟਰਫੇਸ ਦੀ ਉਮੀਦ ਕਰੋ, ਅਤੇ / ਜਾਂ ਪ੍ਰਾਪਤ ਕਰਤਾ ਤੋਂ ਲੋੜੀਂਦੇ ਸਾੱਫਟਵੇਅਰ ਦੀ ਉਮੀਦ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇਸਦੀ ਵਰਤੋਂ ਬਾਰੇ ਜਾਣਦੇ ਹੋ, ਇਹ ਵੈੱਬ ਸਾਈਟ ਸ਼ਾਇਦ ਨਹੀਂ ਹੈ ਵਧੀਆ ਹੱਲ ਹੈ. ਇੱਥੇ ਬਹੁਤ ਵਧੀਆ ਵਿਕਲਪ ਹਨ ਜੋ ਓਪਨ ਸੋਰਸ ਹਨ, E2EE ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਵੈਬ-ਬੇਸਡ ਨਹੀਂ, ਅਤੇ ਇੱਥੋਂ ਤਕ ਕਿ ਕੁਝ ਸਿਗਨਲ ਜੋ ਅਸਥਾਈ ਸੰਦੇਸ਼ਾਂ ਦਾ ਸਮਰਥਨ ਵੀ ਕਰਦੇ ਹਨ. ਮੈਨੂੰ ਨਿੱਜੀ ਇੱਕ ਪ੍ਰਾਈਵੇਟ ਵਰਤਣ ਦੀ XMMP ਸਰਵਰ ਅਤੇ OMEMO ਨੇੜੇ ਦੋਸਤ ਅਤੇ ਪਰਿਵਾਰ ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਲਈ. ਇਸ ਸਾਈਟ ਦਾ ਇਸਤੇਮਾਲ ਸਿਰਫ ਉਚਿਤ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਪ੍ਰਾਪਤ ਕਰਤਾ ਕਿਹੜਾ ਸਾੱਫਟਵੇਅਰ ਚਲਾ ਰਿਹਾ ਹੈ, ਉਨ੍ਹਾਂ ਦੇ ਫੋਨ ਨੰਬਰ / ਸੰਪਰਕ-ਹੈਂਡਲ ਨੂੰ ਨਹੀਂ ਜਾਣਦੇ, ਉਨ੍ਹਾਂ ਦੀ ਤਕਨੀਕੀ ਕੁਸ਼ਲਤਾ ਨੂੰ ਨਹੀਂ ਜਾਣਦੇ (ਪਰ ਮੰਨ ਲਓ ਕਿ ਉਹ ਲਿੰਕ ਤੇ ਕਲਿੱਕ ਕਰ ਸਕਦੇ ਹਨ), ਜਾਂ ਤੁਸੀਂ ਆਪਣੇ ਦੁਆਰਾ ਭੇਜੇ ਸੰਦੇਸ਼ ਨੂੰ ਅੰਦਰੂਨੀ ਸੰਚਾਰ ਟ੍ਰਾਂਸਪੋਰਟ ਤੋਂ ਬਾਹਰ ਰੱਖਣਾ ਪਸੰਦ ਕਰਦੇ ਹੋ.

ਕਿਹੜੀਆਂ ਲੋੜਾਂ ਹਨ?

ਇੱਕ ਆਧੁਨਿਕ ਅਤੇ ਅਪ-ਟੂ-ਡੇਟ ਵੈਬ ਬ੍ਰਾ .ਜ਼ਰ ਜੋ ਵੈਬ ਕ੍ਰਿਪਟੋ ਏਪੀਆਈ ਸਮੇਤ ਮਿਆਰਾਂ ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਲਾਗੂ ਕਰਦਾ ਹੈ ਲੋੜੀਂਦਾ ਹੈ. ਉਦਾਹਰਣਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ: ਕਰੋਮ, ਫਾਇਰਫਾਕਸ, ਐਜ, ਅਤੇ ਸਫਾਰੀ (2020 ਜਾਂ ਇਸਤੋਂ ਬਾਅਦ).

ਕੀ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਸੁਨੇਹੇ ਦੀ ਇੱਕ ਕਾਪੀ ਬਣਾ ਸਕਦੇ ਹਨ?

ਹਾਂ. ਹਾਲਾਂਕਿ ਸੁਨੇਹਾ ਪ੍ਰਾਪਤੀ ਦੇ ਬਾਅਦ ਆਪਣੇ ਆਪ ਨੂੰ ਮਿਟਾ ਸਕਦਾ ਹੈ, ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ ਅਜੇ ਵੀ ਸੁਨੇਹਾ ਵੇਖ ਸਕਦਾ ਹੈ. ਜਦੋਂ ਵੀ ਰਿਸੀਵਰ ਸੰਦੇਸ਼ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੇਖ ਸਕਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਕਾੱਪੀ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ - ਇਹ ਸਾਰੇ ਸੰਚਾਰਾਂ ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ. ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਨੂੰ ਕਾੱਪੀ ਬਣਾਉਣਾ ਵਧੇਰੇ ਮੁਸ਼ਕਲ ਬਣਾਉਣ ਦਾ ਇੱਕ ਵਿਕਲਪ ਹੈ. ਇਸ ਕੇਸ ਵਿੱਚ ਨਕਲ ਕਰਨ ਵਿੱਚ ਤਿੰਨ ਰੁਕਾਵਟਾਂ ਲਾਗੂ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ:

• ਕਾਪੀ ਬਟਨ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ. ਇਹ ਬਟਨ ਡਿਫੌਲਟ ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਉਨ੍ਹਾਂ ਦੇ ਕਲਿੱਪਬੋਰਡ ਵਿੱਚ ਪੂਰੇ ਸੰਦੇਸ਼ ਦੀ ਨਕਲ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ.
• ਡਾਉਨਲੋਡ ਬਟਨ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ. ਇਹ ਬਟਨ ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਟੈਕਸਟ ਫਾਈਲ ਦੇ ਰੂਪ ਵਿੱਚ ਸੁਨੇਹਾ ਡਾ downloadਨਲੋਡ ਕਰਨ ਦੀ ਆਗਿਆ ਦੇਣ ਲਈ ਡਿਫੌਲਟ ਹੁੰਦਾ ਹੈ.
• ਮੈਸੇਜ ਟੈਕਸਟ ਬਾੱਕਸ ਦੇ ਅੰਦਰ ਟੈਕਸਟ ਚੁਣਨ ਦੀ ਯੋਗਤਾ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ.

ਹਾਲਾਂਕਿ, ਇਹ ਕਾੱਪੀ ਪ੍ਰੋਟੈਕਸ਼ਨ ਕਮਜ਼ੋਰ ਹਨ ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੂੰ ਬਾਈਪਾਸ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ. ਨਾਲ ਹੀ, ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ ਹਮੇਸ਼ਾਂ ਸਿਰਫ ਇੱਕ ਸਕ੍ਰੀਨਸ਼ਾਟ ਜਾਂ ਸੰਦੇਸ਼ ਦਾ ਇੱਕ ਫੋਟੋ ਲੈ ਸਕਦਾ ਹੈ.

ਕੀ ਕੋਈ ਨਿੱਜੀ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕੀਤੀ ਗਈ ਹੈ?

ਅਸੀਂ ਉਪਭੋਗਤਾ ਖਾਤਿਆਂ (ਜਿਵੇਂ ਕਿ ਉਪਯੋਗਕਰਤਾ / ਪਾਸਵਰਡ) ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੇ. ਅਸੀਂ ਕੋਈ ਵੀ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਨਹੀਂ ਕਰਦੇ ਜੋ ਤੁਹਾਨੂੰ ਪਛਾਣ ਸਕੇ (ਜਿਵੇਂ ਕਿ ਨਾਮ / ਪਤਾ / ਈਮੇਲ / ਫੋਨ). ਇਹ ਸੰਭਵ ਹੈ ਕਿ ਕੁਝ ਨਿੱਜੀ ਜਾਣਕਾਰੀ ਤੁਹਾਡੇ ਦੁਆਰਾ ਭੇਜੇ ਜਾ ਰਹੇ ਸੰਦੇਸ਼ ਵਿੱਚ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਇੰਕ੍ਰਿਪਟਡ ਹੈ ਅਤੇ ਸਾਡੇ ਕੋਲ ਇਸ ਨੂੰ ਪੜ੍ਹਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ. ਪੂਰੇ ਵੇਰਵਿਆਂ ਲਈ ਕਿਰਪਾ ਕਰਕੇ ਸਾਡੀ ਗੋਪਨੀਯਤਾ ਨੀਤੀ ਦੀ ਸਮੀਖਿਆ ਕਰੋ.

ਕਿਹੜੀ ਜਾਣਕਾਰੀ ਲੌਗ ਕੀਤੀ ਗਈ ਹੈ?

ਸਾਡਾ ਵੈਬ ਸਰਵਰ ਸਾਰੀ ਵੈਬ ਗਤੀਵਿਧੀ 'ਤੇ 24 ਘੰਟੇ ਦੇ ਆਮ ਲਾਗ ਫਾਰਮੈਟ ਨੂੰ ਰੱਖਦਾ ਹੈ. ਇਸ ਵਿੱਚ HTTP ਗਾਹਕਾਂ ਦਾ ਪੂਰਾ IP ਐਡਰੈੱਸ ਲੌਗ ਕਰਨਾ ਸ਼ਾਮਲ ਹੈ. 24 ਘੰਟਿਆਂ ਬਾਅਦ, ਇਹ ਲੌਗ ਕੀਤੀ ਜਾਣਕਾਰੀ ਆਪਣੇ ਆਪ ਮਿਟ ਜਾਏਗੀ. ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ / ਏਪੀਆਈ ਨੂੰ ਭੇਜੀਆਂ ਗਈਆਂ ਹਨ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਵੈਬ ਸਰਵਰ ਦੁਆਰਾ ਕੋਈ ਵੀ ਸੁਨੇਹਾ ਖਾਸ ਜਾਣਕਾਰੀ ਲੌਗ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਡਾਟਾਬੇਸ ਵਿਚ ਸੁਰੱਖਿਅਤ ਕੀਤੀ ਗਈ ਕੋਈ ਵੀ ਜਾਣਕਾਰੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ loggedੰਗ ਨਾਲ ਲਾਗ ਕੀਤੀ ਜਾਂਦੀ ਹੈ. ਅਗਿਆਤ ਅਤੇ ਹੈਸ਼ ਕੀਤੇ IP ਐਡਰੈੱਸਾਂ ਸਮੇਤ ਡਾਟਾਬੇਸ ਵਿਚਲੀਆਂ ਸਾਰੀਆਂ ਐਂਟਰੀਆਂ ਦੀ ਮਿਆਦ ਪੁੱਗਣ ਦਾ ਸਮਾਂ (ਟੀਟੀਐਲ) ਹੁੰਦਾ ਹੈ ਜਿਸ ਦੇ ਬਾਅਦ ਉਹ ਆਪਣੇ ਆਪ ਮਿਟ ਜਾਂਦੇ ਹਨ. ਟੀਟੀਐਲ ਦੀ ਮਿਆਦ ਖਤਮ ਹੋਣ ਦਾ ਸਮਾਂ 1 ਮਿੰਟ ਅਤੇ 2 ਹਫਤਿਆਂ ਦੇ ਵਿਚਕਾਰ ਹੁੰਦਾ ਹੈ.

ਤੁਸੀਂ ਸਰਵਰਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ ਕੀ ਕਰ ਰਹੇ ਹੋ?

ਸਰਵਰ ਸੁਰੱਖਿਆ ਇਕ ਸਪੱਸ਼ਟ ਚਿੰਤਾ ਹੈ. ਇਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਲਈ ਅਸੀਂ ਦੋ ਮੁੱਖ ਖੇਤਰਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਤ ਕਰਦੇ ਹਾਂ:

• ਪਹਿਲਾਂ, ਅਸੀਂ ਘੱਟ ਤੋਂ ਘੱਟ ਸਮੇਂ ਲਈ ਘੱਟ ਤੋਂ ਘੱਟ ਸਟੋਰ ਕਰਦੇ ਹਾਂ ਤਾਂ ਕਿ ਜੇ ਸਰਵਰ ਨਾਲ ਕਦੇ ਸਮਝੌਤਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕੋਈ ਵੀ ਜਾਣਕਾਰੀ ਲੀਕ ਸਾਡੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਨੁਕਸਾਨ ਨਹੀਂ ਪਹੁੰਚਾ ਸਕਦੀ. ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਸਾਰੇ ਸੁਨੇਹੇ ਡਿਕ੍ਰਿਪਟ ਕਰਨ ਦੇ ਕੋਈ ਸਾਧਨ ਨਾਲ ਇਨਕ੍ਰਿਪਟਡ ਨਹੀਂ ਹੁੰਦੇ. ਸਾਡੇ ਉਪਭੋਗਤਾਵਾਂ ਵਿੱਚ ਕਿਸੇ ਵੀ ਸੰਦੇਸ਼ ਨੂੰ ਜੋੜਨ ਲਈ ਇੱਥੇ ਕੁਝ ਵੀ ਸਟੋਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ ਕਿਉਂਕਿ ਅਸੀਂ ਆਪਣੇ ਉਪਭੋਗਤਾਵਾਂ ਤੋਂ ਕੋਈ ਨਿੱਜੀ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਨਹੀਂ ਕਰਦੇ. ਡੇਟਾਬੇਸ ਵਿਚਲੇ ਸਾਰੇ ਰਿਕਾਰਡਾਂ ਦਾ ਇਕ ਮਿਆਦ ਖਤਮ ਹੋਣ ਦਾ ਸਮਾਂ ਹੁੰਦਾ ਹੈ (ਟੀਟੀਐਲ) 1 ਮਿੰਟ ਤੋਂ ਲੈ ਕੇ 2 ਹਫ਼ਤਿਆਂ ਤਕ - ਇਸ ਸਮੇਂ ਦੇ ਲੰਘਣ ਤੋਂ ਬਾਅਦ ਰਿਕਾਰਡ ਆਪਣੇ ਆਪ ਡਿਲੀਟ ਹੋ ਜਾਂਦਾ ਹੈ. ਇਸ ਲਈ, ਡਾਟਾਬੇਸ ਵਿਚ ਮੌਜੂਦ ਬਹੁਤ ਸਾਰੀ ਜਾਣਕਾਰੀ ਪਹਿਲਾਂ ਹੀ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਮਿਟਾ ਦਿੱਤੀ ਗਈ ਸੀ.
• ਅਸੀਂ ਸਮਝੌਤੇ ਨੂੰ ਰੋਕਣ ਲਈ ਬਹੁਤ ਸਾਰੇ ਉਪਾਅ ਕਰਦੇ ਹਾਂ ਅਤੇ ਕੋਈ ਸਮਝੌਤਾ ਹੁੰਦਾ ਹੈ ਜੋ ਵਾਪਰਦਾ ਹੈ:
  • ਵੈਬ ਸਰਵਰ, ਨਿੰਜੀਨਕਸ , ਇਕ ਵੱਖਰੇ ਕੰਟੇਨਰ ਵਿਚ ਬਿਨਾਂ ਕਿਸੇ ਗੈਰ-ਅਧਿਕਾਰਤ ਉਪਭੋਗਤਾ ਦੇ ਤੌਰ ਤੇ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਲੌਗਜ਼ ਤੋਂ ਇਲਾਵਾ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਲਿਖਣ ਦੀ ਪਹੁੰਚ ਤੋਂ ਬਿਨਾਂ. ਕੰਨਟੇਨਰ ਆਪਣੇ ਖੁਦ ਦੇ SELinux ਪ੍ਰਸੰਗ ਵਿੱਚ ਚਲਦਾ ਹੈ ਅੱਗੇ ਤੋਂ ਕਿਸੇ ਵੀ ਫਾਇਲ ਸਿਸਟਮ ਬਦਲਾਵ ਜਾਂ ਕੰਟੇਨਰ ਤੋਂ ਅਸਾਨੀ ਨਾਲ ਬਚਣ ਨੂੰ ਰੋਕਦਾ ਹੈ. ਪੀਐਚਪੀ / ਏਐਸਪੀ / ਜੇਐਸਪੀ / ਆਦਿ ਲਈ ਕੋਈ ਸਹਾਇਤਾ ਨਹੀਂ ਹੈ. - ਸਿਰਫ ਸਥਿਰ ਸਰੋਤ ਦੀ ਸੇਵਾ.
  • ਕੋਡ ਚੱਲ ਰਿਹਾ ਹੈ / ਏਪੀਆਈ ਗੋ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ ਜਿਸ ਨੂੰ ਓਵਰਫਲੋ ਕਮਜ਼ੋਰੀ (ਇੱਕ ਆਮ ਹਮਲਾ ਵੈਟਰ) ਨੂੰ ਬਫਰ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਲਚਕੀਲਾ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ. ਗੋ ਪ੍ਰਕਿਰਿਆ ਇਕ ਵੱਖਰੇ ਕੰਟੇਨਰ ਵਿਚ ਬਿਨਾਂ ਕਿਸੇ ਪ੍ਰਵਾਸੀ ਉਪਭੋਗਤਾ ਦੇ ਤੌਰ ਤੇ ਵੀ ਚਲਦੀ ਹੈ, ਬਿਨਾਂ ਡੇਟਾਬੇਸ ਤੋਂ ਇਲਾਵਾ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਦੀ ਲਿਖਤ ਪਹੁੰਚ. ਕੰਨਟੇਨਰ ਆਪਣੇ ਖੁਦ ਦੇ SELinux ਪ੍ਰਸੰਗ ਵਿੱਚ ਚਲਦਾ ਹੈ ਅੱਗੇ ਤੋਂ ਕਿਸੇ ਵੀ ਫਾਇਲ ਸਿਸਟਮ ਬਦਲਾਵ ਜਾਂ ਕੰਟੇਨਰ ਤੋਂ ਅਸਾਨੀ ਨਾਲ ਬਚਣ ਨੂੰ ਰੋਕਦਾ ਹੈ. ਡਾਟਾਬੇਸ, ਬੈਜਰਡਬੀ , ਗੋ ਪ੍ਰਕਿਰਿਆ ਦਾ ਹਿੱਸਾ ਹੈ (ਬਾਹਰੀ ਡੇਟਾਬੇਸ ਨਿਰਭਰਤਾ / ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ).
  • ਸਰਵਰ ਸਮਝੌਤਾ ਕਰਨ ਦਾ ਮੁੱਖ ਖ਼ਤਰਾ ਇਹ ਹੈ ਕਿ ਹਮਲਾਵਰ ਫਾਈਲਾਂ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਸੰਸ਼ੋਧਿਤ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਸਾਡੇ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਗੋਪਨੀਯਤਾ / ਸੁਰੱਖਿਆ ਨਾਲ ਸਮਝੌਤਾ ਕਰੇਗਾ. ਇੱਕ ਸਮਰਪਿਤ ਪ੍ਰਕਿਰਿਆ ਕਿਸੇ ਵੀ ਤਬਦੀਲੀ ਲਈ ਸਾਰੀਆਂ ਵੈਬ ਸਾਈਟ ਫਾਈਲਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੀ ਹੈ ਅਤੇ ਕੋਈ ਵੀ ਤਬਦੀਲੀ ਹੋਣ ਤੇ ਤੁਰੰਤ ਸਾਨੂੰ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ.
  • ਸਾਰੇ ਪ੍ਰਬੰਧਕੀ ਪਹੁੰਚ ਸੁਰੱਖਿਅਤ ਅਤੇ ਅਧਿਕਾਰਤ ਨੈਟਵਰਕ ਤੱਕ ਸੀਮਿਤ ਹਨ.

ਇਸ ਸਾਈਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਕਿਹੜੇ ਸੁਰੱਖਿਆ ਜੋਖਮ ਮੌਜੂਦ ਹਨ?

ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਜੋਖਮਾਂ ਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਸੰਬੋਧਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਇੱਕ ਅਰਧ-ਸੰਖੇਪ ਸਮਾਨਤਾ ਕਿਸੇ ਵੀ ਇੰਟਰਨੈਟ ਸੰਚਾਰ ਦੀ ਵਰਤੋਂ ਦੇ ਜੋਖਮਾਂ ਨੂੰ ਸੰਖੇਪ ਵਿੱਚ ਦੱਸਣ ਵਿੱਚ ਸਹਾਇਤਾ ਕਰ ਸਕਦੀ ਹੈ. ਇਹ ਕਲਪਨਾ ਕਰੋ ਕਿ ਕੋਈ ਵੀ ਸਿਸਟਮ ਸਿਰਫ ਇਕ ਚੇਨ ਵਿਚਲੇ ਕਮਜ਼ੋਰ ਲਿੰਕ ਜਿੰਨਾ ਹੀ ਸੁਰੱਖਿਅਤ ਹੈ. ਹੁਣ ਇਕ ਦ੍ਰਿਸ਼ ਦੀ ਕਲਪਨਾ ਕਰੋ ਜਿੱਥੇ ਇਕ ਸੀਲ ਕੀਤੇ ਕਮਰੇ ਵਿਚ ਦੋ ਲੋਕ ਹਨ ਜੋ ਕੁਝ ਵੀ ਵੇਖਣ, ਸੁਣਨ ਜਾਂ ਰਿਕਾਰਡ ਕਰਨ ਦਾ ਕੋਈ ਸਾਧਨ ਨਹੀਂ ਹਨ. ਇਕ ਦੂਸਰੇ ਨੂੰ ਸੁਨੇਹਾ ਦੇਵੇਗਾ ਜਿਸ ਨੂੰ ਪੜ੍ਹਦਿਆਂ ਹੀ ਇਹ ਸਾੜ ਜਾਵੇਗਾ. ਜੇ ਉਸ ਕਮਰੇ ਤੋਂ ਬਾਹਰ ਕੋਈ ਵਿਅਕਤੀ ਸੁਨੇਹਾ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਪਾਸ ਕੀਤਾ ਗਿਆ ਸੀ, ਤਾਂ ਇਹ ਸਖਤ ਹੋ ਜਾਵੇਗਾ. ਸੁਨੇਹਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਕਮਜ਼ੋਰ ਲਿੰਕ ਕੀ ਹੈ? ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਲਿੰਕ ਚੁਣਨ ਲਈ ਨਹੀਂ ਹਨ - ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਛੋਟਾ ਲੜੀ ਹੈ. ਹੁਣ ਕਲਪਨਾ ਕਰੋ ਕਿ ਜਦੋਂ ਤੁਸੀਂ ਇੰਟਰਨੈਟ ਤੇ ਸੁਨੇਹਾ ਭੇਜਦੇ ਹੋ ਕਿ ਚੇਨ ਵਿਚ ਘੱਟੋ ਘੱਟ ਇਕ ਮਿਲੀਅਨ ਲਿੰਕ ਹਨ - ਉਨ੍ਹਾਂ ਵਿਚੋਂ ਬਹੁਤ ਸਾਰੇ ਕਮਜ਼ੋਰ ਹਨ - ਉਨ੍ਹਾਂ ਵਿਚੋਂ ਬਹੁਤ ਸਾਰੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤੁਹਾਡੇ ਨਿਯੰਤਰਣ ਤੋਂ ਬਾਹਰ ਹਨ - ਅਤੇ ਇਹ ਹਕੀਕਤ ਹੈ.

ਏਨਕ੍ਰਿਪਸ਼ਨ ਦੀ ਵਰਤੋਂ ਉਪਰੋਕਤ ਮਿਲੀਅਨ ਲਿੰਕ ਸਮੱਸਿਆ ਅਤੇ ਇਸ ਸੋਚ ਵਿਚ ਫਸਾਉਣ ਵਿਚ ਅਸਾਨ ਹੈ ਕਿ ਚੰਗੀ ਤਰ੍ਹਾਂ ਤਿਆਰ ਕੀਤੀ ਗਈ E2EE ਸਿਸਟਮ ਅੰਤ ਦੇ ਸਾਰੇ ਹੱਲ ਪੇਸ਼ ਕਰਦੀ ਹੈ. ਹਾਲਾਂਕਿ, ਇਹ ਸੋਚ ਤੁਹਾਨੂੰ ਮੁਸੀਬਤ ਵਿੱਚ ਪਾ ਸਕਦੀ ਹੈ, ਕਿਉਂਕਿ ਇੱਕ ਹਮਲਾਵਰ ਆਮ ਤੌਰ ਤੇ ਸਿਸਟਮ ਵਿੱਚ ਕਮਜ਼ੋਰ ਲਿੰਕਾਂ ਦੇ ਬਾਅਦ ਜਾਵੇਗਾ. ਉਦਾਹਰਣ ਦੇ ਲਈ, ਆਪਣੇ ਫੋਨ ਜਾਂ ਕੰਪਿ overਟਰ ਨੂੰ ਸੰਭਾਲਣਾ ਅਤੇ ਤਾਰ ਉੱਤੇ ਇਨਕ੍ਰਿਪਟਡ ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਕਰੈਕ ਕਰਨ ਨਾਲੋਂ ਤੁਸੀਂ ਜੋ ਵੀ ਲਿਖਦੇ ਹੋ ਉਸਨੂੰ ਲਿਖਣ ਲਈ ਇੰਪੁੱਟ ਲਾਗਰ ਸੈਟ ਅਪ ਕਰਨਾ ਸ਼ਾਇਦ ਸੌਖਾ ਹੈ. ਮੁੱਕਦੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਜੇ ਮੈਨੂੰ ਮਹੱਤਵਪੂਰਣ / ਨਾਜ਼ੁਕ ਮਹੱਤਵ ਦੇ ਰਾਜ਼ ਨੂੰ ਸੰਚਾਰਿਤ ਕਰਨ ਦਾ ਕੰਮ ਸੌਂਪਿਆ ਗਿਆ ਸੀ, ਤਾਂ ਮੈਂ ਸਿਰਫ ਆਖਰੀ ਰਿਜੋਰਟ ਦੇ aੰਗ ਵਜੋਂ ਇਲੈਕਟ੍ਰਾਨਿਕ ਸੰਚਾਰ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗਾ.

ਇਸ ਲਈ ਕਿਸੇ ਵੀ ਸੰਚਾਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੁਰੱਖਿਆ ਜੋਖਮ ਹਨ, ਪਰੰਤੂ ਤੁਸੀਂ ਅਜੇ ਵੀ ਬੈਂਕਿੰਗ, ਚੀਜ਼ਾਂ ਖਰੀਦਣ, ਈਮੇਲ ਆਦਿ ਲਈ ਵੈੱਬ ਬਰਾ browserਜ਼ਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ. ਅਸਲ ਵਿੱਚ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ... ਇਸ ਸਾਈਟ ਲਈ ਕਿਹੜੇ ਸੁਰੱਖਿਆ ਜੋਖਮ ਅਰਧ-ਵਿਸ਼ੇਸ਼ ਹਨ? ਕੁਝ ਮਨ ਵਿਚ ਆਉਂਦੇ ਹਨ:

• ਇਸ ਸੇਵਾ ਲਈ ਸਭ ਤੋਂ ਵੱਡਾ ਜੋਖਮ ਅਤੇ ਸਭ ਤੋਂ ਵਿਲੱਖਣ ਗੱਲ ਇਹ ਹੈ ਕਿ ਸਾਡੇ ਉਪਭੋਗਤਾ ਸਹੀ ਨਿਰਣੇ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ ਜਦੋਂ ਇਹ ਸਮਝਦੇ ਹੋਏ ਕਿ ਕੀ ਭੇਜਣਾ ਉਚਿਤ ਹੈ ਅਤੇ ਕੀ ਭੇਜਣਾ ਉਚਿਤ ਨਹੀਂ ਹੈ . ਕਈ ਵਾਰ "ਮੈਂ ਇਸ ਜਾਣਕਾਰੀ ਨੂੰ ਈਮੇਲ ਕਰਨਾ ਆਰਾਮਦਾਇਕ ਹਾਂ - ਮੇਰੀ ਇੱਛਾ ਹੈ ਕਿ ਈਮੇਲ ਪੜ੍ਹਨ ਤੋਂ ਬਾਅਦ ਮਿਟਾ ਦਿੱਤੀ ਜਾਏਗੀ" ਅਤੇ "ਮੈਂ ਇਸ ਜਾਣਕਾਰੀ ਨੂੰ ਈਮੇਲ ਕਰਨਾ comfortableਖਾ ਨਹੀਂ ਹਾਂ - ਈਮੇਲ ਇੱਕ ਅਣਉਚਿਤ ਆਵਾਜਾਈ ਹੈ" ਬਹੁਤ ਸੂਖਮ ਹੋ ਸਕਦਾ ਹੈ.
• ਇੱਥੇ ਹਮੇਸ਼ਾਂ ਧਮਕੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਇਸ ਸਾਈਟ ਦੇ ਸੰਚਾਲਕ ਅਸਲ ਵਿੱਚ ਮਾੜੇ ਅਦਾਕਾਰ ਹਨ ਜੋ ਲੋਕਾਂ ਨੂੰ ਕੁਝ ਹਨੇਰਾ ਅੰਤਮ ਟੀਚਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਲੁਭਾਉਂਦੇ ਹਨ. ਅਸੀਂ ਇਕ ਭਰੋਸੇਮੰਦ ਭਰੋਸੇਯੋਗ ਦੇ ਪਾਰ ਆਉਂਦੇ ਹਾਂ - ਹਰ ਚੀਜ਼ ਨੂੰ ਅਸਾਨ ਅਤੇ ਮੁਫਤ ਬਣਾਉਂਦੇ ਹਾਂ - ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰੋ - ਹਰ ਵੇਲੇ ਭਿਆਨਕ ਉਦੇਸ਼ ਨਾਲ. ਬੁਹਾਹਾਹਾਹਾਹਾ! ਤੁਸੀਂ ਕਿਵੇਂ ਸਾਡੇ ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹੋ?
• ਇੱਥੇ ਇਹ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਸਾਡੇ ਕੋਡ ਵਿੱਚ ਬੱਗ ਹਨ ਜੋ ਸੁਰੱਖਿਆ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦੇ ਹਨ ਜਾਂ ਅਸੀਂ ਸਿਰਫ ਚੀਜ਼ਾਂ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਸੋਚਦੇ ਅਤੇ ਸਾਡੀਆਂ ਕਮੀਆਂ ਹੁਣ ਸਾਡੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਬੇਵਜ੍ਹਾ ਖ਼ਤਰੇ ਦਾ ਸਾਹਮਣਾ ਕਰ ਰਹੀਆਂ ਹਨ. ਸਾਨੂੰ ਯਕੀਨ ਹੈ ਕਿ ਉਮੀਦ ਨਹੀਂ - ਪਰ ਅਸੀਂ ਇਸ ਤੋਂ ਇਨਕਾਰ ਨਹੀਂ ਕਰ ਸਕਦੇ.
• ਟੈਕ-ਟਾਇਟਨਜ਼ (ਜਿਵੇਂ ਕਿ ਗੂਗਲ / ਫੇਸਬੁੱਕ / ਵਟਸਐਪ) ਦੇ ਉਲਟ, ਜਿਸ ਵਿੱਚ ਏਰਕ੍ਰਿਪਟਡ ਡੇਟਾ ਦੀਆਂ ਟੇਰਾਬਿਟਸ ਲਗਾਤਾਰ ਆਪਣੇ ਵਿਸ਼ਾਲ ਨੈਟਵਰਕਸ ਵਿੱਚ ਆਉਂਦੀਆਂ ਜਾਂਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ, ਜਿੱਥੇ ਨਿੱਜੀ ਟ੍ਰੈਫਿਕਸ ਨੂੰ ਹੋਰ ਟ੍ਰੈਫਿਕ ਨਾਲ ਜੋੜਨਾ ਸੌਖਾ ਹੁੰਦਾ ਹੈ, ਇਕੱਲੇ ਕੇਂਦਰੀ ਸੇਵਾਵਾਂ (ਜਿਵੇਂ ਕਿ ਸਿਗਨਲ, ਟੈਲੀਗਰਾਮ, ਅਤੇ ਅਸੀਂ) ਬਾਹਰ ਖੜੇ. ਇੱਕ ਨੈਟਵਰਕ ਆਪਰੇਟਰ ਜਾਂ ਇੱਥੋਂ ਤੱਕ ਕਿ ਵੱਡੀ ਸੰਸਥਾ / ਸਰਕਾਰ ਲਈ ਇਹ ਵੇਖਣਾ ਆਸਾਨ ਹੈ ਕਿ ਆਈਪੀ ਐਡਰੈੱਸ ਐਕਸਐਂਗਐਕਸਐਕਸ XYZ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰ ਰਿਹਾ ਹੈ.
• ਹਾਲਾਂਕਿ ਇਸ ਸਾਈਟ ਲਈ ਅਸਲ ਵਿੱਚ ਖਾਸ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਕਿਸੇ ਵੀ ਵੈਬਸਾਈਟ ਦੇ ਵਿਰੁੱਧ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਮੈਨ-ਇਨ-ਦ-ਮਿਡਲ (ਐਮਆਈਟੀਐਮ) ਹਮਲੇ ਇੱਕ ਪ੍ਰਮਾਣਤ ਚਿੰਤਾ ਹਨ .

ਮੈਨ-ਇਨ-ਦ-ਮਿਡਲ (ਐਮਆਈਟੀਐਮ) ਹਮਲਿਆਂ ਬਾਰੇ ਤੁਸੀਂ ਕੀ ਕਰ ਰਹੇ ਹੋ?

ਵੈਬ ਸਾਈਟਾਂ ਦੇ ਸਾਰੇ ਉਪਭੋਗਤਾ ਸੰਭਾਵਤ ਤੌਰ ਤੇ ਐਮਆਈਟੀਐਮ ਦੇ ਹਮਲੇ ਦਾ ਸ਼ਿਕਾਰ ਹੋ ਸਕਦੇ ਹਨ - ਇਹ ਸਾਈਟ ਇਸ ਸੰਬੰਧ ਵਿੱਚ ਵੈੱਬ ਤੇ ਮੌਜੂਦ ਸਭ ਲੋਕਾਂ ਨਾਲੋਂ ਵੱਖਰੀ ਨਹੀਂ ਹੈ. ਇੱਕ ਐਮਆਈਟੀਐਮ ਹਮਲਾ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਹਮਲਾਵਰ ਉਪਭੋਗਤਾ ਦੇ ਬ੍ਰਾ browserਜ਼ਰ ਅਤੇ ਸਾਈਟ ਦੇ ਵੈੱਬ ਸਰਵਰ ਦੇ ਵਿਚਕਾਰ ਸੰਚਾਰ ਨੂੰ ਰੋਕਣ ਅਤੇ ਸੋਧਣ ਦੇ ਯੋਗ ਹੁੰਦਾ ਹੈ. ਇਹ ਹਮਲਾਵਰ ਨੂੰ ਸਾਈਟ ਦੇ ਕਿਸੇ ਵੀ ਕੋਡ / ਸਮਗਰੀ ਨੂੰ ਸੰਸ਼ੋਧਿਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਅਖੀਰਲੇ ਉਪਭੋਗਤਾ ਨੂੰ ਉਹ ਸਾਈਟ ਦਿਖਾਈ ਦੇ ਰਿਹਾ ਹੈ ਜਿਸਦੀ ਉਹ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਨ. ਅਸੀਂ ਐਮਆਈਟੀਐਮ ਹਮਲੇ ਨੂੰ ਹੋਰ ਮੁਸ਼ਕਲ ਬਣਾਉਣ ਲਈ ਕੁਝ ਉਪਾਅ ਕਰਦੇ ਹਾਂ:

• ਐਚਐਸਟੀਐਸ ਦੀ ਵਰਤੋਂ ਬ੍ਰਾsersਜ਼ਰਾਂ ਨੂੰ ਸਿਰਫ ਟੀਐਲਐਸ ਦੁਆਰਾ ਜੁੜਨ ਲਈ ਮਜ਼ਬੂਰ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ. ਸਾਡਾ ਸਰਵਰ ਰੀ-ਡਿਰੈਕਟ ਕਰਨ ਤੋਂ ਇਲਾਵਾ ਗੈਰ- TLS ਸੰਚਾਰ ਨੂੰ ਨਜ਼ਰ ਅੰਦਾਜ਼ ਕਰਨ ਲਈ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ. ਕੇਵਲ TLS 1.2 ਜਾਂ ਇਸਤੋਂ ਵੱਧ ਸਮਰਥਿਤ ਹਨ.
• DNSSEC ਦੀ ਵਰਤੋਂ ਸਾਡੇ ਡੋਮੇਨ ਦੇ ਜ਼ੋਨ ਤੇ ਦਸਤਖਤ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ. ਇਹ ਲਾਗੂ ਕੀਤੇ ਐਮਆਈਟੀਐਮ ਹਮਲਿਆਂ ਨੂੰ ਡੀਐਨਐਸ ਦੇ ਸਪੂਫਿੰਗ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ ਜੇ ਉਪਭੋਗਤਾ ਇੱਕ DNSSEC ਜਾਗਰੂਕ ਰਿਕਰਸਿਵ ਰੈਜ਼ੋਲਿਵਰ ਲਗਾ ਰਿਹਾ ਹੈ.
• ਅਸੀਂ ਸਾਡੇ ਡੋਮੇਨ ਦਾ ਹਵਾਲਾ ਦਿੰਦੇ ਹੋਏ ਕਿਸੇ ਵੀ ਅਣਅਧਿਕਾਰਤ TLS ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਜਾਰੀ ਕਰਨ ਵਾਲੇ ਸਰਟੀਫਿਕੇਟ ਅਧਿਕਾਰੀਆਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ ਇੱਕ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ.
• ਅਸੀਂ ਅੰਤਮ-ਉਪਭੋਗਤਾ ਦੇ ਡਿਵਾਈਸ ਤੇ ਸਟੋਰ ਕੀਤੇ ਕੋਡ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸੰਦੇਸ਼ ਏਨਕ੍ਰਿਪਸ਼ਨ ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ ਬ੍ਰਾ .ਜ਼ਰ ਐਕਸਟੈਂਸ਼ਨਾਂ ਪ੍ਰਕਾਸ਼ਤ ਕੀਤੀਆਂ ਹਨ.

ਹਾਲਾਂਕਿ, ਇੱਕ ਐਮਆਈਟੀਐਮ ਹਮਲਾ ਅਜੇ ਵੀ ਹਮੇਸ਼ਾਂ ਸੰਭਵ ਹੈ - ਖ਼ਾਸਕਰ ਜੇ ਹਮਲਾਵਰ ਨੈਟਵਰਕ / ਜਨਤਕ-ਕੁੰਜੀ infrastructureਾਂਚੇ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਵੱਡੇ / ਸ਼ਕਤੀਸ਼ਾਲੀ ਸੰਗਠਨਾਂ ਜਾਂ ਸਰਕਾਰਾਂ ਲਈ ਹੁੰਦਾ ਹੈ. ਅਸੀਂ ਬ੍ਰਾ browserਜ਼ਰ ਐਕਸਟੈਂਸ਼ਨਾਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੇ ਹਾਂ ਜੋ ਕੁਝ ਐਮਆਈਟੀਐਮ ਜੋਖਮਾਂ ਨੂੰ ਘਟਾਉਣ ਵਿੱਚ ਸਹਾਇਤਾ ਕਰ ਸਕਦੀ ਹੈ.

ਬ੍ਰਾ browserਜ਼ਰ ਐਕਸਟੈਂਸ਼ਨ ਕਿਹੜੇ ਫਾਇਦੇ ਪੇਸ਼ ਕਰਦੇ ਹਨ?

ਅਸੀਂ ਬ੍ਰਾ browserਜ਼ਰ ਐਕਸਟੈਂਸ਼ਨਾਂ ਨੂੰ ਵਾਧੂ ਸਹੂਲਤਾਂ ਅਤੇ ਵਾਧੂ ਸੁਰੱਖਿਆ ਪ੍ਰਦਾਨ ਕਰਨ ਦੇ ਸਾਧਨ ਵਜੋਂ ਪੇਸ਼ ਕਰਦੇ ਹਾਂ. ਸਧਾਰਣ ਸ਼ਬਦਾਂ ਵਿੱਚ ... ਐਕਸਟੈਂਸ਼ਨ ਅਸਥਾਈ ਸੁਨੇਹੇ ਭੇਜਣਾ ਤੇਜ਼ ਅਤੇ ਅਸਾਨ ਬਣਾ ਦਿੰਦੀਆਂ ਹਨ. ਕੁਝ ਸੁਰੱਖਿਆ ਇਸ ਲਈ ਵੀ ਪ੍ਰਾਪਤ ਕੀਤੀ ਗਈ ਹੈ ਕਿਉਂਕਿ ਇਕ ਕੋਡ ਨੂੰ ਏਨਕ੍ਰਿਪਟ ਕਰਨ ਅਤੇ ਤਿਆਰ ਕਰਨ ਲਈ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਸਾਰੇ ਕੋਡ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਐਕਸਟੈਂਸ਼ਨ ਦੇ ਅੰਦਰ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ. ਕਿਉਂਕਿ ਕੋਡ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਇਸ ਨਾਲ ਇਹ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਐਮਆਈਟੀਐਮ ਹਮਲਿਆਂ ਤੋਂ ਕੁਝ ਸੁਰੱਖਿਆ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ. ਹਾਲਾਂਕਿ, ਇਹ ਦੱਸਣਾ ਮਹੱਤਵਪੂਰਣ ਹੈ ਕਿ ਜਦੋਂ ਐਕਸਟੈਂਸ਼ਨਾਂ ਇੱਕ ਐਮਆਈਟੀਐਮ ਹਮਲੇ ਦੇ ਵਿਰੁੱਧ ਵਧੇਰੇ ਸੁਰੱਖਿਆ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੀਆਂ ਹਨ ਜੋ ਸੰਦੇਸ਼ ਦੇ ਸੰਖੇਪਾਂ ਨਾਲ ਸਮਝੌਤਾ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਇੱਕ ਐਮਆਈਟੀਐਮ ਹਮਲਾ ਅਜੇ ਵੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋ ਸਕਦਾ ਹੈ (ਅਰਥਾਤ ਜੇ ਟੀ.ਓ.ਆਰ. / ਵੀਪੀਐਨ / ਆਦਿ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰਦੇ ਹੋਏ ਭੇਜਣ ਵਾਲੇ ਦਾ IP ਪਤਾ ਪਤਾ ਕਰਨ ਲਈ).

ਮੈਂ ਕਿਵੇਂ ਪੱਕਾ ਜਾਣ ਸਕਦਾ ਹਾਂ ਕਿ ਜਮ੍ਹਾਂ ਕੀਤੀ ਗਈ ਕੋਈ ਵੀ ਚੀਜ਼ ਅੰਤ ਤੋਂ ਟੂ-ਐਂਡ੍ਰਿਪਟਡ ਹੈ?

ਕਈ ਹੋਰ ਪ੍ਰਸਿੱਧ ਅੰਤ-ਤੋਂ-ਅੰਤ ਐਨਕ੍ਰਿਪਟਡ (E2EE) ਚੈਟ ਕਲਾਇੰਟਸ ਦੇ ਉਲਟ, ਇਹ ਵੇਖਣਾ ਬਿਲਕੁਲ ਅਸਾਨ ਹੈ ਕਿ ਜਦੋਂ ਤੁਸੀਂ ਕੋਈ ਸੁਨੇਹਾ ਭੇਜਦੇ ਹੋ ਤਾਂ ਸਾਨੂੰ ਕੀ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ. ਹੇਠਾਂ ਦਿੱਤਾ ਵੀਡੀਓ ਟਿutorialਟੋਰਿਅਲ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਪੁਸ਼ਟੀ ਕਿਵੇਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਸਾਡੇ ਕੋਲ ਸਰਵਰ ਨੂੰ ਭੇਜੇ ਗਏ ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ.

ਨਾਲ ਹੀ, ਜੇ ਤੁਸੀਂ ਇਸ ਬਾਰੇ ਸੋਚਦੇ ਹੋ, ਜਦੋਂ ਤੱਕ ਅਸੀਂ ਕੋਈ ਗੁਪਤ ਏਜੰਸੀ ਨਾ ਹੋ ਕੇ ਸੰਵੇਦਨਸ਼ੀਲ ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ, ਉਦੋਂ ਤੱਕ ਸਾਨੂੰ ਕੋਈ ਫ਼ਾਇਦਾ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਸਾਨੂੰ ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਣਾ ਹੈ ਕਿਉਂਕਿ ਉਸ ਯੋਗਤਾ ਦਾ ਹੋਣਾ ਸਾਡੇ ਲਈ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ. ਅਸੀਂ ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨਾ ਵੀ ਨਹੀਂ ਚਾਹੁੰਦੇ - ਹਾਲਾਂਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਪ੍ਰਦਾਨ ਕਰਨਾ ਇਸ ਲਈ ਜ਼ਰੂਰੀ ਬੁਰਾਈ ਹੈ.

ਇਸ ਸਾਈਟ ਤੇ ਐਂਡ-ਟੂ-ਐਂਡ ਇਨਕ੍ਰਿਪਸ਼ਨ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ?

ਇਸ ਸਮੇਂ, ਅਸੀਂ ਪਾਸਵਰਡਾਂ ਤੋਂ ਪ੍ਰਾਪਤ ਕੁੰਜੀਆਂ (PBKDF2 / SHA-256 ਦੇ ਘੱਟੋ ਘੱਟ 150,000 ਦੁਹਰਾਈ) ਦੇ ਨਾਲ ਸਮਰੂਪ ਇਨਕ੍ਰਿਪਸ਼ਨ (ਏਈਐਸ-ਜੀਸੀਐਮ 256 ਬਿੱਟ) ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਾਂ. ਅਸਮੈਟ੍ਰਿਕ ਏਨਕ੍ਰਿਪਸ਼ਨ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ ਕਿਉਂਕਿ ਜ਼ਰੂਰਤਾਂ ਮੌਜੂਦ ਹਨ 1) ਸੰਚਾਰ ਅਰੰਭ ਕਰਨ ਵਾਲੇ ਭੇਜਣ ਵਾਲੇ 2) ਭੇਜਣ ਵਾਲੇ ਅਤੇ ਪ੍ਰਾਪਤਕਰਤਾ ਇਕੋ ਸਮੇਂ onlineਨਲਾਈਨ ਨਹੀਂ ਹੁੰਦੇ ਅਤੇ 3) ਪ੍ਰਾਪਤਕਰਤਾ ਬਾਰੇ ਕੋਈ ਜਾਣਕਾਰੀ ਨਹੀਂ ਅਤੇ 4) ਅਸੀਂ ਚੀਜ਼ਾਂ ਨੂੰ ਅਸਲ ਸਧਾਰਣ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ ਅਤੇ ਕੁੰਜੀ ਪ੍ਰਬੰਧਨ ਹੈ. ਗੁੰਝਲਦਾਰ. ਸਟੈਂਡਰਡ ਵੈਬ ਕ੍ਰਿਪਟੋ ਏਪੀਆਈ ਦੀ ਵਰਤੋਂ ਸਾਰੇ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਫੰਕਸ਼ਨੈਲਿਟੀ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਆਰ ਐਨ ਜੀ ਸ਼ਾਮਲ ਹਨ. ਅਸਲ ਵਿੱਚ, ਇੱਥੇ ਕੀ ਹੁੰਦਾ ਹੈ:

1. ਅੰਤ ਵਾਲਾ ਉਪਭੋਗਤਾ ਇੱਕ ਪਾਸਵਰਡ ਚੁਣਦਾ ਹੈ ਜਾਂ ਇੱਕ ਆਟੋਮੈਟਿਕ ਤਿਆਰ ਹੁੰਦਾ ਹੈ
2. ਲੋੜੀਂਦਾ PBKDF2 / SHA-256 ਦੁਹਰਾਓ ਦੀ ਗਿਣਤੀ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਇੱਕ API ਕਾਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ( ਸਪੈਮ ਨਿਯੰਤਰਣ ਲਈ ਇਹ ਕਦਮ ਲੋੜੀਂਦਾ ਹੈ )
3. ਇੱਕ 32 ਬਾਈਟ ਨਮਕ ਪੈਦਾ ਹੁੰਦਾ ਹੈ
4. ਇੱਕ ਕੁੰਜੀ ਲੂਣ ਅਤੇ ਪਾਸਵਰਡ ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤੀ ਗਈ ਹੈ
5. ਇੱਕ 12 ਬਾਈਟ ਸ਼ੁਰੂਆਤੀ ਵੈਕਟਰ (IV) ਤਿਆਰ ਹੁੰਦਾ ਹੈ
6. ਸੁਨੇਹਾ + IV ਕੁੰਜੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਏਨਕ੍ਰਿਪਟ ਕੀਤਾ ਗਿਆ ਹੈ
7. ਦੁਹਰਾਉਣ ਦੀ ਗਿਣਤੀ, ਨਮਕ, IV, ਅਤੇ ਸਿਫਰ ਟੈਕਸਟ ਸਰਵਰ ਨੂੰ ਭੇਜੇ ਜਾਂਦੇ ਹਨ (ਕੁਝ ਹੋਰ ਜਾਣਕਾਰੀ ਜਿਵੇਂ TTL, RTL, ਆਦਿ ਦੇ ਨਾਲ)
8. ਸਰਵਰ ਸੁਨੇਹੇ ਦਾ ਹਵਾਲਾ ਦੇ ਕੇ ਇੱਕ ਬੇਤਰਤੀਬ ID ਵਾਪਸ ਕਰਦਾ ਹੈ
9. ਫਿਰ ਬਰਾ browserਜ਼ਰ ਅੰਤ-ਉਪਭੋਗਤਾ ਨੂੰ ਇੱਕ ਲਿੰਕ ਦੇ ਨਾਲ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਵਾਪਸੀ ਕੀਤੀ ਆਈਡੀ ਅਤੇ ਪਾਸਵਰਡ ਜਾਂ ਪਾਸਵਰਡ ਤੋਂ ਬਿਨਾਂ ਕੋਈ ਲਿੰਕ ਹੁੰਦਾ ਹੈ (ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਪਾਸਵਰਡ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਦਰਜ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ)
10. ਜੇ ਪਾਸਵਰਡ ਲਿੰਕ ਦਾ ਹਿੱਸਾ ਹੈ, ਇਹ ਯੂਆਰਐਲ ਹੈਸ਼ ਵਿੱਚ ਹੈ , ਅਤੇ ਇਸ ਲਈ ਕਦੇ ਵੀ ਸਰਵਰ ਨੂੰ ਨਹੀਂ ਭੇਜਿਆ ਗਿਆ ਜਦੋਂ ਪ੍ਰਾਪਤਕਰਤਾ ਜੀ ਈ ਟੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ
11. ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਨੂੰ ਪੁੱਛਿਆ ਜਾਂਦਾ ਹੈ ਜੇ ਉਹ ਡੀਕ੍ਰਿਪਟ ਕਰਨਾ ਅਤੇ ਸੁਨੇਹੇ ਨੂੰ ਵੇਖਣਾ ਚਾਹੁੰਦੇ ਹਨ
12. ਬ੍ਰਾ .ਜ਼ਰ ਸੁਨੇਹਾ ID ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਇੱਕ ਬੇਨਤੀ ਕਰਦਾ ਹੈ
13. ਜੇ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਕੈਪਟਚਾ ਪੂਰਾ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਨੂੰ ਦੂਜੇ ਯੂਆਰਐਲ ਤੇ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਜੋ ਉਹ ਸਾਬਤ ਕਰ ਸਕਣ ਕਿ ਉਹ ਮਨੁੱਖ ਹਨ (ਇੱਕ ਵਾਰ ਜਦੋਂ ਉਹ ਪਾਸ ਹੋ ਗਏ ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਵਾਪਸ ਭੇਜ ਦਿੱਤਾ ਗਿਆ)
14. ਸਰਵਰ ਇਨਕ੍ਰਿਪਟਡ ਸੁਨੇਹਾ ਭੇਜਦਾ ਹੈ ਅਤੇ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸੁਨੇਹੇ ਨੂੰ ਇਸ ਸਮੇਂ ਮਿਟਾ ਦੇਵੇਗਾ ਜੇ ਰੀਡ-ਟੂ-ਲਾਈਵ (RTL) ਇੱਕ ਹੈ
15. ਪ੍ਰਾਪਤਕਰਤਾ ਪਾਸਵਰਡ ਨਾਲ ਸੁਨੇਹੇ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰੇਗਾ (ਅਤੇ ਪਾਸਵਰਡ ਲਈ ਪੁੱਛਿਆ ਜਾਵੇਗਾ ਜੇ URL ਵਿੱਚ ਨਹੀਂ)

ਇਹ ਸੈਟਅਪ ਬਹੁਤ ਅਸਾਨ ਹੈ, ਅਤੇ ਪ੍ਰਾਪਤੀਕਰਤਾ ਦੇ ਉਪਕਰਣ ਨੂੰ ਭੇਜਣ ਵਾਲੇ ਦੇ ਉਪਕਰਣ ਤੋਂ ਸੁਨੇਹਾ ਐਨਕ੍ਰਿਪਸ਼ਨ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ, ਪਰ ਯਕੀਨਨ ਇਸ ਗੱਲ ਦੀ ਗਰੰਟੀ ਨਹੀਂ ਹੈ ਕਿ ਅਸਮੈਟ੍ਰਿਕ ਇਨਕ੍ਰਿਪਸ਼ਨ ਪ੍ਰਾਪਤਕਰਤਾ ਦੀ ਨਿਜੀ ਕੁੰਜੀ ਦੇ ਕਬਜ਼ੇ ਵਾਲੇ ਕਿਸੇ ਵਿਅਕਤੀ ਨੂੰ ਜਾਣਨ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਹੀ ਸੰਦੇਸ਼ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰ ਸਕਦੀ ਹੈ. ਲਿੰਕ ਵਾਲਾ ਕੋਈ ਵੀ ਸੰਦੇਸ਼ ਨੂੰ ਡਿਫੌਲਟ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਖੋਲ੍ਹ ਸਕਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਪਾਸਵਰਡ ਯੂਆਰਐਲ ਦਾ ਹਿੱਸਾ ਹੁੰਦਾ ਹੈ - ਇਹ ਲਿੰਕ ਲਈ transportੁਕਵੀਂ ਆਵਾਜਾਈ ਦੀ ਵਰਤੋਂ ਦੀ ਮਹੱਤਤਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ (ਜਿਵੇਂ ਕਿ ਈਮੇਲ / ਚੈਟ / ਟੈਕਸਟ / ਆਦਿ.) - ਤੇ ਛੱਡਿਆ ਇੱਕ ਫੈਸਲਾ ਭੇਜਣ ਵਾਲਾ. ਅਸੀਂ, ਜੇ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਾਂ, ਇੱਕ ਬਹੁਤ ਹੀ ਮੁ basicਲੀ ਅਸਮੈਟ੍ਰਿਕ ਸਕੀਮ ਲਈ ਸਮਰਥਨ ਵੀ ਕੱ. ਸਕਦੇ ਹਾਂ ਜਿਸਦੇ ਦੁਆਰਾ ਪ੍ਰਾਪਤਕਰਤਾ ਇੱਕ ਸੰਦੇਸ਼ ਲਈ ਇੱਕ ਬੇਨਤੀ ਅਰੰਭ ਕਰਦਾ ਹੈ ਅਤੇ ਉਸ ਬੇਨਤੀ ਨੂੰ ਸੰਦੇਸ਼ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਭੇਜਦਾ ਹੈ. ਇਹ ਸੈਟਅਪ ਯੂਆਰਐਲ ਵਿੱਚ ਪਾਸਵਰਡ ਰੱਖਣ ਦੀ ਜ਼ਰੂਰਤ ਨੂੰ ਖਤਮ ਕਰ ਦੇਵੇਗਾ, ਪਰੰਤੂ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਅਰੰਭ ਕਰਨ ਦੀ ਯੋਗਤਾ ਨੂੰ ਵੀ ਖਤਮ ਕਰ ਦੇਵੇਗਾ.

ਡੀਕ੍ਰਿਪਸ਼ਨ ਪਾਸਵਰਡ ਯੂਆਰਐਲ ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ?

ਹਾਂ. ਇਹ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਆ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਜੇਕਰ ਲਿੰਕ ਭੇਜਣ ਲਈ ਵਰਤਿਆ ਗਿਆ insecੰਗ ਅਸੁਰੱਖਿਅਤ ਹੈ, ਤਾਂ ਸੰਗਤ ਦੁਆਰਾ ਸੰਦੇਸ਼ ਅਸੁਰੱਖਿਅਤ ਹੈ. ਇਸ ਮੁੱਦੇ ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ ਸਾਰੇ ਕਾਰਜਕੁਸ਼ਲਤਾ ਅਤਿਰਿਕਤ ਕਦਮ ਅਤੇ ਗੁੰਝਲਤਾਵਾਂ ਪੇਸ਼ ਕਰਦੀਆਂ ਹਨ ਜੋ ਉਪਭੋਗਤਾ ਦੇ ਤਜ਼ਰਬੇ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦੀਆਂ ਹਨ (ਭਾਵ ਚੀਜ਼ਾਂ ਨੂੰ ਸੰਦੇਸ਼ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਸਿਰੇ 'ਤੇ ਸੈਟਅਪ ਕਰਨਾ ਹੁੰਦਾ ਹੈ). ਇੱਕ ਅਸਮੈਟ੍ਰਿਕ ਸਕੀਮ ਜਿਸਦੇ ਤਹਿਤ ਪ੍ਰਾਪਤਕਰਤਾ ਇੱਕ ਸੰਦੇਸ਼ ਲਈ ਇੱਕ ਬੇਨਤੀ ਅਰੰਭ ਕਰਦਾ ਹੈ ਅਤੇ ਭੇਜਦਾ ਹੈ ਕਿ ਬੇਨਤੀ ਲਿੰਕ ਸਾਡੀ "ਸਭ ਕੁਝ ਹੈ ਸੰਖੇਪ" ਕੁੰਜੀ ਜ਼ਰੂਰਤ ਦੇ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ - ਇਸ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ. ਆਖਰਕਾਰ, ਜੇ ਦੋ ਧਿਰਾਂ ਇੱਕ ਦੂਜੇ ਨੂੰ ਸੰਦੇਸ਼ ਅਕਸਰ ਭੇਜ ਰਹੀਆਂ ਹਨ, ਤਾਂ ਇਹ ਬਿਹਤਰ ਹੱਲ ਮੌਜੂਦ ਹਨ ਕਿ ਇਹ ਮੰਨ ਕੇ ਕਿ ਦੋਵੇਂ ਧਿਰਾਂ ਇਨ੍ਹਾਂ ਹੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੀਆਂ ਹਨ.

ਪਰ ਡੀਕ੍ਰਿਪਸ਼ਨ ਪਾਸਵਰਡ URL ਵਿੱਚ ਹੋਣਾ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ?

ਸਹੀ. ਜੇ ਲਿੰਕ ਵਿੱਚ ਡਿਕ੍ਰਿਪਸ਼ਨ ਪਾਸਵਰਡ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਪਾਸਵਰਡ ਲਈ ਪੁੱਛਿਆ ਜਾਵੇਗਾ. ਜੇ ਪਾਸਵਰਡ ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਸੁਰੱਖਿਅਤ communੰਗ ਨਾਲ ਸੰਚਾਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਜਾਂ ਉਹ ਪਹਿਲਾਂ ਹੀ ਇਸ ਨੂੰ ਜਾਣਦੇ ਹਨ), ਤਾਂ ਇਹ ਇੰਟਰਸੈਪਟ ਤੋਂ ਸੁਰੱਖਿਆ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ. ਹਾਲਾਂਕਿ, ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਸਹੀ passwordੰਗ ਨਾਲ ਪਾਸਵਰਡ ਦਰਜ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ. ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਪਾਸਵਰਡ ਭੇਜਣ ਦਾ ਇਹ ਇੱਕ ਤਰੀਕਾ ਹੈ ਜੋ ਰੁਕਾਵਟ ਦੇ ਵਿਰੁੱਧ ਕੁਝ ਸੁਰੱਖਿਆ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ:

1. ਡਿਫੌਲਟ ਸੈਟਿੰਗਜ਼ ਦੇ ਨਾਲ ਇੱਕ ਸੁਨੇਹੇ ਵਿੱਚ ਪਾਸਵਰਡ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰੋ ਅਤੇ ਇਸ ਲਿੰਕ ਨੂੰ ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਭੇਜੋ.
2. ਜਦੋਂ ਪ੍ਰਾਪਤਕਰਤਾ ਲਿੰਕ ਤੇ ਕਲਿਕ ਕਰਦਾ ਹੈ ਅਤੇ ਸੁਨੇਹੇ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ, ਉਹ ਜਾਣਦੇ ਹਨ ਕਿ ਉਨ੍ਹਾਂ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਹੋਰ ਨੇ ਪਾਸਵਰਡ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕੀਤਾ ਕਿਉਂਕਿ ਪਾਸਵਰਡ ਵਾਲਾ ਸੰਦੇਸ਼ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਤੇ ਮਿਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ. ਹਾਲਾਂਕਿ, ਜੇ ਕੋਈ ਸਰਗਰਮ ਐਮਆਈਟੀਐਮ ਹਮਲਾ ਹੈ ਜਾਂ ਜੇ ਤੁਹਾਡੀ ਡਿਵਾਈਸ ਜਾਂ ਪ੍ਰਾਪਤਕਰਤਾ ਦੇ ਉਪਕਰਣ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਇਹ ਅਜੇ ਵੀ ਸੰਭਵ ਹੈ ਕਿ ਕੋਈ ਹੋਰ ਧਿਰ ਪਾਸਵਰਡ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੀ ਹੈ.
3. ਪ੍ਰਾਪਤਕਰਤਾ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਉਹਨਾਂ ਨੇ ਸਫਲਤਾਪੂਰਵਕ ਪਾਸਵਰਡ ਪ੍ਰਾਪਤ ਕੀਤਾ ਹੈ. ਉਦਾਹਰਣ ਦੇ ਲਈ, ਜੇ ਪ੍ਰਾਪਤਕਰਤਾ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਜਦੋਂ ਉਹ ਪਾਸਵਰਡ ਪ੍ਰਾਪਤ ਕਰਨ ਗਏ ਸਨ, ਕਿ ਸੁਨੇਹਾ ਪਹਿਲਾਂ ਹੀ ਮਿਟਾਇਆ ਜਾ ਚੁੱਕਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਪ੍ਰਾਪਤਕਰਤਾ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਹੋਰ ਨੇ ਪਾਸਵਰਡ ਪ੍ਰਾਪਤ ਕੀਤਾ ਹੈ ਅਤੇ ਇਸ ਲਈ ਪਾਸਵਰਡ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਇਸਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ.
4. ਪ੍ਰਾਪਤਕਰਤਾ ਦੁਆਰਾ ਪਾਸਵਰਡ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਿਆਂ, ਤੁਸੀਂ ਹੁਣ ਐਨਕ੍ਰਿਪਸ਼ਨ ਲਈ ਉਹੀ ਪਾਸਵਰਡ ਵਰਤ ਕੇ ਇੱਕ ਸੁਨੇਹਾ ਭੇਜ ਸਕਦੇ ਹੋ - ਸਿਰਫ ਲਿੰਕ ਦੇ ਸੰਸਕਰਣ ਨੂੰ ਸਾਂਝਾ ਕਰੋ ਜਿਸ ਵਿੱਚ ਪਾਸਵਰਡ ਨਹੀਂ ਹੈ.

ਇਹ ਸੇਵਾ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਨੂੰ ਲਿੰਕ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦੀ?

ਇਹ ਸਹੀ ਹੈ - ਅਸੀਂ ਲਿੰਕ ਤਿਆਰ ਕਰਦੇ ਹਾਂ ਅਤੇ ਇਸ ਨੂੰ ਭੇਜਣ ਵਾਲੇ ਤੇ ਛੱਡ ਦਿੰਦੇ ਹਾਂ ਕਿ ਇਸ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਾਉਣਾ ਹੈ. ਇਸ ਸੇਵਾ ਦਾ ਉਦੇਸ਼ ਇੱਕ ਵਿਕਲਪ ਪ੍ਰਦਾਨ ਕਰਨਾ ਹੈ ਜੋ ਮੌਜੂਦਾ ਸੰਦੇਸ਼ ਟ੍ਰਾਂਸਪੋਰਟ ਜਿਵੇਂ ਈਮੇਲ / ਚੈਟ / ਟੈਕਸਟ / ਆਦਿ ਵਿੱਚ ਘੱਟ ਸਥਾਈਤਾ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ. ਇਸ ਲਈ, ਉਮੀਦ ਇਹ ਹੈ ਕਿ ਉਹ ਲਿੰਕ ਜੋ ਅਸੀਂ ਪੈਦਾ ਕਰਦੇ ਹਾਂ ਜੋ ਅਸਥਾਈ ਸੰਦੇਸ਼ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ ਮੌਜੂਦਾ ਸੰਦੇਸ਼ ਟ੍ਰਾਂਸਪੋਰਟ ਦੁਆਰਾ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ. ਇਸ ਨਾਲ ਸੁਰੱਖਿਆ ਪ੍ਰਭਾਵ ਹਨ ਜੋ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸਮਝਣੇ ਚਾਹੀਦੇ ਹਨ. ਆਓ ਇੱਕ ਐਸਐਮਐਸ ਟੈਕਸਟ ਸੁਨੇਹਾ ਇੱਕ ਉਦਾਹਰਣ ਦੇ ਤੌਰ ਤੇ ਲੈਂਦੇ ਹਾਂ ਕਿਉਂਕਿ ਇਹ ਸੰਚਾਰ ਦਾ ਇੱਕ ਬਹੁਤ ਅਸੁਰੱਖਿਅਤ methodੰਗ ਹੈ. ਜਦੋਂ ਤੁਸੀਂ ਇਸ ਸੇਵਾ ਨੂੰ ਟੈਕਸਟ ਸੁਨੇਹੇ ਰਾਹੀਂ ਅਸਥਾਈ ਸੁਨੇਹਾ ਲਿੰਕ ਭੇਜਣ ਲਈ ਵਰਤਦੇ ਹੋ, ਜੇ ਤੁਸੀਂ ਡਿਫਾਲਟ ਮੋਡ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ ਜਿਸ ਨਾਲ ਲਿੰਕ ਵਿਚ ਪਾਸਵਰਡ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਲਿੰਕ ਵਾਲਾ ਕੋਈ ਵੀ ਸੁਨੇਹਾ ਪੜ੍ਹ ਸਕਦਾ ਹੈ ਅਤੇ ਰੁਕਾਵਟ ਦੇ ਵਿਰੁੱਧ ਕੋਈ ਸੁਰੱਖਿਆ ਦੀ ਪੇਸ਼ਕਸ਼ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ. ਇਹ ਸੇਵਾ ਅਜੇ ਵੀ ਇੱਕ ਹੋਰ ਅਸਥਾਈ ਸੰਚਾਰ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ ਜੋ ਗੋਪਨੀਯਤਾ ਅਤੇ ਸੁਰੱਖਿਆ ਨੂੰ ਵਧਾ ਸਕਦੀ ਹੈ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਤੁਸੀਂ ਲਿੰਕ ਨੂੰ ਬਿਨਾਂ ਪਾਸਵਰਡ ਤੋਂ ਭੇਜਣ ਦੀ ਚੋਣ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇਹ ਇੰਟਰਸੇਟ ਦੇ ਵਿਰੁੱਧ ਸੁਰੱਖਿਆ ਪ੍ਰਦਾਨ ਕਰੇਗਾ.

ਇਸ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰਦਿਆਂ ਮੈਂ ਆਪਣੀ ਗੋਪਨੀਯਤਾ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਸੁਰੱਖਿਅਤ ਕਿਵੇਂ ਕਰ ਸਕਦਾ ਹਾਂ?

ਜਿਵੇਂ ਕਿ ਇਸ FAQ ਵਿੱਚ ਕਿਤੇ ਹੋਰ ਵਿਚਾਰਿਆ ਗਿਆ ਹੈ, ਹਾਲਾਂਕਿ ਅਸੀਂ ਤੁਹਾਡੀ ਗੋਪਨੀਯਤਾ ਦੀ ਰੱਖਿਆ ਲਈ ਪਹਿਲਾਂ ਹੀ ਬਹੁਤ ਕੁਝ ਕਰ ਚੁੱਕੇ ਹਾਂ ਅਤੇ ਭਾਵੇਂ ਅਸੀਂ ਕੋਈ ਨਿਜੀ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਨਹੀਂ ਕਰਦੇ ਹਾਂ, ਕੁਝ ਲੌਗ ਨਾਲ ਸਬੰਧਤ ਜਾਣਕਾਰੀ ਸਾਡੇ ਅਤੇ ਹੋਰਾਂ ਦੁਆਰਾ ਤੁਹਾਡੇ ਦੁਆਰਾ ਇੱਕ ਵੈੱਬ ਬਰਾ browserਜ਼ਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਜਮ੍ਹਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ. ਹਾਲਾਂਕਿ, ਤੁਹਾਡੀ ਗੁਪਤਤਾ ਨੂੰ ਹੋਰ ਵੀ ਸੁਰੱਖਿਅਤ ਕਰਨ ਦੇ ਕਈ ਤਰੀਕੇ ਹਨ. ਇੱਕ wayੰਗ ਜਿਹੜਾ ਖੁੱਲਾ ਸਰੋਤ ਸਾੱਫਟਵੇਅਰ ਦੇ ਅਧਾਰ ਤੇ ਵਰਤਣ ਲਈ ਮੁਫਤ ਹੈ, ਅਤੇ ਟੌਰ ਬਰਾ Browਜ਼ਰ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ. ਇਹ ਬ੍ਰਾ browserਜ਼ਰ ਤੁਹਾਡੇ ਗੁਪਤਤਾ ਨੂੰ ਕਈ ਪੱਧਰਾਂ ਤੇ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ - ਟੋਰ ਨੈਟਵਰਕ ਦੀ ਵਰਤੋਂ ਸਮੇਤ. ਟੌਰ ਪਿਆਜ਼ ਨੈਟਵਰਕ ਰਾਹੀਂ ਸਾਡੀ ਸਾਈਟ ਪਹਿਲਾਂ ਹੀ ਪਹੁੰਚਯੋਗ ਹੈ ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਟੌਰ ਦੁਆਰਾ ਸਾਡੀ ਸਾਈਟ ਨੂੰ ਐਕਸੈਸਿਟ ਨੋਡ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ, ਜੋ ਕਿਸੇ ਨੂੰ ਐਗਜ਼ਿਟ ਨੋਡ ਟ੍ਰੈਫਿਕ 'ਤੇ ਲੁਕਣ ਤੋਂ ਰੋਕਦਾ ਹੈ. ਹਾਲਾਂਕਿ, ਇਹ ਯਾਦ ਰੱਖੋ ਕਿ ਇਸ ਦ੍ਰਿਸ਼ ਵਿਚ ਵੀ, ਤੁਹਾਡੀ ਆਈਐਸਪੀ ਦੇਖ ਸਕਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਟੌਰ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ - ਹਾਲਾਂਕਿ ਇਸਦੇ ਲਈ ਨਹੀਂ. ਤੁਸੀਂ ਕਿਸੇ ਵੀਪੀਐਨ ਨਾਲ ਵੀ ਜੁੜ ਸਕਦੇ ਹੋ ਅਤੇ ਫਿਰ ਗੁਪਤਨਾਮਿਆਂ ਦੀਆਂ ਦੋ ਪਰਤਾਂ ਲਈ ਟੋਰ ਬ੍ਰਾserਜ਼ਰ ਨੂੰ ਲਾਂਚ ਕਰ ਸਕਦੇ ਹੋ; ਹਾਲਾਂਕਿ, ਇਹ ਯਾਦ ਰੱਖੋ ਕਿ ਤੁਹਾਡੀ ਆਈਐਸਪੀ ਅਜੇ ਵੀ ਦੇਖ ਸਕਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸ ਸੀਨ ਵਿੱਚ ਇੱਕ ਵੀਪੀਐਨ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ - ਹਾਲਾਂਕਿ ਇਹ ਨਹੀਂ. ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਚਾਹੁੰਦੇ ਕਿ ਤੁਹਾਡਾ ਆਈਐਸਪੀ ਇਹ ਜਾਣੇ ਕਿ ਤੁਸੀਂ ਕਿਹੜੇ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਵੱਡੇ ਜਨਤਕ ਵਾਈਫਾਈ ਨੈਟਵਰਕ ਜਿਵੇਂ ਕਿ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ, ਸਕੂਲ ਆਦਿ ਨਾਲ ਜੁੜ ਸਕਦੇ ਹੋ ਅਤੇ ਫਿਰ ਟੌਰ ਬ੍ਰਾ browserਜ਼ਰ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ.

ਜੇ ਮੈਂ ਸੰਯੁਕਤ ਰਾਜ ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦਾ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?

ਸਾਡੇ ਸਰਵਰ ਯੂਨਾਈਟਡ ਸਟੇਟਸ ਵਿੱਚ ਸਥਿਤ ਹਨ. ਇਸਦੇ ਇਲਾਵਾ, ਸਾਡਾ ਸੀਡੀਐਨ ਪ੍ਰਦਾਤਾ, ਕਲਾਉਡਫਲੇਅਰ, ਸੰਯੁਕਤ ਰਾਜ ਵਿੱਚ ਅਧਾਰਤ ਇੱਕ ਕੰਪਨੀ ਹੈ. ਅਸੀਂ ਆਪਣੇ 'ਤੇ ਜਾਂ ਉਸ ਦੇਸ਼' ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨੂੰ ਦੂਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਹੈ ਜਿਸ ਵਿਚ ਸਾਡੇ ਸਰਵਰ ਸਿਰਫ਼ ਇਸ ਲਈ ਰਹਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਅਸੀਂ ਨਿੱਜੀ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਨਹੀਂ ਕਰਦੇ, ਕੋਈ ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਡਿਕ੍ਰਿਪਟ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਅਤੇ ਹਰ ਚੀਜ਼ ਦੇ ਪ੍ਰਾਪਤ ਹੋਣ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਮਿਟਾ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ. ਹਾਲਾਂਕਿ, ਅਸੀਂ ਕੁਝ ਵਿਸ਼ਵਾਸ ਨੂੰ ਸਮਝ ਸਕਦੇ ਹਾਂ ਕਿਉਂਕਿ ਇਹ ਵੈਬ-ਬੇਸਡ ਹੈ ਅਤੇ ਖ਼ਾਸਕਰ ਜੇ ਤੁਸੀਂ ਕੁਝ ਦੇਸ਼ਾਂ ਵਿੱਚ ਰਹਿੰਦੇ ਹੋ. ਸਾਡੇ ਕੋਲ ਉਨ੍ਹਾਂ ਲੋਕਾਂ ਲਈ ਆਈਸਲੈਂਡ ਅਤੇ ਸਵਿਟਜ਼ਰਲੈਂਡ ਵਿੱਚ ਵਿਕਲਪਾਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਨ ਦੀਆਂ ਕੁਝ ਯੋਜਨਾਵਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਮਰੀਕਾ ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ. ਕਿਰਪਾ ਕਰਕੇ ਸਾਨੂੰ ਦੱਸੋ ਕਿ ਜੇ ਇਹ ਤੁਹਾਡੇ ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਜਦੋਂ ਤੱਕ ਅਸਲ ਮੰਗ ਨਹੀਂ ਹੁੰਦੀ ਉਦੋਂ ਤੱਕ ਸਾਨੂੰ ਵਿਕਲਪ ਪੇਸ਼ ਕਰਨ ਲਈ ਪ੍ਰੇਰਿਆ ਨਹੀਂ ਜਾਵੇਗਾ.

ਤੁਸੀਂ ਸਪੈਮ ਨੂੰ ਰੋਕਣ ਲਈ ਕੀ ਕਰ ਰਹੇ ਹੋ?

ਜਦੋਂ ਵੀ ਤੁਸੀਂ ਕਿਸੇ ਨੂੰ ਸੁਨੇਹਾ ਭੇਜਣ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹੋ ਜੋ ਕਿਸੇ ਲਿੰਕ ਦੁਆਰਾ ਰਿਲੇਅ ਹੋ ਸਕਦਾ ਹੈ, ਤੁਸੀਂ ਸਪੈਮਰਰਾਂ ਨੂੰ ਸੱਦਾ ਦਿੰਦੇ ਹੋ. ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਦੂਰ ਕਰਨਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਿੱਧਾ ਨਹੀਂ ਹੈ. ਅਸੀਂ ਕੁਝ ਕਾਰਨਾਂ ਕਰਕੇ ਸੰਦੇਸ਼ ਭੇਜਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਇੱਕ ਤੀਜੀ ਧਿਰ ਕੈਪਟਾ ਨੂੰ ਲੋਡ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ:

• ਸਾਨੂੰ ਕੈਪਟਿਆਂ ਤੋਂ ਨਫ਼ਰਤ ਹੈ - ਉਹ ਸਮਾਂ ਲੈਂਦੇ ਹਨ ਅਤੇ ਤੰਗ ਕਰਨ ਵਾਲੇ ਹੁੰਦੇ ਹਨ
• ਤੀਜੀ ਧਿਰ ਦਾ ਜਾਵਾ ਸਕ੍ਰਿਪਟ ਲੋਡ ਕਰਨਾ ਗੋਪਨੀਯਤਾ ਅਤੇ ਸੁਰੱਖਿਆ ਲਈ ਹਮਲਾਵਰ ਹੋ ਸਕਦਾ ਹੈ
• ਆਪਣੀ ਕੈਪਟਚਾ ਚਲਾਉਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਕਦੇ ਵੀ ਚੱਕਰਾਂ ਦੀ ਮਾਰ ਤੋਂ ਬਚਣ ਵਾਲੀ ਖੇਡ ਲਈ ਸਾਈਨ ਅਪ ਕਰ ਰਹੇ ਹਾਂ.
• ਆਖਰਕਾਰ ਲੋਕ API ਦੁਆਰਾ ਇਸ ਸੇਵਾ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹ ਸਕਦੇ ਹਨ

ਅਸੀਂ ਸੰਭਵ ਤੌਰ ਤੇ ਕੁਝ ਏਪੀਆਈ ਕੁੰਜੀ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਏਪੀਆਈ ਸਮੱਸਿਆ ਨੂੰ ਘਟਾ ਸਕਦੇ ਹਾਂ, ਪਰ ਫਿਰ ਸਾਨੂੰ ਉਪਭੋਗਤਾ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰਨੀ ਪਵੇਗੀ ਜੋ ਅਸੀਂ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ. ਨਾਲ ਹੀ, ਸਪੈਮਰ ਨੂੰ ਬਹੁਤ ਸਾਰੀਆਂ ਏਪੀਆਈ ਕੁੰਜੀਆਂ ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਰੋਕਣਾ ਕੀ ਹੈ? ਅਸੀਂ ਸੰਦੇਸ਼ਾਂ ਦੀ ਉਨ੍ਹਾਂ ਦੀ ਸਪੈਮਨੀ (ਜੋ ਕਿ ਬਹੁਤ ਹੀ ਮੁਸ਼ਕਲ ਹੈ) ਦਾ ਅਨੁਮਾਨ ਲਗਾਉਣ ਲਈ ਜਾਂਚ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਕਿਉਂਕਿ ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਏਨਕ੍ਰਿਪਟ ਕਰਨ ਤੋਂ ਇਲਾਵਾ, ਸਾਡੇ ਕੋਲ ਸੰਦੇਸ਼ ਦੀ ਸਮਗਰੀ 'ਤੇ ਇਕ ਹੱਥ-ਨੀਤੀ ਹੈ. ਇਹਨਾਂ ਜਰੂਰਤਾਂ ਨੂੰ ਵੇਖਦੇ ਹੋਏ, ਅਸੀਂ ਸਪੈਮ ਨੂੰ ਰੋਕਣ ਲਈ ਦੋ ਤਰੀਕਿਆਂ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਾਂ:

• ਲੋੜੀਂਦੇ PBKDF2 / SHA-256 ਆਵਰਤੀ ਦੀ ਸੰਖਿਆ ਵਿੱਚ ਵਾਧਾ
  ਸਾਰੇ ਸੁਨੇਹਿਆਂ ਨੂੰ ਸਿਰਫ ਥੋੜ੍ਹੀ ਜਿਹੀ ਵਾਰ ਮੁੜ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ - ਸਪੈਮਰ ਕਰਨ ਵਾਲਿਆਂ ਲਈ ਇਕ ਅਣਉਚਿਤ ਗੁਣ ਕਿਉਂਕਿ ਉਹ ਬਹੁਤ ਸਾਰੇ ਸੰਦੇਸ਼ ਭੇਜਣ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਨ. ਕਿਉਕਿ ਇੱਕ ਸਪੈਮਰ ਨੂੰ ਕਿਸੇ ਵੀ ਸਪੈਮ ਮੁਹਿੰਮ ਲਈ ਬਹੁਤ ਸਾਰੇ ਸੰਦੇਸ਼ ਪੈਦਾ ਕਰਨੇ ਪੈਣਗੇ - ਅਸੀਂ ਇਸ ਕਾਰਜ ਨੂੰ ਕੰਪਿ soਟੇਸ਼ਨਲ ਤੌਰ 'ਤੇ ਮਹਿੰਗਾ ਬਣਾਉਣ ਦੀ ਚੋਣ ਕੀਤੀ ਹੈ ਕਿਉਂਕਿ ਸਪੈਮ ਲਈ ਇਸ ਸੇਵਾ ਦੀ ਦੁਰਵਰਤੋਂ ਕਰਨਾ ਇੱਕ ਮਨਘੜਤ ਕੋਸ਼ਿਸ਼ ਹੈ. ਇਹ ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਪੋਸਟ ਕਰਨ ਵਾਲੇ ਨੈਟਵਰਕਾਂ ਦੀ ਨਜ਼ਰ ਰੱਖਣ ਦੁਆਰਾ ਪੂਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ - ਕੁੱਲ ਸੰਭਾਵਤ ਪ੍ਰਾਪਤੀਆਂ ਦੇ ਹਿਸਾਬ ਨਾਲ ਮਾਪਿਆ ਜਾਂਦਾ ਹੈ. ਨੈਟਵਰਕ ਦੀ ਜਾਣਕਾਰੀ ਆਪਣੇ ਆਪ ਹੀ ਸੁਰੱਖਿਅਤ ਤੌਰ ਤੇ ਹੈਸ਼ ਕੀਤੀ ਗਈ ਹੈ ਤਾਂ ਕਿ ਅਸੀਂ ਹੈਸ਼ ਤੋਂ ਅਸਲ ਨੈਟਵਰਕ ਦਾ ਪਤਾ ਨਹੀਂ ਲਗਾ ਸਕਦੇ. ਜਿਵੇਂ ਕਿ ਦਿੱਤੇ ਗਏ ਨੈਟਵਰਕ ਵਿੱਚ ਵਧੇਰੇ ਸੁਨੇਹੇ ਪੋਸਟ ਹੁੰਦੇ ਹਨ, ਅਸੀਂ ਅਗਲੇ ਸੰਦੇਸ਼ ਨੂੰ ਪੋਸਟ ਕਰਨ ਲਈ ਲੋੜੀਂਦੇ ਪੀਬੀਕੇਡੀਐਫ 2 / ਐਸਐਚਏ-256 ਆਕਰਸ਼ਣ ਦੀ ਗਿਣਤੀ ਵਧਾਉਂਦੇ ਹਾਂ. ਇਹ ਬਹੁਤ ਹੀ ਤੇਜ਼ੀ ਨਾਲ ਨਤੀਜਾ ਹੈ ਕਿ ਸਿਰਫ ਇੱਕ ਸੁਨੇਹਾ ਭੇਜਣ ਲਈ ਬਹੁਤ ਸਾਰੇ ਸੀਪੀਯੂ ਸਮੇਂ ਦੀ ਜਰੂਰਤ ਹੁੰਦੀ ਹੈ. ਉਮੀਦ ਹੈ ਕਿ ਇਹ spamੰਗ ਸਪੈਮ ਦੀ ਦੁਰਵਰਤੋਂ ਨੂੰ ਰੋਕਣ ਲਈ ਕਾਫ਼ੀ ਹੋਵੇਗਾ ਅਤੇ ਉਸੇ ਸਮੇਂ, ਅਸਲ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਪ੍ਰਭਾਵਤ ਨਹੀਂ ਕਰੇਗਾ.
• ਜਦੋਂ ਉਹ ਸੁਨੇਹਾ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ ਤਾਂ ਉਪਭੋਗਤਾਵਾਂ ਤੋਂ ਸਪੈਮ ਰਿਪੋਰਟਾਂ ਇਕੱਤਰ ਕਰੋ
  ਸੁਨੇਹੇ ਦੇ ਬਿਲਕੁਲ ਹੇਠਾਂ "ਰਿਪੋਰਟ ਸਪੈਮ" ਬਟਨ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਉਪਭੋਗਤਾ ਸੁਨੇਹਾ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ. ਜੇ ਕੋਈ ਸੁਨੇਹਾ ਸਪੈਮ ਹੈ, ਉਮੀਦ ਹੈ ਕਿ ਕੁਝ ਉਸ ਬਟਨ ਨੂੰ ਦਬਾਉਣ ਲਈ 3 ਸਕਿੰਟ ਦੀ ਜ਼ਰੂਰਤ ਲੈਣਗੇ. ਜਦੋਂ ਸਾਨੂੰ ਇੱਕ ਸਪੈਮ ਰਿਪੋਰਟ ਪ੍ਰਾਪਤ ਹੁੰਦੀ ਹੈ, ਇਹ ਸਾਨੂੰ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ ਅਤੇ ਇਹ ਇੱਕ ਦਿੱਤੇ ਨੈਟਵਰਕ ਲਈ ਲੋੜੀਂਦੀ PBKDF2 / SHA-256 ਦੁਹਰਾਈ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਨ ਦਾ ਕਾਰਨ ਵੀ ਦਿੰਦਾ ਹੈ.

ਜੇ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਸਪੈਮਰ ਇਸ ਸੇਵਾ ਦੀ ਦੁਰਵਰਤੋਂ ਕਰ ਰਹੇ ਹਨ, ਤਾਂ ਕਿਰਪਾ ਕਰਕੇ ਦੁਰਵਿਵਹਾਰ ਰਿਪੋਰਟ ਦਰਜ ਕਰੋ .

ਇੱਥੇ ਇੱਕ ਵਿਕਲਪ ਕਿਉਂ ਹੈ ਕਿ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਨੂੰ ਕੈਪਟਚਾ ਪੂਰਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ?

ਹਾਲਾਂਕਿ ਇਹ ਸੱਚ ਹੈ ਕਿ ਅਸੀਂ ਕੈਪਟਾ ਨੂੰ ਨਾਪਸੰਦ ਕਰਦੇ ਹਾਂ, ਪਰ ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਉਹ ਇੱਕ ਉਦੇਸ਼ ਦੀ ਸੇਵਾ ਕਰਦੇ ਹਨ ਅਤੇ ਇੱਕ ਸਮਾਂ ਅਤੇ ਜਗ੍ਹਾ ਹੈ (ਘੱਟੋ ਘੱਟ ਹੁਣ ਲਈ). ਭੇਜਣ ਵਾਲੇ ਲਈ ਇਹ ਭਰੋਸਾ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਇਹ ਇਕ ਸੌਖਾ ਤਰੀਕਾ ਹੈ ਕਿ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ ਮਨੁੱਖ ਹੈ ਅਤੇ ਸਵੈਚਾਲਤ ਪ੍ਰਕਿਰਿਆਵਾਂ ਸੁਨੇਹੇ ਤਕ ਨਹੀਂ ਪਹੁੰਚ ਰਹੀਆਂ.

ਇਹ ਸੇਵਾ ਕੌਣ ਚਲਾ ਰਿਹਾ ਹੈ ਅਤੇ ਇਹ ਮੁਫਤ ਕਿਉਂ ਹੈ?

ਅਸੀਂ ਸਿਰਫ ਕੁਝ ਕੁ ਮੁੰਡੇ ਹਾਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਾਡੀ ਗੋਪਨੀਯਤਾ ਦੀ ਰੱਖਿਆ ਲਈ ਸਹਾਇਤਾ ਕਰਨ ਲਈ ਚੰਗੇ ਵਿਕਲਪ ਨਾ ਹੋਣ ਦੀ ਬਿਮਾਰੀ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਸੀ. ਅਕਸਰ ਇਸਦਾ ਨਤੀਜਾ ਉਨ੍ਹਾਂ ਦੋਸਤਾਂ ਅਤੇ ਪਰਿਵਾਰਕ ਮੈਂਬਰਾਂ ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਹੁੰਦਾ ਹੈ ਜੋ ਉਨ੍ਹਾਂ ਨਾਲ ਆਪਣੇ ਸਾਵਧਾਨੀਆਂ ਅਤੇ ਜਾਣਕਾਰੀ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦੇ ਹਨ ਇਸ ਬਾਰੇ ਬਹੁਤ ਧਿਆਨ ਨਹੀਂ ਰੱਖਦੇ. ਦੂਜੀ ਵਾਰ ਇਹ ਉਦੋਂ ਆਇਆ ਜਦੋਂ ਰੈਡਡੀਟ ਵਰਗੇ ਵੈੱਬ-ਅਧਾਰਤ ਫੋਰਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਜਾਂ ਵੈਬ-ਅਧਾਰਤ ਸਹਾਇਤਾ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ. ਅਸੀਂ ਕੁਝ ਵੈਬ-ਬੇਸਡ ਅਸਥਾਈ ਸੰਦੇਸ਼ ਹੱਲ ਲੱਭੇ, ਪਰ ਕਿਸੇ ਨੇ ਵੀ E2EE ਦੀ ਪੇਸ਼ਕਸ਼ ਨਹੀਂ ਕੀਤੀ ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਉਨ੍ਹਾਂ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕਦੇ. ਇਸ ਲਈ ਅਸੀਂ ਹੁਣੇ ਆਪਣਾ ਹੱਲ ਤਿਆਰ ਕੀਤਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਦੇਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ ਤਾਂ ਜੋ ਦੂਸਰੇ ਇਸ ਤੋਂ ਲਾਭ ਉਠਾ ਸਕਣ.

ਮੈਂ ਉਪਰੋਕਤ ਪ੍ਰਸ਼ਨਾਂ ਦੇ ਉੱਤਰਾਂ ਤੇ ਕਿਵੇਂ ਭਰੋਸਾ ਕਰ ਸਕਦਾ ਹਾਂ?

ਸਚਮੁੱਚ ਤੁਹਾਨੂੰ ਕਿਸੇ ਵੀ ਵੈਬਸਾਈਟ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਕਿਉਂਕਿ ਇਹ ਕੁਝ ਚੀਜ਼ਾਂ ਕਹਿੰਦਾ ਹੈ - ਕਿਸੇ ਵੀ ਦਾਅਵਿਆਂ ਦੀ ਤਸਦੀਕ ਕਰਨਾ ਇਹ ਆਮ ਤੌਰ' ਤੇ ਵਧੀਆ ਵਿਚਾਰ ਹੈ. ਅਸੀਂ ਐਂਡ-ਟੂ-ਐਂਡ ਇਨਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਨਿਯਮਤ ਕਰਨ ਦੁਆਰਾ ਸਾਡੇ ਤੇ ਵੱਧ ਤੋਂ ਵੱਧ ਭਰੋਸਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨੂੰ ਦੂਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਹੈ. ਉਦਾਹਰਣ ਦੇ ਲਈ, ਆਡਿਟ ਕਰਨਾ ਇਹ ਬਹੁਤ ਅਸਾਨ ਹੈ ਕਿ ਅਸੀਂ ਕੋਈ ਵੀ ਸੁਨੇਹੇ ਨਹੀਂ ਪੜ੍ਹ ਸਕਦੇ ਕਿਉਂਕਿ ਉਹ ਏਨਕ੍ਰਿਪਟਡ ਹਨ . ਅਸੀਂ ਜਾਵਾ ਸਕ੍ਰਿਪਟ ਕੋਡ ਨੂੰ ਵੀ ਇਸ ਸਾਈਟ ਤੇ ਚਲਾ ਰਹੇ ਹਾਂ ਤਾਂ ਜੋ ਇਸਨੂੰ ਪੜ੍ਹਨਾ ਅਤੇ ਸਮਝਣਾ ਆਸਾਨ ਹੋ ਜਾਵੇ. ਸਾਰੇ ਕੋਡ ਨੂੰ ਖੁੱਲਾ ਸਰੋਤ ਬਣਾਉਣਾ ਲੋਕਾਂ ਨੂੰ ਇਹ ਤਸਦੀਕ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਕਿ ਕੀ ਚੱਲ ਰਿਹਾ ਹੈ; ਹਾਲਾਂਕਿ, ਯਾਦ ਰੱਖੋ ਕਿ ਸਰਵਰ ਜੋ ਚੱਲ ਰਿਹਾ ਹੈ ਉਸਨੂੰ ਸੱਚਮੁੱਚ ਤਸਦੀਕ ਕਰਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ. ਹਾਲਾਂਕਿ ਇਹ ਸੱਚ ਹੈ ਕਿ ਜ਼ਿਆਦਾ ਭਰੋਸੇ ਦੀ ਜ਼ਰੂਰਤ ਅੰਤ-ਤੋਂ-ਅੰਤ ਐਨਕ੍ਰਿਪਸ਼ਨ ਨਾਲ ਹਟਾ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਇਹ ਅਜੇ ਵੀ ਇਕ ਅਜਿਹਾ ਕਾਰਕ ਹੈ ਜੋ ਸਾਡੇ ਉਪਭੋਗਤਾ ਇਸ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰਨ ਜਾਂ ਨਾ ਵਰਤਣ ਦਾ ਫ਼ੈਸਲਾ ਕਰਨ ਵੇਲੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਤੋਲ ਕਰਦੇ ਹਨ.