তৃতীয় পক্ষ

একটি তৃতীয় পক্ষ কি?

এটা খুবই বিরল যে একটি ওয়েবসাইট সম্পূর্ণ স্বয়ংসম্পূর্ণ। এইচটিটিপি ওয়েব অ্যালমানাক দেখায় যে বেশিরভাগ ওয়েবসাইট-প্রায় 95%-তে কিছু তৃতীয় পক্ষের সামগ্রী থাকে ।

Almanac তৃতীয় পক্ষের বিষয়বস্তুকে একটি শেয়ার্ড এবং সর্বজনীন উত্সে হোস্ট করা কিছু হিসাবে সংজ্ঞায়িত করে, যা বিভিন্ন সাইট দ্বারা ব্যাপকভাবে ব্যবহৃত হয় এবং একজন পৃথক সাইটের মালিক দ্বারা প্রভাবিত হয় না। এগুলি হতে পারে ছবি বা অন্যান্য মিডিয়া যেমন ভিডিও, ফন্ট বা স্ক্রিপ্ট৷ চিত্র এবং স্ক্রিপ্টগুলি একসাথে যোগ করা অন্য সবকিছুর চেয়ে বেশি। তৃতীয় পক্ষের বিষয়বস্তু একটি সাইট বিকাশের জন্য অপরিহার্য নয়, তবে এটিও হতে পারে; আপনি প্রায় অবশ্যই একটি পাবলিক শেয়ার্ড সার্ভার থেকে লোড করা কিছু ব্যবহার করবেন, ওয়েব ফন্ট, ভিডিওর এমবেডেড আইফ্রেম, বিজ্ঞাপন বা জাভাস্ক্রিপ্ট লাইব্রেরি। উদাহরণস্বরূপ, আপনি Google ফন্ট থেকে পরিবেশিত ওয়েব ফন্ট ব্যবহার করতে পারেন, বা Google Analytics-এর সাথে বিশ্লেষণ পরিমাপ করছেন; আপনি হয়ত লাইক বোতাম যোগ করেছেন বা সোশ্যাল নেটওয়ার্ক থেকে বোতাম দিয়ে সাইন ইন করেছেন; আপনি মানচিত্র বা ভিডিও এম্বেড করতে পারেন, অথবা তৃতীয় পক্ষের পরিষেবার মাধ্যমে কেনাকাটা পরিচালনা করছেন; আপনি হয়ত ত্রুটি ট্র্যাক করছেন এবং তৃতীয় পক্ষের মনিটরিং টুলের মাধ্যমে আপনার নিজস্ব ডেভেলপমেন্ট টিমের জন্য লগিং করছেন।

গোপনীয়তার উদ্দেশ্যে, এটি একটি সামান্য ভিন্ন এবং কম বিস্তৃত সংজ্ঞা বিবেচনা করা দরকারী: একটি তৃতীয়-পক্ষের সংস্থান, এবং বিশেষ করে একটি তৃতীয়-পক্ষের স্ক্রিপ্ট, একটি ভাগ করা এবং সর্বজনীন উত্স থেকে পরিবেশিত হয় এবং ব্যাপকভাবে চিত্রিত হিসাবে ব্যবহৃত হয়, তবে এটি রচিতও হয় সাইটের মালিক ছাড়া অন্য কারো দ্বারা। কিভাবে অন্যদের থেকে আপনার ব্যবহারকারীদের গোপনীয়তা রক্ষা করা যায় তা বিবেচনা করার সময় তৃতীয় পক্ষের লেখকত্বের দিকটিই গুরুত্বপূর্ণ। এটি আপনাকে কোন ঝুঁকিগুলি উপস্থিত রয়েছে তা বিবেচনা করতে পরিচালিত করবে এবং তারপরে সেই ঝুঁকিগুলির উপর ভিত্তি করে তৃতীয় পক্ষের সংস্থান কীভাবে বা ব্যবহার করবেন তা সিদ্ধান্ত নিন। যেমনটি ইতিমধ্যে আলোচনা করা হয়েছে, এই বিষয়গুলি আপনাকে প্রেক্ষাপট বুঝতে এবং সেইজন্য আপনাকে কোন ট্রেড-অফগুলি করতে হবে এবং সেগুলির অর্থ কী তা বুঝতে সাহায্য করবে৷

সাধারণভাবে "থার্ড-পার্টি রিসোর্স" নিয়ে আলোচনা করার সময় এটিকে বোঝানো হয় না: প্রথম-পক্ষ এবং তৃতীয়-পক্ষের মধ্যে পার্থক্য আসলেই একটি প্রেক্ষাপটে যেটিতে কিছু ব্যবহার করা হয়। অন্য ওয়েবসাইট থেকে লোড করা একটি স্ক্রিপ্ট একটি তৃতীয় পক্ষের সম্পদ, এবং যে HTTP অনুরোধটি স্ক্রিপ্টটি লোড করে তাতে কুকি অন্তর্ভুক্ত থাকতে পারে, কিন্তু সেই কুকিগুলি আসলেই "তৃতীয়-পক্ষ কুকিজ" নয়; এগুলি কেবল কুকি, এবং সেগুলি "তৃতীয়-পক্ষ" বা "প্রথম-পক্ষ" কিনা তা নির্ভর করে আপনার সাইটের একটি পৃষ্ঠায় বা স্ক্রিপ্ট মালিকের সাইটের একটি পৃষ্ঠায় স্ক্রিপ্টটি লোড হচ্ছে কিনা তার উপর৷

কেন আমরা তৃতীয় পক্ষের সম্পদ ব্যবহার করি?

তৃতীয় পক্ষগুলি আপনার সাইটে কার্যকারিতা যোগ করার একটি দুর্দান্ত উপায়। এটি এমন বৈশিষ্ট্য হতে পারে যা ব্যবহারকারীদের কাছে প্রকাশ করা হয়, বা অদৃশ্য বিকাশকারী ফাংশন যেমন ত্রুটি ট্র্যাকিং, তবে তারা আপনার বিকাশের লোড কমিয়ে দেয় এবং স্ক্রিপ্টগুলি নিজেরাই অন্য কেউ রক্ষণাবেক্ষণ করে: আপনি যে পরিষেবাটি অন্তর্ভুক্ত করছেন তার উন্নয়ন দল৷ ওয়েবের সংমিশ্রণযোগ্যতার কারণে এই সমস্ত কাজ করে: অংশগুলিকে একত্রিত করতে সক্ষম হওয়া একটি সম্পূর্ণ তৈরি করতে যা তাদের যোগফলের চেয়ে বড়।

HTTP আর্কাইভের ওয়েব অ্যালম্যানাক একটি সুন্দর বর্ণনা দেয়:

তৃতীয় পক্ষগুলি ইমেজ, ভিডিও, ফন্ট, টুলস, লাইব্রেরি, উইজেট, ট্র্যাকার, বিজ্ঞাপন এবং আমাদের ওয়েব পৃষ্ঠাগুলিতে এম্বেড করার কল্পনা করতে পারে এমন অন্য কিছুর একটি শেষ না হওয়া সংগ্রহ সরবরাহ করে। এটি এমনকি সবচেয়ে অ-প্রযুক্তিগতকেও ওয়েবে সামগ্রী তৈরি এবং প্রকাশ করতে সক্ষম করে। তৃতীয় পক্ষ ছাড়া, ওয়েব সম্ভবত সমৃদ্ধ, নিমজ্জিত, জটিল প্ল্যাটফর্মের পরিবর্তে একটি খুব বিরক্তিকর, পাঠ্য-ভিত্তিক, একাডেমিক মাধ্যম হতে পারে যা আজ আমাদের অনেকের জীবনের জন্য অবিচ্ছেদ্য।

তৃতীয় পক্ষের সম্পদ কি করতে পারে?

কিছু তথ্য অ্যাক্সেস করা

আপনি যখন আপনার ওয়েবসাইটে একটি তৃতীয় পক্ষের সংস্থান ব্যবহার করেন, তা যাই হোক না কেন, কিছু তথ্য সেই তৃতীয় পক্ষের কাছে পাঠানো হয়। উদাহরণস্বরূপ, আপনি যদি অন্য সাইট থেকে একটি ছবি অন্তর্ভুক্ত করেন, তাহলে ব্যবহারকারীর ব্রাউজার যে HTTP অনুরোধ করে তা আপনার পৃষ্ঠার URL, সেইসাথে ব্যবহারকারীর IP ঠিকানার সাথে একটি রেফারার হেডার বরাবর পাস করবে।

ক্রস-সাইট ট্র্যাকিং

একই উদাহরণের সাথে চালিয়ে যাওয়া—যখন তৃতীয় পক্ষের সাইট থেকে ছবিটি লোড হয়, তখন এটি একটি কুকি অন্তর্ভুক্ত করতে পারে এবং ব্যবহারকারী যখন পরবর্তীতে সেই ছবিটির অনুরোধ করবে তখন সেই কুকিটি তৃতীয় পক্ষের কাছে ফেরত পাঠানো হবে৷ এর মানে হল যে তৃতীয় পক্ষ জানতে পারে যে তাদের পরিষেবা আপনার সাইটে ব্যবহার করা হচ্ছে, এবং এটি একটি কুকি ফেরত পাঠাতে পারে, সম্ভাব্য সেই ব্যবহারকারীর জন্য একটি অনন্য আইডি সহ। এর মানে হল যে পরের বার ব্যবহারকারী আপনার সাইট ভিজিট করলে, বা অন্য কোনও সাইট যাতে সেই তৃতীয় পক্ষের একটি সংস্থান অন্তর্ভুক্ত থাকে , সেই অনন্য আইডি কুকিটি আবার পাঠানো হবে। এটি তৃতীয় পক্ষকে সেই ব্যবহারকারী কোথায় ভিজিট করে তার একটি লগ তৈরি করতে দেয়: আপনার সাইট, অন্যান্য সাইট যা একই তৃতীয় পক্ষের সংস্থান ব্যবহার করে, সমস্ত ওয়েব জুড়ে৷

এটি ক্রস-সাইট ট্র্যাকিং : একটি তৃতীয় পক্ষকে অনেক ওয়েবসাইটে ব্যবহারকারীর কার্যকলাপের একটি লগ সংগ্রহ করার অনুমতি দেয়, যতক্ষণ না সেই ওয়েবসাইটগুলি একই তৃতীয় পক্ষ থেকে আসা একটি সংস্থান ব্যবহার করে। এটি একটি ফন্ট, একটি চিত্র বা একটি স্টাইলশীট হতে পারে - সমস্ত স্ট্যাটিক সংস্থান৷ এটি একটি গতিশীল সম্পদও হতে পারে: স্ক্রিপ্টের একটি অংশ, একটি সামাজিক মিডিয়া বোতাম, একটি বিজ্ঞাপন৷ অন্তর্ভুক্ত স্ক্রিপ্ট আরও বেশি তথ্য সংগ্রহ করতে পারে, কারণ এটি গতিশীল: এটি ব্যবহারকারীর ব্রাউজার এবং পরিবেশ পরিদর্শন করতে পারে এবং সেই ডেটা তার উদ্ভবকের কাছে ফেরত পাঠাতে পারে। যে কোনো স্ক্রিপ্ট কিছু পরিমাণে এটি করতে পারে, যেমন গতিশীল সম্পদ যা স্ক্রিপ্ট হিসাবে উপস্থাপন করে না, যেমন একটি সোশ্যাল মিডিয়া এম্বেড বা একটি বিজ্ঞাপন বা শেয়ার বোতাম। আপনি যদি জনপ্রিয় ওয়েবসাইটগুলিতে একটি কুকি ব্যানারের বিশদ বিবরণ দেখেন তবে আপনি সেই সংস্থাগুলির একটি তালিকা দেখতে পাবেন যেগুলি আপনার ব্যবহারকারীদের একটি প্রোফাইল তৈরি করতে তাদের কার্যকলাপের একটি ছবি তৈরি করতে একটি ট্র্যাকিং কুকি যুক্ত করতে পারে৷ তাদের শত শত হতে পারে. যদি একটি তৃতীয় পক্ষ বিনামূল্যে একটি পরিষেবা অফার করে, একটি উপায় যা তাদের জন্য অর্থনৈতিকভাবে কার্যকর হতে পারে কারণ তারা এই ডেটা সংগ্রহ করে এবং তারপর নগদীকরণ করে৷

গোপনীয়তার সমস্যাগুলির প্রকারের জন্য একটি দরকারী নির্দেশিকা যা থেকে একটি ব্রাউজারকে তার ব্যবহারকারীদের রক্ষা করা উচিত তা হল টার্গেট প্রাইভেসি থ্রেট মডেল ৷ এটি লেখার সময় এখনও আলোচনার অধীনে একটি নথি, তবে এটি বিদ্যমান গোপনীয়তার হুমকির কিছু উচ্চ-স্তরের শ্রেণীবিভাগ দেয়। তৃতীয় পক্ষের সংস্থানগুলির ঝুঁকিগুলি হল প্রাথমিকভাবে "অবাঞ্ছিত ক্রস-সাইট স্বীকৃতি", যেখানে একটি ওয়েবসাইট একাধিক সাইট জুড়ে একই ব্যবহারকারীকে সনাক্ত করতে পারে এবং "সংবেদনশীল তথ্য প্রকাশ", যেখানে একটি সাইট তথ্য সংগ্রহ করতে পারে যা ব্যবহারকারীকে সংবেদনশীল বলে মনে করে।

