پارتیشن بندی ذخیره سازی

برای تقویت حریم خصوصی کاربر و مبارزه با ردیابی متقابل کانال جانبی، Chrome اکنون اکثر APIهای ذخیره سازی و ارتباطی را در زمینه های شخص ثالث از طریق فرآیندی به نام پارتیشن بندی ذخیره سازی جدا می کند.

وضعیت پیاده سازی

این ویژگی برای همه کاربران در Chrome 115 و جدیدتر فعال شده است. تلاش های مشابهی برای پارتیشن بندی فضای ذخیره سازی در سایر مرورگرهای بزرگ مانند فایرفاکس و سافاری نیز انجام شده یا برنامه ریزی شده است. پیشنهاد Storage Partitioning در GitHub برای بحث بیشتر باز است.

پارتیشن بندی ذخیره سازی چیست؟

برای جلوگیری از انواع خاصی از ردیابی متقابل کانال جانبی، Chrome APIهای فضای ذخیره‌سازی و ارتباطات را در زمینه‌های شخص ثالث پارتیشن بندی می‌کند.

بدون پارتیشن بندی فضای ذخیره سازی، یک سایت می تواند داده ها را در سایت های مختلف به هم بپیوندد تا کاربر را در سراسر وب ردیابی کند. همچنین، به سایت تعبیه‌شده اجازه می‌دهد تا با استفاده از تکنیک‌های کانال جانبی مانند حملات زمان‌بندی ، XS-Leaks و COSI ، حالت‌های خاصی را درباره کاربر در سایت سطح بالا استنباط کند.

از لحاظ تاریخی، ذخیره سازی تنها بر اساس مبدأ کلید خورده است. این بدان معناست که اگر یک iframe از example.com در a.com و b.com تعبیه شده باشد، می‌تواند با ذخیره کردن و بازیابی موفقیت‌آمیز یک شناسه از فضای ذخیره‌سازی، در مورد عادات مرور شما برای آن دو سایت اطلاعات کسب کند. با فعال بودن پارتیشن بندی ذخیره سازی شخص ثالث، storage for example.com در دو پارتیشن مختلف وجود دارد، یکی برای a.com و دیگری برای b.com .

به طور کلی، پارتیشن بندی به این معنی است که داده های نوشته شده توسط API های ذخیره سازی مانند Local Storage و IndexedDB در یک iframe دیگر نمی توانند توسط همه زمینه هایی که منشا یکسانی دارند دسترسی داشته باشند. در عوض، آن داده‌ها اکنون جدا شده‌اند و فقط برای زمینه‌هایی در دسترس هستند که هم مبدا یکسان و هم سایت سطح بالا دارند.

قبل از

API های ذخیره سازی بدون پارتیشن بندی
قبل از پارتیشن بندی ذخیره سازی، example.com می تواند داده ها را زمانی که در a.com تعبیه شده است بنویسد، و سپس زمانی که در b.com جاسازی شده است، آن ها را بخواند.

بعد از

API های ذخیره سازی با پارتیشن بندی.
پس از پارتیشن بندی فضای ذخیره سازی، example.com، هنگامی که در b.com تعبیه شده است، وقتی در a.com جاسازی شود، نمی تواند به فضای ذخیره سازی example.com دسترسی پیدا کند.

پارتیشن بندی ذخیره سازی در iframe های زنجیره ای

پیچیدگی پارتیشن بندی ذخیره سازی زمانی که iframe ها تو در تو هستند به طور قابل توجهی افزایش می یابد، به ویژه هنگامی که یک مبدا چندین بار در زنجیره ظاهر می شود.

به عنوان مثال، A1 حاوی یک iframe برای B است که حاوی یک iframe برای A2 است و هر دو A1 و A2 در یک سایت هستند. اگر پارتیشن بندی فقط سایت سطح بالا و منشاء فریم فعلی را در نظر بگیرد، iframe A2 ممکن است به اشتباه به عنوان "طرف اول" در نظر گرفته شود، زیرا یک سایت را با سطح بالا (A1) به اشتراک می گذارد، علی رغم iframe بین سایتی B در بین. اگر A2 به طور پیش‌فرض به فضای ذخیره‌سازی پارتیشن نشده دسترسی داشت، این می‌تواند A2 را در معرض خطرات امنیتی مانند کلیک جک قرار دهد.

برای رفع این مشکل، کروم یک «بیت اجداد» را به کلید پارتیشن ذخیره‌سازی اضافه می‌کند. اگر سندی بین iframe فعلی و سایت سطح بالا از مبدأ متفاوت (مقابل سایت) باشد، این بیت تنظیم می شود. در این مورد، سایت B بین سایتی است، بنابراین بیت برای A2 تنظیم می شود و ذخیره سازی آن از A1 پارتیشن بندی می شود.

وقتی زنجیره iframe صرفاً از زمینه‌های یک سایت تشکیل شده باشد (به عنوان مثال، سایت A1 حاوی A2، که سپس حاوی A3 است)، بیت اجداد فضای ذخیره‌سازی آنها را بیشتر تقسیم نمی‌کند. در چنین مواردی، فضای ذخیره‌سازی آن‌ها به صورت مشترک باقی می‌ماند، که توسط منبع مشترک و سایت سطح بالا کلید می‌خورد.

