I'm sure as tildes gets bigger, security will continue to be a matter of discussion.

The dev GodEmperors of tildes have (quite awesomely) taken a big position on security already by disallowing breached passwords from being used.

I'm not much of a hacker myself, but it's an armchair interest and I'm sure others more skilled would love to be able to give back to Tildes and help keep the site as secure as possible.

What's the policy on bug hunting, and searching for exploits?

Thanks!

I'm going to college soon, and I'm in the process of straightening out my accounts and login information. What password managers would any of you recommend? I'm looking for something that can be accessed on both desktop (PC) and mobile (Android).

Edit: I have set up KeePass and it looks like a great solution! Thanks for the help.

A lot of the newer websites and services now offer 2FA so I was wondering if Tildes has any plans to do that? No idea how hard it would be to implement but I feel like that would be a welcome addition for many people.

I'd also be happy to hear people's thoughts on this an if you guys think the website actually needs this. In my mind more security is always better than less security.

While reading up on what it takes to run this site, it just occurred to me that the site is hosted on one server with one network connection. Adding a CDN or cloud based DDOS protection would run contrary to the "no third party" thing we've got going on here, so that doesn't seem like an option.

So I got to wondering, what would happen if a malicious actor were to sic a botnet on us? I imagine the outcome would not be good. Do we have any strategies to deal with this?

Got this phishing SMSmessage today. I spun up a VM and investigated the domain provided in the message. Found the provider and reported it to them.

The phishing page is a replica Coinbase login page.

https://imgur.com/a/ZSzNKO7

Firefox recently introduced DNS over HTTPS (DoH) and Trusted Recursive Resolver (TRR) in nightly builds for Firefox 62.

DoH and TRR are intended to help mitigate these potential privacy and security concerns:

1. Untrustworthy DNS resolvers tracking your requests, or tampering with responses from DNS servers.
2. On-path routers tracking or tampering in the same way.
3. DNS servers tracking your DNS requests.

DNS over HTTPs (DoH) encrypts DNS requests and responses, protecting against on-path eavesdropping, tracking, and response tampering.

Trusted Recursive Resolver (TRR) allows Firefox to use a DNS resolver that's different from your machines network settings. You can use any recursive resolver that is compatible with DoH, but it should be a trusted resolver (one that won't sell users’ data or trick users with spoofed DNS). Mozilla is partnering with Cloudflare (but not using the 1.1.1.1 address) as the initial default TRR, however it's possible to use another 3rd party TRR or run your own.

Cloudflare is providing a recursive resolution service with a pro-user privacy policy. They have committed to throwing away all personally identifiable data after 24 hours, and to never pass that data along to third-parties. And there will be regular audits to ensure that data is being cleared as expected.

Additionally, Cloudflare will be doing QNAME minimization where the DNS resolver no longer sends the full original QNAME (foo.bar.baz.example.com) to the upstream name server. Instead it will only include the label for the zone it's trying to resolve.

For example, let's assume the DNS resolver is trying to find foo.bar.baz.example.com, and already knows that ns1.nic.example.com is authoritative for .example.com, but does not know a more specific authoritative name server.

1. It will send the query for just baz.example.com to ns1.nic.example.com which returns the authoritative name server for baz.example.com.
2. The resolver then sends a query for bar.baz.example.com to the nameserver for baz.example.com, and gets a response with the authoritative nameserver for bar.baz.example.com
3. Finally the resolver sends the query for foo.bar.baz.example.com to bar.baz.example.com's nameserver.
   In doing this the full queried name (foo.bar.baz.example.com) is not exposed to intermediate name servers (bar.baz.example.com, baz.example.com, example.com, or even the .com root nameservers)

Collectively DNS over HTTPs (DoH), Trusted Recursive Resolver (TRR), and QNAME Minimization are a step in the right direction, this does not fix DNS related data leaks entirely:

After you do the DNS lookup to find the IP address, you still need to connect to the web server at that address. To do this, you send an initial request. This request includes a server name indication, which says which site on the server you want to connect to. And this request is unencrypted.
That means that your ISP can still figure out which sites you’re visiting, because it’s right there in the server name indication. Plus, the routers that pass that initial request from your browser to the web server can see that info too.