এটি একটি মূল পার্থক্য : তৃতীয় পক্ষ এটি থেকে অতিরিক্ত সংবেদনশীল তথ্য সংগ্রহ না করলেও অযাচিত ক্রস-সাইট স্বীকৃতি খারাপ, কারণ এটি তাদের পরিচয়ের উপর ব্যবহারকারীর নিয়ন্ত্রণ কেড়ে নেয়। ব্যবহারকারীর রেফারার এবং আইপি ঠিকানা এবং কুকিগুলিতে অ্যাক্সেস পাওয়া নিজেই একটি অবাঞ্ছিত প্রকাশ। থার্ড-পার্টি রিসোর্স ব্যবহার করে আপনি কীভাবে সেগুলিকে গোপনীয়তা-সংরক্ষণের উপায়ে ব্যবহার করবেন তার একটি পরিকল্পনা উপাদানের সাথে আসে। এর মধ্যে কিছু কাজ সাইট ডেভেলপার হিসেবে আপনার রেমিটে আছে, এবং কিছু কাজ ব্রাউজার তার ব্যবহারকারী এজেন্টের ভূমিকায় করে থাকে; অর্থাৎ, সংবেদনশীল তথ্য প্রকাশ এবং যেখানে সম্ভব অযাচিত ক্রস-সাইট স্বীকৃতি এড়াতে ব্যবহারকারীর পক্ষে কাজ করা এজেন্ট। নিচে আমরা ব্রাউজার লেভেল এবং সাইট ডেভেলপমেন্ট লেভেলে প্রশমন এবং পন্থা সম্পর্কে আরও বিস্তারিতভাবে দেখব।

সার্ভার-সাইড তৃতীয় পক্ষের কোড

তৃতীয় পক্ষের আমাদের পূর্ববর্তী সংজ্ঞাটি ইচ্ছাকৃতভাবে HTTP অ্যালম্যানাকের বরং ক্লায়েন্ট-সাইড পদ্ধতির পরিবর্তন করেছে (যেমনটি তাদের প্রতিবেদনের জন্য উপযুক্ত!), তৃতীয় পক্ষের লেখকত্ব অন্তর্ভুক্ত করার জন্য, কারণ গোপনীয়তার দৃষ্টিকোণ থেকে, তৃতীয় পক্ষ হল এমন কেউ যে আপনার সম্পর্কে কিছু জানে। ব্যবহারকারীরা যারা আপনি নন।

এতে তৃতীয় পক্ষগুলি অন্তর্ভুক্ত থাকে যারা সার্ভারে আপনার ব্যবহার করা পরিষেবাগুলি প্রদান করে, সেইসাথে ক্লায়েন্টও৷ গোপনীয়তার দৃষ্টিকোণ থেকে, একটি তৃতীয় পক্ষের লাইব্রেরি (যেমন NPM বা কম্পোজার বা NuGet থেকে অন্তর্ভুক্ত কিছু) বোঝাও গুরুত্বপূর্ণ। আপনার নির্ভরতা কি আপনার সীমানার বাইরে ডেটা পাস করে? আপনি যদি একটি লগিং পরিষেবা বা একটি দূরবর্তীভাবে হোস্ট করা ডাটাবেসে ডেটা পাস করেন, যদি আপনি লাইব্রেরিগুলিতে তাদের লেখকদের "ফোন হোম"ও অন্তর্ভুক্ত করেন, তাহলে এগুলি আপনার ব্যবহারকারীদের গোপনীয়তা লঙ্ঘন করতে পারে এবং তাই তাদের অডিট করা দরকার৷ একটি সার্ভার-ভিত্তিক তৃতীয় পক্ষকে সাধারণত ব্যবহারকারীর ডেটা আপনার দ্বারা হস্তান্তর করতে হয়, যার অর্থ এটি যে ডেটা প্রকাশ করে তা আপনার নিয়ন্ত্রণে বেশি। বিপরীতে, একটি ক্লায়েন্ট-ভিত্তিক তৃতীয় পক্ষ-আপনার ওয়েবসাইটে অন্তর্ভুক্ত একটি স্ক্রিপ্ট বা HTTP সংস্থান এবং ব্যবহারকারীর ব্রাউজার দ্বারা আনা হয়েছে-আপনার দ্বারা সংগ্রহের প্রক্রিয়াটি ছাড়াই সরাসরি ব্যবহারকারীর কাছ থেকে কিছু ডেটা সংগ্রহ করতে পারে। এই মডিউলের বেশিরভাগই সেই ক্লায়েন্ট-সাইড তৃতীয় পক্ষগুলিকে কীভাবে চিহ্নিত করবেন তা নিয়ে উদ্বিগ্ন থাকবে যেগুলিকে আপনি অন্তর্ভুক্ত করতে এবং আপনার ব্যবহারকারীদের কাছে প্রকাশ করার জন্য নির্বাচিত করেছেন, ঠিক কারণ আপনার দ্বারা কম মধ্যস্থতা সম্ভব। কিন্তু আপনার সার্ভার-সাইড কোড সুরক্ষিত করার বিষয়টি বিবেচনা করা মূল্যবান যাতে আপনি এটি থেকে আউটবাউন্ড যোগাযোগগুলি বুঝতে পারেন এবং অপ্রত্যাশিত যেকোনও লগ বা ব্লক করতে পারেন। এটি কীভাবে করা যায় তার বিশদ বিবরণ এখানে আমাদের সুযোগের বাইরে (এবং আপনার সার্ভার সেটআপের উপর খুব নির্ভরশীল) তবে এটি আপনার নিরাপত্তা এবং গোপনীয়তার অবস্থানের আরেকটি অংশ।

কেন আপনি তৃতীয় পক্ষের সাথে সতর্ক হতে হবে?

তৃতীয় পক্ষের স্ক্রিপ্ট এবং বৈশিষ্ট্যগুলি সত্যিই গুরুত্বপূর্ণ, এবং ওয়েব বিকাশকারী হিসাবে আমাদের লক্ষ্য হওয়া উচিত এই জাতীয় জিনিসগুলিকে একীভূত করা, সেগুলি থেকে মুখ ফিরিয়ে নেওয়া নয়! কিন্তু সম্ভাব্য সমস্যা আছে। থার্ড-পার্টি কন্টেন্ট পারফরম্যান্সের সমস্যা তৈরি করতে পারে এবং নিরাপত্তার সমস্যাও তৈরি করতে পারে কারণ আপনি আপনার বিশ্বাসের সীমানার মধ্যে একটি বাহ্যিক পরিষেবা আনছেন। কিন্তু তৃতীয় পক্ষের বিষয়বস্তু গোপনীয়তার সমস্যাও তৈরি করতে পারে!

যখন আমরা ওয়েবে তৃতীয় পক্ষের সংস্থান সম্পর্কে কথা বলি, তখন নিরাপত্তা সমস্যাগুলি (অন্যান্য জিনিসগুলির মধ্যে) যেখানে তৃতীয় পক্ষ আপনার কোম্পানি থেকে ডেটা চুরি করতে পারে এবং এর সাথে গোপনীয়তার সমস্যাগুলির সাথে এর বিপরীতে (অন্যান্য জিনিসগুলির মধ্যে) চিন্তা করা দরকারী অন্যান্য জিনিস) যেখানে আপনি অন্তর্ভুক্ত করা তৃতীয় পক্ষ আপনার (বা তাদের) সম্মতি ছাড়াই আপনার ব্যবহারকারীদের ডেটা চুরি করে বা অ্যাক্সেস করে।

একটি নিরাপত্তা সমস্যার একটি উদাহরণ যেখানে "ওয়েব স্কিমাররা" ক্রেডিট কার্ডের তথ্য চুরি করে--একটি তৃতীয় পক্ষের সম্পদ যা একটি পৃষ্ঠায় অন্তর্ভুক্ত করা হয় যেখানে একজন ব্যবহারকারী ক্রেডিট কার্ডের বিবরণ প্রবেশ করে, সম্ভাব্যভাবে, সেই ক্রেডিট কার্ডের বিবরণ চুরি করে পাঠাতে পারে। দূষিত তৃতীয় পক্ষের কাছে। যারা এই স্কিমার স্ক্রিপ্টগুলি তৈরি করে তারা তাদের আড়াল করার জায়গাগুলিতে কাজ করার ক্ষেত্রে খুব সৃজনশীল। একটি সারাংশ বর্ণনা করে যে কীভাবে তৃতীয় পক্ষের সামগ্রীতে স্কিমার স্ক্রিপ্টগুলি লুকিয়ে রাখা হয়েছে যেমন সাইট লোগো, ফেভিকন এবং সোশ্যাল মিডিয়া নেটওয়ার্কের জন্য ব্যবহৃত ছবি, জনপ্রিয় লাইব্রেরি যেমন jQuery, Modernizr, এবং Google Tag Manager, সাইট উইজেট যেমন লাইভ চ্যাট উইন্ডোজ , এবং CSS ফাইল।

গোপনীয়তার সমস্যা একটু ভিন্ন। এই তৃতীয় পক্ষগুলি আপনার প্রস্তাবের অংশ ; আপনার প্রতি আপনার ব্যবহারকারীদের আস্থা বজায় রাখার জন্য, আপনাকে নিশ্চিত হতে হবে যে আপনার ব্যবহারকারীরা তাদের বিশ্বাস করতে পারে। আপনি ব্যবহার করেন এমন কোনো তৃতীয় পক্ষ যদি আপনার ব্যবহারকারীদের সম্পর্কে ডেটা সংগ্রহ করে এবং তারপরে এটির অপব্যবহার করে, বা এটি মুছে ফেলা বা আবিষ্কার করা কঠিন করে তোলে, বা ডেটা লঙ্ঘনের শিকার হয়, বা আপনার ব্যবহারকারীদের প্রত্যাশা লঙ্ঘন করে, তাহলে আপনার ব্যবহারকারীরা সম্ভবত এটিকে ব্রেকডাউন হিসাবে বুঝতে পারবে আপনার পরিষেবার প্রতি তাদের আস্থা, কেবল তৃতীয় পক্ষের নয়। এটা লাইনে আপনার খ্যাতি এবং সম্পর্ক. এই কারণেই নিজেকে জিজ্ঞাসা করা গুরুত্বপূর্ণ: আপনি কি আপনার সাইটে ব্যবহার করছেন এমন তৃতীয় পক্ষকে বিশ্বাস করেন?

তৃতীয় পক্ষের কিছু উদাহরণ কি?

আমরা সাধারণত "তৃতীয় পক্ষ" নিয়ে আলোচনা করছি, কিন্তু আসলে বিভিন্ন ধরনের আছে, এবং তাদের ব্যবহারকারীর ডেটার বিভিন্ন পরিমাণে অ্যাক্সেস আছে। উদাহরণস্বরূপ, আপনার HTML-এ একটি <img> উপাদান যোগ করা, একটি ভিন্ন সার্ভার থেকে লোড করা, সেই সার্ভারটিকে আপনার ব্যবহারকারীদের সম্পর্কে একটি <iframe> হতে পারে, বা একটি <script> উপাদান যোগ করার চেয়ে ভিন্ন তথ্য দেবে। এইগুলি একটি বিস্তৃত তালিকার পরিবর্তে উদাহরণ, কিন্তু আপনার সাইট নিয়োগ করতে পারে এমন বিভিন্ন ধরণের থার্ড-পার্টি আইটেমের মধ্যে পার্থক্য বোঝার জন্য এটি কার্যকর।

একটি ক্রস-সাইট সংস্থান অনুরোধ করা হচ্ছে

একটি ক্রস-সাইট রিসোর্স হল আপনার সাইটের এমন কিছু যা একটি ভিন্ন সাইট থেকে লোড করা হয় এবং এটি একটি <iframe> বা <script> নয়। উদাহরণগুলির মধ্যে রয়েছে <img> , <audio> , <video> , CSS দ্বারা লোড করা ওয়েব ফন্ট এবং WebGL টেক্সচার। এগুলি সবগুলি একটি HTTP অনুরোধের মাধ্যমে লোড করা হয় এবং পূর্বে বর্ণিত হিসাবে, সেই HTTP অনুরোধগুলির মধ্যে অন্য সাইট দ্বারা পূর্বে সেট করা যেকোন কুকি, অনুরোধকারী ব্যবহারকারীর আইপি ঠিকানা এবং রেফারার হিসাবে বর্তমান পৃষ্ঠার URL অন্তর্ভুক্ত থাকবে৷ সমস্ত তৃতীয় পক্ষের অনুরোধে ঐতিহাসিকভাবে ডিফল্টরূপে এই ডেটা অন্তর্ভুক্ত করা হয়েছে, যদিও বিভিন্ন ব্রাউজার দ্বারা তৃতীয় পক্ষের কাছে পাঠানো ডেটা হ্রাস বা বিচ্ছিন্ন করার প্রচেষ্টা রয়েছে, যেমনটি "তৃতীয়-পক্ষ ব্রাউজার সুরক্ষা বোঝার" এ বর্ণনা করা হয়েছে।

একটি ক্রস-সাইট আইফ্রেম এম্বেড করা