برای سایت‌هایی که به دسترسی بدون پارتیشن در میان iframe‌های زنجیره‌ای نیاز دارند، Chrome با گسترش API دسترسی به فضای ذخیره‌سازی برای فعال کردن این مورد استفاده می‌کند . از آنجایی که Storage Access API به سایت قاب‌بندی شده نیاز دارد تا به صراحت API را فراخوانی کند، این امر خطر کلیک جک را کاهش می‌دهد.

API به دلیل پارتیشن بندی تغییر می کند

API های تحت تأثیر پارتیشن بندی را می توان به گروه های زیر تقسیم کرد:

API های ذخیره سازی

  • سیستم سهمیه بندی
    سیستم سهمیه برای تعیین مقدار فضای دیسک برای ذخیره سازی استفاده می شود. سیستم سهمیه هر پارتیشن را به عنوان یک سطل جداگانه مدیریت می کند تا تعیین کند چه مقدار فضای مجاز است و چه زمانی پاک می شود.
    متد navigator.storage.estimate() اکنون اطلاعات مختص به پارتیشن ذخیره سازی را ارائه می دهد. APIهای فقط Chrome مانند window.webkitStorageInfo و navigator.webkitTemporaryStorage منسوخ شده‌اند.
    IndexedDB و ذخیره سازی Cache از سیستم سهمیه پارتیشن بندی شده استفاده می کنند.
  • Web Storage API
    Web Storage API مکانیسم هایی را فراهم می کند که مرورگرها می توانند جفت های کلید-مقدار را ذخیره کنند. دو مکانیسم وجود دارد: ذخیره‌سازی محلی و ذخیره‌سازی جلسه . آنها توسط سهمیه مدیریت نمی شوند، اما همچنان تقسیم بندی می شوند.
  • سیستم فایل خصوصی Origin
    File System Access API به سایت اجازه می دهد تا پس از اعطای دسترسی کاربر، تغییرات را مستقیماً در فایل ها و پوشه های دستگاه بخواند یا ذخیره کند. Origin Private File System یک منبع را قادر می سازد تا محتوای خصوصی را مستقیماً در دیسک ذخیره کند. این محتوا برای کاربر قابل دسترسی است اما اکنون پارتیشن بندی شده است.
  • Storage Bucket API
    Storage Bucket API برای Storage Standard توسعه یافته است که API های ذخیره سازی مختلف مانند IndexedDB و localStorage را با استفاده از مفهوم جدیدی به نام سطل ها ادغام می کند. داده های ذخیره شده در سطل ها و ابرداده های مرتبط با سطل ها پارتیشن بندی می شوند.
  • هدر Clear-Site-Data
    گنجاندن هدر Clear-Site-Data در پاسخ به سرور اجازه می دهد تا داده های ذخیره شده در مرورگر کاربر را پاک کند. حافظه پنهان، کوکی‌ها و فضای ذخیره‌سازی DOM را می‌توان پاک کرد. استفاده از هدر تنها فضای ذخیره سازی را در یک پارتیشن پاک می کند.
  • فروشگاه URL Blob
    URL Blob دسترسی به یک blob را فراهم می کند، یک شی که داده های خام را در خود نگه می دارد. بدون پارتیشن بندی فضای ذخیره سازی، یک URL blob ایجاد شده در یک iframe شخص ثالث در یک سایت می تواند در یک iframe با همان مبدا که در سایت دیگری تعبیه شده است استفاده شود. به عنوان مثال، اگر iframe های example.com در هر دو a.com و b.com تعبیه شده باشند، یک URL حباب ایجاد شده در iframe تعبیه شده در a.com می تواند بدون هیچ محدودیتی به iframe تعبیه شده در b.com ارسال شود و سپس از آن استفاده شود. با شروع Chrome 137 (منتشر شده در 27 مه 2025)، URL های Blob برای همه موارد به جز پیمایش های سطح بالا تقسیم بندی می شوند. مواردی که اکنون مسدود خواهند شد عبارتند از زمانی که URL های حباب متقاطع با fetch() یا به عنوان مقدار مشخصه src برای عناصر مختلف HTML استفاده می شود. پیمایش‌های سطح بالا، مانند فراخوانی window.open() یا کلیک کردن روی پیوندی با target='_blank' ، به آدرس‌های اینترنتی Blob در صورتی که پارتیشن‌بندی شوند مسدود نمی‌شوند، اما اگر سایت URL blob بین سایتی از سایت سطح بالای صفحه شروع کننده پیمایش باشد، noopener اعمال می‌شود. اعمال noopener به این معنی است که سندی که پیمایش را آغاز می‌کند از دریافت دستگیره پنجره برای سند URL حباب که باز شده است جلوگیری می‌کند. در مثال قبلی، پارتیشن بندی از دریافت محتوای URL blob توسط iframe در b.com جلوگیری می کند، اما همچنان می تواند آن را window.open() کند.

