phw

I've been building WhyNotLog to answer tricky questions using statistics. Example questions include "what gives my dog allergies?" or "what affects my sleep?".

Available at https://whynotlog.com and promo code HACKERNEWS gives access to the pro plan for six months.

An unrelated but practical example: I used to play a competitive ski racing game. You would race a course and upon finishing, your client sent the locally-determined finishing time back to the server, where it would end up on the global leader board. It was possible to modify the finishing time in-flight, and set it to whatever you wanted because the server had no way to know if a client was lying. To be fair, I did not succeed because the time was still "protected" by a hash whose input I could not be bothered to figure out.

  Location: Chicago, IL
  Remote: Yes
  Willing to relocate: Yes
  Technologies: Go, Python, JavaScript, React, PostgreSQL, Docker, k8s
  Résumé/CV: https://files.nymity.ch/resume.pdf
  Email: identityfunction@gmail.com

I'm a seasoned software engineer and research scientist solving problems in computer networking, privacy, and security.

In case it's helpful: I'm maintaining a tool kit that makes it possible to run unmodified, general-purpose code inside Nitro enclaves: https://github.com/brave/nitriding

Brave Software | Security/Privacy Researcher | Remote (in-office also possible)

Brave is on a mission to protect the human right to privacy online. We’ve built a free web browser that blocks creepy ads and trackers by default, a private search engine with a truly independent index, a browser-native crypto wallet, and a private ad network (opt-in!) that directly rewards you for your attention. And we’re just getting started. Already 50 million people have switched to Brave for a faster, more private web.

Brave is looking for an experienced security/privacy researcher to join Brave’s research team to develop new ambitious security and privacy research products and work alongside our engineering teams to implement the results of research into our products. This job involves working side-by-side with researchers, research engineers, engineers, and product managers across multiple departments so Brave’s research findings can benefit millions of daily active users around the world. The Researcher will be responsible for a wide range of privacy and security research areas, including privacy-preserving analytics, trusted computing, and detecting and fighting fraud. They should have a passion for helping protect users’ privacy and security.

https://brave.com/careers/?gh_jid=4761953

Feel free to reach out if you have questions. My email address is in my profile.

I've been working on a book for new Ph.D. students: https://research-power-tools.com

It's 95% done. Most of the (unedited) content is available for open review: https://nymity.ch/book/

Brave Software | Security Researcher | Full Time | Remote

Brave is on a mission to protect the human right to privacy online. We’ve built a free web browser that blocks creepy ads and trackers by default, a private search engine with a truly independent index, a browser-native cryptocurrency wallet, and a private ad network (opt-in!) that directly rewards you for your attention. And we’re just getting started. Already 50 million people have switched to Brave for a faster, more private web.

Brave is looking for a Security Researcher to join Brave’s research team to help with both developing new ambitious research ideas and in transferring advanced research prototypes into Brave products. This job involves working collaboratively with both researchers and developers to design, develop, and implement new systems for preserving user security and privacy. Learn more about the Brave Research team here.

For more information: https://brave.com/careers/?gh_jid=4091909

Consider adding Tor onion services to that list. The idea is that you run a Tor daemon that starts an onion service which can expose any TCP-based service. Communication is facilitated via another node, which makes it possible to host onion services behind NAT.

I've written a few paragraphs on the topic. Maybe it's helpful: https://nymity.ch/book/#make-your-code-public

UAP sightings are rarely taken seriously, which is no surprise considering that 99% don't hold up against any kind of scrutiny. There are however a number of credible sightings, the 2004 USS Nimitz incident being the most well known. Unfortunately, studying UAPs in an academic context is still mostly career suicide, so exploratory and speculative work like uaptheory.com can only be found at the fringes. As physicist Avi Loeb said before: if we don't look, we will never find anything. If only we could take the topic more seriously, we may eventually find that the Fermi Paradox is not a paradox after all.

There's research on the same idea but with a (presumably) sounder method behind it: https://sandlab.cs.uchicago.edu/fawkes/

> IEEE seems to have no problem with this paper though.

IEEE is just the publishing organisation and doesn't review research. That's handled by the program committee that each IEEE conference has. These committees consist of several dozen researchers from various institutions that review each paper submission. A typical paper is reviewed by 2-5 people and the idea is that these reviewers can catch ethical problems. As you may expect, there's wide variance in how well this works.

While problematic research still slips through the cracks, the field as a whole is getting more sensitive to ethical issues. Part of the problem is that we don't yet have well-defined processes and expectations for how to deal with these issues. People often expect IRBs to make a judgement call on ethics but many (if not most) IRBs don't have computer scientists that are able to understand the nuances of a given research projects and are therefore ill-equipped to reason about the implications.