So How do I enable it?
DoH and TRR can be enabled in Firefox 62 or newer by going to about:config:

• Set network.trr.mode to 2
  • Here's the possible network.trr.mode settings:
    • 0 - Off (default): Use standard native resolving only (don't use TRR at all)
    • 1 - Race: Native vs. TRR. Do them both in parallel and go with the one that returns a result first.
    • 2 - First: Use TRR first, and only if the name resolve fails use the native resolver as a fallback.
    • 3 - Only: Only use TRR. Never use the native (after the initial setup).
    • 4 - Shadow: Runs the TRR resolves in parallel with the native for timing and measurements but uses only the native resolver results.
    • 5 - Off by choice: This is the same as 0 but marks it as done by choice and not done by default.
• Set network.trr.uri to your DoH Server:
  • Cloudflare’s is https://mozilla.cloudflare-dns.com/dns-query
    (but you can use any DoH compliant endpoint)
• The DNS Tab on about:networking will show which names were resolved using TRR via DoH.

Links:
A cartoon intro to DNS over HTTPS
Improving DNS Privacy in Firefox
DNS Query Name Minimization to Improve Privacy
TRR Preferences

I'm not affiliated with Mozilla or Firefox, I just thought ~ would find this interesting.

I use Lastpass at work but don't have experience with any others. Last time I looked into it Lastpass and Keepass were the only two viable options if I recall (though my memory isn't the most reliable thing). A few quick searches seem to indicate that the market has opened up a bit since then. I'd like to use something open source with Linux, Windows, and Android clients. So, what's your preferred password manager and why?

Hey guys -- I wrote a blog that I'd love some feedback on. I'm an identity product manager and have been trying to train my users to use passphrases. Do these read friendly enough? I want it to be readable by all users, but my target audience is other people in product and software.

https://medium.com/@toritxtornado/training-your-users-to-use-passphrases-2a42fd69e141

This is of course already possible with base 64 encoding and some work on the user's side, but adding the ability to encrypt messages as a native feature would better encourage this as a security measure. This is a standard feature on a lot of darknet markets. Tildes could allow users to upload a public GPG key. Then a private key could be held entirely client-side in session storage to be used by JavaScript.

This feature would probably add too much complexity to the site's simplistic front end. But I'd be interested to have a discussion on the pros/cons.

I don't need to reset my password, and I really appreciate the way that it is done to maximize anonymity. However, I think there is a bit of a problem with how it is done in terms of users getting locked out.

If you're locked out, as far as I can tell, there is no way to view the email hint associated with your account. It seems a bit counter intuitive to me that in order to see the hint for how to regain access to your account, you have to already have that access! I also think that it won't work in the case that someone has been away for a few months and has forgotten their password. I'm not sure what a good way of displaying the hint would be, however, since if it is done by username anyone who has seen your posts can look at your password hint.

Hopefully with a bit of discussion we can cook something up that can solve this catch 22!

Hi! Something I've been wondering, is Tilde planned to eventually have a bug bounty program or something like that for security flaws in the future?

Edit: RIP, forgot to separate those tags with commas...

As can be seen in this post in ~test it is possible to secretly refer to another webpage than the one actually typed. It's not the biggest priority as of now, but it would be nice to see this fixed before Tildes will go live.

In case the ~test post gets deleted, here's an example:
https://innocent.site/

Hey, Just a thought. I'm not sure what the legal standing of warrant canaries (i.e. being compelled to lie) are in Canada, but given the privacy level afforded by the site the key component to that privacy is trust.

You're doing a lot to make sure private data is treated as harmful, and with the open source code being visible, but that's still not a guarantee that the server is actually running the code that will be open sourced.

Tildes could probably benefit from a warrant canary given that it's a platform for user generated content and if it gets prominent enough it may be subject to LEO scrutiny. Compliance with LEO is a given since the website operates under Canadian Jurisdiction, but given the... nature of some requests (Gag Orders / Etc...) a canary could be a privacy positive move for users of Tildes.