Is it okay to @ staff if I want their input on something?

Meta
1

A while ago, I asked a question about what protections the security levels in the Tor and Mullvad browsers provide in practice, and I didn’t get a definitive answer. I think this is an important question that should get input from someone who ostensibly knows what they’re talking about, but I don’t want to overstep boundaries in order to get it answered.

I already looked in the community guidelines but couldn’t find anything.

2

I’m not sure how fond they are of that tbh. Without offending the members of staff I’d also like to say that not all of them are equally well versed in privacy/security and sometimes I personally think regular users on the forum provise better answers in some ares which is natural as not everyone knows every area.

I’d advise you to not @ them although I’m also not sure if it would be allowed. What you could do on the other hand is ask follow-up questions since there were people that answered in that thread.

3

I also agree, some staff members I do not align with their style. I tend to assume they focus more on the moderation side, keeping clutter out and rules enforced, which is still greatly appreciated. Some staff provide good conversations though, but I’d say don’t tag unless it requires moderation or staff specific pings.

Otherwise, forums are async in nature, and a conversation doesn’t have to resolve immediately, it can take days or weeks, sometimes months.

4

cont. I think web browsers are some of the most complicated applications and most important we have on our computers. Asking about exactly how some behaviors may exactly differ is actually pretty tough unless you’re someone who really knows browsers. The only subject matter expert (SME) on this I can think of is the librewolf maintainer who visits here - consider giving them a friendly ping in your thread (SMEs are great to tag, I.e. for anything DNS related I’d be happy to have ignoramous reply).

5

I was aware of this thread, but didn’t want just barge in and waited to see if someone from the staff responds.

The security settings are implemented using the noscript integration.

These are the preferences it sets for each level

// __kSecuritySettings__.
// A table of all prefs bound to the security slider, and the value
// for each security setting. Note that 2-m and 3-m are identical,
// corresponding to the old 2-medium-high setting. We also separately
// bind NoScript settings to the browser.security_level.security_slider
/* eslint-disable */
// prettier-ignore
const kSecuritySettings = {
  // Preference name:                        [0, 1-high 2-m    3-m    4-low]
  "javascript.options.ion":                  [,  false, false, false, true ],
  "javascript.options.baselinejit":          [,  false, false, false, true ],
  "javascript.options.native_regexp":        [,  false, false, false, true ],
  "mathml.disabled":                         [,  true,  true,  true,  false],
  "gfx.font_rendering.graphite.enabled":     [,  false, false, false, true ],
  "gfx.font_rendering.opentype_svg.enabled": [,  false, false, false, true ],
  "svg.disabled":                            [,  true,  false, false, false],
  // Expect asmjs to be switched off for all levels. See tor-browser#44687.
  // TODO: Stop tracking this preference entirely. See tor-browser#44712.
  "javascript.options.asmjs":                [,  false, false, false, false],
  // tor-browser#44234, tor-browser#44242: this interferes with the correct
  // functioning of the browser. So, WASM is also handled by NoScript now.
  "javascript.options.wasm":                 [,  true,  true,  true,  true ],
};

and these the “capabilities”

// Minimum and maximum capability states as controlled by NoScript.
const max_caps = [
  "fetch",
  "font",
  "frame",
  "media",
  "object",
  "other",
  "script",
  "wasm",
  "webgl",
  "noscript",
];
const min_caps = ["frame", "other", "noscript"];

// Untrusted capabilities for [Standard, Safer, Safest] safety levels.
const untrusted_caps = [
  max_caps, // standard safety: neither http nor https
  ["frame", "font", "object", "other", "noscript"], // safer: http
  min_caps, // safest: neither http nor https
];

// Default capabilities for [Standard, Safer, Safest] safety levels.
const default_caps = [
  max_caps, // standard: both http and https
  ["fetch", "font", "frame", "object", "other", "script", "noscript"], // safer: https only
  min_caps, // safest: both http and https
];

// __noscriptSettings(safetyLevel)__.
// Produces NoScript settings with policy according to
// the safetyLevel which can be:
// 0 = Standard, 1 = Safer, 2 = Safest
//
// At the "Standard" safety level, we leave all sites at
// default with maximal capabilities. Essentially no content
// is blocked.
//
// At "Safer", we set all http sites to untrusted,
// and all https sites to default. Scripts are only permitted
// on https sites. Neither type of site is supposed to allow
// media, but both allow fonts (as we used in legacy NoScript).
//
// At "Safest", all sites are at default with minimal
// capabilities. Most things are blocked.
let noscriptSettings = safetyLevel => ({
  __meta: {
    name: "updateSettings",
    recipientInfo: null,
  },
  policy: {
    DEFAULT: {
      capabilities: default_caps[safetyLevel],
      temp: false,
    },
    TRUSTED: {
      capabilities: max_caps,
      temp: false,
    },
    UNTRUSTED: {
      capabilities: untrusted_caps[safetyLevel],
      temp: false,
    },
    sites: {
      trusted: [],
      untrusted: [[], ["http:"], []][safetyLevel],
      custom: {},
      temp: [],
    },
    enforced: true,
    autoAllowTop: false,
  },
  isTorBrowser: true,
  tabId: -1,
});

So you essentially have lists of features that can be used and a classifier which decides which list gets used for what.

Now for the “in practice” part. There is no telemetry in Tor/Mullvad Browser, so nobody from the Tor Project can tell you how the distribution of the various levels is. I would assume that most people are on the default level, followed by the safest level. If the potential gains you get from having some features disabled outweighs the potentially smaller buckets you land in :person_shrugging:

I personally see no real reason the safer level exists, since if you actually have to worry about potential 0 day attacks, you should be using safest and not something in between.

6

The staff are paid by our (your) donations to spend their time answering to the community. Do not be afraid to demand the service you are owed.

7

Actually only 3 of us are paid, and I can’t speak to Jonah or Jordan but I know that the forum is not in my job description. That’s why I’m so rarely here.

9

No offense but it’s honestly a mental health thing for me. It’s too easy for me to get caught up in that “someone on the internet is wrong” mentality. It’s better for my mental health and productivity to focus on the actual work - research, writing, shooting video - and let others handle the community. It’s also why The New Oil doesn’t have a community and hasn’t for a long time.

12

Could you post this answer on the original question, so we can continue the discussion there? That way, anyone else wondering the same thing will have an easier time finding it.

13

I made a post referencing my reply above