The rule for every tool from here on

02Possession is not permission

Write the target, action, time, exclusions and stop before considering the tool. Match each proposal against all of them. A permitted read does not include a scan, and one named page does not include every linked host. A later live exercise would also need a real owned target and setup instructions.

The worked loopback URL is a model of a local address: 127.0.0.1 refers to the same machine. The port 8000 identifies a service there, and /note identifies its path. No service is started here. This card teaches how to read a grant, rather than making a legal judgment about a real test.

03Mark two proposals

Proposal A reads the printed card. Proposal B names the fictional print server. Decide each one from the activity grant.

Original fictional grants. No tool was installed or run for this lesson.
A tool runs the action it is given. Owning the tool is not a grant.

Worked grant
Target: http://127.0.0.1:8000/note
Allowed action: read that owned page
Time: not part of this lesson
Excluded: the fictional print server, any scan, any other host
The loopback page was not started here. The fictional print server is excluded even if a tool could name it.

Activity grant
Target: owned-notes
Allowed action: read the printed card
Time: during this lesson
Excluded: scanning, any other host, the fictional print server
Stop: uncertain permission, private data, or a target other than owned-notes

Proposal A: read the printed owned-notes card during this lesson.
Proposal B: scan the fictional print server with a tool installed on the laptop.

Check: proposal A matches the grant. Proposal B is outside the grant.
Write the target, the action, and the time for proposal A.

1. Copy the activity grant, including the stop.
2. Mark proposal A and proposal B against the target and the action.
3. Check: proposal A matches the grant. Proposal B is outside the grant. Write target, action, and time for A.
4. Stop. Do not install a tool and do not send either proposal.

04Ideas case

Use the fictional case below to connect the goals, identity checks, operations and scope decisions from this module. Write a reason for each decision before comparing with its rubric. This is a self-review activity; the understanding question remains separate.

Original fictional case for the Ideas module. Ungraded. It is a self-review activity.
No tool was run and no directory was built.

Facts
Count: a stored count changes from 4 to 40. The edit log is empty.
Account: rina is signed in. The server denies rina's read of noor's private note.
Bag: the note is shown as standard Base64, with no key.
Envelope: a different copy is marked encryption, and the key is not on the card.
Grant: read owned-notes during this lesson. Excluded: scanning and any other host.
Proposal: scan a different public host.
Directory line: dc-1 holds the club directory.
Name line: notes.lab.invalid A 192.0.2.44.

Rubric. Write one line each from these facts.
1. The count change directly harms integrity. Reading would be confidentiality. A service that fails to load would be availability.
2. Sign-in succeeded. The deny is authorization, and the server makes it.
3. The Base64 bag is encoding. The envelope is encryption. Neither card is a hash.
4. The public-host scan is outside the grant. Stop before any command.
5. dc-1 is the domain controller. The A record is a DNS record, not the directory.

Closing note
These cards are the required path. A live tool, a real password check, and a real directory remain deferred.
This stage does not train an Active Directory attack and does not authorize a target.

1. Name the direct harm of the count change, and the check that denied rina.
2. Name the Base64 bag and the envelope as different operations, and name dc-1 apart from the A record.
3. Decide whether the proposed public-host scan matches the grant. For each classification, cite the case fact that supports it.
4. Stop. The case is not a live test. A later comparison belongs inside a new grant.

05Optional challenge

Allow about ten minutes. A proposed test is allowed “in the afternoon” but has no end time or time zone. Draft a clarification naming the start, end and time zone, and keep the proposed action paused until those limits are settled.

06Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Owner: course lab owner.
Target: supplied willow-record card.
Allowed action: read and annotate the printed card.
Window: 15:00–16:00 UTC, same fictional day.
Excluded: changing files, scans, external services.
Stop: private data appears or permission becomes uncertain.
Proposal P: annotate the card at 15:20.
Proposal Q: scan an external service at 15:20.
Proposal R: change the card file at 15:20.

Count changes from 8 to 80 without an authorized edit.
Bag uses declared standard Base64 with no key.
Server dc-willow holds the account directory; a separate A record maps a hostname to an IPv4 address.
A tool is installed locally but its target is not named in any testing grant.

07Explain your prediction

Optional written self-check: Write permission before commands: target, action, time, exclusions and stop. Tie each security concept to a supplied fact and keep tool ownership separate from permission to use it on a system.