Custom Query (73 matches)

As discussed during the anonymous services meeting, we should change (or discuss changing) the nomenclature on the website to reflect ​Syverson's Genuine Onion'' paper.

Please do not make the mistake of grepping for Hidden and replacing it with Onion.

On reading ​https://www.gnu.org/software/repo-criteria.html (as pointed out on tor-talk), I came across "B0": "All code sent to the user's browser must be free software and labeled for LibreJS or other suitable free automatic license analyzer".

I don't know anything about the politics behind libre JS or the like, but I know some of the Tor sites use JavaScript, and I also know we're not meaning to keep any of it non-free.

Is there some enthusiastic free software zealot out there who wants to inventory the javascript used on various Tor sites, and move us closer to labeling it all as free?

Usability of MacOS installation process

Consequence: User is unable to verify package signature

Steps to reproduce:

1. Download Tor browser

2. Go to ​https://www.torproject.org/docs/verifying-signatures.html.en for instructions.

3. Read the block of text for MacOS and Linux.

4. Follow the link at the bottom of that section to:

​https://www.gnupg.org/documentation/

5. Struggle with the information on that page.

6. Try to go to the SourceForge link there for GPG Mac download.

uBlock Origin blockade: uBlock Origin has prevented the following page from loading:http://macgpg.sourceforge.net/

Because of the following filter

Found in: uBlock filters – Badware risks

7. Give up.

What should have happened:

Follow the GPGTools link at the top of the Tor page's Mac/Linux instruction block. ​https://www.torproject.org/docs/verifying-signatures.html.en

Suggested fixes:

• Divide the MacOS instructions from the Linux instructions.

• Add numbers to the procedures... something like this, for the MacOS:

1. Download Tor Browser and save the signature.asc to your Desktop.
2. Download and install GPGTools.
3. Open a Terminal window (Terminal is in /Applications/Utilities or find it with search)
4. Paste the following into the terminal: [... ...]

...adding links appropriately in the procedure

• Use link colors to help people visually scan through the pages. Take advantage of the human tendency to skim over text and just read the bold, colored stuff:

-Use a color with better contrast against black (the green is wonderful but too dark for good contrast) -Include more keywords in links

• Related installation issue that probably belongs somewhere else:

Opening the DMG and installing the Tor Browser: The application file shows a file modification date of Dec 31, 1999, so it's difficult to know whether the downloaded one is newer than one I have already. No version number is in the file name. Get Info (cmd-I) (which not every Mac user knows about) does show a version number, and it also shows the file has a creation date of Dec 31, 2000, which is before the mod date. The weird dates might cause version control issues but are also likely to worry people who see them.

When I follow a link online to an old version of Tor Browser Bundle, e.g.

​https://www.torproject.org/dist/torbrowser/3.6.6/torbrowser-install-3.6.6_en-US.exe

I receive a 404 message. Instead of displaying a default 404 page, a Tor Browser specific 404 response should helpfully redirect users to the latest version of Tor Browser, either by providing a helpful message such as "Click here to download Tor Browser" or via a 301 redirect.

Right now we have "alpha" and "stable". But sometimes we want to have an extra stable listed as well.

No hurry on this one.

This is the master ticket created to track the efforts to implement a new site for Tor Project, based on the discussion done during Berlin Dev Meeting in Oct 2015: https://trac.torproject.org/projects/tor/wiki/Website/MainSiteRedesign

You can find the other phases of the project and more information on the link above as well.

Phase 1:

• Content mapping
• Decide what to do with content we are moving out of the main site
• Start mocking how the new site will look like
• Test our mocks (get user research help)

This ticket is for tracking different mocks proposed for torproject.org site based on the Berlin Dev Meeting 2015 discussion: https://trac.torproject.org/projects/tor/wiki/Website/MainSiteRedesign

We will reach out to designers in the community and ask for their help.

I've found some behavioral inconsistencies in torproject.org, which I think can confuse our visitors. It would be great if we could fix some of these things.

