Free Security Settings in a Browser practice questions

Computing the file's hash and comparing it to the listed value verifies integrity, which is exactly what a published checksum is for. A cryptographic hash produces a fixed-length digest, and the same input always produces the identical output; a character-for-character match means the file is bit-for-bit identical to what the vendor released, while any difference indicates corruption or tampering. Decrypting the file using the vendor's public key is incorrect because the file was never encrypted and hashing has nothing to do with keys or decryption. Encrypting the file with AES-256 before running it addresses confidentiality, not integrity, and would not tell the technician whether the download matched the original. Signing the file with the technician's private key would create a digital signature proving the technician sent it, but it does nothing to confirm the download matches the vendor's release. When a scenario asks how to verify that a download has not been modified, the answer is always compare hashes, never decrypt.

When certificate warnings appear on every site at once, the most likely cause is an incorrect system clock, so the technician should check the date and time settings first. Certificate validity is bound to a specific date range, and if the machine's clock is wildly wrong, the browser sees every certificate as being outside its valid window and flags all of them simultaneously. Checking whether the certificate is self-signed would explain a warning on a single internal console, such as a printer or router, but not warnings across every public website the user visits. Checking the strength of the AES session key is irrelevant because the session key is negotiated only after certificate validation succeeds and has nothing to do with the warnings. Verifying that a download hash matches the vendor value addresses file integrity for downloads, not certificate trust in the browser. The distinguishing clue is scope: warnings everywhere point to the local machine, and the clock is the usual suspect.

Clearing the cached files for the affected site is the correct first step because the cache stores local copies of site files such as images, CSS, and scripts. When a site is updated, an old cached file can cause pages to look outdated or display with broken formatting. A targeted cache clear forces the browser to re-download the current files, which is low impact and does not sign the user out. Clearing the cookies for the affected site is unnecessary and higher impact here because cookies store session tokens and preferences; wiping them would sign the user out and reset settings without fixing a layout problem. Clearing the entire browsing history only removes the list of visited URLs and timestamps, which affects privacy and auto-suggestions but does nothing for cached page rendering. Resetting all browser settings to default is far too disruptive as a first step and can wipe extensions, permissions, and preferences the user relies on. The proper troubleshooting order moves from least disruptive to most disruptive, so cache clearing for the single site comes well before broad data resets. Remember the mental model: Cache = copies, Cookies = credentials and choices, History = click trail. Broken or outdated pages point directly to cache.

An allowed notification permission for a scam site is the most likely cause because many fake 'virus alert' messages come from notifications the user accidentally approved, not from malware on the machine. Once a site is added to the allowed notifications list, it can push deceptive alerts that mimic security warnings even when no browser tab is open. The fix is to open site settings, review allowed notifications, and remove any unfamiliar or misspelled domains. A disabled pop-up blocker relates to new windows or tabs opening while browsing, not persistent desktop notifications, so it does not explain alerts appearing when the browser is idle. An outdated cached copy of a login page would cause layout or content problems on that specific page, not recurring system-style alerts. A misconfigured secure DNS provider setting typically causes pages to fail to load or produces timeouts, not fake alert messages. Because the malware scan is clean, the technician should focus on browser permissions rather than endpoint remediation. Revoking the rogue notification permission cuts off the abuse path directly and stops the repeated deceptive prompts.

Private-browsing mode is correct because it focuses on local privacy by limiting what the browser keeps on that device after the private window is closed. It does not save visited pages to history, and it clears cookies and site data when the session ends, which reduces traces left behind for the next person using the same computer. However, it does not make the user anonymous on the network; the website, the ISP, and an employer network can still observe activity. Secure DNS encrypts DNS lookups between the device and a DNS provider to reduce local observation and tampering, but it does not control what the browser stores locally. Proxy configuration routes traffic through an intermediate server for filtering, logging, or policy enforcement, which affects where traffic goes rather than local data retention. Browser synchronization does the opposite of protecting local privacy: it copies data such as passwords, history, and bookmarks to the cloud and pulls it onto other signed-in devices, potentially increasing exposure. When a scenario emphasizes reducing what is stored on a shared or kiosk machine, private-browsing mode is the appropriate control.

