WIP from A11y Lab

Bypass Blocks: A mechanism is available to bypass blocks of content that
are repeated on multiple Web pages.
A keyboard-functional "skip" link should be provided to allow keyboard users to navigate
directly to the main content.
Level Compliance 2.3.1.
A Does not apply
Level Compliance 2.3.2.
AAA Does not apply
Level Compliance 2.3.3.
AAA Does not apply
Level Compliance 2.4.1.
A No
22
The main content of a web page rarely comes first in a typical layout. Before users can
arrive at the main content, they must skip past features like the website's logo and
branding, the site search, the login widget, and the main navigation. In some cases, a
secondary navigation level also appears before the main content. The top section of a
web page can be quite long. Providing a way to skip past all of the features at the top of
a web page helps save keystrokes for keyboard users.
https://hushline.app/
General example:
The Skip Navigation Link allows screen reader users to directly access the main content
of the page without repeatedly going through the navigation on each page.

https://github.com/scidsg/project-info/blob/main/hush-line/1.%20Accessibility/WCAG%202.1%20AAA_HushLine%20website.pdf

I'm interested in the pros and cons of displaying the email address, PGP key fingerprint, and PGP key expiration date so prominently on the Hush Line form, especially from the prospective of a source who doesn't know what PGP is (a majority of expected sources, as I understand it).

Pros:

• Shows, in a sense, where your message is going.

Cons:

• The displayed email address and PGP fingerprint is easily spoofed by an attacker. May in fact provide a false sense of security that the form is going to the right place.
• If submitter wants to send an image or file, they maybe simply email the email address in plaintext and expect their message to still be encrypted.
• Submitter may be confused by the presence PGP fingerprint and expiration date.

Alternatives

The source (submitter) doesn't really need to know that their message is being emailed. Thus I don't think we need to display the receiving email address. Instead, we could have the Hush Line user, during the installation process, write a short sentence to display in place of their email address, which could serve as a customized prompt ("Tell X organization about Y", etc.).

For headless installs, to make it easy for users to share their Hush Line URL with people in their proximity, include an automatically generated printable PDF.

Hypotheses:

• The PDF should include a QR code with the app's address
• Since this tool can be used by vulnerable young people, we want to include language to help supplement Hush Line with local emergency numbers and support lines.

Source:

• Scott J. via Plaintext
• Funded by OTF's SUA Lab
• Link to report (TBD)

Size Estimate:
Engineering: Medium (16 points / 2 weeks)

• Testing
• Implementation
  Research: Small (8 points / 1 week)
• Lit Review
• Use existing, approved research

Info and Relationships: Information, structure, and relationships conveyed
through presentation can be programmatically determined or are available
in text.
https://
ecp273mv5gooagvmealdr7ypnikpfso3epgtffgxf43d2xtiahdjrxad.onion.try.hushline.app/
The input or textarea must have a visible label related.
Visible labels benefit all users. When form fields do not have labels that are meaningful
and visible to all users, at all times, users might have to guess or infer what goes in
them.
Placeholder text must not be used as the only method of providing a label for a text
input, placeholder it is not enough because it is not compatible with all screen
readers and does not have enough contrast.

Waveshare 2.7"
Waveshare 2.13"

Conducting an Audit for Hush Line

If you're new to the project and looking for a way to contribute, conducting an audit in your area of expertise can be immensely valuable. Below are some areas where audits can be conducted, along with guidelines on how to proceed:

Usability Audit

1. Interface Design: Assess the intuitiveness of the interface. Is the navigation straightforward? Are the buttons and links clearly labeled?
2. User Experience: Install and use the app. Are there any pain points or areas where the user might get stuck?
3. Consistency: Check for consistency in design elements like colors, fonts, and layout across different pages.
4. Feedback and Error Messages: Ensure that the system provides clear feedback and guidance to the user, especially in case of errors.
5. Report: Document your findings with screenshots and specific examples. Suggest improvements where necessary.

Security Audit

