آپریٹرز کے لیے Lolly

ایک تہ در تہ دفاعی سکیورٹی اور انٹیلیجنس حکمتِ عملی – جو اتفاقاً ایک تخلیقی پروڈکشن پلیٹ فارم بھی ہے

zero-trust تنظیمی مدافعتی نظام جو آپ کے موجودہ کام کے گرد لپٹ جاتا ہے - تاکہ روزمرہ کا جو تخلیقی کام آپ کی ٹیموں کو ہر روز درکار ہوتا ہے وہ آپ کے دائرے سے باہر رِسنے کے بجائے اُس کے اندر ہو۔

اِس میں آپ کے لیے کیا ہے۔ آپ وہ شخص بن جاتے ہیں جس نے کسی ایسی چیز کو ہاں کہی جو محفوظ اور مقبول دونوں تھی۔ آپ ایک اخراج (exfiltration) کا سوراخ بند کرتے ہیں، صلاحیت حاصل کرتے ہیں، اور ایک ہی قدم میں درخواستوں کی قطار ختم کر دیتے ہیں - وہ نایاب سکیورٹی کامیابی جو آپ کو کم نہیں بلکہ زیادہ پسندیدہ بناتی ہے۔ لیگل ڈیپارٹمنٹ کی رات 3 بجے کوئی کال نہیں کیونکہ کوئی embargoed فائل یا کسٹمر ڈیٹا کسی بے ترتیب ویب ٹول تک نہیں پہنچا؛ آپ کی فہرست میں کم SaaS وینڈرز، معاہدے اور آڈٹس؛ اور ایک مکمل طور پر دوبارہ پیدا کیے جانے کے قابل آڈٹ ٹریل جس کی طرف آپ اشارہ کر سکتے ہیں جب کوئی پوچھے۔ آپ رات کو زیادہ سکون سے سوتے ہیں، اور ایسا کرتے ہوئے کچھ دنوں کو روشن بھی کرتے ہیں۔

Lolly کوئی دوسرے درجے کا تخلیقی ٹول نہیں ہے: یہ پروڈکشن-معیار کا آؤٹ پٹ ہر ایک کے ہاتھ میں دے دیتا ہے، اور برانڈ کی رہنمائی میں تخلیق کا تجربہ بے مثال ہے۔ اِسے اتنے وسیع پیمانے پر تقسیم کرنا محفوظ ہونے کی وجہ فنِ تعمیر میں ہے: کچھ بھی اپ لوڈ نہیں ہوتا سوائے اُس کے جو آپ نے خود وہاں رکھا؛ ہر نتیجہ دوبارہ پیدا کیا جا سکتا ہے؛ اور ہر ایکسپورٹ اپنے ساتھ صنعت کی معروف cryptographic ریکارڈز کی متعدد تہیں لے جا سکتا ہے۔ کوئی دستاویز آپ کی میز تک کسی بھی طرح پہنچی ہو، آپ اُس کا مکمل ماخذ (provenance) دیکھ سکتے ہیں، کہ آیا اُس کے ساتھ چھیڑ چھاڑ ہوئی ہے، اور کیا آپ اُسے pixel-perfect دوبارہ تخلیق کر سکتے ہیں۔

آج یہ کہاں کھڑا ہے۔ Lolly کی سکیورٹی خصوصیات بنیادی ڈیزائن کے لحاظ سے مضبوط ہیں، اور اِس کے cryptography اور فائل-پارسنگ انجن SUSE کی انٹرپرائز-درجے کی انفراسٹرکچر ہارڈننگ سے گزر رہے ہیں۔ نیچے دیے گئے سِیل، آن-ڈیوائس سائننگ اور encryption ابھی حقیقی اور قابلِ دفاع ہیں، اور آزاد سرٹیفیکیشن کی طرف بڑھ رہے ہیں - لہٰذا جہاں کوئی معاہدہ تصدیق شدہ یقین دہانی کا تقاضا کرے، اُس عمل کے مکمل ہونے کے دوران انہیں تہ در تہ دفاع کے طور پر تعینات کریں۔

حکمتِ عملی کا فائدہ

