اخلاق در فناوری - بلندانیوز

به گزارش خبرنگاران به نقل از ایتنا،با اینکه جهان فناوری همیشه از قدرت بالایی برخوردار بوده، اما اغلب توان مهار این قدرت زیاد را نداشته است. حقیقت این است که نرم افزارها نوشته می شوند؛ اما چه کسی اهمیت می دهد که کجا و چگونه مورد استفاده قرار می گیرند؟ با این که درس های مربوط به اخلاق حرفه ای در برنامه های درسی برخی از رشته هایی مهندسی گنجانده شده، اما هنوز هم در زمینه رشته های علوم کامپیوتر جای خالی چنین بحثی احساس می گردد. با این وجود و با توجه به این که نرم افزارها هر روز نقش بیشتری در زندگی ما بازی می نمایند، برنامه نویسان باید مسئولیت بیشتری بر دوش خود احساس نمایند. امروزه که کدهای برنامه نویسان در هر جا از جمله یخچال ها، ترموستات ها وجود دارند، هرگونه حرکت اشتباه، نبود بینش یا عدم تصمیم گیری صحیح و به جا می تواند در جایی که کد هست، انسانیت را هم به خطر بیندازد.

آنچه که در پی می آید، چالش هایی اخلاقی هستند که امروزه توسعه دهندگان با آنها روبه رو می باشند؛ خواه خودشان بدانند یا ندانند. از آنجا که طبیعت کار برنامه نویسی بسیار مجرد و انتزاعی است، شاید هیچ پاسخ ساده ای به این چالش ها وجود نداشته باشد. از این بدتر، از آنجا که کسب وکار امروزی با فناوری کامپیوتری گره خورده، به سختی می توان میان نیازها و انگیزه های لازم تمام طرف های درگیر، تعادل برقرار نمود و بنابراین (همان گونه که جورج اُروِل هم در کتاب خودش به تصویر کشیده)، با یک کابوس روبه رو نشد.

شاید بهتر باشد فراتر از زرق وبرق های امروزی فکر کنیم و مصرف آینده آنچه را که امروز بنا می کنیم، درنظر داشته باشیم. کار ساده ای است، این طور نیست؟ می توانید این مقاله را به عنوان نقطه آغازی برای تصمیم گیری های خود در مورد چالش های اخلاق حرفه ای در علوم کامپیوتر مدنظر داشته باشید و از آن استفاده کنید.

چالش شماره 1: فایل های ثبت (log)؛ چه چیزی باید ثبت و ذخیره گردد و چگونه باید از آنها استفاده کرد؟

برنامه نویسان شبیه به برخی از موش ها هستند؛ آنها از هر چیزی یک رکورد و سابقه نگهداری می نمایند و علت آن هم اغلب این است که در موقع لزوم، این کار را تنها راه اشکال زادایی (debugging) از یک سیستم می دانند. اما فایل های log همچنین می توانند هر کاری را که یک کاربر انجام داده، ردیابی نمایند و اگر در دست افراد نامناسب قرار بگیرند می توانند رازهای کاربران را برملا نمایند.

بسکمک از کسب وکارها هستند که به طور فعال و کنش گرانه از فایل های log محافظت می نمایند. حتی برخی از سرویس های تهیه فایل پشتیبان از راه دور نیز وعده می دهند که کپی های اضافی از این اطلاعات را در مکان های جغرافیایی مختلفی قرار می دهند. برای مثال، شرکت Snapshot برای تهیه فایل های پشتیبان از داده ها تأسیس شد و کاربرانی که از فراموشکاری سیستم های خود در به یاد نیاوردن اطلاعات به ستوه آمده بودند، از ایده و کار این شرکت استقبال کردند.

صرف وجود و حضور فایل های log، پرسش های اخلاقی زیادی به پیش می کشد؛ از جمله این که آیا آنها به اندازه کافی محافظت می شوند؟ چه کسی به آنها دسترسی دارد؟ وقتی می گوییم این فایل ها را نابود می کنیم، آیا واقعاً آنها را نابود می کنیم؟ مسئله اصلی این است که چه اطلاعاتی ارزش نگهداری را دارند.

در اینجا، مسئله آینده معادله را پیچیده تر می نماید. در دهه 60 میلادی، کشیدن سیگار در ایالات متحده مورد استقبال قرار می گرفت؛ اما هیچ کسی به فکر نگهداری سابقه و ردیابی عادات سیگار کشیدن مردم نبود. اما امروزه اطلاع از سیگار کشیدن افراد می تواند برای افزایش نرخ بیمه سلامت، یا حتی عدم پوشش بیمه آنها مورد استفاده قرار بگیرد. نمی توان به درستی پیش بینی کرد که این فایل های log بی گناه، چه موارد استفاده ای در آینده پیدا خواهند کرد؛ اما درنظر دریافت اخلاق در نحوه به کارگیری آنها، از اهمیت زیادی برخوردار است.

