قوانین جدید Chrome Web Store از 1 اوت 2026؛ چک لیست Extensionها

اگر Extension شما داده کاربر جمع می کند، به سرویس AI وصل می شود یا قابلیت مالی/Prediction Market دارد، سیاست های جدید Chrome Web Store از 1 اوت 2026 دیگر صرفاً اطلاعیه نیستند و وارد فاز Enforcement شده اند. این راهنما متن تغییرات را به چک لیست فنی برای Permissionها، Telemetry، Privacy Disclosure، Backend و Release تبدیل می کند.

چه چیزی از 1 اوت 2026 اجرا می شود؟

تغییر مهم این است که Compliance را نمی توان فقط با متن Privacy Policy حل کرد. Limited Use می گوید داده جمع آوری شده باید برای «Single Purpose» اعلام شده Extension واقعاً ضروری باشد. Disclosure Requirements نیز دامنه افشا را وسیع تر می کند: همه جمع آوری داده باید به صورت برجسته اعلام شود، حتی اگر به هدف اصلی نزدیک باشد. اگر رفتار Data Handling بعد از نصب تغییر کند، توسعه دهنده باید آن تغییر را به صورت فعال به کاربر اعلام کند. این یعنی معماری Telemetry و فرآیند Release شما مستقیماً به Policy Review وصل شده است.

از نظر عملیات، Enforcement از 1 اوت یعنی نسخه قدیمی منتشرشده نیز باید ممیزی شود. تیمی که فقط Release بعدی را اصلاح می کند اما نسخه فعلی Store را تا چند هفته بدون تغییر نگه می دارد، همچنان در معرض اقدام اجرایی است. بنابراین اولویت با Gap Analysis روی نسخه Live است، سپس Backlog اصلاحات. اگر چند Extension دارید، آن ها را بر اساس سطح Permission و Data Flow رتبه بندی کنید؛ Extension با `tabs`، `history`، `webRequest` یا Native Messaging معمولاً نیازمند بررسی دقیق تر از یک Extension بدون داده است.

Limited Use؛ هر داده باید برای هدف اعلام شده ضروری باشد

واژه کلیدی «strictly necessary» است. این معیار، استدلال «شاید بعداً برای بهبود محصول مفید باشد» را ضعیف می کند. فرض کنید Extension شما متن انتخاب شده را برای خلاصه سازی به Backend می فرستد. ارسال خود متن می تواند برای آن هدف لازم باشد، اما ارسال URL کامل صفحه، کل History، شناسه پایدار دستگاه و لیست Tabهای دیگر ممکن است برای همان Single Purpose قابل دفاع نباشد. طراحی Data Contract باید Field-by-Field باشد و برای هر مقدار یک Purpose واضح داشته باشید.

بهترین تغییر مهندسی، Data Minimization در مبدأ است. داده ای که جمع نمی شود نه Leak می شود، نه نیازمند Retention Policy پیچیده است و نه در Review باید توجیه شود. Event Schemaهای Analytics را بازبینی کنید، Propertyهای Legacy را حذف کنید و Sampling یا Aggregation را قبل از ارسال انجام دهید. اگر Backend یک Payload بزرگ عمومی می گیرد و فقط دو Field را استفاده می کند، Contract را باریک کنید. این کار هم Policy Risk را پایین می آورد و هم هزینه Log/Storage را کاهش می دهد.

نمونه Data Contract حداقلی

const event = {
  feature: 'summarize-selection',
  durationMs,
  success
}
// Do not attach browsing history or unrelated page data.

این نمونه نسخه کامل Policy نیست، اما ذهنیت درست را نشان می دهد: Telemetry عملکردی را از محتوای کاربر و اطلاعات مرور جدا کنید. هرجا داده حساس برای Function لازم است، Scope، Retention و Access آن را مستقل تعریف کنید. همچنین از توسعه دهنده بخواهید دلیل وجود هر Field را در Schema Review بنویسد؛ این توضیح بعداً به Privacy Review و مستندسازی Store کمک می کند.

Disclosure؛ فقط Privacy Policy کافی نیست

Google صریحاً می گوید همه Data Collection باید prominently disclosed باشد. این قید مهم است چون بسیاری از تیم ها اطلاعات را در یک صفحه طولانی Policy دفن می کنند. کاربر باید قبل از فعال شدن رفتار معنی دار بفهمد چه چیزی جمع می شود و چرا. اگر قابلیت اختیاری Voice، Screenshot یا AI Context دارید، Disclosure نزدیک همان Action بسیار قابل فهم تر از یک متن کلی در Onboarding است. Consent نیز باید با واقعیت Product هماهنگ باشد؛ Checkbox مبهم برای مجموعه ای از استفاده های آینده، طراحی مطمئنی نیست.

