نظرًا للوائح الخصوصية الأوروبية، من الأفضل تجنب الطلبات إلى نطاقات طرف ثالث التي يبدأها موقع تستضيفه. من الصعب تحقيق الامتثال مع Discourse، حيث تجعل ميزة Onebox المتصفح يجلب الصورة المصغرة من الموقع الأصلي، مما يجعلها طلبًا من طرف ثالث. انظر المقالة المضمنة أدناه:
يمكنك رؤية في أدوات المطور أن الصورة يتم تنزيلها من موقع طرف ثالث. كما تشير المقالة، إنها مشكلة تتعلق باللائحة العامة لحماية البيانات (GDPR) حتى لو لم يكن للطلب ملفات تعريف ارتباط.
حاليًا، قمت بتعطيل Onebox لمثيلي من Discourse، ولكني أود إعادته بطريقة تحترم الخصوصية بشكل أكبر ولا تفتح مجالًا للحصول على غرامة.
يمكن تقديم الصور من نطاق رئيسي، أو نطاق مخصص مثل cdn.mydomain.com.
لا يمكنك حفظ صور الطرف الثالث على إعداداتك الخاصة بسبب حقوق النشر التي يصعب التعامل معها مع الصور (وهذا يجعل ميزة واحدة من Discourse مشكوك فيها إلى حد ما، ولكن هذه قصة أخرى). لكن Oneboxing لا يتعارض مع اللائحة العامة لحماية البيانات ولم يكن كذلك أبدًا. لكي تكون في الجانب الآمن، من الحكمة الإشارة إلى وجود طرف ثالث متورط عن طريق الربط، وأن اتباع اللائحة العامة لحماية البيانات هو مسؤوليتهم. ولكنك لا تحتاج إلى ذلك أيضًا.
Oneboxing لا تخدم طرفًا ثالثًا. وتسمح اللائحة العامة لحماية البيانات (GDPR) باستخدام خطوط Google، ويجب أن تخبر المستخدمين - وجوجل تتبع اللائحة العامة لحماية البيانات أيضًا.
لكن هذه ليست مسألة اللائحة العامة لحماية البيانات على الإطلاق. الإطارات المضمنة (Iframes) هي كذلك.
لا يتعلق الأمر كثيرًا بـ “إخبار” المستخدمين بقدر ما يتعلق بوجود أساس قانوني، مثل الموافقة أو المصلحة المشروعة. مع الموافقة، يجب أن يكون لديك طريقة مريحة لرفض الموافقة، ثم لا يتم تحميل المورد. مع المصلحة المشروعة، يجب عليك إجراء تقييم للمصلحة المشروعة، وأنا (ويمكنني تخيل العديد من مسؤولي استضافة Discourse الآخرين) أفضل عدم القيام بذلك وبدلاً من ذلك إما تعطيل oneboxing تمامًا، أو إخفاء عنوان IP الخاص بالمستخدم خلف وكيل.
الأمر يتعلق بالضبط بالإخبار. أنت بحاجة إلى موافقة عند جمع البيانات الشخصية للمستخدم أو استخدامها أو تخزينها. وحتى في هذه الحالة، يجب عليك إخبار بما تفعله، ولماذا تفعله، ومدة قيامك به.
لا يُعد Oneboxing جزءًا من ذلك، ولكن يجب عليك الإخبار بذلك إذا كان طرف ثالث متورطًا. و Oneboxes هي مجرد روابط رائعة.
ما قصدته هو: الكشف عن حقيقة أن طلبات الطرف الثالث ليست كافية. بموجب اللائحة العامة لحماية البيانات (GDPR)، يجب عليك تقديم:
الغرض من معالجة هذه البيانات
الأساس القانوني لهذه المعالجة
لا يمكننا استخدام الموافقة، لأن Discourse لا يسمح بعرض الصور الخارجية في الروابط المضمنة فقط للمستخدمين الذين وافقوا على ذلك. ولا يزال الاهتمام المشروع يتطلب إشراك محامٍ في العملية لإجراء اختبار الموازنة بشكل صحيح. سيكون الأمر أسهل بكثير لو لم نضطر إلى القيام بذلك لأن البرنامج لم يجعل المتصفح يرسل طلبات إلى أطراف ثالثة (والتي لا يمكننا حتى إدراجها في سياسة الخصوصية، أو الإشارة إلى سياسات خصوصية تلك الأطراف الثالثة، لأنها يمكن أن تكون أي شخص حرفيًا على الإنترنت).
كما هو موضح في اللائحة العامة لحماية البيانات (GDPR)، فهي ليست مجرد روابط، لأن المتصفح يزورها دون إجراء من المستخدم.
(بالمناسبة، أنا لا أستقي هذا من فراغ، فأنا أعمل في مجال الامتثال للائحة العامة لحماية البيانات (GDPR) في حياتي المهنية ولدي خبرة عملية في كيفية عمل الشكاوى والغرامات في الاتحاد الأوروبي)
بصرف النظر عن المناقشات القانونية، هناك مستخدمون يحظرون الموارد الخارجية للأطراف الثالثة خصيصًا لغرض عدم الكشف عن عناوين IP وعادات التصفح الخاصة بهم للأطراف الثالثة. سيكون من الجيد لو عملت الروابط المضمنة لهم
بصرف النظر عن الاعتبارات القانونية، أعتقد أنه سيكون من المفيد القيام بشيء في هذا المجال.
ومع ذلك، أميل إلى القول بأن الحل هو بالأحرى أن نطلب من المستخدم الموافقة الصريحة لعرض الوسائط الخارجية. لقد تبنت العديد من المواقع الألمانية التي أزورها ممارسة طلب ذلك من المستخدمين بشكل خاص (مثال أدناه).
أعتقد أنه بالإضافة إلى ذلك، سيكون من الجيد وجود معاينات صور ثابتة يتم تقديمها مباشرة من مضيف Discourse، ولكن أميل إلى القول بأن الموافقة الفعلية هي الخطوة الأكثر أهمية.
مثال (Golem.de، موقع أخبار تكنولوجيا المعلومات الألماني):
أنا فضولي بشأن هذا. يمكنني فهم مشكلة Google Font لأنها تتطلب فعليًا جلب الخط من خادم Google لكل مستخدم.
ولكن في تجربتي مع “Onebox”، يظل معاينة الرابط ثابتة ما لم تقم بإعادة بناء الـ HTML. ما أعنيه بذلك. هو أنه في تجربتي، يظل الـ Onebox بنفس معلومات المعاينة حتى لو قام المصدر بتغيير المعلومات على الصفحة.
كان هذا مفيدًا عندما يغير موقع ما معلومات الصفحة بشكل كبير. ظلت معلومات معاينة الـ Onebox الخاصة بي دون تغيير دون إعادة بناء المنشور عبر المفتاح.
لقد بقيت بعض الـ Oneboxes القديمة سليمة على الرغم من أن الموقع الأصلي المرتبط لم يعد يحتوي حتى على المحتوى المرتبط.
من ناحية أخرى، أعتقد أن الـ Iframes يتم تحديثها بالطريقة التي حددتها كما ذكر @Jagster على أنها معاينة حية عند العرض لكل مستخدم كما هو الحال مع جلب خطوط Google.
على الأقل حسب فهمي. هل تخمن أنك ستحتاج أيضًا إلى تعطيل التضمينات أيضًا؟
أتخيل أنه يمكن إنشاء إضافة لإضافة ميزة مثل الميزة أدناه.
أفهم لماذا يقول صديقي الألماني هنا في كندا أنه من الأفضل منع الاتحاد الأوروبي.
كما قال @Firepup650 أعلاه، هذا ليس هو الحال على الإطلاق، حيث يقوم Discourse تلقائيًا بتنزيل وتقديم الصور التي تم عمل Onebox لها، وهذا هو الإعداد الافتراضي حتى.
يمكنك حتى جعل هذا أكثر صرامة عن طريق تبديل block hotlinked media.
كانت المشكلة مشكلة Google، التي لم تتبع اللائحة العامة لحماية البيانات (GDPR). كان هذا أحد أجزاء القضية التي دفعت Google إلى فرض غرامة كبيرة جدًا على الاتحاد الأوروبي. لكنها لم تكن مشكلة للمواقع التي استخدمت خطوط Google و AdSense وما إلى ذلك. لهذا السبب كانت Google في المحاكمة، وليس أولئك الذين قدموا تلك الخدمات.
أتفهم الإحباط - فالعديد من الأشياء التي يقوم بها الاتحاد الأوروبي تكون ذات نوايا حسنة، ولكنها ليست بالضرورة منفذة بشكل جيد وغالبًا ما تعقد الأمور للمطورين.
في هذه الحالة المحددة، أحب ما طبقه الأشخاص، لأنه يمنح المستخدم خيارًا بسيطًا ولكنه ذو مغزى.
إذا كان يمكن القيام بذلك في مكون إضافي، فهذا أفضل. افترضت أنه سيحتاج إلى القيام به في النواة لأنه يعمل عبر جميع الـ oneboxes.
تبدأ الأسباب أو الأسباب الوهمية في الخروج عن الموضوع. ولكن هذه اللوائح هي أشياء تسبب مشاكل في الولايات المتحدة. وهذه اللوائح ضرورية لأن الشركات الأمريكية الضخمة لم تحترم خصوصية المستخدمين على الإطلاق، لأنه لا توجد لوائح في الولايات المتحدة. أو هل يجب أن أقول الآن… لأن حياة المطورين ليست معقدة جدًا
لذلك، لا تشكر الاتحاد الأوروبي. أرسل بطاقات شكر إلى Google و Amazon و Microsoft و X و Apple وما إلى ذلك. وفي نفس الوقت، يمكنك التفكير فيما هو مشترك بينهم.
بالمناسبة، تلقيت رسالة تفيد بأنه لا ينبغي لي السماح لأي شخص دون سن 13 عامًا بالدخول إلى منتدى الخاص بي. بالتأكيد سأسمح لهم بالدخول، حتى من كاليفورنيا، إذا كانوا يستطيعون قراءة اللغة الفنلندية
انتهى (لماذا لا يوجد رمز تعبيري لإسقاط الميكروفون…)
أنا لا أجادل في الحاجة إلى التنظيم - كل ما أقوله هو أن الخطوة من “سنقوم نحن وشركاؤنا الموثوق بهم البالغ عددهم 999 بسرقة بياناتك” إلى نافذة منبثقة كبيرة تقول “انقر هنا للموافقة على أننا وشركاؤنا الموثوق بهم البالغ عددهم 999 سنقوم بسرقة بياناتك” تبدو أحيانًا انتصارًا باهظ الثمن، وأنا أتفهم كيف يجعل ذلك بعض الناس يحكّون رؤوسهم
ولكن بالعودة إلى الموضوع الرئيسي: @kuba-orlik، إذا كان هذا يناسبك، فأقترح إعادة صياغة طلب الميزة إلى “توفير خيار لطلب موافقة المستخدم قبل عرض الوسائط الخارجية” (سأصوت لصالحه، حينها).
إذا كنت تشعر أن العنوان الحالي يناسب طلبك بشكل أفضل، فهذا جيد أيضًا. في هذه الحالة، ربما سأفتح طلبًا آخر بنفسي.
حسنًا، لقد وصل الأمر إلى أقصى الحدود بجنون. ما لم يتغير أو يتم تحريفه، أتذكر أنني قرأت أن الشركة قد تحتاج إلى احترام الضمان على الأجهزة، على سبيل المثال، حيث قام المستخدم النهائي بإتلافها عن طريق تفكيكها ومحاولة إصلاحها.
المشكلة الأكبر هي أنها ذهبت إلى أقصى الحدود لحماية الناس من الحماقة المطلقة.
حسب فهمي، يمكن لمكون إضافي بالفعل تحقيق ذلك لأنه يعدل عناصر النواة على جانب الخادم مقابل مكون سمة يعدل الأشياء على جانب العميل/المتصفح؛ نصوص Tampermonkey تشبه إلى حد ما السمات/المكونات المثبتة على جانب المتصفح. كنت أستخدم نص Tampermonkey على لعبة متصفح قديمة تسمى Fallen Sword لتعديل كيفية ترتيب العناصر في السوق.
ملاحظة جانبية مثيرة للاهتمام: لم أتلق إشعارات لهذا الموضوع.
