blintz

Honestly, I think even the old Caltrain cars were pretty clean. The only dirty parts were the bathrooms (and honestly, train bathrooms are sort of gross most places). Caltrain has always been sort of luxury, though; the median Caltrain rider has a >100k household income, which come to think of it, might be one of the highest median rider incomes for a public transit system in the world.

I think BART struggles with who it's meant to serve now, since it was clearly designed for ultra-peak weekday commute traffic. Recovery for weekend ridership is way better than weekday.

I also agree that the governance structure for BART is weird and overly complex. Why do I elect a BART director? Why are they in their own special BART districts completely discontinuous from the 10 other ways we have sliced up the Bay Area?

All that being said, BART has done some good stuff too. The new cars really are way better, and they were not easy to procure since BART has its own weird, non-standard rail gauge. They have increased frequency and shortened trains on weekends to respond to the ridership changes.

Most of all, BART remains the only form of Bay Area transit genuinely faster than driving in real-world circumstances: it averages above 60mph in parts of the east bay, and goes from downtown Oakland to downtown SF in 11min, which is often 2-3x faster than driving. It's the primary transit system that can compete head-to-head with driving. For that reason, I do hope they keep increasing frequency (shortening trains if necessary).

Totally agree, though SF is closer to overall NYC density than you'd expect (NYC 29k, SF 18k ppl/sq mi; Manhattan is 73k).

I think the Bay Area suburbs are also egregious - e.g. North Berkeley BART station is surrounded by single family homes, even though it's 25min from downtown SF by train.

The electric Caltrain is so wonderful. It’s way quieter, the cars have nicer interiors, and it is running faster and more frequently than before.

Between this, the new BART cars (also much quieter!), and Muni hitting a reliability & satisfaction records, there’s really a transit renaissance going on in the Bay Area. I really hope we can keep this going!

These watermarks are not robust to paraphrasing attacks: AUC ROC falls from 0.95 to 0.55 (barely better than guessing) for a 100 token passage.