Disabling one extension at a time and retesting the app is the best first action because it isolates the cause with minimal disruption while preserving the settings of tools like the approved password manager. Disabling keeps configurations intact and lets the technician compare behavior with and without a specific add-on, which is faster and safer than removal for diagnosis. Uninstalling all extensions and reinstalling them later is more disruptive, loses configuration, and does not clearly identify which single add-on caused the problem. Resetting the browser to its default settings is a last-resort step that wipes extensions, permissions, and preferences, so it is far too heavy-handed for an initial diagnostic. Clearing all cookies and saved passwords immediately would sign the user out of everything and could break the password manager's stored data without addressing an extension-related fault. The recommended workflow is to confirm the symptom, check add-ons first, disable to test, remove only when risk is high, and document each change. Because the user reports the issue occurs in the browser, an extension should be assumed involved until ruled out, and single-step disabling produces cleaner notes for escalation.

The ad blocker blocking third-party scripts the site needs is the most likely explanation because many websites mix advertising with essential functionality. Login buttons, single sign-on flows, payment forms, and embedded chat widgets often load from external domains that an aggressive ad blocker filters, which produces symptoms like a login button that does nothing or a missing chat widget. The fix is to whitelist only the trusted site or temporarily disable the blocker for one page load to confirm the cause, then apply a narrow exception. The pop-up blocker controls new windows and tabs, not the in-page scripts that render a login button or a chat frame, so it would not cause a button to be unresponsive. Secure DNS translates domain names to IP addresses and, if broken, causes pages to fail to load entirely rather than selectively breaking interface elements. The browser cache storing an old version would cause outdated layout or content, but it would not selectively disable third-party scripts that just began failing after installing an ad blocker. Because the timing correlates with the ad blocker installation and the broken features rely on external domains, the blocker is the strongest suspect.

Saved passwords and history may remain available to the next user is the correct risk because signing into a browser account and enabling sync on a shared or loaner device can leave synced data behind if the user forgets to sign out. Saved credentials can auto-fill, and synced tabs can reveal sensitive work resources to whoever uses the machine next. The safe practice is to use separate profiles, sign out on loaner PCs, remove any created profile, and know the remote device removal options. Encrypted DNS lookups are unrelated to browser sign-in and sync; enabling sync does not turn off secure DNS. The pop-up blocker is a separate built-in feature and is not disabled simply by signing into a browser account. Proxy settings are configured at the system or network policy level and are not cleared by enabling browser synchronization. The core lesson is that sync trades convenience for account exposure: a single signed-in account can become a single point of failure, especially on lightly managed or shared devices, so signing out and removing the profile is essential.

Blocking third-party cookies is the best balance because third-party cookies come from domains other than the site being visited and are commonly used to track browsing across many sites. Blocking them limits cross-site profiling while keeping most first-party features, such as staying signed in and remembering preferences, functional. Clearing all cookies on every exit reduces long-term tracking but is more disruptive because it signs the user out of sites and forces fresh logins on the next visit, breaking the 'stay signed in' convenience the scenario wants to preserve. Enabling strict tracking prevention blocks more trackers and fingerprinting scripts, which improves privacy but can disrupt complex sites and business authentication flows, making it heavier than needed for the stated goal. Disabling JavaScript for all sites would break the vast majority of modern web functionality, including logins and interactive content, so it is far too aggressive. The guiding principle is that increasing privacy usually costs convenience, so a technician should choose the least disruptive control that meets the requirement and change one setting at a time to preserve usability while restoring privacy.

The browser proxy settings should be checked first because a common symptom of a misconfigured proxy is 'the internet is broken' in the browser while other applications, such as an email client that connects directly, continue to work. Organizations often route browser traffic through a proxy for filtering, logging, and policy enforcement, and if the proxy is unreachable, wrong, or the PAC file points to a bad location, browsing fails even though Wi-Fi is connected. A quick check is whether the problem persists on a different network; if it disappears on another connection, proxy or network policy is likely the cause. Saved browser passwords only affect auto-filling credentials and have nothing to do with pages failing to load. The notification permissions list controls which sites can display alerts and would not prevent all sites from loading. Private-browsing configuration changes what is stored locally during a session and does not block general web access. Because the failure is browser-specific while other network apps work, the proxy is the most logical first item to verify, following company policy for automatic detection or the provided PAC URL.