1. Vulnerability Scanning: Use automated tools to scan for vulnerabilities like SQL injection, cross-site scripting (XSS), etc.
2. Code Review: Manually review the code for potential security issues, such as improper handling of user data.
3. Authentication and Authorization: Verify that the authentication mechanisms are robust and that users have appropriate access levels.
4. Data Encryption: Ensure that sensitive data is properly encrypted both in transit and at rest.
5. Report: Create a detailed report of your findings, including potential vulnerabilities and recommendations for mitigation.

Accessibility Audit

1. Compliance with Standards: Check if the application adheres to accessibility standards like WCAG (Web Content Accessibility Guidelines).
2. Screen Reader Compatibility: Test the application with screen readers to ensure it is navigable and readable.
3. Keyboard Navigation: Ensure that all functionalities are accessible via keyboard.
4. Color Contrast: Assess if the application has sufficient color contrast, especially for text.
5. Alt Text for Images: Verify that all images have appropriate alternative text for screen readers.
6. Report: Document your findings with examples and suggest any necessary changes to improve accessibility.

Writing Audit

1. Clarity and Conciseness: Check for clear and easily understandable text.
2. Consistency and Style: Ensure tone, style, and terminology are consistent.
3. Grammar and Spelling: Look for grammatical errors or typos.
4. Technical Accuracy: Verify accuracy of technical information.
5. Localization and Internationalization: Review content for proper localization.
6. Report: Document findings and suggest improvements.

Performance Audit

1. Load Time: Evaluate application load times and interactivity.
2. Resource Utilization: Assess CPU, memory, and network usage.
3. Optimization: Identify areas for performance improvement.
4. Scalability: Test how the application handles increased load.
5. Report: Provide analysis with metrics and recommendations.

Code Quality Audit

1. Code Structure: Review code organization and structure.
2. Best Practices: Assess adherence to coding standards and best practices.
3. Redundancy and Efficiency: Identify redundant or inefficient code.
4. Documentation: Check the quality of code comments and documentation.
5. Report: Offer insights and improvement suggestions.

General Guidelines for Auditing

• Detailed Reporting: Provide clear, actionable feedback in your audit report.
• Reproducibility: If you find issues, include steps to reproduce them.
• Prioritize: If you identify multiple issues, prioritize them based on impact.
• Be Constructive: Focus on providing constructive feedback that can help improve the project.
• Follow-up: Be open to discussing your findings with the maintainers and other contributors.

Your audits are crucial in helping us improve Hush Line. We appreciate the time and effort you put into examining our application thoroughly in your area of expertise.

Add a custom name for the header for better white-labeling.

I'm not convinced that running Hush Line's install-tor-only.sh script actually enables automatic Debian updates.