روزمرہ کا تخلیقی کام جس عام طریقے سے انجام پاتا ہے وہ ایک ذمہ داری کی سطح ہے: فائلیں بیرونی ڈیزائن کنٹریکٹرز کو ای میل کی جاتی ہیں، برانڈ اثاثے درجن بھر SaaS ایڈیٹرز میں اپ لوڈ کیے جاتے ہیں، کسٹمر ڈیٹا کسی اجنبی کے ویب ٹول میں پیسٹ کیا جاتا ہے تاکہ "بس ایک فوری گرافک بنا لیا جائے۔" اِن میں سے ہر ایک وہ ڈیٹا ہے جو آپ کے کنٹرول سے نکل رہا ہے۔

Lolly اِسے اُلٹ دیتا ہے۔ وہ کام جو اِن رِساؤ کا سبب بنا - کوٹ کارڈ، مقامی زبان کا بینر، ایونٹ بیج، redacted اسکرین شاٹ - اب ایک ایسے ٹول پر ہوتا ہے جو ملازم کے اپنے آلے پر، آپ کے برانڈ کے مطابق، بغیر کسی سرور کے چلتا ہے۔ آپ نے کسی خطرناک ورک فلو کے اوپر کوئی کنٹرول شامل نہیں کیا؛ آپ نے خطرناک ورک فلو کو ایک ایسے سے بدل دیا جس میں شروع سے ہی اخراج کا کوئی راستہ نہیں ہے۔

• کنفیگریشن آپ کی ہے۔ انجن اور شیلز اوپن سورس ہیں (MPL-2.0)۔ اپنی auth، telemetry یا CA اوپر لگائیں؛ اِسے host کریں یا نہ کریں؛ آپ کے پاس مکمل فیچر اور لاگت کا کنٹرول ہے، git-ٹریک شدہ، کسی SaaS ڈیٹابیس میں بند نہیں۔
• گورننس ڈیٹا ہو سکتی ہے، ڈیش بورڈ نہیں۔ جب آپ کو وہ کنٹرول چاہیے ہو، تو ٹول کیٹلاگ کو ایک Git ریپازٹری کے طور پر منظم کریں - pull-request جائزہ برانڈ کی منظوری بن جاتا ہے، جس میں ایک مکمل آڈٹ ٹریل اور ہر اُس ٹیمپلیٹ کا فوری رول بیک شامل ہے جسے آپ کی افرادی قوت چھو سکتی ہے۔ یہ ایک آپشن ہے، ذمہ داری نہیں: وہ ٹیمیں جو صرف چیزیں بنانا چاہتی ہیں اپنے ٹولز Layout Studio میں خود تیار کرتی ہیں اور اپنی فائلیں کیٹلاگ میں شامل کرتی ہیں، مکمل طور پر ایپ کے اندر، اور کبھی git کو چھوتی ہی نہیں۔ دیکھیں اپنانا اور گورننس۔
• گارڈ ریلز ساختی ہیں۔ برانڈ کی پابندیاں ٹیمپلیٹس میں hard-code کی گئی ہیں، ایسی ہدایات کے طور پر شائع نہیں کی گئیں جنہیں لوگ نظر انداز کر سکیں۔ غلط آؤٹ پٹ کی حوصلہ شکنی نہیں کی جاتی - بلکہ اُسے ظاہر کیا ہی نہیں جا سکتا۔

مواد کو بڑھاتے ہوئے درخواستوں کی قطار کو ختم کریں۔

Lolly کا ایک مقصد ڈیزائن-درخواستوں کا رخ موڑنا ہے: وہ روزمرہ کی درخواستیں جنہیں کبھی کسی ڈیزائنر تک پہنچنے کی ضرورت نہیں پڑتی کیونکہ جس شخص کو اثاثہ درکار تھا اُس نے اِسے خود، درستگی سے، منٹوں میں بنا لیا۔ ہر موڑا گیا ٹکٹ ایک پیداواری کامیابی بھی ہے اور ایک کم فائل کے ہاتھ بدلنے کا سبب بھی۔

Lolly اِس طرح بنایا گیا ہے کہ یہ آپ کی تنظیم کے حقیقی طریقۂ کار کے مطابق ڈھل جائے - اِسے تعینات کرنے کا کوئی ایک درست طریقہ نہیں ہے:

