Ch. 02 Lab-03 Chapter 03 · Software Engineering Ethics

Introduction to Software Engineering · Chapter 03

Software Engineering Ethics

Software engineers make decisions that affect users, clients and society. This chapter introduces professional codes of ethics and the legal and social obligations (privacy, licences, accessibility, security) that shape everyday engineering choices, applied to ITC Club Hub.

ACM/IEEE-CS SE Code 5.2 · ACM Code 2018 GDPR principles · WCAG 2.2 MIT · Apache 2.0 · GPL-3.0 C++20 · ITC Club Hub

Navigate with ← → · Space next · Home/End · G jump to slide · O overview · F fullscreen
Hover the bottom of the screen to reveal the navigation panel.

Agenda

What we will cover

      Click any item to jump directly to that topic.

      Introduction

      Ethics is not a separate phase: it hides inside ordinary tickets

      A normal Club Hub taskThe ethical question inside itWho is affectedTopic
      Add a phone field to registrationDo we need it? Is it optional? Who will see it?StudentsPrivacy
      Export attendance to CSVMay a sponsor receive it? Can the file run formulas?Students, clubPrivacy, security
      Copy a date-parsing function from GitHubWhat does its licence ask of us?Original author, teamLicences
      Show "full" events in redCan a colour-blind student read the status?Students with disabilitiesAccessibility
      Recommend events to studentsIs the ranking fair and explainable?New and part-time studentsAI and data
      Demo on Friday with a known bugDo we tell the client?Client, team, usersCode of ethics
      Ethics: reasoned principles for deciding what is right when choices affect other people. Professional ethics: the obligations a profession accepts in return for the trust society gives it. SWEBOK Guide v4.0 places both in the knowledge area Software Engineering Professional Practice.
      • Most ethical problems in software are not dramatic: they are small defaults, missing checks and silent shortcuts that add up.
      • Codes of ethics, laws and standards (GDPR, WCAG 2.2, open-source licences) give you shared vocabulary so that "this feels wrong" becomes "this breaks principle 1.03".
      • Today every rule is applied to ITC Club Hub, the system your team builds this semester.

      Topic 1 · Why ethics matters

      One decision, many people: the stakeholders of a software choice

      Public and society safety, trust in software, law, inclusion User privacy, access Client club, institute Colleagues team, maintainers Profession reputation of IT Your decision store students' phone numbers?
      • User (students): lose control of their number, receive spam, may be harassed if a list leaks.
      • Client (the club, the institute): liable and embarrassed after a leak; loses members' trust.
      • Colleagues: must secure, back up and one day delete data they never needed.
      • Profession: every leak makes people trust "IT people" a little less.
      • Public: data habits of small apps shape what society accepts as normal.
      Software scales harm: one careless default in a form is copied to every one of the 2000+ students who register.

      Topic 1 · Why ethics matters

      Professional responsibility: legal is the floor, not the ceiling

      A profession has specialised knowledge that the public cannot check for itself, so it promises to use that knowledge responsibly. For a software engineer that means:

      • Competence: accept only work you can do or can learn in time; say so when you cannot.
      • Due care: test, review and think about misuse before you ship.
      • Honesty: report bugs, risks and delays, even when the news is unwelcome.
      • Accountability: your name is on the commit; "the client asked for it" is not a defence for harm.
      Law changes slowly and differs by country; ethics asks what is right here and now. Aim for the green quadrant.
      Against the law Within the law Ethical Unethical Illegal but well-meant probing the institute server for bugs without permission "to help" still wrong: ask for permission first Legal and ethical: the target SMS reminders only after the student opts in; phone field is optional respects users and the client Illegal and unethical selling members' phone numbers to an advertiser breaks data-protection rules and trust Legal, still unethical a pre-ticked "share my data with sponsors" box where no law forbids it deceives the people you serve

      Topic 2 · ACM/IEEE-CS SE Code of Ethics

      The Software Engineering Code: eight principles version 5.2, 1999

      mindmap
        root((SE Code
      8 principles)) Public act in the public interest Client and employer serve them, within the public interest Product highest professional standards Judgment integrity and independence Management ethical leadership of projects Profession integrity and reputation Colleagues fair and supportive Self lifelong learning
      • Written by a joint task force of the ACM and the IEEE Computer Society; it is the code aimed specifically at people who build software.
      • A short version states the eight principles; the full version adds about 80 numbered clauses, cited like 1.03 (principle 1, clause 3).
      • The principles are ordered: when obligations conflict, the public interest comes first. Serving your client never justifies harming the public.
      • The code is a guide for judgment, not an algorithm: it tells you what to weigh, you still have to decide.
      Source: ACM/IEEE-CS Software Engineering Code of Ethics and Professional Practice, version 5.2. Wording on this slide is paraphrased.

      Topic 2 · ACM/IEEE-CS SE Code of Ethics

      Worked example: what each principle means for your Club Hub team

      #PrincipleIn one line (paraphrased)Concrete Club Hub behaviour
      1PublicAct consistently with the public interestEvent capacity matches the room's real safety limit, not what the club wishes
      2Client and employerServe them well, as long as the public is not harmedKeep a club's member list confidential; warn the Product Owner early when a deadline slips
      3ProductMeet the highest professional standards you canUnit-test the 24-hour cancellation rule; never hide a known defect
      4JudgmentKeep integrity and independenceDo not approve a pull request you did not read or run
      5ManagementLead development ethicallyThe Scrum Master gives realistic estimates and never asks the team to hide bugs
      6ProfessionAdvance the integrity and reputation of the professionRespect licences: credit GoogleTest; never paste code of unknown origin
      7ColleaguesBe fair to and supportive of colleaguesReview code, not people; credit teammates' commits in the report
      8SelfKeep learning; practise ethicallyRead WCAG 2.2 before designing the web UI
      Conflict example. The club (client, principle 2) wants 80 seats for a talk in a room that holds 50. Principle 1 wins: the system enforces 50 and offers a waiting list.
      When you cite the code in a lab, name the principle and explain the link to your decision in one sentence: "Principle 3 Product: we add a test for the duplicate-registration rule because a double booking blocks another student."

      Topic 3 · ACM Code of Ethics and Professional Conduct (2018)

      The ACM Code: four sections, for every computing professional

      SectionItemsWhat it covers (paraphrased)Club Hub example
      1 General ethical principles1.1 to 1.7Contribute to society and human well-being; avoid harm; be honest and trustworthy; be fair and do not discriminate; respect the work behind ideas and software; respect privacy; honour confidentiality1.6: collect only what the inventory justifies; 1.4: the web UI must work for blind students too
      2 Professional responsibilities2.1 to 2.9Quality of work and process; competence; knowing the rules that apply; professional review; evaluating risks; working within competence; public awareness; authorised access only; systems that are robustly and usably secure2.4: every change goes through a pull request review; 2.9: passwords hashed, CSV exports safe
      3 Professional leadership3.1 to 3.7Public good as the central concern; social responsibility; quality of working life; policies that reflect the code; helping others grow; care when changing or retiring systems; special care for infrastructure3.6: when Club Hub replaces the paper sign-up sheet, migrate and then destroy old lists
      4 Compliance with the code4.1 to 4.2Uphold and promote the code; treat violations as incompatible with ACM membershipRaise a concern in the retrospective instead of staying silent
      SE CodeACM Code
      AudienceSoftware engineersAll computing professionals
      Version5.2 (1999)2018 update
      Shape8 principles, ~80 clauses4 sections, 25 items
      Newer topicsQuality, managementDiscrimination, security, infrastructure
      The two codes agree on the core: public good first, avoid harm, be honest, respect privacy, do competent work. Use whichever gives the sharper sentence for your case.

      Topic 4 · Privacy and data protection

      Personal data has a lifecycle, and every step carries an obligation

      flowchart LR
        C["1 Collect
      only fields in the inventory
      notice shown at the form
      consent for optional data"] S["2 Store
      access control per role
      no personal data in logs
      protected backups"] U["3 Use
      only for the stated purpose
      organisers see own events"] SH["4 Share
      no sale, no sponsor export
      aggregates for reports"] D["5 Delete
      when retention ends
      or the student asks"] C --> S --> U --> SH --> D R(["Student rights at any time: see, correct, export, delete"]) -.-> S R -.-> U
      Personal data: any information about an identifiable person. In Club Hub: student ID, name, email, phone, club membership, attendance records.
      Data minimisation: collect and keep only what is necessary for a stated purpose. The safest data is the data you never stored.
      Retention: a written limit on how long each field is kept, followed by real deletion (including exports and backups).

      Topic 4 · Privacy and data protection

      The legal landscape: Cambodia is evolving, GDPR is the reference

      GDPR principle (Art. 5)Meaning for Club Hub
      Lawfulness, fairness, transparencyA plain-language notice at registration; no hidden uses
      Purpose limitationEmails collected for reminders are not reused for sponsor marketing
      Data minimisationNo date of birth, no home address, phone only if SMS is wanted
      AccuracyStudents can correct their name and email themselves
      Storage limitationIdentified attendance kept 12 months, then aggregated
      Integrity and confidentialityRole-based access, protected files, redacted logs
      AccountabilityA written data inventory and retention rules in the repository

      Lawful bases (Art. 6) include consent, contract, legal obligation, vital interests, public task and legitimate interests. Valid consent is freely given, specific, informed and unambiguous (an active choice, never a pre-ticked box) and as easy to withdraw as to give. Source: Regulation (EU) 2016/679 (GDPR).

      Cambodia
      • The data-protection landscape is evolving.
      • The Law on Electronic Commerce (2019) contains provisions on protecting personal data held in electronic form, which covers a system like Club Hub.
      • A dedicated, comprehensive personal data protection law has been in preparation.
      • The institute's own rules on student records also apply.
      Why GDPR as the reference?

      It is the most widely copied model: many newer national laws reuse its principles. It binds organisations serving people in the EU; here we use it as a design standard: if Club Hub meets GDPR principles, it is well placed for whatever Cambodian law requires.

      Lecturer note: check the current status of a dedicated Cambodian personal data protection law before this class and update this slide if it has been adopted.

      Topic 4 · Privacy and data protection

      Worked example: a data inventory for ITC Club Hub

      FieldPurposeLegal basis / consentRetentionWho can see it
      studentIdIdentify the student; block double registrationNecessary for the serviceWhile the account is active, deleted 6 months after graduationThe student; admins; organisers see it masked (e2******7)
      nameCheck-in list at the doorNecessary for the serviceAs studentIdThe student; organisers of events the student registered for; admins
      emailLogin; remindersNecessary for login; reminders by opt-in consentAs studentIdThe student; admins. Not organisers
      phone (optional)SMS reminder, only if chosenConsent, withdrawable at any timeDeleted at once when consent is withdrawnNobody on screen; used only by the reminder sender
      clubMembershipsShow "my clubs"; leaders manage membersNecessary for the serviceUntil the student leaves the club, + 30 daysThe student; leaders of that club; admins
      attendanceCheck-in; monthly activity reportLegitimate interest of the institute (documented)Identified 12 months, then aggregated to countsOrganisers (own events only); admins see aggregates
      dateOfBirth, address, photoNo purpose foundNoneNot collectedNobody
      Build the inventory before you design the Student class: every member variable must have a row, and every row needs a purpose. A field without a purpose is deleted.
      The inventory covers copies too: CSV files, exports, backups, log files and test fixtures. Test data uses invented names, never real students.

      Topic 4 · Privacy and data protection

      Privacy by design: build it in, do not bolt it on

      1 Proactive prevent, do not repair review the form first 2 Private by default reminders stay off until the student opts in 3 Embedded consent is its own step, not a hidden setting 4 Full functionality check-in works without any phone number Privacy by Design 7 principles · GDPR Art. 25 5 End-to-end security protected from collection to verified deletion 6 Visibility, transparency plain-language notice and published retention rules 7 Respect for the user students can see, export, correct and delete their data
      • The seven principles come from Ann Cavoukian (Privacy by Design, 2009). GDPR Art. 25 turned the idea into a legal duty: data protection by design and by default.
      • By default is the most powerful: most users never change settings, so the default is the policy.
      • Positive-sum (principle 4): privacy and features are not a trade-off; the check-in feature works perfectly without phone numbers.
      In code: optional data is std::optional, consent flags start as false, and logging functions only accept redacted text.

      Topic 4 · Privacy and data protection

      Data minimisation in code: store less, log nothing personal

      // include/clubhub/Student.h (excerpt)
      namespace clubhub {
      
      // Only the fields that the data inventory allows
      struct Student {
          std::string id;      // institute ID, e.g. "e20230417"
          std::string name;
          std::string email;
          // present only if the student opted in to SMS
          std::optional<std::string> phone;
      };
      
      // "e20230417" -> "e2******7": recognisable, not reusable
      inline std::string maskId(std::string_view id) {
          std::string out{id};
          if (out.size() <= 3) return std::string(out.size(), '*');
          for (std::size_t i = 2; i + 1 < out.size(); ++i)
              out[i] = '*';
          return out;
      }
      
      // The ONLY form of a Student that may reach a log file
      inline std::string redacted(const Student& s) {
          return "Student{id=" + maskId(s.id) + "}";
      }
      }  // namespace clubhub
      // Monthly report row: a pseudonym, no name, no phone
      struct AttendanceRow {
          std::size_t studentKey;   // keyed hash of the ID
          std::string eventId;
      };
      
      // Demo only: std::hash is NOT a cryptographic hash.
      // Production: HMAC-SHA-256 from a crypto library.
      inline std::size_t pseudonym(std::string_view id,
                                   std::string_view secret) {
          std::string key{secret};
          key += id;
          return std::hash<std::string>{}(key);
      }
      
      // BAD: name and phone end up in a shared log file
      // log << "registered " << s.name << " " << *s.phone;
      
      // GOOD: masked ID and the event, nothing else
      log << "registered " << redacted(s) << " for E-017\n";
      registered Student{id=e2******7} for E-017
      The admin report counts attendance per club with AttendanceRow: it needs to know that the same student came twice, not who the student is. Keep the secret out of Git (environment variable or local config file).

      Topic 4 · Privacy and data protection

      Worked example: a privacy notice in plain language, and a fair consent step

      # How ITC Club Hub uses your data (v1.0, September 2026)
      
      **Who we are.** Club Hub is run by the ITC student clubs office.
      Contact: clubhub-privacy@itc.example (reply within 7 days).
      
      **What we collect and why.**
      - Student ID and name: to register you and check you in.
      - Email: to log you in. Reminders only if you switch them on.
      - Phone (optional): only for SMS reminders you ask for.
      - Attendance: to run events and a monthly report per club.
      
      **Who sees it.** Organisers see your name and a masked ID for
      events you registered for. We never sell or give your data to
      sponsors or advertisers.
      
      **How long.** Attendance with your name: 12 months, then only
      counts remain. Account: until 6 months after you graduate.
      
      **Your choices.** See, correct, download or delete your data
      at any time in *My profile*. Withdraw SMS consent in one click.
      Registration screen: consent step (mock-up)

      Your ID, name and email are needed to use Club Hub. Read how we use them.

      Both boxes start unticked. "Create account" works with neither ticked.

      • Layered: a one-line summary on the form, the full notice one click away.
      • Separate: one checkbox per purpose; no "I agree to everything".
      • Not a condition: optional consent never blocks registration.
      • Readable: short sentences, "we" and "you", no legal jargon; offer a Khmer version.

      Topic 5 · Intellectual property and licences

      Copyright is automatic; a licence is the permission you give or receive

      • Copyright protects the expression (the code you wrote) from the moment you write it; no registration needed. Ideas and algorithms are not covered.
      • No licence = no permission. Public code on GitHub without a LICENSE file may be read, but not legally copied into your project.
      • An open-source licence grants everyone the right to use, modify and share, under conditions.
      • Permissive: few conditions (keep the notice). Copyleft: derived works must stay open under the same licence.
      • Other IP: trademarks (names, logos), patents (inventions), trade secrets.
      fewer conditions on whoever reuses the code more freedoms guaranteed to end users Public domain CC0 Unlicense Permissive MIT · BSD-3-Clause Apache-2.0 Weak copyleft LGPL-3.0 MPL-2.0 Strong copyleft GPL-3.0 GPL-2.0 Network AGPL-3.0 no conditions keep copyright and licence text; Apache also: NOTICE file, patent grant, mark changed files share changes to the library itself; your own code may stay closed a distributed derived program is GPL as a whole, with source for users like GPL, also when users only reach the software over a network Known examples: SQLite is public domain · GoogleTest is BSD-3-Clause Kubernetes is Apache-2.0 · the Linux kernel is GPL-2.0 Identifiers are SPDX licence IDs (spdx.org/licenses)

      Topic 5 · Intellectual property and licences

      What a licence allows and requires, and how to apply it to a repository

      MITApache 2.0GPL-3.0
      Commercial use, modify, distributeyesyesyes
      Explicit patent grantnoyesyes
      Keep copyright and licence textyesyes (+ NOTICE file)yes
      State changes in modified filesnoyesyes
      Release source of derived work when distributednonoyes, same licence
      Can be combined into closed-source productsyesyesno
      Warranty or liabilitynone: "as is" in all three
      Choosing. MIT: simplest, maximum reuse. Apache 2.0: like MIT plus patent protection, common in companies. GPL-3.0: you want every improvement to stay open.
      Compatibility runs one way: MIT and Apache-2.0 code may go into a GPL-3.0 project, but GPL code may not go into an MIT or closed project.

      The first two lines of every source file, for example src/RegistrationService.cpp:

      // SPDX-License-Identifier: MIT
      // Copyright (c) 2026 Team Mekong, ITC Club Hub contributors
      # Third-party notices
      
      ITC Club Hub uses the following components.
      
      | Component  | Version | Licence      | Used for | Shipped? |
      |------------|---------|--------------|----------|----------|
      | GoogleTest | 1.15.2  | BSD-3-Clause | tests    | no       |
      
      ## GoogleTest
      Copyright 2008, Google Inc. All rights reserved.
      Source: https://github.com/google/googletest
      Full licence text: see licenses/googletest-LICENSE.txt

      Repository files: LICENSE (full text of the chosen licence, at the root), the SPDX header in each source file, and THIRD_PARTY_NOTICES.md listing every dependency. GitHub detects LICENSE and shows the licence on the repository page.

      Topic 6 · Accessibility and inclusive design

      WCAG 2.2: four principles, three conformance levels

      Accessible ITC Club Hub Perceivable can be seen or heard alt text on posters 4.5:1 text contrast status in words, not only colour Operable can be used everything by keyboard visible focus targets at least 24 × 24 CSS px Understandable makes sense a label on every field errors say how to fix same navigation on every page Robust works with assistive tech semantic HTML ARIA only if needed tested with a screen reader WCAG 2.2 success criteria at levels A, AA (the Club Hub target) and AAA
      • Accessibility: people with disabilities (vision, hearing, motor, cognitive) can use the product. Inclusive design widens this to age, language, slow networks and old phones.
      • WCAG 2.2 (W3C, 2023) groups testable success criteria under the four POUR principles. Level AA is the usual legal and contractual target.
      • New in 2.2, for example: 2.4.11 Focus Not Obscured, 2.5.8 Target Size (Minimum), 3.3.8 Accessible Authentication (no memory puzzles at login).
      The "curb-cut effect": captions, contrast and clear errors help everyone, including a student reading Club Hub on a phone in bright sun.

      Topic 6 · Accessibility and inclusive design

      Worked example: accessibility checklist for the CLI and the planned web UI

      CheckC++ command-line front endPlanned web / mobile UIWCAG 2.2
      Colour is never the only signalStatus as a word: [FULL], [CANCELLED]; honour NO_COLORIcon + text for status; links underlined1.4.1 (A)
      ContrastUse the terminal's default colours; no dark blue on blackText 4.5:1, large text and UI parts 3:11.4.3, 1.4.11 (AA)
      KeyboardMenus accept typed numbers or commands, not only arrow keysTab order follows layout; visible focus not hidden under a sticky header2.1.1 (A), 2.4.7, 2.4.11 (AA)
      Labels and instructionsPrompts give the format: Date (YYYY-MM-DD):Every input has a <label>; required fields marked in text1.3.1, 3.3.2 (A)
      Clear errorsSay what failed, why, and what to do next; non-zero exit codeError next to the field, with a suggestion3.3.1 (A), 3.3.3 (AA)
      Target sizenot applicableButtons at least 24 × 24 CSS px2.5.8 (AA)
      LoginAllow pasting the passwordPassword managers work; no puzzle3.3.8 (AA)
      // The word carries the meaning; colour repeats it
      std::string_view statusLabel(RegistrationStatus s) {
          switch (s) {
          case RegistrationStatus::Registered:
              return "REGISTERED";
          case RegistrationStatus::Waitlisted:
              return "WAITLISTED";
          case RegistrationStatus::Cancelled:
              return "CANCELLED";
          case RegistrationStatus::CheckedIn:
              return "CHECKED IN";
          }
          return "UNKNOWN";
      }
      
      // no-color.org: any NO_COLOR value disables colour
      bool colourEnabled(bool noColorFlag) {
          return !noColorFlag &&
                 std::getenv("NO_COLOR") == nullptr;
      }
      Error: cannot register for "Git Workshop" (E-017):
      the event is full (40 of 40 seats).
      Next step: clubhub waitlist E-017

      Topic 7 · Security responsibilities

      Responsible (coordinated) disclosure: fix first, then tell the world

      timeline
        title Coordinated disclosure, typical 90-day window
        Day 0 : Flaw found : Private report to the security contact
        Day 1 to 3 : Owner acknowledges : Triage and severity rating
        Day 7 to 60 : Fix developed and tested : CVE ID reserved
        Day 60 to 90 : Patch released : Users update
        Day 90 : Public advisory : Reporter credited
      
      As a finder

      Report privately to the owner with steps to reproduce. Access or copy no more data than needed to show the flaw. Do not publish before the agreed date.

      As an owner

      Publish a contact in SECURITY.md, acknowledge quickly, fix, credit the reporter, and never threaten people who report in good faith.

      Deadlines and CVE

      90 days is a widely used default (for example Google Project Zero); flaws already exploited get shorter deadlines. A CVE ID names one vulnerability so everyone talks about the same bug.

      Testing a system you do not own without written permission is unauthorised access (ACM Code 2.8), even with good intentions. Responsibility starts with your own code: robustly and usably secure (ACM 2.9).

      Topic 7 · Security responsibilities

      Security is part of the job: three duties in Club Hub's code and repository

      // Attendance export: cells that start with = + - @ tab
      // or CR run as formulas when an organiser opens the file
      // in a spreadsheet (CSV injection). Neutralise them.
      std::string csvCell(std::string_view raw) {
          constexpr std::string_view risky{"=+-@\t\r"};
          std::string out = "\"";
          if (!raw.empty() &&
              risky.find(raw.front()) != std::string_view::npos)
              out += '\'';
          for (char c : raw) {
              // RFC 4180: a quote inside a field is doubled
              if (c == '"') out += '"';
              out += c;
          }
          return out + '"';
      }
      csvCell("Git Workshop")      -> "Git Workshop"
      csvCell("=HYPERLINK(\"x\")") -> "'=HYPERLINK(""x"")"
      # Security policy (SECURITY.md)
      
      ## Reporting a vulnerability
      Please do not open a public issue. Email
      clubhub-security@itc.example with steps to reproduce.
      We reply within 3 working days and aim to fix
      within 30 days. We credit reporters who wish it.
      
      ## Scope
      The C++ core and CLI in this repository. Do not test
      against real student data or systems you do not own.
      DutyClub Hub practice
      Validate all inputReject malformed IDs and dates; escape CSV output
      Protect secretsNo passwords or keys in Git; .gitignore the local config
      Keep dependencies currentPin GoogleTest to a release; update when advisories appear

      Topic 8 · Ethics of AI and data

      Bias and transparency: a harmless-looking recommender can lock students out

      Attendance history who came to what Model ranks events score per student Top 5 shown others hidden below Student attends what was shown learns from the past narrowed choice Feedback loop and bias risks new students have no history: they see only "popular" events; students who work or live far attend less, so they are shown even less
      • Bias: systematic unfairness to a group. It enters through data (who is missing), design (what is optimised) and feedback (outputs become new inputs).
      • Transparency: people can tell that a system decides, and why. Club Hub: a "Why am I seeing this?" line on each recommended event.
      • Contestability and choice: a switch to "show all events by date" and an opt-out of profiling.
      • Ask before building: does this need personal data at all? A "most popular this week" list may be enough.
      The lab challenge asks your team for a go/no-go decision on exactly this feature.

      Topic 8 · Ethics of AI and data

      Dark (deceptive) patterns: interfaces that trick users against their interest

      PatternWhat it doesClub Hub temptationFair alternative
      Pre-ticked consentAssumes "yes" unless the user notices"Share my profile with sponsors" ticked by defaultUnticked, separate box; not needed to register
      ConfirmshamingGuilt-trips the "no" option"No thanks, I don't care about my club"Neutral: "Not now"
      Roach motelEasy to get in, hard to get outOne-click sign-up, deleting the account needs an email to an admin"Delete my account" in My profile, same effort as sign-up
      NaggingRepeats a request until the user gives inA phone-number pop-up on every loginAsk once; "Don't ask again" is respected
      Fake urgency or scarcityInvents pressure"Only 2 seats left!" when 30 are freeShow the real count: "12 of 40 seats left"
      Disguised adsAdvertising dressed as contentA sponsor promotion styled as a club eventClearly labelled "Sponsored"
      Trick questionsConfusing wording, double negatives"Untick to not stop receiving reminders"Plain positive wording: "Send me reminders"
      The term "dark patterns" was coined by UX designer Harry Brignull in 2010; many regulators now say "deceptive patterns". Under GDPR, consent obtained through such tricks is not valid consent.
      Dark patterns usually improve a metric (sign-ups, consent rate) for a sprint and destroy trust for years. SE Code principle 1 and ACM 1.3 (be honest) rule them out.

      Topic 9 · Case studies

      Three failures, three violated principles

      Therac-25 (1985 to 1987)

      A computer-controlled radiation therapy machine gave massive overdoses in six known accidents in Canada and the United States; several patients died. The new model had dropped the hardware safety interlocks of its predecessors and trusted software reused from them. A race condition, triggered when a fast operator edited the treatment settings, let the beam fire in the wrong mode. Error messages such as "MALFUNCTION 54" were cryptic, and early reports from hospitals were dismissed.

      Principle 3 Product Principle 1 Public

      Lesson: safety-critical software needs independent safeguards, testing of timing, and honest follow-up of incident reports. (Leveson and Turner, 1993)

      Volkswagen emissions software (2015)

      US regulators revealed that diesel cars sold from 2009 contained engine-control software that recognised the conditions of an official emissions test and switched on full exhaust treatment only then. On the road, nitrogen-oxide emissions were many times the legal limit. About 11 million cars worldwide were affected; the company paid tens of billions of dollars in fines, recalls and settlements, and an engineer was sentenced to prison in the US.

      Principle 1 Public Principle 4 Judgment

      Lesson: "my manager asked for it" does not transfer responsibility. Engineers wrote and maintained code whose only purpose was to deceive.

      Cambridge Analytica (revealed 2018)

      A personality-quiz app on Facebook collected data from the roughly 270,000 people who used it and, through the platform's friends feature, from their friends: up to 87 million people in total, almost none of whom had consented. The data was passed to the political consultancy Cambridge Analytica and used to profile voters for targeted political advertising. In 2019 the US Federal Trade Commission fined Facebook 5 billion dollars.

      Principle 1 Public ACM 1.6 Respect privacy

      Lesson: purpose limitation and consent matter; an API that exposes friends' data is an ethical design decision.

      Topic 10 · Ethical decision-making and whistleblowing

      A seven-step framework, with an escalation path

      flowchart LR
        B[1 Establish
      the facts] --> C[2 Stakeholders
      and harms] C --> D[3 Codes, law,
      policy] D --> E[4 At least
      three options] E --> F[5 Test: harm, rights,
      fairness, publicity] F --> G{Resolved in
      the team?} G -- yes --> H[6 Decide, act,
      document] H --> L[7 Reflect and
      improve] G -- no --> I[Escalate: supervisor,
      then institute channel] I --> J{Serious risk,
      still ignored?} J -- no --> M[Keep records,
      follow up internally] J -- yes --> K[External report:
      whistleblowing]
      Publicity test

      Would you be comfortable if the decision were on the front page, or explained face to face to the student it affects?

      Third option

      It is rarely just "obey or refuse". Look for the option that meets the legitimate need without the harm.

      Whistleblowing

      Reporting serious wrongdoing to someone who can act. Internal channels first, dated written records, facts not rumours, and no leaking of personal data while doing it.

      SE Code 6.12 and 6.13

      Paraphrased: first raise a concern with the people involved; report a significant violation to the appropriate authorities when that is impossible, counter-productive or dangerous.

      Topic 10 · Ethical decision-making and whistleblowing

      Worked case: "Export all members' phone numbers for our sponsor"

      StepAnalysis
      1 FactsThe Robotics Club president asks the developer on duty for a CSV of all 120 members' phone numbers so that a phone-shop sponsor can send them offers. 35 members gave a number, for SMS reminders only.
      2 StakeholdersMembers (spam, loss of control), president and club (sponsor money, reputation), sponsor, institute (liability), developer (responsibility).
      3 Codes and rulesSE Code 1 Public and 2 Client (serve the client only within the public interest); ACM 1.6 Respect privacy; GDPR principle purpose limitation: numbers were collected for reminders, not marketing; our own privacy notice says "never given to sponsors".
      4 Options(a) export as asked · (b) refuse and stop there · (c) the club sends the sponsor's offer itself in the newsletter, members contact the sponsor if interested · (d) new opt-in "sponsor offers" box, export only those who tick it
      5 Tests(a) fails harm, rights and publicity tests; breaks our notice. (b) protects members but ignores the club's legitimate need. (c) and (d) meet the need without harm; (d) needs a notice update and a new consent.
      6 Decide, actDecline (a) politely in writing, citing the privacy notice; propose (c) now and (d) as a backlog item for the Product Owner. Record the decision in docs/decisions/0003-sponsor-export.md.
      7 ReflectAdd "no bulk export of contact data" to the admin role design; add a test that the CSV export never contains a phone column.
      Reply to the president (draft): "We can't export members' phone numbers: they were given only for reminders, and our privacy notice promises they never go to sponsors. We can put the sponsor's offer in your next club newsletter today, and we'll add an opt-in 'sponsor offers' option in the next sprint."
      If the president insists or asks an admin to do it quietly, escalate: the teaching assistant (acting client) first, then the clubs office. Do not export "just this once".

      Best practices / common mistakes

      Habits of an ethical engineering team

      Inventory before code

      Every stored field has a purpose, a legal basis, a retention limit and a reader list. Mistake: "let's collect it, it might be useful later".

      Private by default

      Optional features start off; consent boxes start unticked. Mistake: pre-ticked boxes and "agree to all" buttons.

      Redact every log

      Only redacted() output reaches logs; test data is invented. Mistake: printing a whole Student while debugging and committing the log.

      Licence on day one

      LICENSE, SPDX headers and a third-party notice from the first commit. Mistake: copying Stack Overflow or GitHub code without checking its licence.

      Accessible from the first mock-up

      Words plus colour, labels, keyboard paths, 4.5:1 contrast. Mistake: "we'll add accessibility at the end": it is then a redesign.

      Speak up, in writing

      Raise concerns early, use the seven steps, record decisions. Mistake: staying silent about a known bug before a demo, or leaking data to "prove a point".

      Check your understanding

      Chapter quiz 10 questions

      Play this quiz live with the Realtime Quiz app: download the questions, use Import JSON on the instructor dashboard, then open a session. Open Realtime Quiz

      Wrap-up

      Summary

      • Software decisions affect users, clients, colleagues, the profession and the public; legal is the floor, not the ceiling.
      • The SE Code has eight principles; the public interest comes first when obligations conflict.
      • The ACM Code (2018) adds explicit duties on discrimination, privacy and robust, usable security.
      • A data inventory gives every field a purpose, a basis, a retention limit and a reader list; minimise, redact logs, delete on time.
      • Cambodia's rules are evolving (E-Commerce Law 2019); GDPR principles are the design reference; consent is active, specific and withdrawable.
      • No licence means no permission; MIT and Apache 2.0 are permissive, GPL-3.0 is copyleft; ship LICENSE, SPDX headers and third-party notices.
      • WCAG 2.2 POUR, level AA: words not only colour, 4.5:1 contrast, keyboard access, labels and helpful errors, also in the CLI.
      • Report vulnerabilities privately and coordinate disclosure; avoid bias feedback loops and dark patterns.
      • Use the seven decision steps, look for the third option, escalate internally first, and write the decision down.
      Open Lab-03: 5 tasks + 1 challenge

      Next chapter: 04 · Software Development Processes

      Slides