بخش دوم سخت تر است: اگر Data Handling بعد از نصب تغییر کرد، باید به طور Proactive به کاربر اعلام شود. پس Release Process شما باید Trigger مشخص داشته باشد. هر Pull Request که Schema، مقصد Network، Retention یا Third-party Processor را تغییر می دهد، باید Privacy Impact flag بگیرد. در Release Checklist سؤال کنید آیا Disclosure نیاز به Update دارد و آیا کاربر قبلی باید Notice ببیند. این فرآیند جلوی وضعیت خطرناک «کد تغییر کرد، صفحه Store شش ماه عقب است» را می گیرد.

Extensionهای AI و ممنوعیت دورزدن Guardrail

Policy جدید صریحاً Extensionهایی را که برای دورزدن Safety Guardrail، Usage Restriction یا Protective Measure سرویس های AI طراحی شده اند ممنوع می کند. تفاوت مهمی بین «Client جایگزین» و «Bypass Tool» وجود دارد. یک Extension می تواند UI بهتر برای API رسمی بسازد، اما اگر ارزش اصلی محصول شکستن محدودیت ایمنی، حذف کنترل دسترسی یا فریب مکانیزم حفاظتی باشد، ریسک Policy مستقیم است. تیم Product باید Value Proposition و کد را با هم بررسی کند؛ تغییر نام Feature بدون تغییر رفتار کمکی نمی کند.

برای Wrapperهای AI، Authentication و Rate Limit را مطابق API رسمی نگه دارید، از Header یا Token دستکاری شده برای دورزدن محدودیت استفاده نکنید و ادعای «unlock unrestricted mode» را از Product و Marketing حذف کنید اگر معنایش bypass حفاظتی است. در سمت Backend نیز مکانیسمی که درخواست را به چند Account بچرخاند تا limit حفاظتی بی اثر شود می تواند مشکل زا باشد. Rule ساده این است: Integration باید در چارچوب Contract رسمی سرویس کار کند، نه علیه آن.

Prediction Market و تراکنش پول واقعی

بخش Regulated Goods and Services اکنون Prediction Market را صریح تر پوشش می دهد و Extensionهایی که تراکنش پول واقعی روی نتیجه پیش بینی را facilitate یا enable کنند مجاز نیستند. برای تیم هایی که افزونه قیمت، تحلیل یا داشبورد داده بازار می سازند، مرز محصول را دقیق بررسی کنید. نمایش داده یا تحلیل الزاماً همان اجرای تراکنش نیست، اما دکمه Trade، Deep Link مستقیم به flow تراکنش، Wallet integration یا automation خرید می تواند ماهیت محصول را تغییر دهد. تصمیم حقوقی/Policy باید بر اساس رفتار واقعی Feature گرفته شود، نه فقط Category انتخاب شده در Store.

اگر محصول در مرز این تعریف است، قبل از انتشار تغییرات بزرگ یک Review داخلی مستند انجام دهید و قابلیت هایی که تراکنش را اجرا می کنند از Extension جدا کنید. هدف این مقاله ارائه نظر حقوقی نیست؛ هدف این است که تیم فنی زودتر نقطه ای را تشخیص دهد که نیازمند بررسی Policy تخصصی است. Unknown را به Release روز آخر موکول نکنید.

ممیزی Extension؛ از manifest تا Backend

1. `manifest.json` را برای Permissionهای پرقدرت و Host Permissionهای وسیع بررسی کنید.
2. Network callها را از Service Worker، Content Script و UI استخراج کنید و مقصد هرکدام را ثبت کنید.
3. برای هر Payload، Field، Purpose، Retention و Processor را مشخص کنید.
4. Eventهای Analytics قدیمی و داده هایی که دیگر استفاده نمی شوند حذف کنید.
5. Store Listing، Privacy Policy، Onboarding و In-product Notice را با Data Flow واقعی تطبیق دهید.
6. Featureهای AI را از نظر وابستگی به bypass محدودیت یا Guardrail بررسی کنید.
7. هر تغییر Data Handling بعد از نصب را به Release Gate و Notice کاربر وصل کنید.

برای تیم حرفه ای، این Audit بهتر است به Artifact تبدیل شود: یک Data Inventory JSON/YAML یا Spreadsheet که Owner، Source، Destination، Legal/Policy Purpose و Retention را دارد. سپس CI می تواند تغییرات Manifest و endpointهای جدید را Flag کند. قرار نیست Compliance کاملاً خودکار شود؛ Automation فقط تغییرات مشکوک را زودتر جلوی چشم Reviewer می آورد. تصمیم نهایی درباره ضرورت داده هنوز نیازمند Context محصول است.

نقشه انتشار نسخه اصلاحی و جلوگیری از Enforcement

اگر Gap پیدا کردید، ابتدا رفتار پرریسک را محدود کنید، سپس Disclosure و Listing را هماهنگ سازید. تغییر Privacy Text بدون تغییر کدی که داده غیرضروری می فرستد کافی نیست. برعکس، حذف Collection بدون Update مستندات هم باعث اختلاف می شود. Release را با Test account تمیز نصب کنید تا تجربه کاربر جدید را ببینید، سپس Upgrade از نسخه قدیمی را تست کنید تا Notice تغییر Data Handling واقعاً نمایش داده شود. برای Extensionهایی با Update خودکار، Migration State را نیز بررسی کنید.