একটি <iframe> এর মাধ্যমে আপনার পৃষ্ঠাগুলিতে এম্বেড করা একটি সম্পূর্ণ নথি কুকিজ, IP ঠিকানা এবং রেফারারের ট্রাইফেক্টা ছাড়াও ব্রাউজার APIগুলিতে অতিরিক্ত অ্যাক্সেসের অনুরোধ করতে পারে। ঠিক কোন APIs <iframe> d পৃষ্ঠাগুলিতে উপলব্ধ এবং তারা কীভাবে অ্যাক্সেসের অনুরোধ করে তা ব্রাউজার-নির্দিষ্ট, এবং বর্তমানে পরিবর্তনের মধ্য দিয়ে যাচ্ছে: এমবেডেড নথিতে API অ্যাক্সেস কমাতে বা নিরীক্ষণ করার বর্তমান প্রচেষ্টার জন্য নীচে "অনুমতি নীতি" দেখুন।

ক্রস-সাইট জাভাস্ক্রিপ্ট চালানো হচ্ছে

একটি <script> উপাদান সহ আপনার পৃষ্ঠার শীর্ষ-স্তরের প্রেক্ষাপটে ক্রস-সাইট জাভাস্ক্রিপ্ট লোড এবং রান করে। এর মানে হল যে স্ক্রিপ্টটি চালায় সেটিতে আপনার নিজের প্রথম-পক্ষের স্ক্রিপ্টগুলি যা করে তার সম্পূর্ণ অ্যাক্সেস রয়েছে৷ ব্রাউজার অনুমতিগুলি এখনও এই ডেটা পরিচালনা করে, তাই ব্যবহারকারীর অবস্থানের অনুরোধ করার জন্য (উদাহরণস্বরূপ) এখনও ব্যবহারকারীর চুক্তির প্রয়োজন হবে৷ কিন্তু পৃষ্ঠায় উপস্থিত বা JavaScript ভেরিয়েবল হিসাবে উপলব্ধ যেকোন তথ্য এই ধরনের স্ক্রিপ্ট দ্বারা পড়া যেতে পারে, এবং এতে কেবলমাত্র অনুরোধের অংশ হিসাবে তৃতীয় পক্ষের কাছে পাঠানো কুকিজ নয়, বরং শুধুমাত্র আপনার সাইটের উদ্দেশ্যে করা কুকিগুলিও অন্তর্ভুক্ত। একইভাবে, আপনার পৃষ্ঠায় লোড করা একটি তৃতীয় পক্ষের স্ক্রিপ্ট আপনার নিজের কোডের মতো একই HTTP অনুরোধ করতে পারে, যার অর্থ এটি ডেটা পাওয়ার জন্য আপনার ব্যাক-এন্ড এপিআইগুলিতে fetch() অনুরোধ করতে পারে।

আপনার নির্ভরতাগুলিতে তৃতীয় পক্ষের লাইব্রেরি সহ

পূর্বে বর্ণিত হিসাবে, আপনার সার্ভার-সাইড কোড সম্ভবত তৃতীয় পক্ষের নির্ভরতা অন্তর্ভুক্ত করবে, এবং এগুলি তাদের ক্ষমতায় আপনার নিজস্ব কোড থেকে আলাদা করা যায় না; আপনি একটি GitHub সংগ্রহস্থল বা আপনার প্রোগ্রামিং ভাষার লাইব্রেরি (npm, PyPI, কম্পোজার এবং আরও অনেক কিছু) থেকে অন্তর্ভুক্ত কোডটি আপনার অন্যান্য কোডের মতো একই ডেটা পড়তে পারে।

আপনার তৃতীয় পক্ষ জেনে

তারপরে, এটির জন্য আপনার তৃতীয় পক্ষের সরবরাহকারীদের তালিকা এবং তাদের গোপনীয়তা, ডেটা সংগ্রহ এবং ব্যবহারকারীর অভিজ্ঞতার অবস্থান এবং নীতিগুলি সম্পর্কে কিছুটা বোঝার প্রয়োজন৷ এই বোঝাপড়াটি তখন আপনার ট্রেড-অফের সিরিজের অংশ হয়ে ওঠে: পরিষেবাটি কতটা দরকারী এবং গুরুত্বপূর্ণ, আপনার ব্যবহারকারীদের তাদের দাবিগুলি কতটা হস্তক্ষেপকারী, অসুবিধাজনক বা বিরক্তিকর তার বিরুদ্ধে ভারসাম্যপূর্ণ। তৃতীয় পক্ষের বিষয়বস্তু সাইটের মালিক হিসাবে আপনার কাছ থেকে ভারী উত্তোলন নিয়ে মূল্য প্রদান করে এবং আপনাকে আপনার মূল দক্ষতার উপর ফোকাস করার অনুমতি দেয়; এবং তাই একটি ভাল ব্যবহারকারীর অভিজ্ঞতার জন্য সেই ট্রেড-অফ করার এবং কিছু ব্যবহারকারীর স্বাচ্ছন্দ্য এবং গোপনীয়তা ত্যাগ করার মূল্য রয়েছে। ব্যবহারকারীর অভিজ্ঞতাকে বিকাশকারীর অভিজ্ঞতার সাথে বিভ্রান্ত না করা গুরুত্বপূর্ণ, যদিও: "আমাদের ডেভ টিমের পক্ষে পরিষেবাটি তৈরি করা সহজ" ব্যবহারকারীদের কাছে একটি বাধ্যতামূলক গল্প নয়।

আপনি কিভাবে বুঝতে পারবেন তা হল অডিট প্রক্রিয়া।

আপনার তৃতীয় পক্ষের অডিট করুন

তৃতীয় পক্ষ কী করে তা বোঝা হল নিরীক্ষার প্রক্রিয়া। আপনি এটি প্রযুক্তিগত এবং অ-প্রযুক্তিগতভাবে করতে পারেন, এবং একটি পৃথক তৃতীয় পক্ষের জন্য এবং আপনার সম্পূর্ণ সংগ্রহের জন্য।

একটি নন-টেকনিক্যাল অডিট চালান

প্রথম ধাপটি অ-প্রযুক্তিগত: আপনার সরবরাহকারীদের গোপনীয়তা নীতিগুলি পড়ুন। আপনি যদি কোনো তৃতীয় পক্ষের সম্পদ অন্তর্ভুক্ত করেন, তাহলে গোপনীয়তা নীতিগুলি পরীক্ষা করুন৷ এগুলি দীর্ঘ এবং আইনি পাঠ্যে পূর্ণ হবে, এবং কিছু নথিগুলি পূর্ববর্তী মডিউলগুলিতে বিশেষভাবে সতর্ক করা কিছু পন্থা ব্যবহার করতে পারে, যেমন অতিরিক্ত সাধারণ বিবৃতি এবং কীভাবে বা কখন ডেটা সংগ্রহ করা হবে তার কোনও ইঙ্গিত ছাড়াই৷ এটি উপলব্ধি করা গুরুত্বপূর্ণ যে ব্যবহারকারীর দৃষ্টিকোণ থেকে, তৃতীয় পক্ষগুলি সহ আপনার সাইটে সংগ্রহ করা সমস্ত ডেটা এই গোপনীয়তা নীতিগুলি দ্বারা পরিচালিত হবে৷ এমনকি যদি আপনি সবকিছু সঠিকভাবে করেন, আপনি যখন আপনার লক্ষ্য সম্পর্কে স্বচ্ছ হন এবং ডেটা গোপনীয়তা এবং সংবেদনশীলতার বিষয়ে আপনার ব্যবহারকারীদের প্রত্যাশা ছাড়িয়ে যান, ব্যবহারকারীরা আপনার নির্বাচিত তৃতীয় পক্ষের যেকোনো কিছুর জন্য আপনাকে দায়ী করতে পারে। যদি তাদের গোপনীয়তা নীতিতে এমন কিছু থাকে যা আপনি নিজের নীতিতে বলতে চান না কারণ এটি ব্যবহারকারীদের আস্থা হ্রাস করবে, তাহলে বিকল্প সরবরাহকারী আছে কিনা তা বিবেচনা করুন।

এটি এমন কিছু যা কার্যকরীভাবে প্রযুক্তিগত নিরীক্ষার সাথে আরও আলোচিত হতে পারে, কারণ তারা একে অপরকে জানায়। ব্যবসায়িক কারণে (যেমন বিজ্ঞাপন নেটওয়ার্ক বা এমবেডেড সামগ্রী) আপনি যে তৃতীয় পক্ষের সংস্থানগুলিকে অন্তর্ভুক্ত করছেন তা আপনার জানা উচিত কারণ সেখানে একটি ব্যবসায়িক সম্পর্ক থাকবে৷ এটি একটি নন-টেকনিক্যাল অডিট শুরু করার জন্য একটি ভাল জায়গা। কারিগরি নিরীক্ষা তৃতীয় পক্ষগুলিকে চিহ্নিত করতে পারে, বিশেষ করে যেগুলি ব্যবসায়িক কারণে (বাহ্যিক উপাদান, বিশ্লেষণ, ইউটিলিটি লাইব্রেরি) এর পরিবর্তে প্রযুক্তিগত জন্য অন্তর্ভুক্ত করা হয়েছে এবং সেই তালিকাটি ব্যবসা-কেন্দ্রিক তৃতীয় পক্ষের তালিকার সাথে যোগ দিতে পারে। এখানে লক্ষ্য হল আপনার সাইটের মালিক হিসাবে আপনি অনুভব করুন যে আপনি আপনার সাইটে যোগ করা তৃতীয় পক্ষগুলি কী করছেন তা আপনি বুঝতে পেরেছেন এবং একটি ব্যবসা হিসাবে আপনার জন্য তৃতীয় পক্ষের এই তালিকার সাথে আপনার আইনি উপদেষ্টাকে উপস্থাপন করতে সক্ষম হবেন। নিশ্চিত যে আপনি প্রয়োজনীয় কোনো বাধ্যবাধকতা পূরণ করছেন।

একটি প্রযুক্তিগত অডিট চালান

একটি প্রযুক্তিগত নিরীক্ষার জন্য, ওয়েবসাইটের অংশ হিসাবে সম্পদগুলি ব্যবহার করা গুরুত্বপূর্ণ; অর্থাৎ, একটি পরীক্ষার জোতাতে নির্ভরতা লোড করবেন না এবং এটি সেইভাবে পরিদর্শন করুন। নিশ্চিত করুন যে আপনি দেখতে পাচ্ছেন যে কীভাবে আপনার নির্ভরতাগুলি আপনার প্রকৃত ওয়েবসাইটের অংশ হিসাবে কাজ করে, একটি পরীক্ষা বা বিকাশ মোডে না হয়ে সর্বজনীন ইন্টারনেটে স্থাপন করা হয়েছে৷ এটি একটি নতুন ব্যবহারকারী হিসাবে আপনার নিজের ওয়েবসাইট দেখতে খুব শিক্ষণীয়. একটি পরিষ্কার নতুন প্রোফাইলে একটি ব্রাউজার খুলুন, যাতে আপনি সাইন ইন না করেন এবং কোনো সঞ্চিত চুক্তি না থাকে এবং আপনার সাইট দেখার চেষ্টা করুন৷

একটি নতুন অ্যাকাউন্টের জন্য আপনার নিজের সাইটে সাইন আপ করুন, যদি আপনি ব্যবহারকারী অ্যাকাউন্ট প্রদান করেন। আপনার ডিজাইন টিম এই নতুন ব্যবহারকারী অধিগ্রহণ প্রক্রিয়াটিকে একটি UX দৃষ্টিকোণ থেকে সাজিয়েছে, তবে এটি একটি গোপনীয়তার দৃষ্টিকোণ থেকে এটির সাথে যোগাযোগ করা দৃষ্টান্তমূলক হতে পারে। শর্তাবলী, বা কুকি সতর্কীকরণ, বা গোপনীয়তা নীতিতে "স্বীকার করুন" ক্লিক করবেন না; কোনো ব্যক্তিগত তথ্য প্রকাশ না করে বা কোনো ট্র্যাকিং কুকিজ না রেখে আপনার নিজের পরিষেবা ব্যবহার করার কাজটি সেট করুন এবং দেখুন আপনি এটি করতে পারেন কিনা এবং এটি করা কতটা কঠিন। কোন সাইটগুলি অ্যাক্সেস করা হচ্ছে এবং সেই সাইটগুলিতে কোন ডেটা পাস করা হয়েছে তা দেখতে ব্রাউজার বিকাশকারী সরঞ্জামগুলিতে সন্ধান করাও সহায়ক হতে পারে৷ বিকাশকারী সরঞ্জামগুলি পৃথক HTTP অনুরোধগুলির একটি তালিকা প্রদান করে (সাধারণত "নেটওয়ার্ক" নামে একটি বিভাগে), এবং আপনি এখান থেকে টাইপ অনুসারে গোষ্ঠীভুক্ত অনুরোধগুলি দেখতে পারেন (HTML, CSS, চিত্র, ফন্ট, JavaScript, JavaScript দ্বারা শুরু করা অনুরোধ)। প্রতিটি অনুরোধের ডোমেন দেখানোর জন্য একটি নতুন কলাম যুক্ত করাও সম্ভব, যা প্রদর্শন করবে কতগুলি বিভিন্ন জায়গায় যোগাযোগ করা হচ্ছে এবং শুধুমাত্র তৃতীয় পক্ষকে দেখানোর জন্য একটি "তৃতীয়-পক্ষের অনুরোধ" চেকবক্স থাকতে পারে। (একটি ধারাবাহিক নিরীক্ষা করার জন্য Content-Security-Policy প্রতিবেদন ব্যবহার করাও কার্যকর হতে পারে, যার জন্য আরও পড়ুন।)

