Safari MCP 'ਤੇ ਬਣਿਆ ਇੱਕ ਆਟੋਮੇਸ਼ਨ ਟੂਲ ਡਿਵੈਲਪਰ ਦੇ ਡੈਸ਼ਬੋਰਡ ਟੈਬ ਨੂੰ ਪੜ੍ਹਦੇ ਸਮੇਂ ਬੰਦ ਕਰ ਦਿੱਤਾ। ਇਸ ਘਟਨਾ ਨੇ ਉਸ ਗਾਰਡ (guard) ਵਿੱਚ ਇੱਕ ਲੁਕਵੀਂ ਖਾਮੀ ਨੂੰ ਉਜਾਗਰ ਕੀਤਾ ਜੋ AI-ਡਰਾਈਵਨ ਏਜੰਟਾਂ ਨੂੰ ਕਿਸੇ ਅਜਿਹੇ ਟੈਬ ਨੂੰ ਛੂਹਣ ਤੋਂ ਰੋਕਣ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ ਜੋ ਉਨ੍ਹਾਂ ਦਾ ਨਹੀਂ ਸੀ, ਅਤੇ ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਉਂ "safe-by-default" ਸ਼੍ਰੇਣੀਆਂ ਇੱਕ ਦੇਣ ਦੀ ਬਜਾਏ ਰੁਕਾਵਟ ਬਣ ਸਕਦੀਆਂ ਹਨ।

ਉਹ ਗਾਰਡ ਜੋ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ—ਜਦੋਂ ਤੱਕ ਕਿ ਉਹ ਰੁਕਿਆ ਨਹੀਂ

ਟੂਲ ਆਪਣੇ ਦੁਆਰਾ ਬਣਾਏ ਗਏ ਹਰ ਟੈਬ ਨੂੰ ਇੱਕ ਅੰਦਰੂਨੀ ਆਈਡੈਂਟੀਫਾਇਰ (identifier) ਨਾਲ ਟੈਗ ਕਰਦਾ ਹੈ। ਏਜੰਟ ਦੁਆਰਾ ਕੋਈ ਵੀ ਕਮਾਂਡ ਜਾਰੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਗਾਰਡ ਉਸ ਮਾਰਕਰ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ; ਜੇਕਰ ਮਾਰਕਰ ਗਾਇਬ ਹੈ, ਤਾਂ ਗਾਰਡ ਕਾਰਵਾਈ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦਿੰਦਾ ਹੈ। ਅਸਲ ਵਿੱਚ, ਗਾਰਡ ਨੇ ਏਜੰਟ ਨੂੰ ਅਜਿਹੇ ਪੇਜ ਨੂੰ ਪੜ੍ਹਨ ਤੋਂ ਰੋਕ ਦਿੱਤਾ ਜੋ ਉਸਨੇ ਨਹੀਂ ਖੋਲ੍ਹਿਆ ਸੀ—ਬਿਲਕੁਲ ਉਹੀ ਜੋ ਇਸਨੂੰ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ।

ਇੱਕ ਫਾਰਮ ਭਰਦੇ ਸਮੇਂ, ਪੇਜ ਕਿਸੇ ਦੂਜੇ ਡੋਮੇਨ 'ਤੇ ਰੀਡਾਇਰੈਕਟ (redirect) ਹੋ ਗਿਆ। ਰੀਡਾਇਰੈਕਟ ਨੇ ਮਾਰਕਰ ਨੂੰ ਹਟਾ ਦਿੱਤਾ, ਜਿਸ ਨਾਲ ਟੈਬ ਬਿਨਾਂ ਲੇਬਲ ਦੇ ਰਹਿ ਗਿਆ। ਗਾਰਡ ਨੇ ਗਾਇਬ ਮਾਰਕਰ ਨੂੰ ਦੇਖਿਆ ਅਤੇ ਰਿਪੋਰਟ ਕੀਤੀ, “ਮੈਂ ਮਾਲਕੀ ਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਇਸ ਲਈ ਮੈਂ ਇਸ ਟੈਬ ਨੂੰ ਨਹੀਂ ਪੜ੍ਹਾਂਗਾ।” ਉਸ ਸਮੇਂ ਸੇਫਟੀ ਚੈੱਕ (safety check) ਉਮੀਦ ਅਨੁਸਾਰ ਹੀ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ।

ਉਹ ਕਲੀਨਅੱਪ ਕੋਡ ਜਿਸਨੇ ਸੀਮਾ ਲੰਘ ਦਿੱਤੀ

