Custom Query (70 matches)

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

No hurry on this one.

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.

Background

In the past years we worked on many policy documents (CoC, membership policy, etc). We should make them available on a prominent page on torproject.org.

Current situation

The policy documents are published in the gitweb: ​https://gitweb.torproject.org/community/policies.git/tree/

Some other bylaws can be found here: ​https://www.torproject.org/about/financials.html.en

Expected situation

Create a section within "About Tor" named "Policies". With a general text describing our current policies.

I would also suggest that we inline describe our current values, how membership works, how voting works, etc.

Create formatted versions of:

• CoC
• Membership guidelines
• statement of values
• voting system
• board documents (like bylaws)
• ...

and link them from the main policy page.

*Timeline*

I would suggest that we collect ideas within this ticket and make a meeting in Mexico :-)

The research portal isn't the prettiest website, nor does it contain the most up to date information. This ticket will act as a central ticket for tasks around updating and refreshing the research portal.

The Metrics/Analysis trac component has been gathering tickets that are not really suited to being trac tickets. The Metrics team certainly isn't going to look at them any time soon. I had tagged these with the keyword research-ideas.

The ideas page is at ​https://research.torproject.org/ideas.html on the portal.

The bug tracker link to Tor on ​https://www.torproject.org/getinvolved/volunteer.html.en requires a trac account. It is very unlikely that anyone visiting this page for the first time (like after clicking "Get Involved" on about:tor) is logged in.

This longer link gives the same result without login.

I don't know though if this should be fixed in trac or the website.

arma lately mentioned that it is probably not a good idea anymore to use tor-ramdisk. I am looking into alternatives.

Currently tor-ramdisk is mentioned on the new (coming) community projects list (#16576) and the volunteer page: ​http://expyuzz4wqqyqhjn.onion/projects/projects.html.en ​https://github.com/torproject/webwml/pull/38

Also the wiki links it at several places: AutomationInventory doc/VM doc/EmbeddedTips

Wikipedia has a page about it (#27668).

Adding #13703 as parent to let them know of each other.

Which are good alternatives (in use)?

Affected page: ​https://www.torproject.org/getinvolved/relays.html.en

Problem: "No video with supported format and MIME type found" The video's URL is ​https://media.torproject.org/video/2012-03-04-BuildingBridges.ogv and forbidden by CSP.

Solution: Change

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'

(​https://www.hardenize.com/report/torproject.org/1544035352#www_csp)

to

Content-Security-Policy: default-src 'self'; style-src 'self' 'unsafe-inline'; media-src 'self' https://media.torproject.org

or even to

Content-Security-Policy: default-src 'self'; style-src 'self' 'unsafe-inline'; media-src 'self' https://media.torproject.org; frame-ancestors 'self'; block-all-mixed-content; disown-opener; plugin-types application/pdf; base-uri 'self'

On ​https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerification we outline how to make a link between the bundles we actually ship (including update files) to the artifacts one gets by following our reproducible builds path.

So far, this contains instructions for Linux and Windows bundles. macOS is tricky and dealt with in #18925.

This ticket is to add respective instructions for our .apk file(s) we ship.

When running our new website with 'lektor server' python 2.x stacktraces, and fails to load 'about' pages. Hopefully I'll be able to provide a branch to pull from for future patches (#29493), but until then providing attaching a patch file you should be able to apply with 'git am 0001-Stacktrace-when-launching-lektor-server.patch'.