সাইমন হার্নের "রিকোয়েস্ট ম্যাপ জেনারেটর" টুলটি একটি সর্বজনীনভাবে উপলব্ধ পৃষ্ঠার সমস্ত উপ-অনুরোধের একটি সহায়ক ওভারভিউ হতে পারে।

এটি সেই বিন্দুতে যেখানে আপনি অ-প্রযুক্তিগত নিরীক্ষার অংশ হিসাবে চিহ্নিত ব্যবসা-কেন্দ্রিক তৃতীয় পক্ষকে অন্তর্ভুক্ত করতে পারেন (অর্থাৎ: তাদের সংস্থানগুলি ব্যবহার করার জন্য আপনার সাথে আর্থিক সম্পর্ক রয়েছে এমন সংস্থাগুলির তালিকা)। এখানে লক্ষ্য হল তৃতীয় পক্ষের তালিকার সাথে মিল করা যা আপনি বিশ্বাস করেন যে আপনি ব্যবহার করছেন (আর্থিক এবং আইনী রেকর্ড থেকে) এবং আপনি আসলে যে তালিকাটি ব্যবহার করছেন (আপনার ওয়েবসাইট কোন তৃতীয় পক্ষের HTTP অনুরোধ করে তা দেখে)। আপনি প্রতিটি ব্যবসার তৃতীয় পক্ষের জন্য সনাক্ত করতে সক্ষম হবেন যা প্রযুক্তিগত আউটবাউন্ড অনুরোধ করা হয়েছে। আপনি যদি ব্যবসায়িক সম্পর্কের দ্বারা চিহ্নিত তৃতীয় পক্ষের জন্য প্রযুক্তিগত নিরীক্ষায় অনুরোধগুলি সনাক্ত করতে না পারেন, তাহলে কেন এবং আপনার পরীক্ষায় সেই নির্দেশিকা থাকাটা গুরুত্বপূর্ণ: সম্ভবত তৃতীয় পক্ষের সংস্থান শুধুমাত্র একটি নির্দিষ্ট দেশে লোড করা হয়েছে, বা একটি নির্দিষ্ট দেশে ডিভাইসের ধরন, বা লগ ইন করা ব্যবহারকারীদের জন্য। এটি অডিট করার জন্য আপনার সাইটের এলাকার তালিকাকে বড় করবে এবং নিশ্চিত করবে যে আপনি সমস্ত আউটবাউন্ড অ্যাক্সেস দেখতে পাচ্ছেন। (অথবা সম্ভবত এটি একটি তৃতীয় পক্ষের সংস্থান সনাক্ত করবে যার জন্য আপনি অর্থ প্রদান করছেন এবং ব্যবহার করছেন না, যা সর্বদা অর্থ বিভাগকে উত্সাহিত করে।)

আপনি অডিটের অংশ হতে চান এমন তৃতীয় পক্ষের কাছে অনুরোধের তালিকা সংকুচিত করার পরে, একটি পৃথক অনুরোধে ক্লিক করলে সেটির সমস্ত বিবরণ দেখাবে এবং বিশেষ করে, সেই অনুরোধে কোন ডেটা পাঠানো হয়েছে। এটিও খুব সাধারণ যে একটি তৃতীয় পক্ষের অনুরোধ যা আপনার কোডটি শুরু করে তারপরে আরও অনেক তৃতীয় পক্ষের অনুরোধ শুরু করে । এই অতিরিক্ত তৃতীয় পক্ষগুলি আপনার নিজের গোপনীয়তা নীতিতে "আমদানি করা" হয়৷ এই কাজটি শ্রমসাধ্য কিন্তু মূল্যবান, এবং এটি প্রায়ই বিদ্যমান বিশ্লেষণে ঢোকানো যেতে পারে; আপনার ফ্রন্টএন্ড ডেভেলপমেন্ট টিম ইতিমধ্যেই পারফরম্যান্সের কারণে (সম্ভবত ওয়েবপেজটেস্ট বা লাইটহাউসের মতো বিদ্যমান সরঞ্জামগুলির সাহায্যে) অনুরোধগুলি নিরীক্ষণ করা উচিত এবং সেই প্রক্রিয়ার মধ্যে একটি ডেটা এবং গোপনীয়তা নিরীক্ষা অন্তর্ভুক্ত করা এটিকে আরও সহজ করে তুলতে পারে।

করবেন

একটি পরিষ্কার নতুন ব্যবহারকারী প্রোফাইল সহ একটি ব্রাউজার খুলুন, যাতে আপনি সাইন ইন না করেন এবং কোনো সঞ্চিত চুক্তি না থাকে; তারপর ব্রাউজার ডেভেলপমেন্ট টুলস নেটওয়ার্ক প্যানেল খুলুন সব বহির্গামী অনুরোধ দেখতে. প্রতিটি অনুরোধের ডোমেন দেখানোর জন্য একটি নতুন কলাম যোগ করুন এবং উপস্থিত থাকলে শুধুমাত্র তৃতীয় পক্ষগুলি দেখানোর জন্য "তৃতীয়-পক্ষের অনুরোধ" চেকবক্সে টিক চিহ্ন দিন। তারপর:

• আপনার সাইটে যান.
• একটি নতুন অ্যাকাউন্টের জন্য সাইন আপ করুন, যদি আপনি ব্যবহারকারী অ্যাকাউন্ট প্রদান করেন।
• আপনার তৈরি অ্যাকাউন্ট মুছে ফেলার চেষ্টা করুন.
• সাইটে একটি বা দুটি সাধারণ ক্রিয়া সম্পাদন করুন (এটি ঠিক কী তা নির্ভর করবে আপনার সাইট কী করে তার উপর নির্ভর করবে, তবে বেশিরভাগ ব্যবহারকারী যে সাধারণ ক্রিয়াগুলি সম্পাদন করে তা বেছে নিন)।
• বিশেষ করে তৃতীয় পক্ষের নির্ভরতা জড়িত থাকে এমন একটি বা দুটি কাজ আপনি জানেন। এর মধ্যে সোশ্যাল মিডিয়াতে কন্টেন্ট শেয়ার করা, চেকআউট ফ্লো শুরু করা বা অন্য সাইট থেকে কন্টেন্ট এম্বেড করা অন্তর্ভুক্ত থাকতে পারে।

এই প্রতিটি কাজ করার সময়, আপনার নয় এমন ডোমেনগুলি থেকে অনুরোধ করা সংস্থানগুলির একটি রেকর্ড তৈরি করুন, বর্ণনা অনুযায়ী নেটওয়ার্ক প্যানেলটি দেখে৷ এগুলি আপনার তৃতীয় পক্ষের কিছু। এটি করার একটি ভাল উপায় হল একটি HAR ফাইলে নেটওয়ার্ক অনুরোধ লগগুলি ক্যাপচার করতে ব্রাউজার নেটওয়ার্ক সরঞ্জামগুলি ব্যবহার করা৷

HAR ফাইল এবং ক্যাপচারিং

একটি HAR ফাইল হল একটি পৃষ্ঠার দ্বারা করা সমস্ত নেটওয়ার্ক অনুরোধগুলির একটি প্রমিত JSON ফর্ম্যাট৷ একটি নির্দিষ্ট পৃষ্ঠার জন্য একটি HAR ফাইল পেতে, এতে:

ক্রোম

DevTools ব্রাউজারটি খুলুন ( মেনু > আরও সরঞ্জাম > বিকাশকারী সরঞ্জাম ), নেটওয়ার্ক প্যানেলে যান, পৃষ্ঠাটি লোড করুন (বা রিফ্রেশ করুন) এবং নো থ্রটলিং ড্রপডাউন মেনুর কাছে উপরের ডানদিকে নিচের দিকের তীর সংরক্ষণ চিহ্নটি বেছে নিন।

ফায়ারফক্স

ব্রাউজার ডেভেলপার টুল খুলুন ( মেনু > আরও টুল > ওয়েব ডেভেলপার টুল ), নেটওয়ার্ক প্যানেলে যান, পৃষ্ঠাটি লোড করুন (বা রিফ্রেশ করুন) এবং থ্রোটলিং ড্রপডাউন মেনুর পাশে উপরের ডানদিকে কগ প্রতীকটি বেছে নিন। এর মেনু থেকে, সেভ অল অ্যাজ HAR ** বেছে নিন।

সাফারি