1. If you go to the "About Tor" page or the "Contact" pages, both are highlighted in the horizontal menu. (to view: ​https://www.torproject.org/about/overview.html.en)

2. About Tor > Projects leads to "Software and Services" (​https://www.torproject.org/projects/projects.html.en). I think that this should be consistently named.

3. About Tor > Projects does does not redirect to a different page and has submenu items visible from the About Tor page. About Tor > Documentation and About Tor > Projects both do. My suggestion is to making Tor People redirect to a separate page with a separate vertical side menu, but also having the About Tor> Projects and About Tor > Documentation menus nested in the vertical menu on About Tor is also acceptable, as long as these side menus behave consistently.

4. Some pages are blank: ​https://www.torproject.org/docs/manual.html.en, ​https://www.torproject.org/docs/installguide.html.en. This is bad because it makes them look broken. I don't have a better idea of what to put here without restructuring the whole website contents, but I think at the very least it should not be blank.

5. You can browse to some pages that have different styling (go ​https://www.torproject.org/docs/documentation.html.en, click "Install Tor Browser" to get to ​https://www.torproject.org/projects/torbrowser.html.en), which really throws me off. It looks like it's a different site, or I've been redirected/scammed. I think there are other instances of this, but I can't recall every instance of where this happened.

6. This may not be too big of an issue, but the main menu (Tor Home About Tor Documentation Press Blog Contact) keeps the current tab highlighted if the user is in that tab (Press is highlighted on ​https://www.torproject.org/press/press.html.en), but this doesn't happen for the submenu (Download Volunteer Donate)--the volunteer page ​https://www.torproject.org/getinvolved/volunteer.html.en does not have volunteer highlighted.

When viewing this web page I find I have to increase the size of text because I have poor vision.

If I use the control-+ to increase the text size, your web page forces me to scroll the window left to right to read lines of text.

Use the method that wikipedia.com uses for displaying the screen.

wikipedia.com adjusts the text to fit within the displayed window by making lines shorter as text size increases and making lines longer as text size increases.

Go to wikipedia.com and view any entry. Then do a control-+ to increase text size and see what it does. Then do a control-- to reduce size of text and see what it does. NOTE: I am using Ubuntu 16.04 - hence my control-+ increases text size and control-- will decrease text size. I don't know what keys are used to do this with other operating systems.

Just an idea from a 71 year old with bad eyes.

It would be useful for visitors to our web pages to have access to content that:

• goes into more depth than a FAQ entry
• is more formal than a blog post
• is less comprehensive than a reference manual section
• is more stable than a wiki page

These pages would form sort of a knowledge base or resource section.

We start with code signing on OS X now and should have instructions on our website for getting rid of the code signing parts to make it easier for comparing the things we ship with the things we built.

Currently check.torproject.org don't have onion. Use .onion to determine whether user is via Tor or not.

When TBA is first launched there is a "Learn More" link the user can click. We should take advantage of this and create a useful webpage where the user can learn more. (Orfox currently has this, too, and the link goes to ​the Guardian Project's Orfox page.

Gpg recently failed to verify a Tor Browser download - a first for me. Since data errors in downloads aren't as common as years ago, I assumed an error in the *.asc sig file itself, or other issues.

Such as my Linux GPG version not playing well with the version used to sign Tor Browser.

I wanted to verify checksum of the downloaded TBB, but after a few searches on TorProject didn't find the checksum, I re-download TBB. It was faster in the long run, but it's a big package to re-download for users with limited data plans, when a few byte checksum would suffice to see if there was a download data error.

I propose that checksum files - or a prominent link, be added to the download page - not make users hunt them. That's how many well run projects seem to do it - app packages, sig files & checksums are all easily found, or have links on the same page.

The statement, "See our instructions on how to verify package signatures, which allows you to make sure you've downloaded the file we intended you to get. Also, note that the Firefox ESR in our bundles is modified from the default Firefox ESR " should be placed above the packages & sig files, where users are far more likely to see it.

The wording could be stronger, clearer - why users would want to verify the TBB / other packages PGP signatures of downloads, EVEN from TorProject's site (not rely solely on checksums). A brief statement why verifying signed packages is important & how it's unrelated to using checksums. If users (of anything) don't understand a real purpose or need, they're more likely to skip steps.

I could write something to make changes, additions & submit for consideration, but only if there's interest in making changes to general security methods to educate users, that work for many products.

• Verification instructions: They're generally good & someone did a lot of work, but many users unfamiliar w/ PGP / GPG's real purpose & the procedures may be clueless.

On the Windows verify instructions (maybe Linux, OS X), it's unclear which signature & which "package" they're verifying. If they're installing GPG or gpg4win, the instructions should include steps (or link to clear instructions) to first verify GPG itself (once), then a separate verification of downloaded Tor products - EVEN from TorProject's https site.

The statement, "make sure you've downloaded the file we intended you to get." means little to non-gpg users or slightly familiar. To many, they downloaded the correct platform package, therefore they "have the file intended for their OS." As far as they know, they did everything required.

When I do release announcements, I say "you can find the source code in the usual place". I'd really like to link to the download page instead -- but the download page is pretty big, and people are likely to get confused. Instead, I should link to the "source code" header in particular... but I don't see a way to do that in our current download page.

Any solution or alternative would be welcome.