You generally start as an assistant professor, which means you are on the tenure track but you don't yet have tenure. After several years, if you did well, you get promoted to associate professor, meaning that you got tenure. Finally, after some more years, you turn into a full professor, at which point you will likely earn the most.

All three types are generally referred to as "professor" but they differ in their seniority.

We used an online survey to study this, and some other questions: https://nymity.ch/onion-services/

Figure 10 shows that most users (52%) use bookmarks, followed by locally-saved text files (37%), and referral to trusted web pages (35%).

Also, lots of people find themselves unable to determine an onion service's legitimacy (Figure 12), which is why phishing attacks are successful. We document one such attack in Section 5.1 of another research paper: https://nymity.ch/sybilhunting/pdf/sybilhunting-sec16.pdf

This idea has since been applied to several other domains. Last year we had a look at all archived RSA keys of Tor relays: https://nymity.ch/anomalous-tor-keys/

We found that several thousand relays that shared prime factors (most part of a research project), ten relays shared moduli, and 122 relays used a non-standard RSA exponent, presumably in an attempt to manipulate the Tor network's distributed hash table, which powers onion services.

Ideally, a geolocation system should also work in an adversarial setting, when somebody is trying to spoof their geolocation. We recently learned that some VPN providers do that, to appear to have proxies in more countries: https://research.owlfolio.org/pubs/2018-catch-proxies-lie.pd...

Obviously, people can lie in their reverse DNS record but active measurements from distributed vantage points (e.g., by using the RIPE Atlas network) could expose that.

If the SYN queue is more than half full, the kernel (used to?) adapts the number of SYN/ACK retransmissions to mitigate the load. Interestingly, this opens a side channel that can be determined remotely, and used to measure packet filtering world-wide. See Section 2.1 in: https://censorbib.nymity.ch/pdf/Ensafi2015a.pdf

I'm one of the authors. You are right, these are the only onion services that were most likely targeted. The others are part of our publicly available dataset, but most likely false positives.

Here's a summary that's a bit easier to digest: https://blog.torproject.org/blog/learning-more-about-gfws-ac...

Citation needed. I have been hosting various IEEE papers on my websites for years and have never heard from IEEE.

My understanding is that CS publishers tolerate researchers hosting their own papers, but I'm very interested in evidence suggesting otherwise.

The bots in the "botnet problem" were connecting to a hidden service that was hosted in the Tor network. That isn't quite the same thing as bots that connect to hosts outside of Tor. Therefore, this isn't an issue for CloudFlare, and a bad example.

Raspberry Pis don't make very good relays. They don't have enough CPU power to relay non-trivial amounts of data, and slow relays that clog easily aren't useful to the network.

The Library Freedom Project is working on deploying exit nodes in libraries: https://libraryfreedomproject.org/

There are 2^80 possible onion domains and only ~10,000 are currently used. Simply brute-forcing the entire namespace isn't effective, especially because the verification step is a web service that has to try and fetch an onion service descriptor to see if it's online.

Also, onion domains are Base32-encoded, which means that they aren't case sensitive and they don't use the digits 0, 1, 8, and 9.

We have a discussion on this in Section 5.6 of our paper: https://nymity.ch/active-probing/imc2015.pdf

By "hijacking" we mean that an entity in the network is "borrowing" IP addresses meant for Internet users for ~20 minutes of probing activity. That's not the same as IP spoofing, i.e., simply sending IP packets with a spoofed source address.

That's entirely possible and wouldn't be the first time that an exit relay's upstream or data center is responsible for MitM attacks.

That's a good point. It's not possible right now (unless you wrap it into a shell script) but we want to add some sort of "continuous scanning" option over the coming days/weeks.

Manually blocking known bad exits won't really hurt your anonymity but it's also not really necessary as the Tor Project does that for you.

I was actually objecting to stuff like this: ExitNodes {us}. By interfering with your path selection algorithm in such a strong way, you make it easier for attackers to narrow down your path over time (which gives them an idea of which exit relays to monitor) and intersection attacks also become easier. Then again, you might have good reasons to do exactly that. It depends on your threat model, of course.

That's not necessary. Most of the relays in the report were already BadExited by the Tor Project. That means that the network consensus has the "BadExit" flag set which tells Tor clients not to select a particular relay as the last hop in its circuit. In fact, by interfering with your path selection algorithm, you reduce your anonymity over time.

First of all, it's not that big of a problem. While our list looks long and scary, there are around 1,000 exit relays, so the chance of selecting a bad one in your circuit is not high. Furthermore, Tor's path selection algorithm is weighted by a relay's bandwidth for load balancing (one of the many performance/anonymity trade-offs). Many of the fastest relays of the network are run by well-respected people and organisations such as the CCC. Also, the Tor Project "removes" malicious relays from the network (see Section 1.1 in the paper).

Finally, we published our scanner for a good reason: to crowd-source the hunt for more malicious relays :)