ব্রাউজার ডেভেলপার টুল খুলুন ( মেনু > ডেভেলপ > ওয়েব ইন্সপেক্টর দেখান ; আপনার যদি ডেভেলপ মেনু না থাকে তাহলে মেনু > সাফারি > পছন্দ > অ্যাডভান্সড > মেনু বারে ডেভেলপ মেনু দেখান থেকে সক্রিয় করুন, নেটওয়ার্ক প্যানেলে যান, লোড করুন। পৃষ্ঠাটি (বা রিফ্রেশ করুন) এবং উপরের ডানদিকে রপ্তানি নির্বাচন করুন (সংরক্ষণ লগের ডানদিকে; আপনাকে উইন্ডোটি বড় করতে হতে পারে)।

আরও বিস্তারিত জানার জন্য, আপনি তৃতীয় পক্ষের কাছে যা পাঠানো হয়েছে তাও রেকর্ড করতে পারেন (অনুরোধ বিভাগে), যদিও এই ডেটা প্রায়শই অস্পষ্ট হয় এবং দরকারীভাবে ব্যাখ্যা করা যায় না।

তৃতীয় পক্ষকে সংহত করার সময় সর্বোত্তম অনুশীলন

আপনার সাইট কোন তৃতীয় পক্ষগুলি ব্যবহার করে তার উপর আপনি আপনার নিজস্ব নীতি সেট করতে পারেন: আপনি কোন বিজ্ঞাপন প্রদানকারীকে তাদের অনুশীলনের উপর ভিত্তি করে ব্যবহার করেন, বা তাদের কুকিজ সম্মতি পপআপ কতটা বিরক্তিকর বা অনুপ্রবেশকারী তা পরিবর্তন করুন, অথবা আপনি আপনার সাইটে বা ট্র্যাকিংয়ের সোশ্যাল মিডিয়া বোতামগুলি ব্যবহার করতে চান কিনা আপনার টুইটগুলিতে Google Analytics-এ ট্র্যাক করার জন্য আপনার ইমেলগুলির লিঙ্ক বা utm_campaign লিঙ্কগুলি৷ একটি সাইট বিকাশ করার সময় বিবেচনা করার একটি দিক হল আপনার বিশ্লেষণ পরিষেবার গোপনীয়তা এবং নিরাপত্তা ভঙ্গি। কিছু বিশ্লেষণ পরিষেবা স্পষ্টভাবে গোপনীয়তা-সুরক্ষার উপর ব্যবসা করে। প্রায়শই, একটি তৃতীয়-পক্ষের স্ক্রিপ্ট ব্যবহার করার উপায়ও রয়েছে যা নিজের মধ্যে গোপনীয়তা সুরক্ষা যোগ করে: আপনি প্রথম দল নন যা তাদের ব্যবহারকারীদের গোপনীয়তা উন্নত করতে এবং তৃতীয় পক্ষের ডেটা সংগ্রহ থেকে তাদের রক্ষা করতে চায় এবং ইতিমধ্যেই সমাধান থাকতে পারে। অবশেষে, অনেক থার্ড-পার্টি প্রদানকারী অতীতের তুলনায় এখন ডেটা সংগ্রহের সমস্যাগুলির প্রতি বেশি সংবেদনশীল, এবং প্রায়শই এমন বৈশিষ্ট্য বা প্যারামিটার রয়েছে যা আপনি যোগ করতে পারেন যা আরও ব্যবহারকারী-প্রতিরক্ষামূলক মোড সক্ষম করে। এখানে কিছু উদাহরণঃ.

একটি সামাজিক মিডিয়া শেয়ারিং বোতাম যোগ করার সময়

সরাসরি HTML বোতাম এম্বেড করার কথা বিবেচনা করুন: https://sharingbuttons.io/ সাইটটিতে কিছু ভালোভাবে ডিজাইন করা উদাহরণ রয়েছে। অথবা আপনি প্লেইন HTML লিঙ্ক যোগ করতে পারেন. এখানে ট্রেড-অফ হল যে আপনি "শেয়ার কাউন্ট" পরিসংখ্যান এবং আপনার Facebook বিশ্লেষণে আপনার গ্রাহকদের শ্রেণীবদ্ধ করার ক্ষমতা হারাবেন। এটি একটি তৃতীয় পক্ষ প্রদানকারীর ব্যবহার এবং কম বিশ্লেষণ ডেটা গ্রহণের মধ্যে ট্রেড-অফের একটি উদাহরণ৷

আরো সাধারণভাবে, আপনি যখন কোনো তৃতীয় পক্ষ থেকে কোনো ধরনের ইন্টারেক্টিভ উইজেট এম্বেড করছেন, তখন প্রায়ই সেই তৃতীয় পক্ষের সাথে একটি লিঙ্ক প্রদান করা সম্ভব। এর অর্থ এই যে আপনার সাইটের ইনলাইন অভিজ্ঞতা নেই, তবে এটি তৃতীয় পক্ষের সাথে ডেটা ভাগ করার সিদ্ধান্ত আপনার থেকে আপনার ব্যবহারকারীর কাছে স্থানান্তরিত করে, যারা তাদের পছন্দ মত ইন্টারঅ্যাক্ট করতে বা না করতে পারে।

উদাহরণস্বরূপ, আপনি এইভাবে mysite.example.com-এ আপনার পরিষেবা শেয়ার করতে Twitter এবং Facebook-এর জন্য লিঙ্ক যোগ করতে পারেন:

<a href="https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Facebook" target="_blank" >Share on Facebook</a>
<a href="https://twitter.com/intent/tweet/?text=My%20cool%20service!&amp;url=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Twitter" target="_blank">Share on Twitter</a>

মনে রাখবেন যে Facebook শেয়ার করার জন্য একটি URL নির্দিষ্ট করার অনুমতি দেয় এবং টুইটার একটি URL এবং কিছু পাঠ্য নির্দিষ্ট করার অনুমতি দেয়।

একটি ভিডিও এমবেড করার সময়

আপনি যখন ভিডিও-হোস্টিং সাইটগুলি থেকে ভিডিওগুলি এম্বেড করছেন, তখন এম্বেডিং কোডে গোপনীয়তা-সংরক্ষণের বিকল্পগুলি সন্ধান করুন৷ উদাহরণ স্বরূপ, YouTube-এর জন্য, এম্বেড করা পৃষ্ঠা দেখার ব্যবহারকারীদের উপর ট্র্যাকিং কুকিজ রাখা এড়াতে youtube.com এম্বেড URL-এ www.youtube-nocookie.com দিয়ে প্রতিস্থাপন করুন। YouTube থেকে শেয়ার/এম্বেড লিঙ্ক তৈরি করার সময় আপনি "গোপনীয়তা-বর্ধিত মোড সক্ষম করুন" চেক করতে পারেন৷ এটি তৃতীয় পক্ষের দ্বারা প্রদত্ত আরও ব্যবহারকারী-প্রতিরক্ষামূলক মোড ব্যবহার করার একটি ভাল উদাহরণ৷ ( https://support.google.com/youtube/answer/171780 এটিকে আরও বিশদে বর্ণনা করে, এবং বিশেষভাবে YouTube-এর জন্য অন্যান্য এম্বেডিং বিকল্পগুলি।)

অন্যান্য ভিডিও সাইটগুলিতে এই বিষয়ে কম বিকল্প রয়েছে: TikTok, উদাহরণস্বরূপ, এই লেখার সময় ট্র্যাক না করে ভিডিও এম্বেড করার উপায় নেই। ভিডিওগুলি নিজে হোস্ট করা সম্ভব (এটি একটি বিকল্প ব্যবহার করছে), তবে এটি অনেক বেশি কাজ হতে পারে, বিশেষত অনেকগুলি ডিভাইস সমর্থন করার জন্য।

পূর্বে আলোচনা করা ইন্টারেক্টিভ উইজেটগুলির মতো, প্রদান করা ওয়েবসাইটের লিঙ্ক দিয়ে একটি এমবেডেড ভিডিও প্রতিস্থাপন করা প্রায়ই সম্ভব। এটি কম ইন্টারেক্টিভ কারণ ভিডিওটি ইনলাইনে চলবে না, তবে এটি ব্যবহারকারীর সাথে দেখতে হবে কিনা তার পছন্দকে ছেড়ে দেয়৷ এটি "ফেসেড প্যাটার্ন" এর একটি উদাহরণ হিসাবে ব্যবহার করা যেতে পারে, এটিকে ট্রিগার করার জন্য ব্যবহারকারীর ক্রিয়াকলাপের প্রয়োজন হয় এমন কিছু দিয়ে গতিশীলভাবে ইন্টারেক্টিভ সামগ্রী প্রতিস্থাপনের নাম। একটি এম্বেড করা TikTok ভিডিওকে TikTok ভিডিও পৃষ্ঠার একটি সাধারণ লিঙ্ক দিয়ে প্রতিস্থাপিত করা যেতে পারে, তবে আরও কিছু কাজ করে ভিডিওটির জন্য একটি থাম্বনেইল পুনরুদ্ধার করা এবং প্রদর্শন করা এবং এটি একটি লিঙ্ক করা সম্ভব। এমনকি যদি নির্বাচিত ভিডিও প্রদানকারী ট্র্যাকিং ছাড়াই ভিডিওগুলি এম্বেড করার একটি সহজ উপায় সমর্থন না করে, তবে অনেক ভিডিও হোস্ট oEmbed সমর্থন করে, একটি API যা, একটি ভিডিও বা এমবেড করা সামগ্রীর লিঙ্ক দেওয়া হলে, একটি থাম্বনেইল সহ এটির জন্য প্রোগ্রাম্যাটিক বিশদ প্রদান করবে এবং শিরোনাম। TikTok oEmbed সমর্থন করে (বিশদ বিবরণের জন্য https://developers.tiktok.com/doc/embed-videos দেখুন), যার অর্থ আপনি (ম্যানুয়ালি বা প্রোগ্রাম্যাটিকভাবে) একটি TikTok ভিডিও https://www.tiktok.com/@scout2015/video/6718335390845095173 এর লিঙ্ক চালু করতে পারেন। https://www.tiktok.com/@scout2015/video/6718335390845095173 JSON মেটাডেটাতে সেই ভিডিওটির সাথে https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173 এবং reevem3 প্রদর্শন ওয়ার্ডপ্রেস প্রায়ই এম্বেড করা বিষয়বস্তুর জন্য oEmbed' তথ্যের অনুরোধ করতে এটি ব্যবহার করে, উদাহরণস্বরূপ। আপনি একটি "ফেসেড" দেখানোর জন্য এই প্রোগ্রামটিকে ব্যবহার করতে পারেন যা ইন্টারেক্টিভ দেখায় এবং ব্যবহারকারী যখন এটিতে ক্লিক করতে পছন্দ করে তখন একটি ইন্টারেক্টিভ ভিডিও এম্বেড বা লিঙ্ক করতে স্যুইচ করে৷

বিশ্লেষণ স্ক্রিপ্ট এম্বেড করার সময়

Analytics আপনার ব্যবহারকারীদের সম্পর্কে তথ্য সংগ্রহ করার জন্য ডিজাইন করা হয়েছে যাতে এটি বিশ্লেষণ করা যায়: এটির জন্য এটি। অ্যানালিটিক্স সিস্টেমগুলি মূলত অ্যাক্সেস এবং ব্যবহারকারীদের সম্পর্কে ডেটা সংগ্রহ এবং প্রদর্শনের পরিষেবা, যা বাস্তবায়নের সহজতার জন্য গুগল অ্যানালিটিক্সের মতো তৃতীয় পক্ষের সার্ভারে করা হয়। এছাড়াও স্ব-হোস্টেড অ্যানালিটিক্স সিস্টেম রয়েছে যেমন https://matomo.org/ , যদিও এটি এর জন্য তৃতীয় পক্ষের সমাধান ব্যবহার করার চেয়ে বেশি কাজ করে। আপনার নিজস্ব অবকাঠামোতে এই ধরনের একটি সিস্টেম চালানো আপনাকে ডেটা সংগ্রহ কমাতে সাহায্য করে, যদিও, এটি আপনার নিজস্ব ইকোসিস্টেম ছেড়ে যায় না। অন্যদিকে, সেই ডেটা ম্যানেজ করা, এটি অপসারণ করা এবং এর জন্য নীতি নির্ধারণ করা আপনার দায়িত্ব হয়ে যায়। ক্রস-সাইট ট্র্যাকিং নিয়ে বেশিরভাগ উদ্বেগ আসে যখন এটি গোপনে এবং গোপনে করা হয়, বা এমন কোনও পরিষেবা ব্যবহার করার পার্শ্ব-প্রতিক্রিয়া হিসাবে যার মধ্যে ডেটা সংগ্রহের মোটেই প্রয়োজন নেই। সাইটের মালিকদের তাদের ব্যবহারকারীদের সম্পর্কে অবহিত করার জন্য বিশ্লেষণ সফ্টওয়্যারটি প্রকাশ্যে ডেটা সংগ্রহ করার জন্য ডিজাইন করা হয়েছে।

ঐতিহাসিকভাবে, একটি দৈত্য মাছ ধরার জালের মতো, সমস্ত কিছু সম্পর্কে আপনি যা করতে পারেন সমস্ত ডেটা সংগ্রহ করার এবং তারপরে আকর্ষণীয় নিদর্শনগুলির জন্য পরে এটি বিশ্লেষণ করার একটি পদ্ধতি রয়েছে। এই মানসিকতা, বৃহৎ অংশে, ডেটা সংগ্রহের বিষয়ে অস্বস্তি এবং অস্থিরতার অনুভূতি তৈরি করেছে যা এই কোর্সের 1 অংশে আলোচনা করা হয়েছিল। এখন, অনেক সাইট প্রথমে কোন প্রশ্ন জিজ্ঞাসা করতে হবে তা নির্ধারণ করে এবং তারপর সেই প্রশ্নের উত্তর দেওয়ার জন্য নির্দিষ্ট এবং সীমিত ডেটা সংগ্রহ করে।

যদি কিছু তৃতীয় পক্ষের পরিষেবা আপনার সাইট এবং অন্যান্য সাইট দ্বারা ব্যবহার করা হয়, এবং এটি আপনার সাইটে তাদের জাভাস্ক্রিপ্ট সহ আপনার দ্বারা কাজ করে, এবং এটি প্রতিটি ব্যবহারকারীর জন্য কুকি সেট করে, তাহলে এটি বিবেচনা করা গুরুত্বপূর্ণ যে তারা অযাচিত ক্রস-সাইট করতে পারে স্বীকৃতি; যে, সাইট জুড়ে আপনার ব্যবহারকারীদের ট্র্যাকিং. কিছু হতে পারে এবং কিছু নাও হতে পারে, কিন্তু এখানে গোপনীয়তা-সুরক্ষামূলক অবস্থানটি অনুমান করা হয় যে এই ধরনের তৃতীয় পক্ষের পরিষেবা আসলে ক্রস-সাইট ট্র্যাকিং করছে যদি না আপনার অন্যথায় চিন্তা করার বা জানার উপযুক্ত কারণ থাকে। এই ধরনের পরিষেবাগুলি এড়ানোর জন্য এটি নিজেই একটি কারণ নয়, তবে সেগুলি ব্যবহার করার ট্রেড-অফ সম্পর্কে আপনার মূল্যায়নে এটি বিবেচনা করার মতো বিষয়।

অ্যানালিটিক্সে ট্রেড-অফ শুধুমাত্র এটি ব্যবহার করবেন কিনা তা বেছে নেওয়ার জন্য ব্যবহৃত হত: সমস্ত ডেটা সংগ্রহ করুন এবং অন্তর্দৃষ্টি এবং পরিকল্পনার বিনিময়ে গোপনীয়তার সাথে আপস করুন, অথবা সম্পূর্ণরূপে অন্তর্দৃষ্টি ছেড়ে দিন। যাইহোক, এটি আর হয় না, এবং প্রায়শই এই দুটি চরমের মধ্যে একটি মধ্যম স্থল খুঁজে পাওয়া যায়। সংগৃহীত ডেটা সীমিত করতে এবং এর স্টোরেজের পরিমাণ এবং সময়কাল কমাতে কনফিগারেশন বিকল্পগুলির জন্য আপনার বিশ্লেষণ প্রদানকারীকে পরীক্ষা করুন। যেহেতু আপনার পূর্বে বর্ণিত প্রযুক্তিগত নিরীক্ষণের রেকর্ড রয়েছে, তাই এই কনফিগারেশনগুলি পরিবর্তন করা আসলে সংগৃহীত ডেটার পরিমাণ হ্রাস করে তা নিশ্চিত করতে আপনি সেই নিরীক্ষণের প্রাসঙ্গিক বিভাগগুলি পুনরায় চালাতে পারেন। আপনি যদি কোনও বিদ্যমান সাইটে এই রূপান্তরটি তৈরি করে থাকেন তবে এটি আপনাকে কিছু পরিমাণ নির্ধারণযোগ্য ব্যবস্থা দিতে পারে যা আপনার ব্যবহারকারীদের জন্য লেখা যেতে পারে। উদাহরণস্বরূপ, গুগল অ্যানালিটিক্সে বেশ কয়েকটি অপ্ট-ইন (তাই ডিফল্টরূপে বন্ধ) গোপনীয়তা বৈশিষ্ট্য রয়েছে, যার মধ্যে অনেকগুলি স্থানীয় ডেটা সুরক্ষা আইন মেনে চলার জন্য সহায়ক হতে পারে। গুগল অ্যানালিটিক্স সেটআপ করার সময় বিবেচনা করার জন্য কিছু বিকল্পগুলির মধ্যে রয়েছে সংগৃহীত ডেটা (অ্যাডমিন> ট্র্যাকিং তথ্য> ডেটা রিটেনশন) 26-মাসের ডিফল্টর চেয়ে কম এবং আংশিক আইপি নাম প্রকাশের মতো আরও কিছু প্রযুক্তিগত সমাধান সক্ষম করা ( এইচটিটিপিএস দেখুন : //support.google.com/analytics/answer/9019185 আরও বিশদ জন্য)।

গোপনীয়তা-সংরক্ষণের উপায়ে তৃতীয় পক্ষগুলি ব্যবহার করা

এখনও অবধি, আমরা আপনার অ্যাপ্লিকেশনটির নকশা পর্বের সময় তৃতীয় পক্ষ থেকে কীভাবে আপনার ব্যবহারকারীদের রক্ষা করতে পারি তা নিয়ে আলোচনা করেছি, যখন আপনি সেই অ্যাপ্লিকেশনটি কী করবেন তা পরিকল্পনা করছেন। কোনও নির্দিষ্ট তৃতীয় পক্ষকে মোটেও ব্যবহার না করার সিদ্ধান্ত নেওয়া এই পরিকল্পনার অংশ এবং আপনার ব্যবহারগুলি নিরীক্ষণও এই বিভাগে আসে: এটি আপনার গোপনীয়তার অবস্থান সম্পর্কে সিদ্ধান্ত নেওয়ার বিষয়ে। যাইহোক, এই সিদ্ধান্তগুলি সহজাতভাবে খুব দানাদার নয়; একটি নির্দিষ্ট তৃতীয় পক্ষ ব্যবহার করা বা না বাছাই করা নির্বাচন করা একটি সংক্ষিপ্ত সিদ্ধান্ত নয়। এটি সম্ভবত অনেক বেশি যে আপনি এর মধ্যে কিছু চাইবেন: একটি নির্দিষ্ট তৃতীয় পক্ষের অফারটি ব্যবহার করার প্রয়োজন বা পরিকল্পনা করা তবে কোনও গোপনীয়তা-অগত্যা প্রবণতা হ্রাস করুন (ইচ্ছাকৃত বা দুর্ঘটনাজনিত হোক)। এটি "বিল্ড টাইম" এ ব্যবহারকারীদের সুরক্ষার কাজ: আপনি যে প্রত্যাশা করেননি তা হ্রাস করার জন্য সেফগার্ড যুক্ত করা। এগুলি সমস্তই নতুন এইচটিটিপি শিরোনাম যা আপনি পৃষ্ঠাগুলি পরিবেশন করার সময় সরবরাহ করতে পারেন এবং যা ব্যবহারকারী এজেন্টকে নির্দিষ্ট গোপনীয়তা বা সুরক্ষা অবস্থান নেওয়ার নির্দেশ বা আদেশ দেবে।

রেফারার-নীতি

করবেন

আপনি যখন তাদের সাথে লিঙ্ক করেন বা যখন তারা কোনও পৃষ্ঠায় সাবরেসোর্স হিসাবে লোড হয় তখন অন্য সাইটগুলিকে রেফারার শিরোনাম গ্রহণ থেকে বিরত রাখতে strict-origin-when-cross-origin বা noreferrer নীতি নির্ধারণ করুন:

index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />

বা সার্ভার-সাইড, উদাহরণস্বরূপ এক্সপ্রেসে:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

যদি প্রয়োজন হয় তবে নির্দিষ্ট উপাদান বা অনুরোধগুলিতে একটি লক্ষ্যের নীতি সেট করুন।

কেন এটি ব্যবহারকারীর গোপনীয়তা রক্ষা করে

ডিফল্টরূপে, প্রতিটি এইচটিটিপি অনুরোধ করে ব্রাউজারটি একটি Referer শিরোনামে পাস করে যা অনুরোধটি শুরু করার পৃষ্ঠার ইউআরএল থাকে, কোনও লিঙ্ক, এম্বেড থাকা চিত্র বা স্ক্রিপ্ট কিনা। এটি একটি গোপনীয়তার সমস্যা হতে পারে কারণ ইউআরএলগুলিতে ব্যক্তিগত তথ্য থাকতে পারে এবং তৃতীয় পক্ষের কাছে সেই ইউআরএলগুলি পাওয়া যায় সেই ব্যক্তিগত তথ্য তাদের কাছে পাস করে। ওয়েব.ডিইভ প্রাইভেট ডেটাযুক্ত ইউআরএলগুলির কয়েকটি উদাহরণ তালিকাভুক্ত করে - এটি জেনে যে কোনও ব্যবহারকারী আপনার সাইটে https://social.example.com/user/me@example.com থেকে এসেছেন তা আপনাকে জানায় যে সেই ব্যবহারকারীটি কে, এটি একটি নির্দিষ্ট ফাঁস যা . এমনকি এমন একটি ইউআরএল যা নিজেই ব্যক্তিগত তথ্য প্রকাশ করে না তা প্রকাশ করে যে এই নির্দিষ্ট ব্যবহারকারী (আপনি যদি জানেন তবে তারা যদি লগ ইন করেন তবে) অন্য সাইট থেকে এখানে এসেছিলেন এবং এটি প্রকাশ করে যে এই ব্যবহারকারী সেই অন্য সাইটটি পরিদর্শন করেছেন। এটি নিজেই এমন তথ্যের এক্সপোজার যা আপনার ব্যবহারকারীর ব্রাউজিংয়ের ইতিহাস সম্পর্কে আপনার জানা উচিত নয়।

একটি Referrer-Policy শিরোনাম সরবরাহ করা (সঠিক বানান সহ!) আপনাকে এটিকে পরিবর্তন করতে দেয়, যাতে কিছু বা রেফারিং ইউআরএল কোনওটিই পাস হয় না। এমডিএন সম্পূর্ণ বিশদ তালিকাভুক্ত করে তবে বেশিরভাগ ব্রাউজারগুলি এখন ডিফল্টরূপে strict-origin-when-cross-origin একটি অনুমানযোগ্য মান গ্রহণ করেছে, যার অর্থ রেফারার ইউআরএল এখন কেবল তৃতীয় পক্ষগুলিতে কেবল একটি উত্স হিসাবে পাস করা হয়েছে ( https://web.dev বরং https://web.dev/learn/privacy )। আপনার কিছু না করে এটি একটি দরকারী গোপনীয়তা সুরক্ষা। তবে আপনি Referrer-Policy: same-origin (বা Referrer-Policy: no-referrer )। (এটি গোপনীয়তা-বনাম-ইউটিলিটি ব্যালেন্সের একটি দুর্দান্ত উদাহরণ; নতুন ডিফল্টটি আগের চেয়ে অনেক বেশি গোপনীয়তা-সংরক্ষণ, তবে এটি এখনও আপনার পছন্দের তৃতীয় পক্ষগুলিকে উচ্চ স্তরের তথ্য দেয় যেমন আপনার বিশ্লেষণ সরবরাহকারী))

এই শিরোনামটি স্পষ্টভাবে নির্দিষ্ট করে দেওয়ার জন্য এটিও দরকারী কারণ ব্রাউজার ডিফল্টগুলির উপর নির্ভর করার পরিবর্তে আপনি নীতিটি ঠিক কী তা জানেন । আপনি যদি শিরোনামগুলি সেট করতে সক্ষম না হন তবে <head> হেড>: <meta name="referrer" content="same-origin"> এ একটি মেটা উপাদান ব্যবহার করে পুরো এইচটিএমএল পৃষ্ঠার জন্য একটি রেফারার নীতি সেট করা সম্ভব; এবং যদি নির্দিষ্ট তৃতীয় পক্ষের বিষয়ে উদ্বিগ্ন হন তবে <script> , <a> , বা <iframe> : <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer"> মতো পৃথক উপাদানগুলিতে referrerpolicy বৈশিষ্ট্য সেট করাও সম্ভব <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">

বিষয়বস্তু-নিরাপত্তা-নীতি

Content-Security-Policy শিরোনাম, প্রায়শই "সিএসপি" হিসাবে উল্লেখ করা হয়, যেখানে বাহ্যিক সংস্থানগুলি লোড করা যায় তা নির্দেশ করে। এটি প্রাথমিকভাবে ক্রস-সাইট স্ক্রিপ্টিং আক্রমণ এবং স্ক্রিপ্ট ইনজেকশন প্রতিরোধের মাধ্যমে সুরক্ষার উদ্দেশ্যে ব্যবহৃত হয়, তবে আপনার নিয়মিত নিরীক্ষণের পাশাপাশি ব্যবহৃত হলে এটি আপনার নির্বাচিত তৃতীয় পক্ষগুলি যেখানে ডেটা পাস করতে পারে সেখানে সীমাবদ্ধ করতে পারে।

এটি সম্ভবত একটি কম-গ্রেট ব্যবহারকারীর অভিজ্ঞতা; যদি আপনার তৃতীয় পক্ষের কোনও স্ক্রিপ্টগুলি আপনার তালিকার নয় এমন কোনও উত্স থেকে নির্ভরতা লোড করা শুরু করে, তবে সেই অনুরোধটি অবরুদ্ধ করা হবে, স্ক্রিপ্টটি ব্যর্থ হবে এবং আপনার অ্যাপ্লিকেশনটি এটির সাথে ব্যর্থ হতে পারে (বা কমপক্ষে তার জাভাস্ক্রিপ্ট-ব্যর্থতায় হ্রাস করা যেতে পারে ফ্যালব্যাক সংস্করণ)। এটি কার্যকর যখন সিএসপি সুরক্ষার জন্য প্রয়োগ করা হয়, যা এর স্বাভাবিক উদ্দেশ্য: ক্রস-সাইট স্ক্রিপ্টিং সমস্যাগুলির বিরুদ্ধে রক্ষা করা (এবং এটি করার জন্য, একটি কঠোর সিএসপি ব্যবহার করুন)। আপনার পৃষ্ঠাটি যে সমস্ত ইনলাইন স্ক্রিপ্টগুলি ব্যবহার করে তা জানার পরে আপনি সেগুলির একটি তালিকা তৈরি করতে পারেন, একটি হ্যাশ মান গণনা করতে পারেন বা প্রতিটিটির জন্য একটি এলোমেলো মান (একটি "ননস" বলা হয়) যুক্ত করতে পারেন এবং তারপরে আপনার সামগ্রী সুরক্ষায় হ্যাশের তালিকা যুক্ত করতে পারেন নীতি. এটি তালিকায় নেই এমন কোনও স্ক্রিপ্টকে লোড করা থেকে বিরত রাখবে। এটি সাইটের জন্য উত্পাদন প্রক্রিয়াতে বেক করা দরকার: আপনার পৃষ্ঠাগুলিতে স্ক্রিপ্টগুলিকে ননস অন্তর্ভুক্ত করা বা বিল্ডের অংশ হিসাবে একটি হ্যাশ গণনা করা দরকার। সমস্ত বিবরণের জন্য স্ট্রাইম-সিএসপিতে নিবন্ধটি দেখুন।

ভাগ্যক্রমে, ব্রাউজারগুলি একটি সম্পর্কিত শিরোনাম, Content-Security-Policy-Report-Only সমর্থন করে। যদি এই শিরোনামটি সরবরাহ করা হয়, তবে সরবরাহিত নীতি লঙ্ঘনকারী অনুরোধগুলি অবরুদ্ধ করা হবে না, তবে একটি জেএসওএন রিপোর্ট সরবরাহ করা ইউআরএলে প্রেরণ করা হবে। এই জাতীয় শিরোনামটি দেখতে এরকম দেখতে পারে: Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/ , এবং যদি ব্রাউজারটি 3p.example.com ব্যতীত অন্য কোথাও থেকে কোনও স্ক্রিপ্ট লোড করে, সেই অনুরোধটি সফল হবে তবে সরবরাহিত report-uri একটি প্রতিবেদন প্রেরণ করা হবে। সাধারণত এটি কোনও নীতি বাস্তবায়নের আগে পরীক্ষা -নিরীক্ষার জন্য ব্যবহৃত হয় তবে এখানে একটি দরকারী ধারণা হ'ল এটিকে "চলমান নিরীক্ষণ" পরিচালনার উপায় হিসাবে ব্যবহার করা। আপনার নিয়মিত অডিট যেমন পূর্বে বর্ণিত হয়েছে, আপনি সিএসপি রিপোর্টিং চালু করতে পারেন যে কোনও অপ্রত্যাশিত ডোমেন উপস্থিত হয় কিনা তা দেখতে, যার অর্থ এই হতে পারে যে আপনার তৃতীয় পক্ষের সংস্থানগুলি তাদের নিজস্ব তৃতীয় পক্ষের সংস্থানগুলি লোড করছে এবং যা আপনাকে বিবেচনা এবং মূল্যায়ন করতে হবে। (এটি আপনার সুরক্ষার সীমানা পেরিয়ে যাওয়ার কিছু ক্রস-সাইট স্ক্রিপ্টিং শোষণের চিহ্নও হতে পারে, অবশ্যই এটি সম্পর্কে জানাও গুরুত্বপূর্ণ!)

Content-Security-Policy ব্যবহারের জন্য একটি জটিল এবং ফিডলি এপিআই। এটি জানা যায়, এবং সিএসপির "পরবর্তী প্রজন্ম" তৈরি করার কাজ চলছে যা একই লক্ষ্যগুলি পূরণ করবে তবে ব্যবহার করা যথেষ্ট জটিল হবে না his এটি এখনও প্রস্তুত নয়, তবে আপনি যদি দেখতে চান তবে কোথায় আপনি দেখতে চান এটি শিরোনাম করছে (বা জড়িত হতে এবং এর নকশায় সহায়তা করতে!) তারপরে বিশদগুলির জন্য https://github.com/wicg/csp-next দেখুন।

করবেন

পরিবেশন করা পৃষ্ঠাগুলিতে এই এইচটিটিপি শিরোনাম যুক্ত করুন: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control । যখন জসন সেই ইউআরএলে পোস্ট করা হয়, এটি সংরক্ষণ করুন। অন্যদের দ্বারা পরিদর্শন করার সময় আপনার ওয়েবসাইটের অনুরোধ করে এমন তৃতীয় পক্ষের ডোমেনগুলির সংগ্রহ পেতে সেই সঞ্চিত ডেটা পর্যালোচনা করুন। সেই তালিকাটি কখন পরিবর্তিত হয় তা দেখার জন্য আপনার প্রত্যাশিত ডোমেনগুলি তালিকাভুক্ত করতে Content-Security-Policy-Report-Only শিরোনাম আপডেট করুন:

Content-Security-Policy-Report-Only: default-src 'self' https://expected1.example.com https://expected2.example.com ; report-uri https://a-url-you-control

কেন

এটি চলমান ফ্যাশনে আপনার প্রযুক্তিগত নিরীক্ষণের অংশ গঠন করে। আপনি যে প্রাথমিক প্রযুক্তিগত নিরীক্ষণ করেছেন তা আপনাকে তৃতীয় পক্ষের একটি তালিকা দেবে যা আপনার সাইটটি ব্যবহার করে বা ব্যবহারকারীর ডেটা পাস করে। এই শিরোনামটি তখন পৃষ্ঠার অনুরোধগুলির কারণ হবে যে কোন তৃতীয় পক্ষের সাথে এখন যোগাযোগ করা হচ্ছে এবং আপনি সময়ের সাথে সাথে পরিবর্তনগুলি ট্র্যাক করতে পারেন। এটি আপনাকে কেবল আপনার বিদ্যমান তৃতীয় পক্ষের পরিবর্তনের জন্য সতর্ক করে দেয় না, তবে নতুন যুক্ত তৃতীয় পক্ষগুলিকেও পতাকাঙ্কিত করবে যা প্রযুক্তিগত নিরীক্ষায় যুক্ত করা হয়নি। আপনার প্রত্যাশিত ডোমেনগুলি সম্পর্কে প্রতিবেদন বন্ধ করার জন্য শিরোনামটি আপডেট করা গুরুত্বপূর্ণ, তবে সময়ে সময়ে ম্যানুয়াল প্রযুক্তিগত নিরীক্ষণের পুনরাবৃত্তি করাও গুরুত্বপূর্ণ (কারণ Content-Security-Policy পদ্ধতির ডেটা কী পাস হয় তা পতাকাঙ্কিত করে না, কেবলমাত্র একটি অনুরোধ রয়েছে তৈরি করা হয়েছে।)

মনে রাখবেন যে এটি প্রতিবার পরিবেশন করা পৃষ্ঠাগুলিতে বা প্রতিটি পৃষ্ঠায় যুক্ত করার দরকার নেই। কতগুলি পৃষ্ঠার প্রতিক্রিয়া শিরোনামটি পান তা টিউন করুন যাতে আপনি প্রতিবেদনের একটি প্রতিনিধি নমুনা পান যা পরিমাণে অপ্রতিরোধ্য নয়।

অনুমতি নীতি

Permissions-Policy শিরোনাম (যা Feature-Policy নামের অধীনে প্রবর্তিত হয়েছিল) Content-Security-Policy ধারণার ক্ষেত্রে একই রকম, তবে এটি শক্তিশালী ব্রাউজার বৈশিষ্ট্যগুলিতে অ্যাক্সেসকে সীমাবদ্ধ করে। উদাহরণস্বরূপ, অ্যাক্সিলোমিটার, ক্যামেরা বা ইউএসবি ডিভাইসগুলির মতো ডিভাইস হার্ডওয়্যার ব্যবহারকে সীমাবদ্ধ করা বা পুরো-স্ক্রিনে যাওয়ার অনুমতি বা সিঙ্ক্রোনাস XMLHTTPRequest ব্যবহার করার অনুমতি যেমন সীমাবদ্ধ করা সম্ভব। এই বিধিনিষেধগুলি একটি শীর্ষ-স্তরের পৃষ্ঠায় প্রয়োগ করা যেতে পারে (এই বৈশিষ্ট্যগুলি ব্যবহার করার চেষ্টা করা থেকে লোড স্ক্রিপ্টগুলি এড়াতে) বা আইফ্রেমের মাধ্যমে লোড করা সাবফ্রেমেড পৃষ্ঠাগুলিতে। এপিআই ব্যবহারের এই বিধিনিষেধটি সত্যিই ব্রাউজার ফিঙ্গারপ্রিন্টিং সম্পর্কে নয়; এটি অনুপ্রবেশকারী জিনিসগুলি (যেমন শক্তিশালী এপিআই ব্যবহার করা, অনুমতিগুলি পপ আপ করা উইন্ডোজ ইত্যাদি) থেকে তৃতীয় পক্ষকে অস্বীকার করার বিষয়ে। এটি লক্ষ্য গোপনীয়তার হুমকি মডেল দ্বারা "অনুপ্রবেশ" হিসাবে সংজ্ঞায়িত করা হয়।

একটি Permissions-Policy শিরোনাম (বৈশিষ্ট্য, অনুমোদিত উত্স) জোড়গুলির একটি তালিকা হিসাবে নির্দিষ্ট করা হয়, সুতরাং:

Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*

এই উদাহরণটি এই পৃষ্ঠাটি ("স্ব") এবং <iframe> এস থেকে অরিজিন example.com থেকে জাভাস্ক্রিপ্ট থেকে navigator.geolocation এপিআই ব্যবহার করার অনুমতি দেয়; এটি এই পৃষ্ঠাটি এবং সমস্ত সাবফ্রেমগুলি পূর্ণ স্ক্রিন এপিআই ব্যবহার করতে দেয় এবং এটি কোনও পৃষ্ঠা নিষিদ্ধ করে, এই পৃষ্ঠাটি অন্তর্ভুক্ত করে ভিডিও তথ্য পড়ার জন্য ক্যামেরা ব্যবহার করা থেকে। এখানে আরও অনেক বিশদ এবং সম্ভাব্য উদাহরণগুলির একটি তালিকা রয়েছে।

অনুমতিগুলির দ্বারা পরিচালিত বৈশিষ্ট্যগুলির তালিকাগুলি-পলিসি শিরোনামটি বড় এবং এটি প্রবাহিত হতে পারে। বর্তমানে তালিকাটি https://github.com/w3c/webapsec-permissions-policy/blob/main/features.md এ বজায় রাখা হয়েছে।

করবেন

ব্রাউজারগুলি যা Permissions-Policy ডিফল্টরূপে সাবফ্রেমগুলিতে শক্তিশালী বৈশিষ্ট্যগুলি অস্বীকার করে এবং সেগুলি সক্ষম করতে আপনাকে কাজ করতে হবে! এই পদ্ধতির ডিফল্টরূপে ব্যক্তিগত। যদি আপনি দেখতে পান যে আপনার সাইটে সাবফ্রেমগুলির এই অনুমতিগুলির প্রয়োজন হয় তবে আপনি সেগুলি নির্বাচন করে যুক্ত করতে পারেন। যাইহোক, ডিফল্টরূপে মূল পৃষ্ঠায় কোনও অনুমতি নীতি প্রয়োগ করা হয়নি, এবং তাই স্ক্রিপ্টগুলি (তৃতীয় পক্ষের স্ক্রিপ্টগুলি সহ) যা মূল পৃষ্ঠা দ্বারা লোড করা হয় এই বৈশিষ্ট্যগুলি ব্যবহার করার চেষ্টা করা থেকে সীমাবদ্ধ নয়। এই কারণে, ডিফল্টরূপে সমস্ত পৃষ্ঠাগুলিতে একটি সীমাবদ্ধ Permissions-Policy প্রয়োগ করা কার্যকর এবং তারপরে ধীরে ধীরে আপনার পৃষ্ঠাগুলির প্রয়োজনীয় বৈশিষ্ট্যগুলিতে ফিরে যুক্ত করুন।

Permissions-Policy প্রভাবিত করে এমন শক্তিশালী বৈশিষ্ট্যগুলির উদাহরণগুলির মধ্যে রয়েছে ব্যবহারকারীর অবস্থানের জন্য অনুরোধ করা, সেন্সরগুলিতে অ্যাক্সেস (অ্যাক্সিলোমিটার, জাইরোস্কোপ এবং চৌম্বকীয়তা সহ), ফুলস্ক্রিনে যাওয়ার অনুমতি এবং ব্যবহারকারীর ক্যামেরা এবং মাইক্রোফোনে অ্যাক্সেসের জন্য অনুরোধ করা অন্তর্ভুক্ত। বৈশিষ্ট্যগুলির (পরিবর্তিত) সম্পূর্ণ তালিকাটি উপরে লিঙ্কযুক্ত।

দুর্ভাগ্যক্রমে, ডিফল্টরূপে সমস্ত বৈশিষ্ট্যগুলি অবরুদ্ধ করা এবং তারপরে নির্বাচন করে পুনরায় উত্সাহ দেওয়ার জন্য শিরোনামের সমস্ত বৈশিষ্ট্য তালিকাভুক্ত করা প্রয়োজন, যা বরং অকার্যকর বোধ করতে পারে। তবুও, এই জাতীয় Permissions-Policy শিরোনাম শুরু করার জন্য একটি ভাল জায়গা। অনুমতিগুলি স্পলিসি। com/ এ জাতীয় শিরোনাম তৈরি করার জন্য একটি সুবিধাজনকভাবে ক্লিকযোগ্য জেনারেটর রয়েছে: এটি একটি শিরোনাম তৈরি করতে ব্যবহার করে যা এতে সমস্ত বৈশিষ্ট্যগুলি অক্ষম করে:

Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(),
display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(),
fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(),
payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()

ওয়েব ব্রাউজারগুলিতে অন্তর্নির্মিত গোপনীয়তা বৈশিষ্ট্যগুলি বুঝতে

"বিল্ড টাইম" এবং "ডিজাইনের সময়" সুরক্ষা ছাড়াও, "রান টাইম" এ ঘটে এমন গোপনীয়তা সুরক্ষাও রয়েছে: এটি ব্যবহারকারীদের সুরক্ষার জন্য ব্রাউজারগুলিতে প্রয়োগ করা গোপনীয়তা বৈশিষ্ট্য। এগুলি এমন বৈশিষ্ট্য নয় যা আপনি সরাসরি কোনও সাইট বিকাশকারী হিসাবে নিয়ন্ত্রণ করতে বা ট্যাপ করতে পারেন - তারা পণ্য বৈশিষ্ট্যগুলি - তবে এগুলি এমন বৈশিষ্ট্য যা আপনার সচেতন হওয়া উচিত, কারণ আপনার সাইটগুলি ব্রাউজারগুলিতে এই পণ্য সিদ্ধান্তের দ্বারা প্রভাবিত হতে পারে। এই ব্রাউজার সুরক্ষাগুলি কীভাবে আপনার সাইটে প্রভাব ফেলতে পারে তার উদাহরণ দেওয়ার জন্য, যদি আপনার ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্ট থাকে যা পৃষ্ঠা সেটআপের সাথে চালিয়ে যাওয়ার আগে লোড হওয়ার তৃতীয় পক্ষের নির্ভরতার জন্য অপেক্ষা করে এবং তৃতীয় পক্ষের নির্ভরতা কখনই লোড হয় না, তারপরে আপনার পৃষ্ঠা সেটআপটি কখনই সম্পূর্ণ হতে পারে না এবং তাই ব্যবহারকারীকে অর্ধ-লোড পৃষ্ঠার সাথে উপস্থাপন করা হয়।

এর মধ্যে সাফারি (এবং অন্তর্নিহিত ওয়েবকিট ইঞ্জিন) বুদ্ধিমান ট্র্যাকিং প্রতিরোধ এবং ফায়ারফক্সে (এবং এর ইঞ্জিন, গেকো) বর্ধিত ট্র্যাকিং সুরক্ষা অন্তর্ভুক্ত রয়েছে। এগুলি সমস্ত তৃতীয় পক্ষের পক্ষে আপনার ব্যবহারকারীদের বিশদ প্রোফাইল তৈরি করা কঠিন করে তোলে।

গোপনীয়তার বৈশিষ্ট্যগুলিতে ব্রাউজার পদ্ধতির ঘন ঘন পরিবর্তিত হয় এবং এটি আপ টু ডেট থাকা গুরুত্বপূর্ণ; নিম্নলিখিত সুরক্ষার তালিকা লেখার সময় সঠিক। ব্রাউজারগুলি অন্যান্য সুরক্ষাও বাস্তবায়ন করতে পারে; এই তালিকাগুলি সম্পূর্ণ নয়। এখানে পরিবর্তনগুলি বজায় রাখার উপায়গুলির জন্য সেরা অনুশীলনের মডিউলটি দেখুন এবং আপনার প্রকল্পগুলিকে প্রভাবিত করতে পারে এমন পরিবর্তনগুলির জন্য আগত ব্রাউজার সংস্করণগুলির সাথে পরীক্ষা করতে ভুলবেন না। মনে রাখবেন যে ছদ্মবেশী/প্রাইভেট ব্রাউজিং মোডগুলি কখনও কখনও ব্রাউজারের ডিফল্ট থেকে বিভিন্ন সেটিংস প্রয়োগ করে (তৃতীয় পক্ষের কুকিজগুলি এই জাতীয় মোডগুলিতে ডিফল্টরূপে অবরুদ্ধ করা যেতে পারে, উদাহরণস্বরূপ)। অতএব, ছদ্মবেশী মোডে পরীক্ষা করা বেশিরভাগ ব্যবহারকারীর সাধারণ ব্রাউজিংয়ের অভিজ্ঞতার প্রতিফলন করতে পারে না যদি তারা ব্যক্তিগত ব্রাউজিং ব্যবহার না করে। এছাড়াও মনে রাখবেন যে বিভিন্ন পরিস্থিতিতে কুকিগুলি ব্লক করার অর্থ হতে পারে যে অন্যান্য স্টোরেজ সমাধান যেমন window.localStorage কেবল কুকিজই নয়, অবরুদ্ধ করা হয়।

ক্রোম

• তৃতীয় পক্ষের কুকিগুলি ভবিষ্যতে অবরুদ্ধ করার উদ্দেশ্যে। এই লেখার হিসাবে এগুলি ডিফল্টরূপে অবরুদ্ধ নয় (তবে এটি কোনও ব্যবহারকারী দ্বারা সক্ষম করা যেতে পারে): https://support.google.com/chrome/answer/95647 বিশদ ব্যাখ্যা করে।
• ক্রোমের গোপনীয়তা বৈশিষ্ট্যগুলি এবং বিশেষত ক্রোমের বৈশিষ্ট্যগুলি যা গুগল এবং তৃতীয় পক্ষের পরিষেবাগুলির সাথে যোগাযোগ করে, প্রাইভেস্যান্ডবক্স.কম/ এ বর্ণিত হয়েছে।

প্রান্ত

• তৃতীয় পক্ষের কুকিজগুলি ডিফল্টরূপে অবরুদ্ধ করা হয় না (তবে এটি কোনও ব্যবহারকারী দ্বারা সক্ষম করা যেতে পারে)।
• এজের ট্র্যাকিং প্রতিরোধের বৈশিষ্ট্যগুলি অযোগ্য সাইটগুলি এবং পরিচিত ক্ষতিকারক ট্র্যাকারগুলির ট্র্যাকারগুলিকে ব্লক করে ডিফল্টরূপে অবরুদ্ধ।

ফায়ারফক্স

• তৃতীয় পক্ষের কুকিজগুলি ডিফল্টরূপে অবরুদ্ধ করা হয় না (তবে এটি কোনও ব্যবহারকারী দ্বারা সক্ষম করা যেতে পারে)।
• ফায়ারফক্সের বর্ধিত ট্র্যাকিং সুরক্ষা ব্লকগুলি ডিফল্ট ট্র্যাকিং কুকিজ, ফিঙ্গারপ্রিন্টিং স্ক্রিপ্টস, ক্রিপ্টোমিনার স্ক্রিপ্ট এবং পরিচিত ট্র্যাকারদের দ্বারা। ( https://support.mozilla.org/kb/trackers- এবং-scripts-firefox-blocks- enhanced-ট্র্যাক আরও কিছু বিশদ সরবরাহ করে)।
• তৃতীয় পক্ষের কুকিগুলি সাইট-সীমাবদ্ধ, সুতরাং প্রতিটি সাইটে মূলত একটি পৃথক কুকি জার থাকে এবং সাইটগুলি জুড়ে সম্পর্কযুক্ত হতে পারে না (মোজিলা এই " মোট কুকি সুরক্ষা " বলে।

কী অবরুদ্ধ হতে পারে সে সম্পর্কে কিছুটা অন্তর্দৃষ্টি পেতে এবং ডিবাগ ইস্যুতে সহায়তা করতে, ঠিকানা বারে শিল্ড আইকনটি ক্লিক করুন বা দেখুন about:protections (ডেস্কটপে)।

সাফারি

• তৃতীয় পক্ষের কুকিগুলি ডিফল্টরূপে অবরুদ্ধ করা হয়।
• বুদ্ধিমান ট্র্যাকিং প্রতিরোধের বৈশিষ্ট্যের অংশ হিসাবে, সাফারি রেফারারকে নির্দিষ্ট পৃষ্ঠার পরিবর্তে শীর্ষ-স্তরের সাইট হতে অন্যান্য পৃষ্ঠাগুলিতে পাস করা হ্রাস করে: ( https://something.example.com/this/specific/page পরিবর্তে https://something.example.com https://something.example.com/this/specific/page )।
• ব্রাউজার localStorage ডেটা সাত দিন পরে মুছে ফেলা হয়।

( https://webkit.org/blog/10218/full-third-party-cookie-blocking- এবং-more/ এই বৈশিষ্ট্যগুলি সংক্ষিপ্তসার করে))

কী অবরুদ্ধ হতে পারে সে সম্পর্কে কিছুটা অন্তর্দৃষ্টি পেতে এবং ডিবাগ সমস্যাগুলিকে সহায়তা করতে, সাফারির বিকাশকারী মেনুতে (ডেস্কটপে) "বুদ্ধিমান ট্র্যাকিং প্রতিরোধের ডিবাগ মোড" সক্ষম করুন। (আরও তথ্যের জন্য https://webkit.org/blog/9521/inteligent-tracking-prevention-2-3/ দেখুন))

এপিআই প্রস্তাবনা

কেন আমাদের নতুন এপিআই দরকার?

ব্রাউজার পণ্যগুলিতে নতুন গোপনীয়তা-সংরক্ষণ বৈশিষ্ট্য এবং নীতিগুলি ব্যবহারকারীর গোপনীয়তা সংরক্ষণে সহায়তা করে, তারা চ্যালেঞ্জগুলি নিয়েও আসে। অনেক ওয়েব প্রযুক্তি অন্যান্য উদ্দেশ্যে ডিজাইন করা এবং ব্যবহার করা সত্ত্বেও ক্রস-সাইট ট্র্যাকিংয়ের জন্য ব্যবহারযোগ্য। উদাহরণস্বরূপ, আমরা প্রতিদিন ব্যবহার করি এমন অনেক পরিচয় ফেডারেশন সিস্টেমগুলি তৃতীয় পক্ষের কুকিজের উপর নির্ভর করে। প্রকাশকরা আজ আয়ের জন্য নির্ভর করে এমন অসংখ্য বিজ্ঞাপনের সমাধানগুলি তৃতীয় পক্ষের কুকিজের শীর্ষে নির্মিত। অনেক জালিয়াতি সনাক্তকরণ সমাধানগুলি ফিঙ্গারপ্রিন্টিংয়ের উপর নির্ভর করে। তৃতীয় পক্ষের কুকিজ এবং ফিঙ্গারপ্রিন্টিং চলে গেলে এই ব্যবহারের ক্ষেত্রে কী ঘটে?

ব্রাউজারগুলির পক্ষে ব্যবহারের ক্ষেত্রে পৃথক করা এবং অন্যের কাছ থেকে গোপনীয়তা-আভিজাত্য ব্যবহারগুলি নির্ভরযোগ্যভাবে পার্থক্য করা কঠিন এবং ত্রুটিযুক্ত হবে। এ কারণেই বেশিরভাগ বড় ব্রাউজারগুলি তৃতীয় পক্ষের কুকিজ এবং ফিঙ্গারপ্রিন্টিং অবরুদ্ধ করেছে বা এটি করার ইচ্ছা করেছে, ব্যবহারকারীর গোপনীয়তা রক্ষার জন্য।

একটি নতুন পদ্ধতির প্রয়োজন: তৃতীয় পক্ষের কুকিজ পর্যায়ক্রমে এবং ফিঙ্গারপ্রিন্টিং প্রশমিত করা হয়, বিকাশকারীদের উদ্দেশ্য-নির্মিত এপিআইগুলির প্রয়োজন যা ব্যবহারের কেসগুলি পূরণ করে (যা দূরে যায় নি) তবে এটি গোপনীয়তা-সংরক্ষণ পদ্ধতিতে ডিজাইন করা হয়েছে। লক্ষ্যটি হ'ল এপিআই ডিজাইন করা এবং তৈরি করা যা ক্রস-সাইট ট্র্যাকিংয়ের জন্য ব্যবহার করা যায় না। পূর্ববর্তী বিভাগে বর্ণিত ব্রাউজার বৈশিষ্ট্যগুলির বিপরীতে, এই প্রযুক্তিগুলি ক্রস ব্রাউজার এপিআই হওয়ার আকাঙ্ক্ষা করে।

এপিআই প্রস্তাবগুলির উদাহরণ

নিম্নলিখিত তালিকাটি বিস্তৃত নয় - এটি যা আলোচনা করা হচ্ছে তার কিছু স্বাদ।

তৃতীয় পক্ষের কুকিগুলিতে নির্মিত প্রযুক্তিগুলি প্রতিস্থাপনের জন্য এপিআই প্রস্তাবগুলির উদাহরণ:

• পরিচয় ব্যবহারের কেস: ফেডসিএম
• বিজ্ঞাপনগুলি কেসগুলি ব্যবহার করে: ব্যক্তিগত ক্লিক পরিমাপ , আন্তঃব্যবহারযোগ্য ব্যক্তিগত অ্যাট্রিবিউশন , অ্যাট্রিবিউশন রিপোর্টিং , বিষয়গুলি , ফ্লেজ , প্যারাকিট ।

প্যাসিভ ট্র্যাকিংয়ে নির্মিত প্রযুক্তিগুলি প্রতিস্থাপনের জন্য এপিআই প্রস্তাবগুলির উদাহরণ:

• জালিয়াতি সনাক্তকরণ ব্যবহার কেস: ট্রাস্ট টোকেন ।

অন্যান্য এপিআইগুলি তৃতীয় পক্ষের কুকিজ ছাড়াই ভবিষ্যতে তৈরি করতে পারে এমন অন্যান্য প্রস্তাবগুলির উদাহরণ:

• স্টোরেজ অ্যাক্সেস API

অধিকন্তু, অন্য ধরণের এপিআই প্রস্তাবটি চেষ্টা করার জন্য উত্থিত হচ্ছে এবং তাই খুব বেশি ব্রাউজার-নির্দিষ্ট গোপনীয় কভার্ট ট্র্যাকিং প্রশমিতকরণ রয়েছে। একটি উদাহরণ গোপনীয়তা বাজেট । এই বিভিন্ন ব্যবহারের ক্ষেত্রে, এপিআইগুলি যে প্রাথমিকভাবে ক্রোম দ্বারা প্রস্তাবিত হয়েছিল গোপনীয়তা স্যান্ডবক্সের ছাতার শব্দের অধীনে লাইভ।

গ্লোবাল-প্রাইভেসি-নিয়ন্ত্রণ এমন একটি শিরোনাম যা এমন কোনও সাইটের সাথে যোগাযোগ করতে চায় যা ব্যবহারকারী যে কোনও সংগৃহীত ব্যক্তিগত ডেটা অন্য সাইটের সাথে ভাগ না করা চান তা চান। এর উদ্দেশ্য ট্র্যাক না করার অনুরূপ, যা বন্ধ ছিল।

এপিআই প্রস্তাবগুলির স্থিতি

এই এপিআই প্রস্তাবগুলির বেশিরভাগটি এখনও মোতায়েন করা হয়নি, বা কেবল পতাকাগুলির পিছনে বা পরীক্ষার জন্য সীমিত পরিবেশে মোতায়েন করা হয়।

এই পাবলিক ইনকিউবেশন পর্বটি গুরুত্বপূর্ণ: ব্রাউজার বিক্রেতারা এবং বিকাশকারীরা এই এপিআইগুলি দরকারী কিনা এবং তারা আসলে যা তাদের জন্য ডিজাইন করা হয়েছে তা আসলে কী করে কিনা তা নিয়ে আলোচনা এবং অভিজ্ঞতা সংগ্রহ করে। বিকাশকারী, ব্রাউজার বিক্রেতারা এবং অন্যান্য বাস্তুতন্ত্রের অভিনেতারা এপিআইয়ের নকশায় পুনরাবৃত্তি করতে এই পর্বটি ব্যবহার করেন।

নতুন এপিআই প্রস্তাবিত হওয়ার সাথে আপ টু ডেট রাখার সেরা জায়গাটি বর্তমানে গিটহাবের প্রস্তাবগুলির গোপনীয়তা গোষ্ঠীর তালিকা ।

আপনার কি এই এপিআই ব্যবহার করা দরকার?

যদি আপনার পণ্যটি সরাসরি তৃতীয় পক্ষের কুকিজ বা ফিঙ্গারপ্রিন্টিংয়ের মতো কৌশলগুলির শীর্ষে নির্মিত হয় তবে আপনার এই নতুন এপিআইগুলির সাথে জড়িত হওয়া উচিত, তাদের সাথে পরীক্ষা করা উচিত এবং আলোচনা এবং এপিআই ডিজাইনে আপনার নিজের অভিজ্ঞতা অবদান রাখা উচিত। অন্যান্য সমস্ত ক্ষেত্রে, লেখার সময় আপনাকে এই নতুন এপিআইগুলির সমস্ত বিবরণ জানতে হবে না, তবে কী আসছে সে সম্পর্কে সচেতন হওয়া ভাল।