GhostMarket.net-এর 2009 সালের ডেটা উন্মুক্ত হওয়ার দাবি

তারিখটি শুধু বছর পর্যন্ত নির্দিষ্ট করে সংরক্ষণ করা হয়েছে। ডেটাবেসের 1 জানুয়ারি 2009 মানটি কেবল 2009 সালকে উপস্থাপনের একটি প্রযুক্তিগত পদ্ধতি; এতে দাবি করা হয় না যে ঘটনাটি 1 জানুয়ারি ঘটেছিল। অভ্যন্তরীণ মেটাডেটায় 2009-কে “ডেটা লঙ্ঘনের তারিখ” বলা হয়েছে, আর SQL এক্সপোর্টের হেডারে তৈরির সময় হিসেবে 2009 সালের জুলাই উল্লেখ আছে। ডেটাবেস ডাম্প তৈরির সময় থেকে বোঝা যেতে পারে কখন এক্সপোর্টটি তৈরি হয়েছিল, কিন্তু শুধু তা দিয়ে ডেটা উন্মুক্ত হওয়ার তারিখ প্রতিষ্ঠা করা যায় না। প্রকাশ্য মেটাডেটায় 2009 সালের উল্লেখ সত্তাটির কার্যক্রমের সময়কালকে সমর্থন করে, তবে ব্যক্তিগত ডেটা উন্মুক্ত হওয়ার ঘটনাটিকে কোনো নির্দিষ্ট দিনের সঙ্গে যুক্ত করে না। এসব কারণে breachDatePrecision হলো year, সঠিক দিনটি এখনও অজানা, এবং 1 জানুয়ারি হিসেবে উপস্থাপনের সীমাবদ্ধতা স্পষ্টভাবে জানানো হয়েছে। ভবিষ্যতে কোনো প্রাথমিক উৎস পাওয়া গেলে তার ভিত্তিতে তারিখটি আলাদাভাবে পর্যালোচনা করা যেতে পারে।

উৎসটি একটি সম্পূর্ণ 37,28,860-বাইটের 7z আর্কাইভ। এর SHA-256 পরিচয় সিল করা আছে এবং পূর্ণাঙ্গ 7z অখণ্ডতা পরীক্ষায় এটি উত্তীর্ণ হয়েছে। আর্কাইভের চারটি সাধারণ ফাইলই বের করা হয়েছে এবং প্রতিটিকে আলাদাভাবে আকার ও SHA-256 দিয়ে শনাক্ত করে উৎসের সঙ্গে যুক্ত করা হয়েছে। এগুলো হলো একটি সাধারণ Breached_Info মেটাডেটা ফাইল, GhostMarket-এর প্রেক্ষাপট ও নমুনাসংবলিত একটি Info মেটাডেটা ফাইল, phpBB ব্যবহারকারী টেবিলের একটি CSV রূপ এবং আটটি phpBB টেবিলসংবলিত একটি MySQL ডাম্প। আর্কাইভের ভেতরে আর কোনো আর্কাইভ পাওয়া যায়নি, এবং উৎসের পে-লোড পরিবর্তন করা হয়নি। ব্যাখ্যামূলক ফাইলগুলোকে বিপুল পরিমাণ অ্যাকাউন্ট ডেটা হিসেবে না ধরে PII-মুক্ত গণনাসূচক ও কাঠামোগত লেবেলের মাধ্যমে মূল্যায়ন করা হয়েছে। এই পার্থক্য বজায় রাখার ফলে কোনো ফাইল পড়া যায় বলেই তার মধ্যে পাওয়া প্রতিটি টোকেন আমদানির যথাযথ ভিত্তি আছে, এমন ভুল ধারণা তৈরি হয় না।

ই-মেইল ম্যাপিংয়ের ভিত্তি কেবল স্কিমায় থাকা স্পষ্ট নির্দেশনা। MySQL DDL সরাসরি phpbb_users.user_email এবং phpbb_banlist.ban_email-কে ই-মেইল ফিল্ড হিসেবে চিহ্নিত করে। নামের মধ্যে “email” থাকা অন্য কলামগুলো, যেমন user_email_hash, user_emailtime, user_allow_viewemail এবং user_allow_massemail, আসলে হ্যাশ, টাইমস্ট্যাম্প বা পছন্দের সেটিংসের ফ্ল্যাগ বোঝায়; এগুলো ঠিকানা হিসেবে আমদানি করা হয় না। অন্যান্য স্থানে ব্যবহারকারীর নাম, বার্তার বিষয়, পোস্ট, তাৎক্ষণিক বার্তা আদান-প্রদানের শনাক্তকারী ও কনফিগারেশন মানের মধ্যে বিরানব্বইটি সম্পূর্ণ ফিল্ডের মান দেখতে ক্যানোনিক্যাল ই-মেইল ঠিকানার মতো হলেও, সেসব ফিল্ড অ্যাকাউন্টের ই-মেইল বোঝায় না এবং সেগুলো বাদ দেওয়া হয়েছে। ম্যাপিং বেছে নিতে ক্যাটালগের সংখ্যার সঙ্গে মেলানো, নির্ধারিত লক্ষ্য সংখ্যার সঙ্গে সমন্বয় করা বা নির্বিচারে কাঁচা টোকেন সংগ্রহের কোনো পদ্ধতি ব্যবহার করা হয়নি। শুধু DDL-এ ঘোষিত ই-মেইল ফিল্ডগুলো গ্রহণ করা হয়েছে।