The existing impossibility results imply that these attacks are essentially unavoidable (https://arxiv.org/abs/2311.04378) and not very costly, so this line of inquiry into LLM watermarking seems like a dead end.

I feel like the killer feature is playing all the old games. Sitting on the couch and feeling like you know the answers is so different than having to actually buzz in and say them on the spot!

This is such a neat idea, and you get the gist of it from just the screenshot. I wonder what kinds of 'integration' you could do (clipboard, opening links, drag-and-drop, etc). I could see this as an educational tool for doing development on a Chromebook, because of the (emulated) terminal + filesystem.

This measure has over $1 million is spending in favor of it, the most of any measure on the March ballot; several of the folks spending in favor of it are people in our industry (the CEO of Ripple has given $250k alone). Apparently, supporters have outspent opponents almost 10 to 1 (https://sfstandard.com/2024/01/22/london-breed-prop-e-san-fr...).

I hope the statements from the EFF and ACLU, which have both highlighted the negative privacy implications of the measure, help convince folks to vote no.

This is preventing new logins to ChatGPT.

This seems really useful for stuff like AMD SEV-SNP, where we want a measurement of the (kernel + initrd + arguments) to guarantee certain behavior from the machine. Ideally, we could use this as the container hypervisor, and have it produce attestations that bind to the hashes of the running containers. This relies on not having container escapes; not sure what the state of the art on that is right now.

It's exciting that cryptographic constructions (like m/n secret sharing where m is hidden) can solve problems in complexity; I would have expected things to flow mostly the other way.

Generally on board with the author, but this didn’t ring as true:

> Oyster payment cards are virtually impossible to use anonymously

You can just buy them with cash from the machines, right? Isn’t it a rare example of a public service in the UK that does not involve a bunch of surveillance?

The Stanford cryptography class (http://crypto.stanford.edu/~dabo/cs255/) and associated book (https://crypto.stanford.edu/~dabo/cryptobook/BonehShoup_0_4....) is almost everything you'd ever want to know about cryptography. If you really like that and want to see the frontiers of cryptography research, the next (and last!) class is https://crypto.stanford.edu/cs355/23sp/; alternatively, there's a security class (https://cs155.stanford.edu/) more focused on industry and application.

Pro tip: nearly every instance of both these classes is available online (all the way back to 1998!), so if something's not making sense, you can always go back and see if it was explained differently in a prior iteration of the class.

Concrete is really impressive and permissively licensed. The ML library has a FHE version of (a subset of) scikit-learn, which I honestly thought I’d see in another 5+ years. Like look at this example:

    # Now we train in the clear and quantize the weights
    model = LogisticRegression(n_bits=8)
    model.fit(X_train, y_train)

    # We can simulate the predictions in the clear
    y_pred_clear = model.predict(X_test)

    # We then compile on a representative set 
    model.compile(X_train)

    # Finally we run the inference on encrypted inputs !
    y_pred_fhe = model.predict(X_test, fhe="execute")

    print("In clear  :", y_pred_clear)
    print("In FHE    :", y_pred_fhe)
    print(f"Similarity: {int((y_pred_fhe == y_pred_clear).mean()*100)}%")

There’s some ways to go on performance, but the ergonomics of using FHE are already pretty good!

I'm not an expert, but I see the main threat to continued improvement as running out of high-quality data. LLM's are a cool thing you can produce only because there is a bunch of freely available high-quality text representing (essentially) the sum of human knowledge. What if GPT-4 (or 5, or 6) is the product of that, and then further improvements are difficult? This seems like the most likely way for improvement to slow or halt; the article cites synthetic data as a fix, but I'm suspicious that that could really work.

I’m gay, so it just hits more personally.

The idea that nobody is entitled to privacy until they turn 18 is crazy. I shudder for all the LGBT kids whose parents all now have a (state enforced!) right to snoop on them.

(Honestly headline should be: “Utah bill gives parents full access to their children's online accounts, including posts and private messages”)

This is really cool. Federated learning seems like it could unlock a lot of value in healthcare settings.

Have you had any luck convincing hospitals / insurers / etc that this satisfies HIPAA and is safe? How do you convince them?

  => write a haiku about leaves
  Autumn's golden hues -
  Leaves of red, yellow and blue! \
  #haikupoetry #leavesshort[1] > segmentation fault  ./chat

Interesting.

What if instead of trying to evaluate these models privately, which tends to have a lot of overhead, we instead try to mix lots of user queries and send them in batches?

We could use enclaves to do the mixing, and while there’s be added latency, we could achieve model outputs that are (by definition) at the current state of the art for LLMs. We would not hide the contents of queries, but we’d at least hide who is making which queries.

Sure, we'd love to talk! Hardware acceleration is really cool. Send us an email: founders @ blyss.dev.

The main thing we'd like the security review to focus on is our Rust client code. We'd also really like to select for a reviewing team that has a deep level of familiarity with cryptography. We would provide the team with a summary of the sensitive operations involved in lattice-based key generation, so that lattice experience would not need to be a hard prerequisite to understanding the code.

This seems like it would be a cool browser standard. The browser could check that the specified SRI hash matches one published by some other entity, and then include extra information in the ‘lock’ icon or dialog, that goes further than TLS.

Usually, when I have an idea for a standard, it turns out one exists, so maybe I’ll do some digging…

Yeah, we don’t natively support range queries.

The simple way to efficiently do this kind of check would be to store an index of keys (perhaps chunk them into buckets, like 0-10, 10-20, etc), and then privately retrieve the individual items. Retrievals are fast, especially when batched, so if the ultimate number of items you’re trying to retrieve is not too large, this can work.

If you want to chat more about range queries, feel free to email us (founders @ blyss.dev)

The space overhead is roughly constant (or at most logarithmic in n), and varies by the scheme. In practice, it’s something like 1.5-8x overhead. This is no big deal for storage, but does make it a pain on the memory side for processing (since the full database, including the overhead factor, needs to be resident in memory).

True! We are using FHE to perform PIR. The underlying scheme we use is a real homomorphic encryption scheme (Regev + GSW), but yeah, we explicitly do not support performing arbitrary computation on encrypted data. As it turns out, that's still quite slow - the Google FHE C++ transpiler still takes seconds to do 32-bit arithmetic operations. Our PIR system is able to achieve much more practical speed + communication overheads.

Yes, it's generated in the browser for each query.

And this depends on the application - for example, for the private password checker, all the dumped passwords data is from a public dataset, so its not encrypted. In messaging, the data would be encrypted under the intended recipient's public key.

Yeah, this is definitely a risk of any in-browser demo of this tech. The story for apps is much better, since there's a routine installation process, signatures are checked, etc. We'd like private retrievals to eventually be part of the browser itself, so that it can make a kind of "private GET" request natively.

We'd also love to bind our client JS code to a hash of our build output from GitHub, but as of now there's no simple way to do this that the browser will pin automatically - integrity checks are good, but don't prevent the server from just changing the hash. We've toyed with writing an extension for this, but haven't gotten around to it.

Things tend to get pretty slow when you try to compute SNARKs over FHE computations. Some progress is getting made, but it's still pretty academic.

There is a cool company trying to instead use FHE to accelerate SNARKs: https://github.com/Sunscreen-tech/Sunscreen. They seem to be making some headway!

Some data, like passwords or other credentials, isn't stuff anyone really wants to monetize - so secrets managers (things like HashiCorp Vault) and password managers are both interested in using this to allow them to collect even less data.

In other cases, for the same compliance and data security reasons behind the desire for on-prem, larger enterprises prefer that their SaaS vendors collect as little data about them as possible. Blyss can get you the best of both worlds: the data security of on-prem, with the convenience and ease-of-deployment of SaaS.