ਕਿਹੜਾ macOS ਔਜ਼ਾਰ ਇੱਕ ਐਪ ਨੂੰ ਸਿਰਫ਼ VPN ਰਾਹੀਂ ਜਾਣ ਲਈ ਮਜਬੂਰ ਕਰ ਸਕਦਾ ਹੈ?
ਸਿਰਫ਼-VPN ਹੱਦ ਲਈ ਰਾਹ ਅਤੇ ਇਨਕਾਰ ਦੋਵੇਂ ਚਾਹੀਦੇ ਹਨ। ਪ੍ਰਤੀ-ਐਪ ਪਰੋਫਾਈਲ, ਪ੍ਰਾਕਸੀ, ਫਿਲਟਰ ਅਤੇ PF ਦੀ ਤੁਲਨਾ ਕਰੋ, ਫਿਰ ਉਹੀ ਇੱਕ ਐਪ ਪਰਖੋ ਜੋ ਤੁਹਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਲੋੜਾਂ ਦੇ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਇੱਕ ਲਾਈਨ — “ਇਹ ਐਪ VPN ਵਰਤ ਸਕਦੀ ਹੈ, ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ” — ਚੁੱਪਚਾਪ ਦੋ ਅਜਿਹੇ ਤੰਤਰ ਮੰਗਦੀ ਹੈ ਜੋ ਕੋਈ ਇੱਕ ਸਵਿੱਚ ਨਹੀਂ ਦਿੰਦਾ। ਟ੍ਰੈਫਿਕ ਨੂੰ ਮਨਜ਼ੂਰ ਸੁਰੰਗ ਰਾਹੀਂ ਜਾਣ ਦਾ ਰਾਹ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਜੋ ਟ੍ਰੈਫਿਕ ਸਿੱਧਾ ਬਾਹਰ ਜਾਵੇਗਾ ਉਸਨੂੰ ਇਨਕਾਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਅਜਿਹੇ ਔਜ਼ਾਰ ਆਮ ਹਨ ਜੋ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਚੰਗਾ ਕਰਦੇ ਹਨ ਅਤੇ ਦੂਜਾ ਬਿਲਕੁਲ ਨਹੀਂ, ਇਸ ਲਈ ਜੋ ਤੁਲਨਾ ਸਿਰਫ਼ ਪੁੱਛਦੀ ਹੈ ਕਿ ਕੀ ਕੋਈ ਚੀਜ਼ ਬਲਾਕ ਕਰ ਸਕਦੀ ਹੈ, ਉਹ ਆਤਮ-ਵਿਸ਼ਵਾਸ ਨਾਲ ਸਵਾਲ ਦੇ ਅੱਧੇ ਹਿੱਸੇ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਪਹਿਲਾਂ ਹੱਦ ਲਿਖੋ, ਫਿਰ ਉਹ ਭਾਗ ਚੁਣੋ ਜੋ ਉਸਦੇ ਦੋਵੇਂ ਅੱਧਿਆਂ ਨੂੰ ਢਕਦੇ ਹਨ।
ਇੱਕ ਵਾਕ ਵਿੱਚ ਲੁਕੀਆਂ ਦੋ ਲੋੜਾਂ
ਮਾਰਗਦਰਸ਼ਨ ਉਹ ਭਾਗ ਹੈ ਜੋ ਕਿਸੇ ਕਨੈਕਸ਼ਨ ਨੂੰ ਸੁਰੰਗ ਜਾਂ ਪ੍ਰਾਕਸੀ ਵਿੱਚ ਰੱਖਦਾ ਹੈ। ਇਨਕਾਰ ਉਹ ਭਾਗ ਹੈ ਜੋ ਉਸੇ ਕਨੈਕਸ਼ਨ ਨੂੰ ਕਿਸੇ ਹੋਰ ਰਾਹ ਰਾਹੀਂ ਬਾਹਰ ਜਾਣ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਵੱਖ-ਵੱਖ ਭਾਗ ਇਹਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ, ਉਹ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਕੋਈ ਉਤਪਾਦ ਇੱਕ ਵਿੱਚ ਸ਼ਾਨਦਾਰ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਦੂਜੇ ਬਾਰੇ ਕੁਝ ਨਾ ਕਹੇ:
| Approach | Steers traffic | Refuses direct egress | Knows the app identity |
|---|---|---|---|
| Per-app VPN profile | Yes, for the apps it names | Only if a filter or firewall also blocks | Yes, within its own rules |
| Application proxy setting | Partly, for requests that honour it | No | No |
| Content filter | No | Yes | Yes, if the filter is written that way |
| Local PF ruleset | No | Yes, by address and port | Not reliably |
ਸਾਰਣੀ ਨੂੰ ਦਰਜਾਬੰਦੀ ਨਹੀਂ, ਜਾਂਚ-ਸੂਚੀ ਵਜੋਂ ਪੜ੍ਹੋ। ਕੋਈ ਵੀ ਕਤਾਰ ਦੋਵੇਂ ਵਿਚਕਾਰਲੇ ਕਾਲਮ ਨਹੀਂ ਭਰਦੀ, ਅਤੇ ਜੋ ਕਤਾਰਾਂ ਉਹਨਾਂ ਨੂੰ ਢਕਦੀਆਂ ਹਨ ਉਹ ਦੋ ਸਹਿਯੋਗੀ ਭਾਗ ਹਨ: ਇੱਕ ਰਾਹ ਦਾ ਮਾਲਕ, ਦੂਜਾ ਇਨਕਾਰ ਦਾ। ਪਛਾਣ ਵਾਲਾ ਕਾਲਮ ਕਿਸੇ ਹੋਰ ਕਾਰਨ ਕਰਕੇ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਜੋ ਨਿਯਮ ਐਪ ਦਾ ਨਾਮ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਉਹ ਉਸ ਐਪ ਬਾਰੇ ਨਿਯਮ ਲਾਗੂ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਤੁਸੀਂ ਜੋ ਵੀ ਤੈਨਾਤ ਕਰੋ, ਉਸਨੂੰ ਤਿੰਨਾਂ ਦਾ ਜਵਾਬ ਦੇਣਾ ਪਵੇਗਾ, ਨਹੀਂ ਤਾਂ ਲੋੜਾਂ ਦੇ ਦਸਤਾਵੇਜ਼ ਦੀ ਹੱਦ ਮਸ਼ੀਨ ਉੱਤੇ ਦੀ ਹੱਦ ਨਹੀਂ ਹੈ।
ਸਿਰਫ਼ ਮਾਰਗਦਰਸ਼ਨ ਬਾਹਰ ਨਿਕਲਣ ਦਾ ਰਾਹ ਛੱਡਦਾ ਹੈ
ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਾਕਸੀ ਸੈਟਿੰਗ ਇਨਕਾਰ ਤੋਂ ਬਿਨਾਂ ਮਾਰਗਦਰਸ਼ਨ ਦੀ ਸਭ ਤੋਂ ਸਪਸ਼ਟ ਮਿਸਾਲ ਹੈ। ਇਹ ਸਿਸਟਮ ਪ੍ਰਾਕਸੀ ਦਾ ਆਦਰ ਕਰਨ ਵਾਲੀ ਐਪ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦਾ ਮਾਰਗਦਰਸ਼ਨ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ ਢਕਦੀ: ਸਹਾਇਕ ਪ੍ਰਕਿਰਿਆ, ਅੱਪਡੇਟਰ, ਬੈਕਗਰਾਊਂਡ ਸੇਵਾ ਜਾਂ ਵੱਖਰਾ ਪ੍ਰੋਟੋਕਾਲ ਉਸ ਸੈਟਿੰਗ ਨੂੰ ਕਦੇ ਪੜ੍ਹੇ ਬਿਨਾਂ ਆਪਣਾ ਰਾਹ ਲੈ ਸਕਦੇ ਹਨ। ਇਸ ਲਈ ਇੱਕ ਪੈਨਲ ਵਿੱਚ SOCKS ਅੰਤ ਬਿੰਦੂ ਚੁਣਨਾ ਐਪ ਲਈ ਸਿੱਧੇ ਨਿਕਾਸ ਦੀ ਮਨਾਹੀ ਦੀ ਨੀਤੀ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਜੇ ਲੋੜ ਪੂਰੀ ਐਪ ਬਾਰੇ ਹੈ, ਤਾਂ ਪੁੱਛੋ ਕਿ ਨਿਯਮ ਅਸਲ ਵਿੱਚ ਕਿਹੜੇ ਭਾਗਾਂ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ।
ਪ੍ਰਤੀ-ਐਪ VPN ਪਰੋਫਾਈਲ ਪ੍ਰਾਕਸੀ ਨਾਲੋਂ ਬਿਹਤਰ ਮਾਰਗਦਰਸ਼ਨ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਪਲੇਟਫਾਰਮ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਐਪਾਂ ਸੁਰੰਗ ਵਿੱਚ ਦਾਖਲ ਹੋਣਗੀਆਂ ਹਰ ਐਪ ਦੇ ਆਪਣੇ ਆਪ ਫੈਸਲਾ ਕਰਨ ਦੀ ਥਾਂ। ਫਿਰ ਵੀ ਇਹ ਕਿਸੇ ਚੀਜ਼ ਤੋਂ ਇਨਕਾਰ ਨਹੀਂ ਕਰਦਾ: ਪਰੋਫਾਈਲ ਰਾਹ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਜੋ ਟ੍ਰੈਫਿਕ ਇਸ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ ਉਹ ਆਮ ਰਾਹ ਲੈਂਦਾ ਹੈ। ਇਹੀ ਖੱਪਾ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਦੂਜਾ ਭਾਗ ਆਪਣੀ ਥਾਂ ਕਮਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਇੱਕ ਸਵਿੱਚ ਵਰਗੇ ਦਿਖਣ ਵਾਲੇ ਉਤਪਾਦ ਆਮ ਤੌਰ ’ਤੇ ਦੋ ਹੁੰਦੇ ਹਨ।
ਸਿਰਫ਼ ਇਨਕਾਰ ਐਪ ਨੂੰ ਤੋੜ ਦਿੰਦਾ ਹੈ
Apple ਦਾ ਦਸਤਾਵੇਜ਼ ਸਮੱਗਰੀ-ਫਿਲਟਰਾਂ ਬਾਰੇ ਨੈੱਟਵਰਕ ਸਟੈਕ ਵਿੱਚੋਂ ਲੰਘਦੇ ਟ੍ਰੈਫਿਕ ਉੱਤੇ ਇਜਾਜ਼ਤ-ਜਾਂ-ਬਲਾਕ ਫੈਸਲੇ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਉਹ ਫੈਸਲਾ ਸੁਰੰਗ ਨਹੀਂ ਹੈ ਅਤੇ ਨਾ ਹੀ ਪ੍ਰਾਕਸੀ ਕਨੈਕਸ਼ਨ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕੋਈ ਚੀਜ਼ ਅੱਗੇ ਵਧ ਸਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਨਹੀਂ ਕਿ ਕਿੱਥੇ ਜਾਂਦੀ ਹੈ। ਸਿਰਫ਼ ਫਿਲਟਰ ਇਨਕਾਰ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਲਾਗੂ ਕਰਦਾ ਹੈ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਬੇਕਾਰ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਸਾਫ਼ ਲੌਗਾਂ ਨਾਲ ਅਤੇ ਬਿਨਾਂ ਕਿਸੇ ਵਿਆਖਿਆ ਦੇ। ਫਿਲਟਰ ਦਾ ਫੈਸਲਾ ਕਨੈਕਸ਼ਨ ਰੋਕ ਸਕਦਾ ਹੈ ਪਰ ਸੁਰੰਗ ਕਦੇ ਨਹੀਂ ਦਿੰਦਾ, ਇਸ ਲਈ ਇਸਨੂੰ ਮਾਰਗਦਰਸ਼ਨ ਨਾਲ ਜੋੜਨਾ ਡਿਜ਼ਾਈਨ ਦਾ ਫੈਸਲਾ ਹੈ, ਵਿਕਲਪਿਕ ਵਾਧਾ ਨਹੀਂ।
ਸਥਾਨਕ ਤੌਰ ’ਤੇ ਪ੍ਰਬੰਧਿਤ PF ਨਿਯਮ-ਸਮੂਹ ਉਸ ਸਪੈਕਟ੍ਰਮ ਦੇ ਦੂਜੇ ਸਿਰੇ ’ਤੇ ਬੈਠਾ ਹੈ। ਇਹ ਪ੍ਰਸ਼ਾਸਕ ਦੀ ਮਲਕੀਅਤ ਵਾਲੀ ਮਸ਼ੀਨ ’ਤੇ ਜਾਇਜ਼ ਸਹਾਇਤਾ-ਫੈਸਲਾ ਹੈ, ਅਤੇ ਇਹ ਆਪਣੇ ਆਪ ਵੰਡਣਯੋਗ ਉਤਪਾਦ ਦਾ ਆਧਾਰ ਨਹੀਂ ਹੁੰਦਾ, ਕਿਉਂਕਿ ਜਿਸ ਕੋਲ ਨਿਯਮ-ਸਮੂਹ ਹੈ ਉਸ ਕੋਲ ਹੋਰ ਫਾਇਰਵਾਲ ਵਰਤੋਂਕਾਰਾਂ ਨਾਲ ਇਸਦੇ ਸੰਪਰਕ, ਇਸਦਾ ਅੱਪਗ੍ਰੇਡ ਰਾਹ ਅਤੇ ਨਿਯਮ ਗਲਤ ਹੋਣ ’ਤੇ ਇਸਦੀ ਰਿਕਵਰੀ ਵੀ ਹੈ। ਉਤਪਾਦ ਵਿੱਚ PF ਜੋੜਨਾ ਉਸ ਮਲਕੀਅਤ ਵਾਲੇ ਸਵਾਲ ਨੂੰ ਹਟਾਉਂਦਾ ਨਹੀਂ; ਇਹ ਉਸਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ।
ਤੈਨਾਤੀ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਨਿਯਮ ਕੱਲ੍ਹ ਵੀ ਰਹੇਗਾ ਜਾਂ ਨਹੀਂ
Apple ਪਲੇਟਫਾਰਮਾਂ ’ਤੇ Network Extension ਕਿਵੇਂ ਤੈਨਾਤ ਹੁੰਦਾ ਹੈ ਇਹ ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਦੇ ਪ੍ਰਦਾਤਾ-ਕਿਸਮ, ਪੈਕੇਜਿੰਗ ਅਤੇ OS ਸੰਸਕਰਣ ’ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। macOS ’ਤੇ ਐਪ ਐਕਸਟੈਂਸ਼ਨ ਵਰਤੋਂਕਾਰ ਸੰਦਰਭ ਵਿੱਚ ਚੱਲਦਾ ਹੈ ਅਤੇ ਉਹ ਵਰਤੋਂਕਾਰ ਲੌਗ ਆਊਟ ਹੋਣ ’ਤੇ ਖਤਮ ਹੁੰਦਾ ਹੈ, ਜਦਕਿ ਸਿਸਟਮ ਐਕਸਟੈਂਸ਼ਨ ਦਾ ਸੰਦਰਭ ਸੈਸ਼ਨ ’ਤੇ ਨਿਰਭਰ ਨਾ ਕਰਨ ਵਾਲਾ ਗਲੋਬਲ ਹੁੰਦਾ ਹੈ। ਜੇ ਸੁਰੱਖਿਆ ਲੌਗ ਆਊਟ ਤੋਂ ਬਾਅਦ ਵੀ ਟਿਕਣੀ ਹੈ, ਤਾਂ ਉਹ ਫ਼ਰਕ ਪੈਰ-ਟਿੱਪਣੀ ਨਹੀਂ, ਪੂਰਾ ਡਿਜ਼ਾਈਨ ਹੈ। ਵਿਵਹਾਰ ਦਾ ਵਾਅਦਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੈਨਾਤੀ ਦਾ ਰਾਹ ਪੱਕਾ ਕਰੋ, ਕਿਉਂਕਿ ਉਹੀ ਕੋਡ ਕਿਹੜੀ ਐਕਸਟੈਂਸ਼ਨ ਕਿਸਮ ਭੇਜੀ ਜਾਂਦੀ ਹੈ ਉਸ ਅਨੁਸਾਰ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਉਤਰਦਾ ਹੈ।
ਸਰੋਤ ਦੀ ਉਪਲਬਧਤਾ ਲਾਗੂਕਰਨ ਤੋਂ ਵੱਖਰਾ ਮਾਮਲਾ ਹੈ। ਭੰਡਾਰ ਪੜ੍ਹਨ ਨਾਲ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਕੋਈ ਚੀਜ਼ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤੀ ਗਈ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਇੰਸਟਾਲ ਕੀਤੀ ਬਾਈਨਰੀ ਇਸ ਮਸ਼ੀਨ ’ਤੇ ਕੀ ਕਰ ਸਕਦੀ ਹੈ। ਦਸਤਖਤ, ਇੰਸਟਾਲੇਸ਼ਨ ਅਤੇ ਅਧਿਕਾਰ ਅਜੇ ਵੀ ਲਾਗੂ ਹਨ, ਅਤੇ ਪੁਰਾਣੇ ਕਰਨਲ ਐਕਸਟੈਂਸ਼ਨ ਜਾਂ ਲਾਇਬ੍ਰੇਰੀ-ਇੰਜੈਕਸ਼ਨ ਦੀ ਚਾਲ ਦੁਆਲੇ ਬਣੀਆਂ ਹਦਾਇਤਾਂ ਕਿਸੇ ਹੋਰ ਪਲੇਟਫਾਰਮ ਅਤੇ ਹੋਰ ਜੋਖਮ-ਰੁਖ ਦਾ ਵਰਣਨ ਕਰਦੀਆਂ ਹਨ, ਭਾਵੇਂ ਉਹ ਕਦੇ ਵੀ ਕਿੰਨੀਆਂ ਚੰਗੀਆਂ ਚੱਲੀਆਂ ਹੋਣ।
ਐਪ ਦਾ ਨਾਮ ਲੈਣ ਵਾਲਾ ਸਵੀਕ੍ਰਿਤੀ-ਮਾਮਲਾ
ਉਹ ਇੱਕ ਕਿਰਿਆ ਚੁਣੋ ਜੋ ਐਪ ਆਪਣੇ ਆਪ ਕਰਦੀ ਹੈ, ਉਹ ਪਤਾ ਨੋਟ ਕਰੋ ਜਿੱਥੇ ਇਸਨੂੰ ਪਹੁੰਚਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇਹ ਕਿ ਉਹ ਪਤਾ IPv4 ਹੈ ਜਾਂ IPv6, ਫਿਰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਸੁਰੰਗ-ਰਹਿਤ ਹਾਲਤ ਵਿੱਚ ਉਹੀ ਕਿਰਿਆ ਦੁਹਰਾਓ। ਦੂਜੀ ਵਾਰ ਘੋਸ਼ਿਤ ਇਨਕਾਰ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਚੁੱਪਚਾਪ ਸਿੱਧੀ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਨਹੀਂ। ਇਹੀ ਉਹ ਅੱਧਾ ਹਿੱਸਾ ਹੈ ਜੋ ਲੋਕ ਅਣ-ਨਿਰਦਿਸ਼ਟ ਛੱਡਦੇ ਹਨ, ਅਤੇ ਇਨਕਾਰ ਦੇ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਵਾਲਾ ਇੱਕੋ ਅੱਧਾ ਹਿੱਸਾ। ਇਸਨੂੰ ਪਹਿਲਾਂ ਸੁਰੰਗ ਉਪਲਬਧ ਹੋਣ ’ਤੇ ਚਲਾਓ, ਤਾਂ ਜੋ ਦੋਵਾਂ ਨਤੀਜਿਆਂ ਵਿਚਕਾਰ ਫ਼ਰਕ ਸਿਰਫ਼ ਗੈਰਹਾਜ਼ਰ ਸੁਰੰਗ ਤੋਂ ਆ ਸਕੇ।
ਫਿਰ ਲੋੜ ਵਿੱਚ ਦੱਸੇ ਗਏ ਤਬਦੀਲੀਆਂ ਵਿੱਚੋਂ ਲੰਘੋ: ਐਪ ਮੁੜ ਚਾਲੂ ਕਰਨਾ, ਸਹਾਇਕ ਪ੍ਰਕਿਰਿਆ ਦਾ ਸਰਗਰਮ ਹੋਣਾ, ਸੁਰੰਗ ਦਾ ਮੁੜ ਜੁੜਨਾ, ਮਸ਼ੀਨ ਦਾ ਨੈੱਟਵਰਕ ਬਦਲਣਾ, ਅਤੇ ਜਿੱਥੇ ਲਾਗੂ ਹੋਵੇ ਉੱਥੇ ਲੌਗ ਆਊਟ ਜਾਂ ਰੀਬੂਟ। ਬ੍ਰਾਊਜ਼ਰ ਦਾ ਜਨਤਕ-IP ਪੰਨਾ ਕਿਸੇ ਹੋਰ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਸਾਕਟ ਦੀ ਜਾਂਚ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਇਹ ਇਸਦੀ ਥਾਂ ਨਹੀਂ ਲੈ ਸਕਦਾ। ਜਿੱਥੇ ਕੋਈ ਸਮਰਥਿਤ ਤੈਨਾਤੀ ਐਪ ਦੇ ਅਸਲ ਵਿਵਹਾਰ ਨੂੰ ਨਹੀਂ ਢਕਦੀ, ਉੱਥੇ ਸਪਸ਼ਟ ਗੇਟਵੇ ਅਤੇ ਵਿਕਲਪਿਕ ਨਿਕਾਸ ਤੋਂ ਬਿਨਾਂ ਅਧਿਕ੍ਰਿਤ ਵੱਖਰਾ ਵਾਤਾਵਰਣ ਆਪਣੀ ਪ੍ਰਬੰਧਨ-ਲਾਗਤ ਵਾਲਾ ਸੰਜਮ-ਫੈਸਲਾ ਹੈ, ਚੈੱਕਬਾਕਸ ਦਾ ਬਦਲ ਨਹੀਂ।
ਚਾਰ ਐਂਟਰੀਆਂ ਲਿਖ ਕੇ ਮੁਕਾਓ: ਐਪ ਕਿਹੜੇ ਭਾਗਾਂ ਨਾਲ ਬਣੀ ਹੈ, ਮਾਰਗਦਰਸ਼ਨ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ, ਇਨਕਾਰ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ, ਅਤੇ ਉਹ ਹਾਲਤਾਂ ਜਿੱਥੇ ਨਿਯਮ ਅਜੇ ਵੀ ਲਾਗੂ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ। ਜਨਤਕ ਭੰਡਾਰ ਚੋਣ ਦਾ ਇੱਕ ਮਾਪਦੰਡ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਉਹਨਾਂ ਚਾਰ ਵਿੱਚੋਂ ਇੱਕ ਨਹੀਂ ਹੈ, ਅਤੇ ਉਹੀ ਐਂਟਰੀਆਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਦਿੱਤਾ ਗਿਆ ਔਜ਼ਾਰ ਨੈੱਟਵਰਕਿੰਗ ਲੋੜ ਪੂਰੀ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।