• تعینات کریں، serve نہ کریں۔ Lolly کو اپنے موجودہ MDM (Intune، Jamf، Munki…) کے ذریعے آلات تک پہنچائیں۔ یہ مقامی طور پر ایک ڈیسک ٹاپ/موبائل ایپ یا آف لائن PWA کے طور پر چلتا ہے - کسی بھی firewall کے پیچھے، کسی بھی air-gapped ماحول میں کام کرتا ہے، جس میں برقرار رکھنے کے لیے کوئی سرور نہیں اور اپ ڈیٹ کی رفتار IT کے کنٹرول میں۔
• صرف serve کریں۔ اپنے نیٹ ورک کے اندر (یا کسی VPN کے پیچھے) ایک instance چلائیں؛ صارفین اِس تک براؤزر میں پہنچتے ہیں، کچھ انسٹال نہیں ہوتا۔ کوئی ٹول ایک بار شائع کریں، ہر ایک کے پاس فوراً موجود ہو جاتا ہے؛ رسائی کے کنٹرول کے لیے اپنے IdP کے ساتھ جوڑیں۔
• ہائبرڈ۔ آف لائن فیلڈ کام کے لیے مقامی ایپس، اُدھار لی گئی مشینوں کے لیے ہمیشہ-تازہ ترین براؤزر ورژن - دونوں ایک ہی ٹول لائبریری کی طرف اشارہ کرتے ہوئے۔

مکمل تعیناتی ماڈلز اور انتظامی تفصیلات تعیناتی اور کنفیگریشن میں موجود ہیں۔

اخراج-مخالف یوٹیلیٹیز

Lolly ٹولز کی ایک قسم - پرائیویسی یوٹیلیٹیز - خاص طور پر فائلوں کو دائرے کے اندر رکھنے کے لیے موجود ہے۔

• پوشیدہ ڈیٹا ہٹائیں

دستاویزات اور میڈیا فائلوں سے مقام اور تمام پوشیدہ شناختی معلومات کو ہٹا دیں۔

• ٹیکسٹ ہیلپر

ساختہ اور غیر ساختہ ٹیکسٹ کو گمنام کریں، encode کریں، فارمیٹ کریں، اور اُس میں ردوبدل کریں۔

• PDF کمپریس کریں

ایک اوور سائزڈ PDF کو آن-ڈیوائس سکیڑیں، تاکہ جیسے ہی کوئی فائل ای میل کرنے کے لیے بہت بڑی ہو جائے کوئی بھی فریقِ ثالث کی "compress my PDF" ویب سائٹ کی طرف نہ جائے - جو کہ عین وہ جگہ ہے جہاں سے ڈیٹا کھڑکی سے باہر نکل جاتا ہے۔

یہ سب آن-ڈیوائس تبدیلیاں ہیں: آپ کی فائل یا ڈیٹا اندر جاتا ہے، صاف کیے گئے bytes باہر آتے ہیں، اور اپ لوڈ کرنے کے لیے کوئی سرور نہیں ہے۔ یہ اُس عام ٹول کے دانستہ برعکس ہیں جسے کوئی نیک نیت ملازم بصورتِ دیگر استعمال کرتا ہے یعنی "اپنی فائل کو صاف کرنے کے لیے کسی اجنبی کی ویب سائٹ پر اپ لوڈ کریں"۔

Text Helper فائلوں کے بجائے متن کے لیے وہی سودا ہے۔ یہ وہی ٹیب والا ورک بینچ ہے جسے کوئی ملازم ورنہ کسی اجنبی کی سائٹ پر تلاش کرنے جاتا، اور یہ ایک بھی ان پٹ بیان نہیں کرتا، کیونکہ جس چیز کو یہ چھوتا ہے وہ کبھی صفحے سے باہر نہیں جاتی۔

Compress PDF اس سیٹ کو مکمل کرتا ہے: بڑے حجم کی اٹیچمنٹ آپ کی چنی ہوئی کوالٹی سیٹنگ کے تحت چھوٹی ہو جاتی ہے — اُسی مشین پر جس میں وہ پہلے سے موجود ہے۔

تعیّن پذیری اور دوبارہ پیدا کرنے کی صلاحیت

ہر ٹول کا input ایک URL پیرامیٹر کے طور پر بیان کیا جا سکتا ہے، اور ایک ہی inputs ایک ہی فائل پیدا کرتے ہیں۔ اِس کے آپریٹر کے لیے دو نتائج ہیں:

• URL ہی مصنوعہ ہے۔ لنک commit کریں، اثاثہ طلب پر دوبارہ تیار کریں - Git میں کوئی binaries شامل نہیں، chat میں "تازہ ترین ورژن" کے پیچھے بھاگنا نہیں۔ اثاثے اور ٹول کے ID مستقل معاہدے ہیں، لہٰذا آج بنایا گیا لنک بعد میں بھی حل ہو جاتا ہے۔
• CLI وہی render راستہ ہے جو GUI کا ہے، لہٰذا build pipelines اور ایپ کبھی الگ نہیں ہوتے۔ OG امیجز، سوشل کارڈز اور ڈیٹا ویژولز build کے وقت، دوبارہ پیدا کیے جا سکنے کے انداز میں تیار کریں۔

Prompt to Image تعیّن پذیری کی سب سے سادہ شکل ہے: متن ہی پورا ان پٹ ہے، ٹائپ سیٹ شدہ تصویر ہی پورا آؤٹ پٹ، اور ایک ہی متن ہمیشہ ایک ہی طرح ترتیب پاتا ہے۔

ماخذ اور Content Credentials

ایکسپورٹس Content Credentials اپنے ساتھ لے جا سکتے ہیں - ایک signed C2PA manifest جو فائل کے bytes کے hash سے منسلک ہوتا ہے۔ فائل میں بعد کی کوئی بھی تبدیلی سِیل کو توڑ دیتی ہے، لہٰذا ایک C2PA-آگاہ verifier تبدیلی کو cryptographic طور پر، آف لائن پہچان لیتا ہے۔ یہ credential چھیڑ چھاڑ کو ظاہر کرنے والا ہے: یہ چھیڑ چھاڑ کو روکنے کے بجائے اُس کی نشاندہی کرتا ہے، اور یہی وہ چیز ہے جو مکمل طور پر آف لائن تصدیق کو ممکن بناتی ہے۔

• بطورِ ڈیفالٹ آن، آن-ڈیوائس۔ signing key آلے پر تیار ہوتی ہے، ناقابلِ اخراج ہوتی ہے (حتیٰ کہ Lolly بھی اِسے پڑھ نہیں سکتا)، اور signing مقامی طور پر ہوتی ہے - صرف اختیاری شناخت کا اندراج ہی نیٹ ورک کو چھوتا ہے۔
• اعتماد کے درجے۔ ایک غیر مندرج ایکسپورٹ ساختی طور پر درست ہوتا ہے لیکن گمنام طور پر signed ہوتا ہے (untrusted)۔ کوئی تصدیق شدہ شناخت درج کریں (Lolly CA سے مختصر مدت کا certificate، جو کسی ای میل سے منسلک ہو) اور Lolly root کو pin کرنے والے verifiers trusted + signer کی ای میل رپورٹ کرتے ہیں۔ ایک قابلِ اعتماد timestamp اتھارٹی اور فریقِ ثالث-validator کی سبز روشنی (C2PA مطابقت) روڈ میپ پر ہیں۔ ہر درجہ واضح ہے، اور کوئی فائل صرف اُتنے ہی اعتماد کا دعویٰ کرتی ہے جتنا وہ ثابت کر سکے۔
• Credential کی مدتِ حیات signing کے وقت آپریٹر/صارف کا فیصلہ ہے: 7 / 30 / 90 / 365 دن، ڈیفالٹ 30۔
• Lolly Imprint۔ ایک دوسرا، تکمیلی سگنل جو بطورِ ڈیفالٹ آن ہے: ایک غیر مرئی پکسل واٹر مارک جو raster ایکسپورٹس میں (اور PDF/PPTX کے اندر Lolly کے بنائے گئے rasters میں، کبھی صارف کی اپنی embedded تصویر میں نہیں) پکایا جاتا ہے۔ جہاں credential کسی بھی container تبدیلی پر ختم ہو جاتا ہے، وہاں Imprint دوبارہ محفوظ کیے جانے یا اسکرین شاٹ کے بعد بھی برقرار رہتا ہے - ایک دیرپا "یہ پکسلز Lolly سے گزرے ہیں" اشارہ، صرف موجودگی بتانے والا، کوئی ذاتی ڈیٹا شامل نہیں۔ یہ security-through-obscurity ہے، کوئی سخت دفاع نہیں، اور credential کی جگہ لینے کے بجائے اُس کی تکمیل کرتا ہے۔ imprint=0 سے اِس سے دستبردار ہوا جا سکتا ہے۔
• Durable Content Credentials (اختیاری)۔ ایک raster ایکسپورٹ اضافی طور پر ایک غیر مرئی durable نشان لے جا سکتا ہے جو ایک soft-binding شناخت کنندہ (identifier) کو encode کرتا ہے، تاکہ C2PA credential اُس صورت میں بھی بازیاب کیا جا سکے جب کسی سوشل اپ لوڈ یا دوبارہ محفوظ کیے جانے نے فائل کا metadata ہٹا دیا ہو - وہ صورتِ حال جہاں ایک عام credential ضائع ہو جاتا۔ یہ صرف raster کے لیے ہے اور اِس کے لیے ایک neural-encode پاس درکار ہوتا ہے، اِس لیے یہ بطورِ ڈیفالٹ آف ہے (اِسے آن کرنے کے لیے durable=1)۔ Lolly آج اپنے durable نشان کو /verify پر آف لائن پہچان لیتا ہے؛ فریقِ ثالث ٹولز (مثلاً Adobe) کی طرف سے بازیابی صنعت کی soft-binding resolution طے ہونے کے بعد آئے گی۔
• تصدیق آن-ڈیوائس ہے۔ کسی بھی فائل کو /verify پر ڈراپ کریں (یا lolly validate <file> چلائیں) تاکہ ایک آف لائن رپورٹ مل سکے کہ آیا یہ واقعی Lolly سے بنائی گئی تھی اور تب سے غیر تبدیل شدہ ہے۔ ویب کا Verify منظر AI سے تیار کردہ مواد کی بھی نشاندہی کرتا ہے، Lolly Imprint کا پتا لگاتا ہے، SEAL دستخطوں کی تصدیق کرتا ہے (ایک byte-level دستخط جو DNS میں key رکھتا ہے - نیٹ ورک کو صرف ایک DNS key lookup چھوتا ہے، کبھی فائل نہیں)، اختیاری طور پر فریقِ ثالث پکسل واٹر مارکس کے لیے deep-scan کرتا ہے (ایک بار کا آن-ڈیوائس ماڈل ڈاؤن لوڈ)، اور پوشیدہ ڈیٹا سامنے لاتا ہے - یہ سب کچھ فائل اپ لوڈ کیے بغیر۔ دیکھیں Content Credentials کی شناخت۔