پرسش های متداول

قوانین جدید Chrome Web Store از چه تاریخی اجرا می شوند؟

Enforcement تغییرات اعلام شده از 1 اوت 2026 آغاز شده است.

Limited Use جدید چه می گوید؟

داده ای که Extension جمع می کند باید برای Single Purpose اعلام شده واقعاً ضروری باشد و جمع آوری برای اهداف دیگر ممنوع است.

آیا فقط Privacy Policy را باید تغییر دهیم؟

خیر. Data Flow واقعی، Manifest، Telemetry، Backend و Disclosure داخل محصول باید با هم منطبق باشند.

آیا همه Extensionهای AI ممنوع شده اند؟

خیر. ممنوعیت جدید روی Extensionهایی تمرکز دارد که Guardrail، محدودیت استفاده یا حفاظت های سرویس AI را دور می زنند.

Prediction Market همیشه ممنوع است؟

Policy صریحاً Extensionهایی را که تراکنش پول واقعی روی نتایج پیش بینی را تسهیل یا فعال می کنند ممنوع می کند؛ برای موارد مرزی باید رفتار واقعی محصول بررسی شود.

منبع اصلی و جمع بندی

تمام تغییرات اصلی این راهنما از اعلام رسمی Chrome Web Store استخراج شده است. پیام اجرایی آن روشن است: Permission و Data Collection را حداقلی کنید، Disclosure را به رفتار واقعی متصل کنید و تغییرات Privacy را مثل تغییر Schema یا API یک Release Concern جدی بدانید. این رویکرد علاوه بر عبور از Review، سطح ریسک امنیتی Extension را نیز کمتر می کند.

چک لیست 15 دقیقه ای قبل از Release

• آیا Single Purpose در Listing و رفتار واقعی یکسان است؟
• آیا Field داده ای وجود دارد که بدون آن Feature همچنان کار می کند؟ حذفش کنید.
• آیا Permission گسترده ای برای Feature قدیمی باقی مانده است؟
• آیا مقصد Third-party جدید بدون Disclosure اضافه شده است؟
• آیا Update نسخه قبلی Notice لازم را به کاربر نشان می دهد؟
• آیا Feature AI از API و محدودیت های رسمی استفاده می کند؟
• آیا تیم Support پاسخ مشخصی برای سؤال «چه داده ای می گیرید و چرا؟» دارد؟
• آیا Data Inventory و Store Listing با Commit فعلی همگام اند؟

Policy را به کنترل مهندسی در CI تبدیل کنید

ممیزی دستی برای یک Extension کوچک ممکن است کافی باشد، اما در تیمی که هر هفته Release دارد، Policy باید بخشی از Definition of Done شود. یک کنترل سبک در CI می تواند تغییر `manifest.json`، اضافه شدن Host Permission، مقصد Network تازه یا تغییر فایل های Telemetry را تشخیص دهد و Pull Request را برای Privacy Review علامت گذاری کند. این Gate نباید ادعا کند که Compliance را خودکار تشخیص می دهد؛ وظیفه اش فقط این است که تغییر پرریسک بی سر و صدا وارد Release نشود. Reviewer انسانی هنوز باید بررسی کند داده برای Single Purpose ضروری است و Disclosure با رفتار واقعی سازگار مانده است.

برای جلوگیری از False Positive، Ruleها را بر اساس سطح ریسک تنظیم کنید. تغییر متن UI معمولی لازم نیست Privacy Review بگیرد، اما افزودن `host_permissions`، endpoint خارجی، SDK Analytics یا قابلیت AI جدید باید Trigger شود. در Repository می توانید یک فایل `privacy-inventory.yml` نگه دارید که نام داده، منبع، مقصد، Purpose و Retention را ثبت کند. هر PR که Payload را تغییر می دهد، Inventory را هم به روزرسانی کند. این الگو علاوه بر Chrome Web Store برای Audit امنیتی و پاسخ به Incident نیز ارزش دارد، چون تیم می داند چه داده ای واقعاً از مرورگر خارج می شود.

سناریوی واقعی؛ Extension خلاصه ساز با AI

فرض کنید افزونه ای متن انتخاب شده را برای خلاصه سازی به یک API ابری می فرستد. مسیر امن این است که فقط همان Selection و اطلاعات حداقلی لازم برای درخواست ارسال شود، کاربر پیش از اولین ارسال از انتقال محتوا آگاه باشد و تغییر Provider یا Retention در Release بعدی Notice مناسب ایجاد کند. اگر تیم برای Analytics همزمان URL کامل، عنوان همه Tabها و شناسه پایدار کاربر را ارسال می کند، باید برای تک تک این داده ها ضرورت را اثبات کند؛ در غیر این صورت حذف آن ها انتخاب ساده تر و کم ریسک تری است. همین سناریو نشان می دهد چرا Policy جدید عملاً مسئله Architecture است، نه فقط متن Legal.