ਇਸ ਤੋਂ ਬਾਅਦ ਇੱਕ ਮੈਨੂਅਲ ਕਲੀਨਅੱਪ ਰੁਟੀਨ (cleanup routine) ਆਈ ਜਿਸਦਾ ਮਕਸਦ ਅਨਾਥ (orphaned) ਟੈਬਾਂ—ਜਿਨ੍ਹਾਂ ਕੋਲ ਮਾਰਕਰ ਨਹੀਂ ਸੀ—ਨੂੰ ਬੰਦ ਕਰਨਾ ਸੀ। ਰੁਟੀਨ ਨੇ ਮਾਲਕੀ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੇ ਬਿਨਾਂ ਟੂਲ ਨੂੰ “close a tab” ਕਹਿਣ ਲਈ ਕਿਹਾ। ਕਿਉਂਕਿ ਗਾਰਡ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਿਆ ਕਿ ਟੈਬ ਉਸਦਾ ਆਪਣਾ ਸੀ, ਟੂਲ ਇੱਕ ਡਿਫੌਲਟ ਐਕਸ਼ਨ 'ਤੇ ਆ ਗਿਆ: “close the current tab.” ਮੌਜੂਦਾ ਟੈਬ ਉਹ ਡੈਸ਼ਬੋਰਡ ਸੀ ਜਿਸ ਨੂੰ ਡਿਵੈਲਪਰ ਪੜ੍ਹ ਰਿਹਾ ਸੀ, ਨਾ ਕਿ ਕੋਈ ਅਨਾਥ ਟੈਬ।

ਨਤੀਜਾ ਇੱਕ ਵਿਨਾਸ਼ਕਾਰੀ ਕਾਰਵਾਈ ਸੀ ਜੋ ਇੱਕ ਸੇਫਟੀ ਪਾਥ (safety path) ਦੁਆਰਾ ਸ਼ੁਰੂ ਕੀਤੀ ਗਈ ਸੀ ਜਿਸਨੂੰ ਇੱਕ ਡੈੱਡ ਐਂਡ (dead end) ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ।

ਤਿੰਨ ਪਰਤਾਂ ਜਿਨ੍ਹਾਂ ਨੇ “ਕੋਈ ਮਾਲਕੀ ਨਹੀਂ” ਨੂੰ ਇਜਾਜ਼ਤ ਵਜੋਂ ਲਿਆ

  1. ਕਮਾਂਡ ਸ਼੍ਰੇਣੀਕਰਨ (Command categorisation) – ਉਹ ਸੂਚੀ ਜਿਸਨੇ ਕਮਾਂਡਾਂ ਨੂੰ ਸਮੂਹਬੱਧ ਕੀਤਾ ਸੀ, ਉਸਨੇ close_tab ਨੂੰ ਇੱਕ ਵਿਸ਼ਾਲ “tab management” ਬੱਕੇ ਦੇ ਅਧੀਨ ਰੱਖਿਆ। ਡਿਵੈਲਪਰ ਨੇ ਮੰਨ ਲਿਆ ਕਿ ਉਸ ਬੱਕੇ ਵਿੱਚ ਸਭ ਕੁਝ ਨੁਕਸਾਨ ਰਹਿਤ ਸੀ ਕਿਉਂਕਿ ਹੋਰ ਕਮਾਂਡਾਂ (ਜਿਵੇਂ ਕਿ “list tabs”) ਸਿਰਫ਼ ਜਾਣਕਾਰੀ ਪੜ੍ਹਦੀਆਂ ਹਨ। ਕਿਸੇ ਵੀ ਸਪਸ਼ਟ ਨੋਟ ਨੇ close_tab ਨੂੰ ਵਿਨਾਸ਼ਕਾਰੀ ਵਜੋਂ ਫਲੈਗ ਨਹੀਂ ਕੀਤਾ, ਇਸ ਲਈ ਇਸਨੇ ਆਪਣੇ ਗੁਆਂਢੀਆਂ ਦੀ ਮਹਿਸੂਸ ਕੀਤੀ ਗਈ ਸੁਰੱਖਿਆ ਨੂੰ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈ ਲਿਆ।
  2. ਐਕਸਟੈਂਸ਼ਨ-ਪੱਧਰੀ ਨੀਤੀ (Extension-level policy) – Safari ਐਕਸਟੈਂਸ਼ਨ ਜਿਸਨੇ ਸਾਰੀਆਂ ਬ੍ਰਾਊਜ਼ਰ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਵਿਚੋਲਗੀ ਕੀਤੀ, ਉਸਨੇ ਕਿਸੇ ਵੀ ਕਾਰਵਾਈ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਜਦੋਂ ਸੈਸ਼ਨ ਦਾ ਕੁਝ ਵੀ ਮਾਲਕ ਨਹੀਂ ਸੀ। ਉਹ ਨਿਯਮ ਸਿਰਫ਼ ਰੀਡ-ਓਨਲੀ (read-only) ਕਾਰਵਾਈਆਂ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਇਸਨੇ close_tab ਨੂੰ ਪ੍ਰੋਵੇਨੈਂਸ ਚੈੱਕ (provenance check) ਤੋਂ ਬਿਨਾਂ ਚਲਾਉਣ ਦਾ ਰਾਹ ਵੀ ਖੋਲ੍ਹ ਦਿੱਤਾ।
  3. ਲੌਜਿਕ ਮਿਸਮੈਚ (Logic mismatch) – ਕਲੀਨਅੱਪ ਰੁਟੀਨ ਨੇ ਇੱਕ ਟੈਬ 'ਤੇ ਮਾਲਕੀ ਦੇ ਫਲੈਗ ਦੀ ਜਾਂਚ ਕੀਤੀ ਪਰ ਫਿਰ ਉਸ ਟੈਬ 'ਤੇ ਕਲੋਜ਼ ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕੀਤਾ ਜਿਸ ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਨੇ “current” ਦੱਸਿਆ ਸੀ। ਇਸ ਮਿਸਮੈਚ ਨੇ ਮਾਰਕਰ ਲੱਭਣ ਵਿੱਚ ਗਾਰਡ ਦੀ ਅਸਫਲਤਾ ਨੂੰ ਕਲੋਜ਼ ਕਮਾਂਡ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਦਿੱਤਾ ਅਤੇ ਇਸਨੂੰ ਗਲਤ ਨਿਸ਼ਾਨੇ ਵੱਲ ਮੋੜ ਦਿੱਤਾ।