باہمی تعامل کے نوٹس۔ Lolly آج اپنی credentials اور بہت سی فریقِ ثالث credentials کو آف لائن تصدیق کرتا ہے، بشمول دیگر پروڈیوسرز کے C2PA claim v2 manifests پڑھنا۔ باہمی تعامل کا ایک معاملہ ابھی جاری ہے: WebM - جس کی ابھی تک کوئی معیاری C2PA میپنگ نہیں ہے، لہٰذا Lolly manifest کو ایک Matroska حصے کے طور پر منسلک کرتا ہے (فریقِ ثالث ٹولز Lolly کے MP4 کی بغیر کسی اضافی سیٹنگ کے تصدیق کرتے ہیں؛ WebM معیار طے ہونے کے بعد آئے گا)۔

Encryption اور پاس ورڈنگ

اُن فائلوں کے لیے جنہیں مقفل حالت میں سفر کرنا ہو، سب کچھ آن-ڈیوائس ہوتا ہے:

• PDF اوپن-پاس ورڈ - Standard ایک 40-bit RC4 رکاوٹ ہے (کہیں بھی کھلتی ہے، لنک میں سفر کر سکتی ہے)؛ Strong AES-256 ہے (PDF 2.0)، جو ایکسپورٹ کے وقت ٹائپ کیا جاتا ہے اور کبھی لنک میں نہیں ڈالا جاتا۔
• مقفل ڈاؤن لوڈز - ایک ZIP، ایک Projects فولڈر، یا ایک batch رن مکمل طور پر مقفل کیا جا سکتا ہے: Standard ZipCrypto (کمزور، عالمگیر) یا Strong AES-256 (WinZip AE-2)۔ تہ در تہ دفاع: کسی Strong zip کے اندر کوئی بھی PDF علیحدہ طور پر بھی AES-256 سے مقفل ہوتا ہے، لہٰذا unpack کرنے کے بعد بھی مقفل رہتا ہے۔
• پاس ورڈ سے محفوظ شیئر لنکس - پورا لنک اسٹیٹ ایک PBKDF2-اخذ کردہ key کے تحت AES-256-encrypted ہوتا ہے؛ صرف ciphertext سفر کرتا ہے، پاس ورڈ کبھی لنک میں نہیں ہوتا، اور decryption وصول کنندہ کے براؤزر میں ہوتی ہے۔

