Google ਵਿਗਿਆਪਨ ਬਲੌਕਰਾਂ ਦੁਆਰਾ ਵਰਤੀ ਗਈ webRequest API ਦੀ ਪਾਬੰਦੀ ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾਉਂਦਾ ਹੈ

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

ਗੂਗਲ ਦੇ ਮਨੋਰਥ:

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

• ਐਡ-ਆਨ ਹੇਠਲੇ ਪੱਧਰ 'ਤੇ ਸਾਰੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ, ਜੋ ਦੁਰਵਿਵਹਾਰ ਅਤੇ ਗੋਪਨੀਯਤਾ ਦੀ ਉਲੰਘਣਾ ਲਈ ਵਿਸ਼ਾਲ ਮੌਕੇ ਖੋਲ੍ਹਦਾ ਹੈ। ਗੂਗਲ ਦੇ ਅੰਕੜਿਆਂ ਦੇ ਅਨੁਸਾਰ, ਸਾਰੇ ਖੋਜੇ ਗਏ ਖਤਰਨਾਕ ਐਡ-ਆਨਾਂ ਵਿੱਚੋਂ 42% ਨੇ webRequest API ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਇਹ ਨੋਟ ਕੀਤਾ ਗਿਆ ਹੈ ਕਿ ਹਰ ਮਹੀਨੇ, ਕ੍ਰੋਮ ਵੈੱਬ ਸਟੋਰ ਕੈਟਾਲਾਗ ਵਿੱਚ ਔਸਤਨ 1800 ਖਤਰਨਾਕ ਐਡ-ਆਨ ਲਗਾਉਣ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਬਲੌਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਸਮੀਖਿਆ ਕਰਨ ਨਾਲ ਅਸੀਂ ਬਿਨਾਂ ਕਿਸੇ ਅਪਵਾਦ ਦੇ ਸਾਰੇ ਖਤਰਨਾਕ ਐਡ-ਆਨਾਂ ਨੂੰ ਫੜ ਸਕਦੇ ਹਾਂ, ਇਸਲਈ ਸੁਰੱਖਿਆ ਨੂੰ ਵਧਾਉਣ ਲਈ, ਏਪੀਆਈ ਪੱਧਰ 'ਤੇ ਐਡ-ਆਨਾਂ ਨੂੰ ਸੀਮਤ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਗਿਆ ਸੀ। ਮੁੱਖ ਵਿਚਾਰ ਸਾਰੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਨਹੀਂ, ਬਲਕਿ ਸਿਰਫ ਉਸ ਡੇਟਾ ਲਈ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਨਾ ਹੈ ਜੋ ਉਦੇਸ਼ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਜ਼ਰੂਰੀ ਹੈ। ਖਾਸ ਤੌਰ 'ਤੇ, ਸਮੱਗਰੀ ਨੂੰ ਬਲੌਕ ਕਰਨ ਲਈ, ਐਡ-ਆਨ ਨੂੰ ਸਾਰੇ ਗੁਪਤ ਉਪਭੋਗਤਾ ਡੇਟਾ ਤੱਕ ਪੂਰੀ ਪਹੁੰਚ ਦੇਣਾ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ;
• ਪ੍ਰਸਤਾਵਿਤ ਤਬਦੀਲੀ ਘੋਸ਼ਣਾਤਮਕ API declarativeNetRequest ਉੱਚ-ਪ੍ਰਦਰਸ਼ਨ ਵਾਲੀ ਸਮੱਗਰੀ ਫਿਲਟਰਿੰਗ ਦੇ ਸਾਰੇ ਕੰਮ ਦੀ ਦੇਖਭਾਲ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਲਟਰਿੰਗ ਨਿਯਮਾਂ ਨੂੰ ਲੋਡ ਕਰਨ ਲਈ ਸਿਰਫ਼ ਐਡ-ਆਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਐਡ-ਆਨ ਟ੍ਰੈਫਿਕ ਵਿੱਚ ਦਖ਼ਲ ਨਹੀਂ ਦੇ ਸਕਦਾ ਹੈ ਅਤੇ ਉਪਭੋਗਤਾ ਦਾ ਨਿੱਜੀ ਡੇਟਾ ਅਟੱਲ ਰਹਿੰਦਾ ਹੈ;
• ਗੂਗਲ ਨੇ declarativeNetRequest API ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਘਾਟ ਦੇ ਸੰਬੰਧ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਟਿੱਪਣੀਆਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਿਆ ਅਤੇ ਫਿਲਟਰਿੰਗ ਨਿਯਮਾਂ ਦੀ ਸੀਮਾ ਨੂੰ ਸ਼ੁਰੂਆਤੀ ਪ੍ਰਸਤਾਵਿਤ 30 ਹਜ਼ਾਰ ਪ੍ਰਤੀ ਐਕਸਟੈਂਸ਼ਨ ਤੋਂ ਵੱਧ ਤੋਂ ਵੱਧ 150 ਹਜ਼ਾਰ ਤੱਕ ਵਧਾ ਦਿੱਤਾ, ਅਤੇ ਗਤੀਸ਼ੀਲਤਾ ਦੀ ਸਮਰੱਥਾ ਨੂੰ ਵੀ ਜੋੜਿਆ। ਨਿਯਮ ਬਦਲੋ ਅਤੇ ਜੋੜੋ, HTTP ਸਿਰਲੇਖਾਂ ਨੂੰ ਹਟਾਓ ਅਤੇ ਬਦਲੋ (ਰੈਫਰਰ, ਕੂਕੀ, ਸੈੱਟ-ਕੂਕੀ) ਅਤੇ ਮਾਪਦੰਡਾਂ ਦੀ ਬੇਨਤੀ ਕਰੋ;
• ਉੱਦਮਾਂ ਲਈ, webRequest API ਦੇ ਸੰਚਾਲਨ ਦੇ ਬਲਾਕਿੰਗ ਮੋਡ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸੰਭਵ ਹੈ, ਕਿਉਂਕਿ ਐਡ-ਆਨ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਨੀਤੀ ਇੱਕ ਪ੍ਰਬੰਧਕ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜੋ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਸਮਝਦਾ ਹੈ ਅਤੇ ਜੋਖਮਾਂ ਤੋਂ ਜਾਣੂ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਨਿਸ਼ਚਿਤ API ਨੂੰ ਐਂਟਰਪ੍ਰਾਈਜ਼ਾਂ ਵਿੱਚ ਕਰਮਚਾਰੀਆਂ ਦੇ ਆਵਾਜਾਈ ਦੇ ਪ੍ਰਵਾਹ ਨੂੰ ਰਿਕਾਰਡ ਕਰਨ ਅਤੇ ਅੰਦਰੂਨੀ ਪ੍ਰਣਾਲੀਆਂ ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ;
• ਗੂਗਲ ਦਾ ਟੀਚਾ ਵਿਗਿਆਪਨ ਬਲੌਕਿੰਗ ਐਡ-ਆਨ ਨੂੰ ਕਮਜ਼ੋਰ ਕਰਨਾ ਜਾਂ ਦਬਾਉਣ ਦਾ ਨਹੀਂ ਹੈ, ਪਰ ਸੁਰੱਖਿਅਤ ਅਤੇ ਵਧੇਰੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਵਿਗਿਆਪਨ ਬਲੌਕਰ ਬਣਾਉਣ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਣਾ ਹੈ;
• ਨਵੀਂ ਘੋਸ਼ਣਾਤਮਕ ਨੈੱਟ ਰਿਕੁਐਸਟ ਦੇ ਨਾਲ webRequest API ਦੇ ਸੰਚਾਲਨ ਦੇ ਬਲਾਕਿੰਗ ਮੋਡ ਨੂੰ ਛੱਡਣ ਦੀ ਝਿਜਕ ਨੂੰ ਗੁਪਤ ਡੇਟਾ ਤੱਕ ਐਡ-ਆਨ ਦੀ ਪਹੁੰਚ ਨੂੰ ਸੀਮਤ ਕਰਨ ਦੀ ਇੱਛਾ ਦੁਆਰਾ ਸਮਝਾਇਆ ਗਿਆ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ webRequest API ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਛੱਡ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਜ਼ਿਆਦਾਤਰ ਐਡਆਨ ਵਧੇਰੇ ਸੁਰੱਖਿਅਤ ਘੋਸ਼ਣਾਤਮਕ ਨੈੱਟ ਰਿਕੁਐਸਟ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਨਗੇ, ਕਿਉਂਕਿ ਸੁਰੱਖਿਆ ਅਤੇ ਕਾਰਜਕੁਸ਼ਲਤਾ ਵਿਚਕਾਰ ਚੋਣ ਕਰਦੇ ਸਮੇਂ, ਜ਼ਿਆਦਾਤਰ ਵਿਕਾਸਕਾਰ ਆਮ ਤੌਰ 'ਤੇ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਚੋਣ ਕਰਨਗੇ।

