An asset is something we want to protect: work, access, privacy, availability or reputation. A threat can cause harm, while a vulnerability makes it easier to occur. Reusing a password is a weakness; a fraudulent access attempt is a threat; losing files would be an effect. Distinguishing them helps select a measure connected to the cause rather than a list of tools appearing to solve everything.

Security and privacy are related but different. An account can resist outsiders while publishing excessive information; a limited audience does not guarantee recovering lost files. Separate prevention, exposure limitation, detection and recovery. “Active” and “passive” measure labels vary with context: explain their concrete function before using them as categories. Harassment also requires protecting the person and activating support, not just settings changes. We use fictional cases and observable facts. “Something is wrong” expresses concern; knowing what was received, shared or executed guides the next decision without investigating people.

Digital identity develops through what we publish, what others share and inferences services make. A platform may combine interactions to rank content or advertising according to its objectives. Those inferences can be wrong. Seeing many similar recommendations proves neither personal need nor majority opinion. Distinguish a screen observation, a proposed explanation and evidence of how the system works.

The Social Dilemma supports analysing the attention economy, recommendations and profiling without diagnosing students’ habits. Its block occupies 3.5 of the ten sessions: 0.25 preparation, 2.25 authorised viewing or a coherent selection and 1 checking and transfer. Before it, record a prediction and a question; during it, three observations without transcribing dialogue; afterwards, check two claims against primary sources. The written alternative addresses the same problem without viewing outside class. The conclusion provides the portal with one privacy guideline and one wellbeing guideline, concrete, reviewable and free from user blame.

Authentication checks access credentials; authorisation determines permitted actions afterwards. A unique password prevents one reused credential leak automatically affecting other accounts, while an additional factor reduces certain risks. One-time codes remain secrets and must not be supplied in response to an unexpected message. Verify requests through a known route rather than using the doubtful link to establish its own legitimacy.

Permissions must match function and audience: reading, commenting and editing differ. Review recipients and existing links in the agreed environment. Hiding a portal link or button does not implement authentication. Projects also contain secrets such as WiFi keys or tokens in code, screenshots and history. Submit example configuration with fictional values and keep real configuration outside the package. Removing a value from the current version does not guarantee removal from earlier copies; report exposure to the teacher for revocation or renewal through the authorised procedure and access review, without testing other people’s accounts.

The first step depends on facts: receiving a suspicious message differs from revealing a key or executing a file. Phishing impersonates an entity to obtain information or trigger actions. If only received, avoid interaction and verify through a known channel. If credentials or codes were supplied, compromise may exist: seek support and use official recovery and session or access review. Deleting the message does not revoke a credential.

If a suspicious file was executed on a practice computer, stop using it and notify the responsible person through the school’s procedure without further experimentation. With impersonation or harassment, protect the person, preserve relevant evidence with adult support, avoid amplifying content and use school or service reporting and help. The portal neither investigates perpetrators nor requests passwords, documents or private narratives. Every ending states first action, responsible channel and limitation. If events are uncertain, lead to checking or support rather than automatic reassurance.

A backup preserves content for recovery under specific conditions. It does not replace a password, just as a password does not restore a lost file. An update fixes or changes software according to its contents; permissions limit actions and authentication protects access. Selecting measures requires stating which asset they protect, against which situation and with what limitation. The portal avoids absolute promises such as “now you are safe”.

Practice restoration uses a fictional file with a recognisable version. Preserve the backup, restore it into a test location and open the result to check content and version, not only filename. Do not delete the original to simulate loss. The test establishes recovery of that file, not an account or every incident. A wellbeing guideline also needs action, context and review: reducing notifications during a task and checking whether it helps differs from diagnosis through a universal hour limit. If an interaction causes distress, the resource leads to human support without grading personal habits.

A decision tree organises questions and options to lead to another question or a final recommendation. Each node needs an identifier, text and options whose destinations exist. Labels should describe understandable facts, such as having sent a code, because the person consulting the portal may not know the incident’s technical name. Different paths may share a support recommendation without making their earlier questions identical. The node table allows these relationships and their content to be reviewed before becoming an interface.

In the portal, HTML structures content, CSS supports readability and JavaScript responds to the event of choosing an option by displaying the destination node. Separating node data from presentation allows a recommendation to change without duplicating the whole interface. textContent displays messages as text without interpreting them as HTML. The program must also retain state: which node it is showing and which path it has followed. This history allows Back to recover the previous step instead of always leading to a fixed destination.

Home resets both the current node and the history; changing only visible text would leave the possibility of returning to an earlier incident. Navigation must also work with a keyboard and clearly named buttons. Visible focus indicates which control receives keyboard interaction and must remain in a logical location when controls are replaced. Changes are communicated through a status region where appropriate, with its behaviour checked. Responses remain local: this functionality does not require sending them to a server.

Coverage describes which nodes, options and endings have been tested. It reveals parts of the tree that a brief demonstration may leave unchecked. The three representative incidents are phishing without interaction, supplied credentials and harassment or impersonation. Executed-file and uncertainty options are also checked when they form part of the tree. Completing three paths does not guarantee that every option has been activated. Each test needs expected questions, actions and recommendations before execution so observations can be compared with a defined reference afterwards.

Content and functionality answer different questions. Content review checks that advice matches the facts and its source; functional review checks destinations, Back, Home and history. A path can work technically while offering unsuitable advice. Going back, changing branches and restarting from different endings reveals whether the path retains or clears state as intended. Recording the tester’s choice also helps distinguish an ambiguous question from an incorrectly programmed destination.

Review includes how the portal is used: keyboard navigation, focus and announcement of updates in the available environment. Adding a label does not establish complete accessibility; behaviour must be observed. Another pair solving cases without directions from the authors may reveal comprehension difficulties. Finally, the authorised recipient and reader role are checked in the restricted submission environment. The local folder and tree do not create those permissions themselves. Reviewing access does not entail automatically publishing the portal as a public advisory tool.

Submission combines editable portal, recommendation sources, protected fictional profile, restoration test and navigation log. Each item demonstrates something different and must match the submitted version. A screenshot replaces neither the executable tree nor direct evidence of permissions or content recovery. Review the whole package, including images, configuration files and copies, to avoid real data or secrets.

Credit acknowledges authorship; a licence or permission determines authorised reproduction, modification and distribution. An attributed resource may still prohibit the intended adaptation. Identify original and external material, conditions and changes, replacing anything you cannot reuse. Recommendations link to their sources and are reviewed if these change. A01 retains an executed microportal, corrected fault and initial protection tests; A02 extends coverage, three incidents, restoration and verified improvement. Each partner explains data, event, history and a response decision. The result guides and facilitates seeking help within its limits, without promising diagnosis or professional resolution.