ਹਰੇਕ ਪਰਤ ਨੇ ਇਹ ਮੰਨ ਲਿਆ ਕਿ “ਕੋਈ ਮਾਲਕੀ ਦਰਜ ਨਹੀਂ” ਦਾ ਮਤਲਬ ਹੈ “ਕਾਰਵਾਈ ਕਰਨ ਲਈ ਸੁਰੱਖਿਅਤ ਹੈ,” ਅਤੇ ਇਕੱਠੇ ਮਿਲ ਕੇ ਉਹਨਾਂ ਨੇ ਇੱਕ ਟੈਬ-ਬੰਦ ਕਰਨ ਵਾਲੀ ਕਮਾਂਡ ਪੈਦਾ ਕੀਤੀ ਜੋ ਕਾਨੂੰਨੀਤਾ ਦੇ ਕਿਸੇ ਵੀ ਸਬੂਤ ਤੋਂ ਬਿਨਾਂ ਚੱਲੀ।

ਹੱਲ: ਵਿਨਾਸ਼ਕਾਰੀ ਕਾਰਵਾਈਆਂ ਲਈ ਮਾਲਕੀ ਦਾ ਸਬੂਤ ਲਾਜ਼ਮੀ ਹੈ

ਸੋਧਿਆ ਹੋਇਆ ਲੌਜਿਕ ਰੀਡ-ਓਨਲੀ ਪਾਥਾਂ ਨੂੰ ਵਿਨਾਸ਼ਕਾਰੀ ਪਾਥਾਂ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ। ਹੁਣ, close_tab ਕਮਾਂਡ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਟੂਲ ਨੂੰ ਟਾਰਗੇਟ ਟੈਬ ਲਈ ਇੱਕ ਵੈਧ ਮਾਰਕਰ ਪੇਸ਼ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਮਾਰਕਰ ਗਾਇਬ ਹੈ, ਤਾਂ ਕਮਾਂਡ ਮੌਜੂਦਾ ਟੈਬ 'ਤੇ ਡਿਫੌਲਟ ਹੋਣ ਦੀ ਬਜਾਏ ਇੱਕ ਐਰਰ (error) ਦਿੰਦੀ ਹੈ। ਗਾਰਡ ਹੁਣ ਕਿਸੇ ਆਮ “do something” ਬ੍ਰਾਂਚ 'ਤੇ ਵਾਪਸ ਨਹੀਂ ਜਾਂਦਾ।

ਇਹ ਤਬਦੀਲੀ ਉਸ ਅਸਪਸ਼ਟ ਸਥਿਤੀ ਨੂੰ ਖਤਮ ਕਰਦੀ ਹੈ ਜਿੱਥੇ ਗਾਇਬ ਮਾਰਕਰ ਨੂੰ ਜਾਂ ਤਾਂ “ਕੁਝ ਕਰਨ ਲਈ ਨਹੀਂ” ਜਾਂ “ਜਾਓ ਅਤੇ ਕਾਰਵਾਈ ਕਰੋ” ਵਜੋਂ ਪੜ੍ਹਿਆ ਜਾ ਸਕਦਾ ਸੀ। ਇੱਕ ਸਪਸ਼ਟ ਅਸਫਲਤਾ ਨੂੰ ਲਾਜ਼ਮੀ ਬਣਾ ਕੇ, ਟੂਲ ਉਪਭੋਗਤਾ ਦੇ ਕੰਮ ਨੂੰ ਅਚਾਨਕ ਹੋਣ ਵਾਲੇ ਨੁਕਸਾਨ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।

ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਕਿਸ ਚੀਜ਼ ਦਾ ਧਿਆਨ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ

  • ਸ਼੍ਰੇਣੀ ਦੇ ਨਾਮ ਨੂੰ ਸੁਰੱਖਿਆ ਨਿਰਧਾਰਤ ਨਾ ਕਰਨ ਦਿਓ – “tab management” ਵਰਗਾ ਲੇਬਲ ਇਸਦੇ ਅ