দুটি স্বতন্ত্র কম্পাইল করা রিডার 505টি INSERT স্টেটমেন্টের সব 34,014টি SQL সারি কোনো কাঠামোগত ত্রুটি ছাড়াই পার্স করেছে। উভয় রিডারের ফলাফলে বৈধ ই-মেইল ঠিকানা একই ক্রমে মোট 3,281 বার এসেছে; উভয় রিডার একই 71,823 বাইট এবং একই SHA-256 পরিচয় তৈরি করেছে। সারির কলামসংখ্যার অমিল, অসমাপ্ত স্টেটমেন্ট, স্ক্যানারের ব্যর্থতা এবং পার্সারের ত্রুটির সংখ্যা সব ক্ষেত্রেই শূন্য ছিল। একই ঠিকানার পুনরাবৃত্তি বাদ দেওয়া এবং কঠোর ASCII ই-মেইল যাচাই প্রয়োগের পর ক্রমানুসারে সাজানো 3,271টি স্বতন্ত্র ক্যানোনিক্যাল ঠিকানা অবশিষ্ট ছিল। phpBB ব্যবহারকারী CSV-এর স্পষ্ট user_email কলাম থেকে স্বাধীনভাবে ই-মেইল ঠিকানা মোট 3,280 বার পাওয়া গেছে; এতে ঠিক একই 3,271টি ঠিকানার ক্যানোনিক্যাল সেট পাওয়া গেছে। CSV ও SQL থেকে তৈরি ক্যানোনিক্যাল ফাইল দুটি বাইট পর্যায়ে অভিন্ন। CSV আবার আমদানি করা হয় না; একই টেবিল উৎসের দুটি বিন্যাসে থাকার কারণে যেন কোনো অ্যাকাউন্ট দুবার লেখা না হয়, সে জন্য এটিকে সমতুল্য উপস্থাপনার প্রমাণ হিসেবে রাখা হয়েছে।

Info মেটাডেটা ফাইলে ই-মেইলের মতো দেখতে দুটি কাঁচা টোকেন আছে। এর মধ্যে শুধু একটি স্পষ্ট অ্যাকাউন্ট ই-মেইল সেটের অন্তর্ভুক্ত। অন্যটি মেটাডেটা বা নমুনা লেখায় রয়েছে এবং সেটিকে কোনো প্রামাণ্য অ্যাকাউন্ট ই-মেইল ফিল্ডের সঙ্গে যুক্ত করা যায় না। তাই Info ফাইলকে ই-মেইলের উৎস হিসেবে নির্বাচন করা হয়নি এবং সেটিকে NON_AUTHORITATIVE_METADATA_SAMPLE শ্রেণির অমীমাংসিত বিষয় হিসেবে নথিভুক্ত করা হয়েছে। সাধারণ Breached_Info ফাইলে কোনো ই-মেইল ফিল্ড বা অ্যাট চিহ্ন নেই। CSV রূপটিকে DUPLICATE_REPRESENTATION_SET_EQUAL হিসেবে যুক্ত করা হয়েছে। ম্যাপিংয়ের আওতা সচেতনভাবে PARTIAL রাখা হয়েছে, কারণ এসব শ্রেণিবিন্যাস আর্কাইভের প্রতিটি লেখা বা পুরো ঐতিহাসিক ঘটনার তথ্য সম্পূর্ণ থাকার দাবি করে না। তবু যে ঠিকানাগুলো গ্রহণ করা হয়েছে, সেগুলোর সবই স্পষ্ট DDL নির্দেশনা এবং স্বাধীনভাবে পাওয়া ক্যানোনিক্যাল সেটগুলোর মিল দ্বারা সম্পূর্ণভাবে সমর্থিত।

উৎসে ব্যবহারকারীর নাম, IP ঠিকানা, পাসওয়ার্ড হ্যাশ, ফোরাম পোস্ট এবং ব্যক্তিগত বার্তার টেবিল রয়েছে, তাই রেকর্ডটির পরিসরের প্রেক্ষাপট হিসেবে এসব শ্রেণি তালিকাভুক্ত করা হয়েছে। LeakData-এর এই কার্যক্রমে শুধু ই-মেইল ঠিকানা আমদানি করা হয়। এই কাজের মাধ্যমে পাসওয়ার্ড, IP ঠিকানা, ব্যবহারকারীর নাম, পোস্টের বিষয়বস্তু বা ব্যক্তিগত বার্তার বিষয়বস্তু Mongo রিলেশনশিপে লেখা হয় না। totalRecords-এ উৎসের 3,331টি অ্যাকাউন্ট সারির সংখ্যা নথিভুক্ত করা হয়েছে। canonicalEmailCount এবং affectedCountLowerBound হলো 3,271, কিন্তু এই সংখ্যা স্বতন্ত্র ব্যক্তির সংখ্যা নয়। একজন ব্যক্তি একাধিক ঠিকানা নিয়ন্ত্রণ করতে পারেন, আবার একটি ঠিকানা একাধিক ব্যক্তি ব্যবহার করতে পারেন বা সেটি নিষ্ক্রিয় থাকতে পারে। ঠিক কতজন ব্যক্তি প্রভাবিত হয়েছেন তা এখনও অজানা, তাই pwnCount হলো null। 3,271 সংখ্যাটি কেবল স্পষ্ট ই-মেইল ফিল্ডে যাচাই করা স্বতন্ত্র ক্যানোনিক্যাল ঠিকানার সংখ্যার নিম্নসীমা।

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