چالش شماره 2: چگونه می توان کاربران را به محصولات تبدیل کرد؟

در زمانی که شرکت های تازه کار فناوری یکی پس از دیگری تأسیس می شدند، این ضرب المثل به وجود آمده بود: اگر برای یک سرویس پولی پرداخت نمی کنید، شما مشتری نیستید؛ بلکه محصول هستید. سرویس های رایگان به وفور در اینترنت یافت می شوند. در حقیقت آن قدر زرق وبرق و شگفتی های خدمات اینترنتی رایگان ما را مجذوب خود می نمایند که یادمان می رود از خود بپرسیم پس این سرویس های رایگان از کجا پول به دست می آورند.

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

چالش شماره 3: محتوا تا چه حد باید رایگان باشد؟

تعدادی از کسب وکارها هستند که بدون دریافت پول، محتوا تولید می نمایند. برخی از آنها آگهی می فروشند، یا حتی برخی از آنها برای دسترسی به محتوا، پول دریافت می نمایند. این کسب وکارها اغلب نمی توانند به بقای خود ادامه دهند و نمی توانند روی سرویس خود قیمت گذاری نمایند.

توسعه دهندگان باید از خودشان بپرسند که کد آنها چگونه از همه پشتیبانی می نماید؛ از سازنده آن گرفته تا مصرف نماینده. آیا کسانی که محتوا تولید می نمایند، دوست دارند که کارشان به این طریق توزیع گردد؟ آیا تنها اینکه کارشان در دسترس دیگران قرار بگیرد و مورد توجه باشند، برایشان کافی است؟ آیا درآمدی منصفانه دارند؟

درنظر ندریافت این پرسش ها منجر به دزدی محتوا می گردد و باعث می گردد مردم چشم خود را در برابر دزدی بسته نگه دارند. از این گذشته، قرار نیست اطلاعات و دسترسی به آن، تماماً رایگان باشد.

چالش شماره 4: چه میزان از محافظت لازم است؟

برخی می گویند باید هرچیزی با دو الگوریتم مختلف، دو بار رمزگذاری گردد و سپس روی یک هارددیسک ذخیره گردد و آن هم در یک گاوصندوق قرار داده گردد. اما این کار باعث کاهش سرعت کار می گردد و فرایند توسعه را ده برابر سختتر می نماید. بدتر از این، اگر یک بیت یا بخشی از الگوریتم اشتباه باشد، تمام اطلاعات از دست می رود؛ چرا که رمزنگاری قابل بازگشت (undo) نیست.

از سوی دیگر، محافظت از داده ها برای دیگران اهمیتی ندارد. در واقع، گروه توسعه دهنده بعدی در صورت لزوم می تواند کار رمزنگاری را انجام دهد. این ممکن است حرف توسعه دهندگان باشد، یا حتی ممکن است بگویند که لازم نیست در این مورد حساسیت زیاد به خرج داد.

گروه هایی که از این مسئولیت ها غفلت می نمایند، معمولا قادر هستند کدهای دیگری تولید نمایند و ویژگی های جالبی ایجاد نمایند که برای مردم جذابیت دارند و مردم از آنها استقبال می نمایند. اما واقعاً چه کسی اهمیت می دهد که این کدها ایمن هستند یا نه؟ برای میزان محافظت، هیچ پاسخ ساده ای وجود ندارد. تنها برخی حدس ها در این زمینه وجود دارد. البته امنیت بیشتر، همیشه بهتر است.

چالش شماره 5: اشکال زدایی بکنیم یا نکنیم؟

بحث راجع به چالش های اخلاقی در هنگام دریافت تصمیم های فعال، به اندازه کافی سخت است و وقتی که در کناری گذاشته می شوند و برچسب دارای اشکال می خورند تا این که نهایتاً اشکال زدایی شوند، مسئله حتی سختتر هم می گردد. برای حل مسائلی که در کد به وجود می آیند، چقدر باید کار کنیم تا آنها را حل کنیم؟ آیا باید تمام کد را کنار بگذاریم؟ چگونه متوجه می شویم که آیا یک اشکال، به اندازه کافی جدی هست که آن را رفع نماییم یا نه؟