ਇਤਰਾਜ਼ ਡਿਵੈਲਪਰ ਜੋੜ:

• ਐਡ-ਆਨ ਡਿਵੈਲਪਰਾਂ ਦੁਆਰਾ ਸੰਚਾਲਿਤ ਕੀਤਾ ਗਿਆ ਟੈਸਟ ਵਿਗਿਆਪਨ ਬਲੌਕ ਕਰਨ ਵਾਲੇ ਐਡ-ਆਨ ਦੇ ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਇੱਕ ਮਾਮੂਲੀ ਸਮੁੱਚਾ ਪ੍ਰਭਾਵ ਦਿਖਾਓ (ਟੈਸਟਿੰਗ ਦੌਰਾਨ, ਵੱਖ-ਵੱਖ ਐਡ-ਆਨਾਂ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦੀ ਤੁਲਨਾ ਕੀਤੀ ਗਈ ਸੀ, ਪਰ ਇੱਕ ਵਾਧੂ ਪ੍ਰਕਿਰਿਆ ਦੇ ਓਵਰਹੈੱਡ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖੇ ਬਿਨਾਂ, ਜੋ ਕਿ ਬਲਾਕਿੰਗ ਮੋਡ ਵਿੱਚ ਹੈਂਡਲਰਾਂ ਦੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦਾ ਤਾਲਮੇਲ ਕਰਦੀ ਹੈ। webRequest API);
• ਐਡ-ਆਨ ਵਿੱਚ ਸਰਗਰਮੀ ਨਾਲ ਵਰਤੇ ਜਾਣ ਵਾਲੇ API ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਕਰਨਾ ਵਿਹਾਰਕ ਨਹੀਂ ਹੈ। ਇਸਨੂੰ ਹਟਾਉਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਇੱਕ ਵੱਖਰੀ ਅਨੁਮਤੀ ਜੋੜ ਸਕਦੇ ਹੋ ਅਤੇ ਐਡ-ਆਨ ਵਿੱਚ ਇਸਦੀ ਵਰਤੋਂ ਦੀ ਢੁਕਵੀਂਤਾ ਨੂੰ ਸਖਤੀ ਨਾਲ ਨਿਯੰਤਰਿਤ ਕਰ ਸਕਦੇ ਹੋ, ਜੋ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰਸਿੱਧ ਐਡ-ਆਨ ਦੇ ਲੇਖਕਾਂ ਨੂੰ ਉਹਨਾਂ ਦੇ ਉਤਪਾਦਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਦੁਬਾਰਾ ਕੰਮ ਕਰਨ ਤੋਂ ਬਚਾਏਗਾ ਅਤੇ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਕੱਟਣ ਤੋਂ ਬਚੇਗਾ;
• ਓਵਰਹੈੱਡ ਲਾਗਤਾਂ ਨੂੰ ਘਟਾਉਣ ਲਈ, ਤੁਸੀਂ API ਨੂੰ ਮਿਟਾ ਨਹੀਂ ਸਕਦੇ ਹੋ, ਪਰ ਇਸਨੂੰ ਫਾਇਰਫਾਕਸ ਵਿੱਚ webRequest ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਸਮਾਨ, ਵਾਅਦਾ ਵਿਧੀ ਦੇ ਅਧਾਰ ਤੇ ਰੀਮੇਕ ਕਰ ਸਕਦੇ ਹੋ;
• ਪ੍ਰਸਤਾਵਿਤ ਵਿਕਲਪ, declarativeNetRequest, ਐਡ ਬਲਾਕਿੰਗ ਅਤੇ ਸੁਰੱਖਿਆ/ਗੋਪਨੀਯਤਾ ਲਈ ਐਡ-ਆਨ ਡਿਵੈਲਪਰਾਂ ਦੀਆਂ ਸਾਰੀਆਂ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ ਇਹ ਨੈਟਵਰਕ ਬੇਨਤੀਆਂ 'ਤੇ ਪੂਰਾ ਨਿਯੰਤਰਣ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ, ਕਸਟਮ ਫਿਲਟਰਿੰਗ ਐਲਗੋਰਿਦਮ ਦੀ ਵਰਤੋਂ ਦੀ ਆਗਿਆ ਨਹੀਂ ਦਿੰਦਾ, ਅਤੇ ਆਗਿਆ ਨਹੀਂ ਦਿੰਦਾ ਗੁੰਝਲਦਾਰ ਨਿਯਮਾਂ ਦੀ ਵਰਤੋਂ ਜੋ ਸ਼ਰਤਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ ਇਕ ਦੂਜੇ ਨੂੰ ਓਵਰਲੈਪ ਕਰਦੇ ਹਨ;
• declarativeNetRequest API ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਦੇ ਨਾਲ, uBlock Origin ਅਤੇ uMatrix ਐਡ-ਆਨਾਂ ਦੀ ਮੌਜੂਦਾ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਬਦਲਾਅ ਦੇ ਮੁੜ ਬਣਾਉਣਾ ਅਸੰਭਵ ਹੈ, ਅਤੇ Chrome ਲਈ NoScript ਪੋਰਟ ਦੇ ਹੋਰ ਵਿਕਾਸ ਨੂੰ ਵੀ ਅਰਥਹੀਣ ਬਣਾਉਂਦਾ ਹੈ;
• ਗੋਪਨੀਯਤਾ ਬਾਰੇ ਚਿੰਤਾਵਾਂ ਦੂਰ-ਦੁਰਾਡੇ ਦੀਆਂ ਹਨ, ਕਿਉਂਕਿ webRequest API ਦਾ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਲਈ, ਗੈਰ-ਬਲੌਕਿੰਗ ਮੋਡ ਥਾਂ 'ਤੇ ਬਚਿਆ ਹੋਇਆ ਹੈ ਅਤੇ ਅਜੇ ਵੀ ਸਾਰੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਲਈ ਖਤਰਨਾਕ ਐਡ-ਆਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਪਰ ਇਸ ਵਿੱਚ ਦਖਲ ਦੇਣ ਦੀ ਸਮਰੱਥਾ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਫਲਾਈ (ਸਮੱਗਰੀ ਬਦਲੋ, ਆਪਣੇ ਇਸ਼ਤਿਹਾਰ ਲਗਾਓ, ਮਾਈਨਰ ਚਲਾਓ ਅਤੇ ਇਨਪੁਟ ਫਾਰਮਾਂ ਦੀ ਸਮੱਗਰੀ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੋ, ਪੰਨਾ ਲੋਡ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ);
• ਬ੍ਰਾਊਜ਼ਰ ਡਿਵੈਲਪਰ ਬਹਾਦਰ, ਓਪੇਰਾ и ਵਿਵਾਲੀ, Chromium ਇੰਜਣ 'ਤੇ ਬਣਾਇਆ ਗਿਆ, ਆਪਣੇ ਉਤਪਾਦਾਂ ਵਿੱਚ webRequest ਬਲੌਕਿੰਗ ਮੋਡ ਲਈ ਸਮਰਥਨ ਛੱਡਣ ਦਾ ਇਰਾਦਾ ਰੱਖਦਾ ਹੈ।

ਸਰੋਤ: opennet.ru