(I stumbled upon this issue while investigating #133 -- they're related, though I think solving this issue will answer the questions I raise in #133. )

What I did to test this hypothesis

On a fresh Raspberry Pi OS, I SSH'd in. I then ran sudo apt-get install unattended-upgrades.

This creates the file /etc/apt/apt.conf.d/50unattended-upgrades. Here's what I think is the relevant section, just after the file is created (so these are essentially the default settings):

// Within lines unattended-upgrades allows 2 macros whose values are
// derived from /etc/debian_version:
//   ${distro_id}            Installed origin.
//   ${distro_codename}      Installed codename (eg, "buster")
Unattended-Upgrade::Origins-Pattern {
        // Codename based matching:
        // This will follow the migration of a release through different
        // archives (e.g. from testing to stable and later oldstable).
        // Software will be the latest available for the named release,
        // but the Debian release itself will not be automatically upgraded.
//      "origin=Debian,codename=${distro_codename}-updates";
//      "origin=Debian,codename=${distro_codename}-proposed-updates";
        "origin=Debian,codename=${distro_codename},label=Debian";
        "origin=Debian,codename=${distro_codename},label=Debian-Security";
        "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";

        // Archive or Suite based matching:
        // Note that this will silently match a different release after
        // migration to the specified archive (e.g. testing becomes the
        // new stable).
//      "o=Debian,a=stable";
//      "o=Debian,a=stable-updates";
//      "o=Debian,a=proposed-updates";
//      "o=Debian Backports,a=${distro_codename}-backports,l=Debian Backports";
};

I think it's safe for me to assume that the way this works is you uncomment any setting you want to turn on, and comment out or delete any settings you want to turn off. Notice that, while the Debian security lines are not commented out, "origin=Debian,codename=${distro_codename}-updates";" IS commented out by default here.

Next, I'm going to run each relevant lines that are in Hush Line's install-tor-only.sh script. (Among other things, I assume one of the goals of the install script is to comment in "origin=Debian,codename=${distro_codename}-updates";", so we'll watch that line closely.)

First up:

sudo sed -i 's/\/\/\s\+"\${distro_id}:\${distro_codename}-security";/"\${distro_id}:\${distro_codename}-security";/g' /etc/apt/apt.conf.d/50unattended-upgrades

After running this command, my /etc/apt/apt.conf.d/50unattended-upgrades file reads:

// Within lines unattended-upgrades allows 2 macros whose values are
// derived from /etc/debian_version:
//   ${distro_id}            Installed origin.
//   ${distro_codename}      Installed codename (eg, "buster")
Unattended-Upgrade::Origins-Pattern {
        // Codename based matching:
        // This will follow the migration of a release through different
        // archives (e.g. from testing to stable and later oldstable).
        // Software will be the latest available for the named release,
        // but the Debian release itself will not be automatically upgraded.
//      "origin=Debian,codename=${distro_codename}-updates";
//      "origin=Debian,codename=${distro_codename}-proposed-updates";
        "origin=Debian,codename=${distro_codename},label=Debian";
        "origin=Debian,codename=${distro_codename},label=Debian-Security";
        "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";

        // Archive or Suite based matching:
        // Note that this will silently match a different release after
        // migration to the specified archive (e.g. testing becomes the
        // new stable).
//      "o=Debian,a=stable";
//      "o=Debian,a=stable-updates";
//      "o=Debian,a=proposed-updates";
//      "o=Debian Backports,a=${distro_codename}-backports,l=Debian Backports";
};

I think this is no change -- the "Debian-Security" lines remain commented in. All fine so far.

Next up, it looks like we try to uncomment the general updates line:

sudo sed -i 's/\/\/\s\+"\${distro_id}:\${distro_codename}-updates";/"\${distro_id}:\${distro_codename}-updates";/g' /etc/apt/apt.conf.d/50unattended-upgrades

And here is the file after running this sed command:

// Within lines unattended-upgrades allows 2 macros whose values are
// derived from /etc/debian_version:
//   ${distro_id}            Installed origin.
//   ${distro_codename}      Installed codename (eg, "buster")
Unattended-Upgrade::Origins-Pattern {
        // Codename based matching:
        // This will follow the migration of a release through different
        // archives (e.g. from testing to stable and later oldstable).
        // Software will be the latest available for the named release,
        // but the Debian release itself will not be automatically upgraded.
//      "origin=Debian,codename=${distro_codename}-updates";
//      "origin=Debian,codename=${distro_codename}-proposed-updates";
        "origin=Debian,codename=${distro_codename},label=Debian";
        "origin=Debian,codename=${distro_codename},label=Debian-Security";
        "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";

        // Archive or Suite based matching:
        // Note that this will silently match a different release after
        // migration to the specified archive (e.g. testing becomes the
        // new stable).
//      "o=Debian,a=stable";
//      "o=Debian,a=stable-updates";
//      "o=Debian,a=proposed-updates";
//      "o=Debian Backports,a=${distro_codename}-backports,l=Debian Backports";
};

Crucially, the line pertaining to updates is still commented out. This is the first thing that concerns me here. I worry that this installation script does not actually enable the unattended updates we want to be enabled. See below for a potential solution. For now, we'll keep working through the Tor-only install script.

I assume that next two sed commands in the install script pertain to this section of the 50unattended-updates file:

// Remove unused automatically installed kernel-related packages
// (kernel images, kernel headers and kernel version locked tools). 
//Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
 
// Do automatic removal of newly unused dependencies after the upgrade
//Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
        
// Do automatic removal of unused packages after the upgrade
// (equivalent to apt-get autoremove)
//Unattended-Upgrade::Remove-Unused-Dependencies "false";
        
// Automatically reboot *WITHOUT CONFIRMATION* if
//  the file /var/run/reboot-required is found after the upgrade
//Unattended-Upgrade::Automatic-Reboot "false";

The next command Hush Line installer runs is:

sudo sed -i 's|//\s*Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";|Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";|' /etc/apt/apt.conf.d/50unattended-upgrades

This one works fine. File is now:

// Remove unused automatically installed kernel-related packages
// (kernel images, kernel headers and kernel version locked tools).
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";

// Do automatic removal of newly unused dependencies after the upgrade
//Unattended-Upgrade::Remove-New-Unused-Dependencies "true";

The next command in the Hush Line script looks similar.

sudo sed -i 's|//\s*Unattended-Upgrade::Remove-Unused-Dependencies "true";|Unattended-Upgrade::Remove-Unused-Dependencies "true";|' /etc/apt/apt.conf.d/50unattended-upgrades

However, it searches for a commented-out setting set to "true" when the commented-out Remove-Unused-Dependencies setting in the file is set to "false". Thus, this sed command won't find a text to act on.

As expected after running it, the relevant line remains commented in.

// Remove unused automatically installed kernel-related packages
// (kernel images, kernel headers and kernel version locked tools).
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
 
// Do automatic removal of newly unused dependencies after the upgrade
//Unattended-Upgrade::Remove-New-Unused-Dependencies "true";

// Do automatic removal of unused packages after the upgrade
// (equivalent to apt-get autoremove)
//Unattended-Upgrade::Remove-Unused-Dependencies "false";
        
// Automatically reboot *WITHOUT CONFIRMATION* if
//  the file /var/run/reboot-required is found after the upgrade
//Unattended-Upgrade::Automatic-Reboot "false";

Checking whether a standard Blackbox install reproduces these issues flagged above

Now, just to make sure I'm not missing some piece of code in the Hush Line install script(s) that do anything else to these settings, let's do a fresh Blackbox install and see what the state of /etc/apt/apt.conf.d/50unattended-upgrades is once its up and running.

// Within lines unattended-upgrades allows 2 macros whose values are
// derived from /etc/debian_version:
//   ${distro_id}            Installed origin.
//   ${distro_codename}      Installed codename (eg, "buster")
Unattended-Upgrade::Origins-Pattern {
        // Codename based matching:
        // This will follow the migration of a release through different
        // archives (e.g. from testing to stable and later oldstable).
        // Software will be the latest available for the named release,
        // but the Debian release itself will not be automatically upgraded.
//      "origin=Debian,codename=${distro_codename}-updates";
//      "origin=Debian,codename=${distro_codename}-proposed-updates";
        "origin=Debian,codename=${distro_codename},label=Debian";
        "origin=Debian,codename=${distro_codename},label=Debian-Security";
        "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";

        // Archive or Suite based matching:
        // Note that this will silently match a different release after
        // migration to the specified archive (e.g. testing becomes the
        // new stable).
//      "o=Debian,a=stable";
//      "o=Debian,a=stable-updates";
//      "o=Debian,a=proposed-updates";
//      "o=Debian Backports,a=${distro_codename}-backports,l=Debian Backports";
};

As expected, while "Security" is commented in, regular "-updates" remain commented out.

Also, as expected, //Unattended-Upgrade::Remove-Unused-Dependencies "false"; remains commented out:

// Remove unused automatically installed kernel-related packages
// (kernel images, kernel headers and kernel version locked tools).
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";

// Do automatic removal of newly unused dependencies after the upgrade
//Unattended-Upgrade::Remove-New-Unused-Dependencies "true";

// Do automatic removal of unused packages after the upgrade
// (equivalent to apt-get autoremove)
//Unattended-Upgrade::Remove-Unused-Dependencies "false";

// Automatically reboot *WITHOUT CONFIRMATION* if
//  the file /var/run/reboot-required is found after the upgrade
//Unattended-Upgrade::Automatic-Reboot "false";

Half a solution: A sed command that successfully uncomments "updates"

After some fiddling, I wrote a sed command that seems to successfully uncomment the updates line.

sed -i 's/\/\/ \+\"origin=Debian,codename=${distro_codename}-updates/        "origin=Debian,codename=${distro_codename}-updates/g' /etc/apt/apt.conf.d/50unattended-upgrades

Running this gives us what I think is the desired result:

Unattended-Upgrade::Origins-Pattern {
// Codename based matching:
// This will follow the migration of a release through different
// archives (e.g. from testing to stable and later oldstable).
// Software will be the latest available for the named release,
// but the Debian release itself will not be automatically upgraded.
        "origin=Debian,codename=${distro_codename}-updates";
//      "origin=Debian,codename=${distro_codename}-proposed-updates";
"origin=Debian,codename=${distro_codename},label=Debian";
"origin=Debian,codename=${distro_codename},label=Debian-Security";
"origin=Debian,codename=${distro_codename}-security,label=Debian-Security";

(If we don't care about the 8-space indentation, we can do: sed -i 's/\/\/ \+\"origin=Debian,codename=${distro_codename}-updates/"origin=Debian,codename=${distro_codename}-updates/g' /etc/apt/apt.conf.d/50unattended-upgrades)

We can do the same for the security updates

sed -i 's/\/\/ \+\"origin=Debian,codename=${distro_codename}-security/        "origin=Debian,codename=${distro_codename}-security/g' /etc/apt/apt.conf.d/50unattended-upgrades

but it seems as if that line is not commented out by default, and thus isn't strictly necessary. But maybe it's good to have in case the default file changes.

Fixing "Remove-Unused-Dependencies"

It's unclear to me if we want to comment in the setting //Unattended-Upgrade::Remove-Unused-Dependencies "false";, since that would, presumably, turn OFF removing unused dependencies.

ISSUE -- the best looking place to share re TOR ... I think it violates the community rules (see image).
Other ideas on where to post, or keep it to the S&D page?

@glenn-sorrentino

Thanks!

Give prominence to an article if released within the last 24 hours

1.4.6.Contrast (Enhanced): The visual presentation of text and images of
text has a contrast ratio of at least 7:1, except for the following:
• Large Text: Large-scale text and images of large-scale text have a contrast ratio
of at least 4.5:1;
• Incidental: Text or images of text that are part of an inactive user interface
component, that are pure decoration, that are not visible to anyone, or that are
part of a picture that contains significant other visual content, have no contrast
requirement.
• Logotypes: Text that is part of a logo or brand name has no minimum contrast
requirement.
See 1

Summary

Refactor the existing app.py file into multiple modules for better maintainability and readability.

Details

The app.py file currently contains various functionalities like routing, database interactions, form handling, etc. These should be separated into distinct modules.

Tasks

• Analyze app.py to identify distinct components.
• Create separate module files (crypto.py, db.py, forms.py, models.py, routes.py) in the hushline subdirectory.
• Move encryption and decryption related functions to crypto.py.
• Move database connection and query functions to db.py.
• Move form definitions to forms.py.
• Move ORM model definitions to models.py.
• Move Flask routes/views to routes.py.
• Refactor app.py to import these modules.
• Update __init__.py to initialize the Flask app and configure extensions.
• Test the application after each change.

Acceptance Criteria

• Each module should only contain related functionalities.
• The application should work as expected after refactoring.

Another bit of the install scripts that shellcheck flagged are these two lines.

Here's what shellcheck says about the first line above (a similar warning is given for the second line):

[Line 158:](javascript:setPosition(158, 8))
sed -i 's/\/\/\s\+"\${distro_id}:\${distro_codename}-security";/"\${distro_id}:\${distro_codename}-security";/g' /etc/apt/apt.conf.d/50unattended-upgrades
       ^-- [SC2016](https://www.shellcheck.net/wiki/SC2016) (info): Expressions don't expand in single quotes, use double quotes for that.

I think both these lines are trying to do a global substitution-in-place in the file /etc/apt/apt.conf.d/50unattended-upgrades. (My regex reading isn't great!) But the important question that shellcheck is asking is whether the variables distro_id and distro_codename are being expanded.

I wrote a little test script to test this:

distro_id="Some ID"
distro_codename="Some codename"
echo 's/\/\/\s\+"\${distro_id}:\${distro_codename}-security";/"\${distro_id}:\${distro_codename}-security";/g'

This echo statement prints the variables' names, not their values. So literally: s/\/\/\s\+"\${distro_id}:\${distro_codename}-security";/"\${distro_id}:\${distro_codename}-security";/g

I'm not sure how to fix this, but it seems important.

Install using "ANTIALIAS" for display_status.py not supported.

Update to "BICUBIC".

When I ran scripts/install-tor-only.sh through shellcheck, one of the things it flagged was this line:

Here's what shellcheck prints:

[Line 145:](javascript:setPosition(145, 10))
nginx -t && systemctl restart nginx || error_exit
         ^-- [SC2015](https://www.shellcheck.net/wiki/SC2015) (info): Note that A && B || C is not if-then-else. C may run when A is true.

My interpretation here is that shellcheck wants you to be more explicit about the order of operations, which we can do with parenthesis.

My guess is that we want something like this:

(nginx -t && systemctl restart nginx) || error_exit

This makes more clear that if either nginx -t or systemctl restart nginx return false, the code should run error_exit, which I think is the intention of this line of code. And shellcheck is happy with this line (no warning).

Target Size: The size of the target for pointer inputs is at least 44 by 44
CSS pixels except when:
• Equivalent: The target is available through an equivalent link or control on the
same page that is at least 44 by 44 CSS pixels;
• Inline: The target is in a sentence or block of text;
• User Agent Control: The size of the target is determined by the user agent and
is not modified by the author;
Level Compliance 2.5.2.
A Yes
Level Compliance 2.5.3.
A Yes
Level Compliance 2.5.4.
A Does not apply
29
• Essential: A particular presentation of the target is essential to the information
being conveyed.
The intent of this success criteria is to ensure that target sizes are large enough for
users to easily activate them, even if the user is accessing content on a small handheld
touch screen device, has limited dexterity, or has trouble activating small targets for
other reasons. For instance, mice and similar pointing devices can be hard to use for
these users, and a larger target will help them activate the target.

@glenn-sorrentino did we want to put this up on S&D LinkedIn? Could be a great way to get people outside of the tech / cyber security sector to see it! e.g. the students, journalists, med ppl (I've a fair few students and med / psych folk in my network).

Lemme know!

Led by Scott via Plaintext

I noticed here:

That this script will git clone this e-Paper repo down to wherever the user happens to run the script from.

Should we have a cd [somewhere] command above this git clone call, so we're sure of where it's being cloned to, regardless of what working directory the user is in, like we do with with Hush Line's general install script? Or pip install it to an absolute path, as we do with Blackbox?

The intent of this Success Criterion is to help users find content and orient themselves
within it by ensuring that each Web page has a descriptive title. Titles identify the
current location without requiring users to read or interpret page content.
Level Compliance 2.4.2.
A No
23
• The page <title> must be accurate and informative.
• The <title> should be concise.
• The page <title> should be unique, if possible.
• Unique information should come first in the <title>.
Currently, HushLine website home and try.HushLine have the same title:

Link Purpose (Link Only): A mechanism is available to allow the purpose
of each link to be identified from link text alone, except where the purpose of
the link would be ambiguous to users in general.

Problem:
Right now the screen doesn't communicate if the device is online, but only if the app is running. This can lead to users running the service without knowing it's unreachable.

Potential Solution:
A wifi signifier in the same pattern as smart devices and personal computers.
Full strength: ---
Medium: --
Weak: -
None: /

Providing documentation surrounding the research process involved in creating the surveys for HushLine and OnionShare.

This document will provide rationale and process for documentation and visibility purposes regarding our methods.

Tracking issue for:

• https://github.com/scidsg/hushline/security/code-scanning/2

Contrast (Minimum): The visual presentation of text and images of
text has a contrast ratio of at least 4.5:1, except for the following:
• Large Text: Large-scale text and images of large-scale text have a contrast ratio
of at least 3:1;
• Incidental: Text or images of text that are part of an inactive user interface
component, that are pure decoration, that are not visible to anyone, or that are
part of a picture that contains significant other visual content, have no contrast
requirement.
• Logotypes: Text that is part of a logo or brand name has no minimum contrast
requirement.
The intent of this Success Criterion is to provide enough contrast between text and its
background so that it can be read by people with moderately low vision (who do not use
contrast-enhancing assistive technology).
Color deficiencies can affect luminance contrast somewhat. Therefore, in the
recommendation, the contrast is calculated in such a way that color is not a key factor
so that people who have a color vision deficit will also have adequate contrast between
the text and the background.
You can use one of these tools to validate any contrast.

In the QA table, it might be useful to include the hash of the most recent commit for each QA install/run.

For example, if I was to do a test install right now, I'd mark the date Nov 1, but we might have multiple commits throughout today. A more exact measure of the state of the project at a given time is the hash of the last commit. Right now, for example, that would be bf77df5. (GitHub is good about automatically making these in to links.) Maybe "Last commit" could be a new column in the QA table?

https://github.com/scidsg/project-info/blob/main/hush-line/1.%20Accessibility/WCAG%202.1%20AAA_HushLine%20website.pdf

1.3.3.Sensory Characteristics: Instructions provided for understanding and
operating content do not rely solely on sensory characteristics of
components such as shape, size, visual location, orientation, or sound.
The intent of this Success Criterion is to ensure that all users can access instructions for
using the content, even when they cannot perceive shape or size or use information
about spatial location or orientation.
While using shape, provide visible label/name to the control

Summary

Integrate Poetry to manage the project's dependencies and virtual environment.

Details

Move from using requirements.txt to Poetry for better dependency management and to leverage its benefits in handling virtual environments and project configurations.

Tasks

• Install Poetry on the development machine.
• Initialize Poetry in the project root to create a pyproject.toml.
• Add current dependencies from requirements.txt to Poetry.
• Remove requirements.txt after moving dependencies.
• Use poetry shell to manage the virtual environment.
• Update the README/documentation to reflect the use of Poetry.
• If applicable, build and publish the package using Poetry.
• Update CI/CD configuration to use Poetry for dependency management.

Acceptance Criteria

• All project dependencies should be managed by Poetry.
• The project should correctly install and run within a Poetry-managed virtual environment.
• Documentation should clearly explain how to set up the project with Poetry.

Connect with Elio to start work stream for Hush Line visual design work.

Can't login ; using the credentials it sent a message to confirm identity... which I can't .

Can you authorize @glenn-sorrentino ?

Labels or Instructions: Labels or instructions are provided when content
requires user input.
Level Compliance 3.3.2.
A No

It is very important that blind users have access to the instruction at the right time,
especially in form mode where the screen reader is only reading the labels of each
input. You could use aria-describedby.
This recommendation is related to 1.3.1, after adding a label, you can use aria-
describedby.

The recommendation is that you relate to the textarea as much information as you
want, so the blind users hear it at the right time when navigating with keyboard in case
there are not exploring with the arrow keys.
You could use aria-describedby. See example TEST TA-012.
https://thepaciellogroup.github.io/AT-browser-tests/test-files/textarea.html

Share links to the Husline and OnionShare surveys, for the purposes of participant recruitment and data collection.

The links will bring individuals to the respective survey, which they can then complete.

FOSSTODON HUSHLINE
Hushline is a secure, confidential information sharing tool. Did you know this existed?!

Do you use something like this?
Do you wish you or your job had something like this?!

Come share your thoughts with us in an anonymous 1 minute survey!

https://cryptpad.fr/form/#/2/form/view/aznAzzpG6Fh3K1Dq0JjslCK-NmSugmfLTP7ej+SqRl0/

Is your feature request related to a problem? Please describe.
I'm really into I2P and noticed that Hush Line doesn't support it. This is a bit of a setback for me, as I prefer I2P's approach to privacy over alternatives like Tor.

Describe the solution you'd like
I'd love to see Hush Line integrate I2P support. I2P excels in creating a private network layer, which would significantly enhance Hush Line's existing privacy features. This integration would make the app even more appealing to privacy enthusiasts like myself who favor I2P.

Describe alternatives you've considered
Although Tor and VPNs are common alternatives, I2P's unique approach to decentralization and anonymity makes it a more attractive option for users serious about their online privacy.

Additional context

All focusable elements must have a visual focus and visual hover indicator when in
focus.
As users tab through links elements, they must be able to see where the keyboard
focus is. A visual focus indicator should also be available to mouse users. You can also
enhance the active states.
Note: you could create different styles for each of the different states — focus, hover,
and active — but you don't have to. Sometimes it makes more sense to give them all
the same style.
There is a black outline in the Submit button, but since the button is black, it is almost
no noticeable.

Add images to articles on homepage.

I'm testing out the easy install (curl -sSL https://install.hushline.app | bash) in an Ubuntu docker container. I get this error:

root@b3d4f8372e0e:/# curl -sSL https://install.hushline.app | bash
  _    _           _       _      _            
 | |  | |         | |     | |    (_)           
 | |__| |_   _ ___| |__   | |     _ _ __   ___ 
 |  __  | | | / __| '_ \  | |    | | '_ \ / _ \
 | |  | | |_| \__ \ | | | | |____| | | | |  __/
 |_|  |_|\__,_|___/_| |_| |______|_|_| |_|\___|
                                               
🤫 Your anonymous tip line and suggestion box. 

A free tool by Science & Design - https://scidsg.org
bash: line 19: whiptail: command not found
You chose Cancel.
root@b3d4f8372e0e:/#       

If I install the whiptail package, it then works. (Likewise, on a totally fresh Ubuntu, I had to install the curl package too.)

Seems that if whiptail isn't installed, it should handle it better-- like, display instructions on how to install it for their OS.

Finishing the installation wizard, it seems I need these packages in ubuntu:

• curl
• whiptail
• sudo
• git
• wget

Design File:
https://www.figma.com/file/8zwfIJvrBOTfVu2OYiLynw/Hush-Line---Social-Media?type=design&node-id=0%3A1&mode=design&t=MmIcf37GuI1b55t2-1

Content DB:
https://docs.google.com/spreadsheets/d/1f4wMx0i8evxH1QGtZP5aEpvLSrDZyYi6XfR_XazXSgc/edit?usp=sharing

What happened

During my first installation of Hush Line, I entered the password to the email address incorrectly (I entered the actual email account's password, rather than the generated app password).

When I hit enter to submit this password, Hush Line never gave an error message of any kind. In fact, I made it through the entire installation process swimmingly, even receiving the nice ✅ Installation complete! message in my Terminal at the end.

However, when I went to send a test message through my up-and-running Hush Line form, I simply never received an email in my inbox. A real-world user who entered an incorrect password as I did would very likely just think they weren't getting any submissions to their Hush Line.

What I expected to happen

Ideally, the installing user would get an error message if they entered an incorrect password for the email account Hush Line is to use, the sooner the better.

Possible solutions

Technically, I'm not sure how to "test" this correctness of the email password... maybe Hush Line itself sends a test/confirmation message itself at the end of the installation process and somehow checks if it was successful or not?

Ability to troubleshoot

Even when I knew the problem -- that I had entered the wrong password -- I wasn't certain how to best fix the issue with my installation. I ended up simply running the installation script again, hoping for the best. I think this ended up working, but I think it hints at a need for some kind of option to edit your Hush Line configuration if/when needed?

Fix deprecated image processing properties
Update epd library to V2
Reduce refresh rate with new epd library

Graphical Objects: Parts of graphics required to understand the content, except
when a particular presentation of graphics is essential to the information being
conveyed.
The intent of this Success Criterion is to ensure that active user interface components
(i.e., controls) and meaningful graphics are distinguishable by people with moderately
low vision.
Low contrast controls are more difficult to perceive and may be completely missed by
people with a visual impairment.
For active controls such as buttons, tabs, links, any visual information provided that is
necessary for a user to identify that a control is present and how to operate it must have
a minimum 3 to 1 contrast ratio with the adjacent colors.
Also, any visual information necessary to indicate state, such as whether a component
is focus, hover, select, press, check, visited/unvisited, must also ensure that the
information used to identify the control in that state has a minimum 3 to 1 contrast ratio.
Currently, there is no visible focus in the textarea.

https://github.com/scidsg/project-info/blob/main/hush-line/1.%20Accessibility/WCAG%202.1%20AAA_HushLine%20website.pdf

In progress
Conducted by Subgraph