سال ها پیش آیزاک آسیموف هنگامی که قوانین روباتیک را می نوشت، با چنین مسئله ای روبه رو بود. یکی از قوانین او، از این قرار بود که روبات نباید کاری انجام دهد که موجب آسیب رساندن به انسان ها گردد. البته روبات های آسیموف دارای مغزهایی بودند که می توانستند به طور آنی مسئله را حل نمایند. اما این پرسش ها در مورد توسعه دهندگان آنقدر پیچیده هستند که از بسکمک از اشکال ها غفلت می گردد و حل نشده باقی می مانند؛ چون هیچ کسی دوست ندارد حتی در مورد آنها کمی فکر کند.

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

چالش اخلاقی شماره 6: برای جلوگیری از سوءاستفاده، تا چه حد باید کدنویسی کرد؟

دوربین وب که اپل در ابتدا روانه بازار کرد، دارای یک جزء مکانیکی اضافی بود؛ یک شاتر که در هنگام تمام شدن کار دوربین، لنز آن را می بست. شاتر و سوییچِ مربوط به آن، با هم لینک بودند و بدون باز کردن شاتر نمی شد از دوربین استفاده کرد. برخی از وب کم های امروزی دارای یک LED هستند که در هنگام کار دوربین مورد استفاده قرار می گیرند. ایده جالبی است؛ اما کسی که کار برنامه نویسی کامپیوتری انجام داده باشد، می داند که ممکن است در جایی از کد، اتصال میان دوربین و LED از بین برود. اگر این جا پیدا گردد، دوربین می تواند به عنوان یک ابزار جاسوسی مورد استفاده قرار بگیرد.

چالشی که یک مهندس با آن روبه روست، پیش بینی موارد سوءاستفاده از کد و تلاش برای جلوگیری از آن است. شاتر اپل، یکی از مثال های شاخص و کارآمد است که نشان می دهد این طراحی تا چه حد می تواند بهینه و ظریف باشد. پیش تر، هکری را دیده بودم که تلاش می کرد یک نرم افزار شبکه به ماشین حساب خودش اضافه کند. پس از کمی فکر، تصمیم گرفت سیستم وی تنها از پروتکل های سیمی (wired) پشتیبانی کند؛ چون از آن نگران بود که ممکن است نوجوانان، یک ماشین حساب با قابلیت وای فای را با خود سر جلسه امتحان ببرند. او با پشتیبانی از پروتکل سیمی، اطمینان حاصل کرد که اگر کسی بخواهد از این ماشین حساب استفاده کند، باید به وسیله یا دستگاه کناری خود سیم وصل کند که البته ریسک سوءاستفاده از آن بسیار بالا است.

چالش شماره 7: تا چه حد می توان از مشتریان دربرابر درخواست جمع آوری اطلاعات، دفاع کرد؟

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

می توان این درخواست ها را وارسی کرد یا حتی از یک وکیل کمک گرفت تا ببینید اینها تا چه حد از مشروعیت قانونی برخوردار هستند. اما مسئله این است که زور دادگاه ها بیشتر از افراد است و آنها کار خود را به پیش می برند. در این زمینه هیچ راه چاره ساده ای وجود ندارد. برخی از شرکت ها ترجیح می دهند دست از کسب وکار بکشند و به مشتریان خود دروغ نگویند. اما برخی دیگر بیشتر مایل هستند با آغوش باز از چنین درخواست هایی استقبال نمایند.

چالش شماره 8: با سرشت بین المللی و فرامرزی اینترنت چه باید کرد؟

اینترنت از مرزهای جغرافیایی عبور می نماید و در همه جا حضور دارد. این مسئله می تواند برای مشتریان (الف) و (ب) که در کشورهای مختلفی زندگی می نمایند، یک چالش حقوقی باشد. اما مسئله به همین جا ختم نمی گردد؛ چون ممکن است سرورهای (پ) و (ت) هم در کشورهای مختلفی باشند. این امر به مسائل اخلاقی آشکار منجر می گردد.

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

چالش شماره 9: به اوپن سورس چقدر باید اهمیت داد؟

همه می دانند که فناوری اوپن سورس رایگان است؛ یعنی لازم نیست برای آن هیچ پولی پرداخت گردد و همین مسئله است که آن را جالب و در عین حال پیچیده می سازد. ولی افراد کمی هستند که موارد اخلاقی کد مجانی و رایگان را مدنظر قرار می دهند. همه بسته های اوپن سورس، دارای مجوزهایی هستند که باید آنها را اجرا کرد.

برخی از این مجوزها، چیز زیادی از کاربران نمی خواهند. مجوزهایی همچون Apache یا MIT از این دسته هستند. اما سایر مجوزها همچون مجوز عمومی GNU از شما می خواهند تا تمام بهبودها و توسعه های خود را با دیگران نیز به اشتراک بگذارید. تخطی از مجوزهای اوپن سورس، می تواند چالش هایی اخلاقی ایجاد کند.