Air-gap کے لیے تیار

Air-gap ایک اولین درجے کی تعیناتی ہے، کوئی خاص موڈ نہیں - Lolly render کے وقت بغیر کسی نیٹ ورک کے شروع سے ہی چلتا ہے۔ ویب شیل ایک offline-first PWA ہے (service worker)؛ fonts اور WASM آن-ڈیوائس محفوظ ہوتے ہیں؛ ٹول اسٹیٹ host bridge کے ذریعے مقامی طور پر محفوظ رہتا ہے، کبھی localStorage میں نہیں۔ کوئی بھی ٹول جو نیٹ ورک تک پہنچتا ہے وہ صرف ایک allowlisted host.net صلاحیت کے ذریعے ایسا کرتا ہے جسے اُسے اپنے manifest میں اعلان کرنا ہوتا ہے - ایک شیل جو اِسے پورا نہیں کر سکتا (یا نہیں کرے گا) اُسے stub کر دیتا ہے۔ شیلز کو اپنے MDM کے ذریعے آلات تک پہنچائیں، یا اپنے نیٹ ورک کے اندر ایک instance serve کریں، اور ایک مکمل طور پر air-gapped انسٹال بغیر کسی جگہ رابطہ کیے render، ایکسپورٹ، encrypt اور credentials کی تصدیق کرتا ہے۔

جاننے کے لیے مفید

اِسے رول آؤٹ کرنے سے پہلے چند باتیں واضح کر لینا مفید ہے:

• ہارڈننگ جاری ہے۔ cryptography اور parsers SUSE کی انٹرپرائز-پیمانے کی ہارڈننگ سے گزر رہے ہیں (اوپر دیکھیں) - آج بنیادی ڈیزائن کے لحاظ سے مضبوط؛ جہاں کوئی معاہدہ تصدیق شدہ یقین دہانی کا تقاضا کرے وہاں تہ در تہ دفاع کے طور پر تعینات کریں۔
• *ٹول hooks ایک سکیورٹی sandbox نہیں ہیں۔ کسی ٹول کی اختیاری hooks.js host bridge کے inject ہونے کے ساتھ چلتی ہے، لیکن ایک براؤزر شیل میں یہ صفحے کے realm میں چلتی ہے اور window/document/fetch تک پہنچ سکتی* ہے۔ ٹول کوڈ کے ساتھ ویسا ہی سلوک کریں جیسا آپ کسی بھی کوڈ کے ساتھ کرتے ہیں جسے آپ چلاتے ہیں - اِس کا جائزہ لیں۔ یہی وجہ ہے کہ ایک ایسی تنظیم جو مشترکہ کیٹلاگ چلاتی ہے اُسے Git جائزے کے ذریعے کنٹرول کر سکتی ہے؛ کسی بھی صورت، صرف وہی ٹولز چلائیں جن کا آپ نے جائزہ لیا ہے جب تک Worker isolation نہ آ جائے۔
• Content Credentials چھیڑ چھاڑ کو ظاہر کرتے ہیں۔ یہ تبدیلی کو روکنے کے بجائے اُس کی نشاندہی کرتے ہیں - اوپر باہمی تعامل کے نوٹس دیکھیں۔
• دو encryption درجے۔ Standard تالے تیز، عالمگیر رکاوٹیں ہیں؛ Strong (AES-256) مکمل تحفظ ہے - کسی بھی حساس چیز کے لیے Strong کا انتخاب کریں، یہ نوٹ کرتے ہوئے کہ اِسے ایک جدید reader درکار ہے۔

آگے کہاں جائیں

• اپنانا اور گورننس - personas، رخ موڑنے کا میٹرک، اور مکمل طور پر گورننس-بطور-ڈیٹا۔
• تعیناتی - deploy/serve/hybrid، MDM، اور خدمات کی self-hosting۔
• کنفیگریشن - profiles، برانڈ پیکس، صلاحیت gating، اور feature flags۔
• پرائیویسی پالیسی - رسمی "کچھ جمع نہیں کرتا، کچھ اپ لوڈ نہیں کرتا" بیان۔