API های ارتباطی

همراه با API های ذخیره سازی، API های ارتباطی که به یک زمینه اجازه می دهد تا در سراسر مرزهای مبدا ارتباط برقرار کند نیز تقسیم بندی می شوند. تغییرات عمدتاً بر APIهایی تأثیر می‌گذارد که امکان کشف زمینه‌های دیگر را با استفاده از پخش یا قرار ملاقات با منشأ مشابه فراهم می‌کنند.

به دلیل پارتیشن بندی، API های ارتباطی زیر از مبادله داده های iframe های شخص ثالث با زمینه های یکسان خود جلوگیری می کنند:

  • کانال پخش
    Broadcast Channel API امکان برقراری ارتباط بین زمینه‌های مرور (پنجره‌ها، برگه‌ها یا iframe) و کارگرانی از همان مبدا را فراهم می‌کند.
    رفتار متقابل iframe postMessage() پیشنهاد نمی شود که تغییر کند، زیرا رابطه بین آن زمینه ها قبلاً به وضوح تعریف شده است.
  • SharedWorker
    SharedWorker API کارگری را فراهم می‌کند که می‌تواند در زمینه‌های مرور با همان مبدأ قابل دسترسی باشد.
  • قفل های وب
    Web Locks API به کدهای در حال اجرا در یک برگه یا کارگر با همان مبدا اجازه می دهد تا در حین انجام برخی کارها، قفلی برای یک منبع مشترک بدست آورد.

Service Worker API

Service Worker API به سایت ها اجازه می دهد تا وظایف را در پس زمینه انجام دهند. سایت‌ها کارگران خدماتی را ثبت می‌کنند که زمینه‌های کارگری جدیدی را برای پاسخگویی به رویدادها ایجاد می‌کنند. به طور سنتی، این کارگران می‌توانستند با هر زمینه‌ای با منشأ مشابه ارتباط برقرار کنند. با این حال، از آنجایی که کارکنان خدمات می‌توانند زمان‌بندی درخواست‌های ناوبری را تغییر دهند، خطر نشت اطلاعات بین‌سایتی مانند شنود تاریخچه را به همراه دارند.

به همین دلیل، Service Workers ثبت شده از یک زمینه شخص ثالث اکنون پارتیشن بندی شده اند.

APIهای برنامه افزودنی

برنامه‌های افزودنی برنامه‌هایی هستند که به کاربران اجازه می‌دهند تجربه مرور خود را سفارشی کنند.

صفحات افزونه (صفحات دارای طرح chrome-extension:// ) را می توان در سایت های سراسر وب جاسازی کرد. در این سناریو، صفحات افزونه همچنان به پارتیشن سطح بالای خود دسترسی دارند. برنامه های افزودنی همچنین می توانند سایت های دیگر را جاسازی کنند. هنگامی که آنها این کار را انجام دهند، آن سایت های جاسازی شده به پارتیشن سطح بالای خود دسترسی خواهند داشت، مشروط بر اینکه برنامه افزودنی دارای مجوزهای میزبان برای آنها باشد.

برای اطلاعات بیشتر، به اسناد افزونه مراجعه کنید.

نسخه ی نمایشی: تست پارتیشن بندی فضای ذخیره سازی

سایت آزمایشی: https://storage-partitioning-demo-site-a.glitch.me/

سایت نمایشی که تیک های سبز در سمت چپ و صلیب های قرمز را در سمت راست نشان می دهد.
تصویری از نسخه آزمایشی، خروجی یک مرورگر با پارتیشن بندی ذخیره سازی در سمت چپ و بدون پارتیشن بندی ذخیره سازی در سمت راست را نشان می دهد.

دمو از دو سایت استفاده می کند: سایت A و سایت B.

  • وقتی از سایت A در زمینه سطح بالا بازدید می کنید، داده ها را با استفاده از روش های مختلف ذخیره سازی تنظیم می کند.
  • سایت B صفحه ای را از سایت A جاسازی می کند و آن جاسازی سعی می کند گزینه های ذخیره سازی قبلی را بخواند.
  • هنگامی که سایت A در سایت B تعبیه شده است، هنگامی که فضای ذخیره سازی پارتیشن بندی می شود به آن داده ها دسترسی ندارد و بنابراین خواندن ها با شکست مواجه می شوند.
  • نسخه ی نمایشی از موفقیت یا عدم موفقیت هر خواندن برای نشان دادن پارتیشن بندی داده ها استفاده می کند.

در حال حاضر، می توانید پارتیشن بندی فضای ذخیره سازی را در Chrome با استفاده از سوئیچ خط فرمان --disable-features=ThirdPartyStoragePartitioning خاموش کنید. توجه: این سوئیچ خط فرمان برای اهداف توسعه و آزمایش در نظر گرفته شده است و ممکن است در نسخه‌های بعدی Chrome حذف یا تغییر یابد.

همچنین می توانید مرورگرهای دیگر را به همین روش تست کنید تا وضعیت پارتیشن بندی آنها را مشاهده کنید.

مشارکت کنید و بازخورد را به اشتراک بگذارید