زمانی یکی از این مدیران یکی از شرکت های بزرگ به من گفت: ما MySQL را توزیع نمی کنیم و بنابراین به هیچ کسی هم بدهکار نیستیم. او دست روی مسئله مهمی می گذاشت که دهه ها پیش نوشته شده بود؛ یعنی تعهد توزیع مجدد نرم افزار. این شرکت برای برنامه های کاربردی وب خود، از MySQL استفاده می کرد و تصور می کرد که نباید آن را دوباره توزیع کند.

هیچ راه ساده ای برای سنجش تعهدات اخلاقی وجود ندارد و بسکمک از برنامه نویسان شاید وقت خود را تلف کرده اند و صفحه ها در مورد شرایط و موارد استفاده از نرم افزار، قلم فرسایی یا به عبارت بهتر صفحه کلیدفرسایی کرده اند. با این وجود، اگر مردم از توزیع مجدد نسخه هایی که خودشان آنها را بهبود و ارتقاء می دهند، پرهیز نمایند، تمام تلاش اوپن سورس به بن بست خواهد انجامید. جالب آن که در اغلب موارد، این گونه مشارکت ها به نفع همه است؛ زیرا همه دوست دارند نرم افزار اصلی، با موارد استفاده آنها سازگاری داشته باشد.

چالش شماره 10: چه میزان از سرکشی و نظارت لازم است؟

شاید رئیس شرکت شما مایل باشد اطمینان حاصل کند که همه کارمندان کارشان را به درستی انجام می دهند. ممکن است شما هم بخواهید اطمینان حاصل کنید که برای کاری که انجام می دهید، پول دریافت می کنید. شاید این ایده برای شما مطرح گردد که برای گرفتار کردن افراد خلافکار، بهتر است از یک تله (در پشتی) استفاده کنید. اما در هر صورت، باید اطمینان حاصل نمایید که این در پشتی (همچون قدرت سوپرمن) تنها برای حقیقت و عدالت مورد استفاده قرار می گیرد. اما اگر خلافکاران متوجه وجود همچین در پنهانی شوند و خودشان از آن سوءاستفاده نمایند، چطور؟ اگر در پنهانی شما، برای دروغ و بی عدالتی مورد سوءاستفاده قرار بگیرد، چطور؟ کد شما نمی تواند در مورد مسائل اخلاقی تصمیم گیری کند؛ این کار شماست که تصمیم گیری کنید.

چالش شماره 11: یک کد تا چه حد باید ایمن از آسیب باشد؟

مطمئناً در زمانی که مسائل کوچک هستند، محاسبات مینیمال، ساختمان داده ها ساده، و رویکرد غیرمستقیم و brute force بهترین جواب را می دهند. کاربران کد خود را امتحان می نمایند و می گویند: خدای من، چقدر سریع عمل می نماید! اما چند ماه بعد، وقتی که به اندازه کافی داده وارد سیستم شده، نقاط ضعف الگوریتم مشخص می شوند و کد نهایتاً زمین گیر می گردد. توسعه دهندگان اغلب باید تصمیم بگیرند که تا چه حد باید مجدّانه روی محصول نهایی کار نمایند.

آیا بهتر است از راه چارهی ساده و دم دستی استفاده نمایند، یا این که هفته ها وقت صرف تقویت کد خود بنمایند؟ درست است که مشتریان و کاربران باید جوانب احتیاط را رعایت نمایند و از برنامه ها sign-off نمایند؛ اما توسعه دهندگان نیز باید مراقب چنین مواردی باشند و آنها را از قبل پیش بینی نمایند.

چالش شماره 12: پیامدهای آینده، تا چه حد روی تصمیمات کنونی تأثیرگذار است؟

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

برای بیشتر توسعه دهندگان، آسیب های جانبی چندان آشکار و مشهود نیستند. ما برای امروز کد می نویسیم؛ اما باید عواقب آن را هم درنظر بگیریم. برای مثال، برخی از برنامه نویسان عاشق نوشتن کدهای پیچیده ای هستند که با سیستم عامل یکپارچه می شوند و درایوهای جدید یا پیچیده تری نصب می نمایند. آیا این کار در آینده هم جواب خواهد داد؟ آیا با درایوهای جدید هم به خوبی کار خواهد کرد؟ آیا با نسل های آینده سیستم های عامل هم سازگاری خواهد داشت، یا این که نرم افزار شما نهایتاً موجب خواهد شد که مردم کامپیوتری آهسته تر داشته باشند که مرتباً از کار باز می ایستد؛ حتی در زمانی که نرم افزارهای شما را هم اجرا نمی نمایند؟!

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