cyphar
I still think the original point I was replying to ("don't stand out") doesn't apply to systems with "soft" anonymity like Signal. Even more importantly, arguing that specific features like custom servers or non-Firebase notifications are problematic because they "stand out" is particularly silly -- those features are the exact kind that are already fingerprintable by virtue of Signal's inbox design. Even if the social graph is somewhat anonymised, Signal does not attempt to hide that you are using Signal. (You could argue custom servers leak some data about your social graph but I'm not sure it is much worse than the theoretical leaks we spoke about earlier. And it's kinda notable that when Moxie argued against federated servers as a concept, that wasn't among the arguments he made.)
My point is that by construction they are not an anonymity tool, no centralised server can be. They can add features to make it less easy to track users but that's not the same as providing anonymity, and it's important to not confuse the two.
To give an example: my email provider has a feature to auto-encrypt all inbound emails to a PGP public key. Is this a nice feature to make it harder for someone to read my past emails if someone gets access to their infrastructure? Sure. Does this make my emails end-to-end encrypted? Absolutely not. In a similar vein, Signal making social graph correlation harder is a welcome feature but is not the same as making it anonymous.
They intentionally store very little data about their users but their "mailbox" model explicitly means that the server (or an attacker) can figure out who is talking to whom. And that's fine! Signal isn't trying to be an anonymity network, so while stuff like sealed sender are nice features it's important to remember that anonymity breaks are explicitly not part of the Signal threat model.
"Don't stand out" only makes sense as advice for anonymity tools to avoid bifurcating the anonymity set -- it doesn't make much sense when you're taking about a service which links your account to your phone number and thus every server request is explicitly identifying you.
> The Times 03/Jan/2009 Chancellor on brink of second bailout for banks
I would've thought the implication was kind of obvious? And I'm not sure why you mention Dodd-Frank -- there were many bailouts throughout 2007-2010 and the point of Dodd-Frank was to put an end to that scheme.
It's also not at all a given that website owners would prefer the national CAs -- as an obvious example, most Rust projects (foo.rs) would probably not trust the Serbian CAs as much as they would LetsEncrypt. Even for website owners that live in the country, it seems possible that Chinese website owners might prefer to use non-Chinese CAs. And again, if the solution is to just special-case one American legal entity then we have just moved back to the original VeriSign-signs-everything model.
The real issue is that the CA model has been obviously broken since at least the days of the Comodo hack -- the trust decision for who can certify the website identity is made by the website owner but really clients are the ones that actually care (it's their data at the end of the day) and they have no input. Moxie had a proposal in 2011 to fix this by letting clients decide the policies for how a certificate should be trusted[1] and I think it is a far more workable solution than the alternatives. If one of the LetsEncrypt intermediates was compromised none of the alternative proposals would have any real hope of providing a workable mitigation.
This incident was obviously comically bad but the Comodo hack had a more painful impact on the mitigation that should give everyone pause -- their CA had signed a quarter of the internet's certificates so the trust couldn't just be revoked. Imagine one of the LetsEncrypt intermediates got compromised -- our mitigation strategies really cannot cope with that kind of disaster scenario. Browsers would be in the unenviable position where they'd be forced to make huge portions of the internet go dark for potentially months.
This push for centralisation without the infrastructure to back it up has always been the most frustrating aspect of Docker Inc over the past >10 years I've worked on container runtimes.
> Shigeru Miyamoto: For every Zelda game we tell a new story, but we actually have an enormous document that explains how the game relates to the others, and bind them together. But to be honest, they are not that important to us. We care more about developing the game system… give the player new challenges for every chapter that is born.
So I don't think this is as clear cut as "a different group of people decades later make a timeline". The least charitable view might be that they never intended the unified timeline thing to became public and didn't consider it "lore", but I'm not sure I buy that either (since they talked about some details in other interviews, including the Victorious/Fallen Hero split most people object to).
[1]: https://www.nintendoforums.com/articles/40/super-play-magazi...
Maybe they did release the timeline because of fan pressure but some sort of timeline did exist for at least a decade before they released it which doesn't fit your theory they just came up with something and released it in secondary media because of fan pressure.
[1]: https://www.nintendoforums.com/articles/40/super-play-magazi...
I would be surprised if it did not have some impact on the writing of the games, though of course there is (as of yet) no explicit reference to the timeline in the games.
[1]: https://zelda.fandom.com/wiki/The_Legend_of_Zelda_timeline [2]: https://zelda.nintendo.com/about/
The irony. Perhaps the Bene Gesserit were just trying to "pace the frontier" of the eugenics market? Who can say?
If you know someone with N logins has N passwords it's a decent indication they use a password manager and so passwords are unlikely to be weak, if they have 1 password it's probably shared elsewhere and weak.
I also wasn't responding to a question asking about practical exploits, I was responding to a question that claimed the k-anonymity model is "provably anonymous" and "harmless". Since it clearly leaks some information it's definitely not the former and one could argue it's not the later though the "harm" is minimal.
> My browser fingerprint leaks, what, thousands of times more information than that - surely fixing applications like Chrome ...
I fail to see how the privacy nightmare of modern browsers is relevant to a discussion on whether opt-out signalling to third-party services is a reasonable stance for an open source project? By that metric no privacy bug is worth reporting because Chrome continues to exist. If only there was a term for this kind of non-sequitur...
I don't think these are /critical/ issues and the latter is basically just an argument against the HIBP service, but the point is that a user should opt-in to sharing their data in cases like this so they have a chance to make an informed decision. The k-anonymity design of the HIBP service has a degree of anonymity, it's not "provably anonymous" like homomorphic encryption or similar schemes would be.
1. Only a very small number of valid seeds were discarded when compared to the number of n values. It seems we don't yet know why about half of the valid seeds were discarded but the explanation of a buggy curve validity checker doesn't seem implausible to me.
2. Directly to your point, most of the prime192 and prime239 curves required larger n values to find a valid seed and they are both smaller and used an earlier timestamp.
Assuming that is actually the real reasoning trace (open weight model reasoning traces usually do things like switch languages or talk in non-standard English because of model drift, so it's a bit surprising that Claude wouldn't do the same) there was a study a few years ago that found base models produce better answers if you put "take a deep breath" in the prompt[1]. Maybe in the RL training stage stuff like that gets reinforced and because reasoning traces are hidden in RLHF it doesn't get selected out? My money is on it not being the real reasoning trace though.
So am I saying this is needless bloat and Micro$oft have lost their ways? Yes! Back in my day we had to do it by hand -- the sheer entitlement (pun intended) to expect a computer to do computations for you. The children yearn for practical uses of trigonometry!
Turns out that json.Encoder always appends a newline but (as GP said) json.Decoder will not attempt to read it if the JSON is complete at the power-of-two byte boundary (IIRC the buffer doubles for the first few iterations). The extra byte in the pipe when closed then causes reads and writes to go boom. We switched to using json.Marshal because it doesn't output a newline (sadly the encoded form isn't streamed as a result).
I still get twitchy around encoding/json as a result of that experience.
[1]: https://github.com/docker/docker/issues/14203#issuecomment-1...
The intended audience is obvious from first paragraph alone:
> At Anthropic, coding is no longer the bottleneck to building systems or doing research. Claude is able to autonomously iterate on research loops, micro-optimize complex programs, and build new services from the ground up at a speed and scale we haven’t seen before. The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI.
Translation:
> We are so far at the cutting edge we need to build shiny new infrastructure to replace the smelly "human scale" cruft. How could you /not/ value us at $2T?
There actually is another way, but it isn't really that handy (as it is basically just shorthand for multiple assignment):
func mustInt(v int, err error) int {
fmt.Printf("got: (%v, %v)\n", v, err)
return v
}
func foobar() (int, error) {
return -123, nil
}
func badbeef() (int, error) {
return nil, fmt.Errorf("moo")
}
func main() {
vals := []any{
mustFn(foobar()),
mustFn(badbeef()),
}
fmt.Printf("got vals: %v\n", vals)
}
func mustFn[T any](v T, err error) T {
fmt.Printf("got: (%v, %v)\n", v, err)
return v
}
func foobar() (int64, error) {
return -123, nil
}
func deadbeef() (string, error) {
return "weird name for a cafe", nil
}
func badbeef() (*int, error) {
return nil, fmt.Errorf("moo")
}
func main() {
vals := []any{
mustFn(foobar()),
mustFn(deadbeef()),
mustFn(badbeef()),
}
fmt.Printf("got vals: %v\n", vals)
}
When I last did astrophysics research half a decade ago (as an undergrad) the workflow for doing research boiled down to writing pipelines to clean the data and then have scripts to find interesting candidates and analyse them automatically. It was necessary to filter stuff to reduce false positives, so it's possible this candidate was just missed by such scripts.
It's also possible this star is in some PhD student's dataset and they just haven't published yet. Astrophysics papers in this vein usually focus on techniques for classification and data science so you'd expect to have at least dozens if not hundreds to thousands of interesting stellar objects before you have something worth publishing unless it was some truly novel technique. A paper just saying "we found an exoplanet" isn't particularly interesting these days, as it turns out there are a lot of them.
(I haven't looked at the data and I'm sure my skills have atrophied by now anyway, sadly.)
More power to the guy who did this (astrophysics is probably the most hobbyist-friendly science since a lot of the data is public and the only lab equipment you need is a laptop) but I suspect "ordinary" folks are far more impressed by this than astrophysics folks. A decade or two ago exoplanets were still thought to be very rare but we've since figured out they are quite common and have moved on to just cataloguing them.
But there is a bigger point to be made: in my experience most privacy activists argue that taking an absolutist stance personally is counter-productive -- just because it is almost impossible to completely eliminate risks from your life does not mean you should give up and not try to minimise them. And of course, the goal for most people isn't to protect against targeted attacks (since that means you already need to take fugitive-on-the-run-level precautions), it's to avoid becoming a target in the first place.
In case you were not aware, spooks have focused on metadata analysis over "full take" (data) analysis for a very long time because they are far more effective and require less data to analyse. This has been the case at least since the early 2000s with Stellar Wind but arguably even the Stasi worked this way -- they cared a lot more about who you were talking to than what you were talking about. The Snowden revelations in 2013 talked almost entirely about metadata-only systems that were being used to invasively surveil the world.
If your point was more "I have nothing to hide" then you can find plenty of articles online to disabuse you of that notion. There's even a Wikipedia article about it[2].
[1]: https://abcnews.com/blogs/headlines/2014/05/ex-nsa-chief-we-... [2]: https://en.wikipedia.org/wiki/Nothing_to_hide_argument
Even better, the OCI distribution protocol (which was Docker distribution until a few years ago) is not a static-blob-over-HTTP protocol! The blob bits are and you can route them to blob storage but you need a smart server for a few key bits of the protocol.
Back in the day I made proposals for distribution formats that didn't have these flaws and were more distributed (and previous proposals like AppC's discovery had similar ideas) but they were roundly rejected by the Docker people.
Nix does have a similar model in some respects (in particular the idea of input-hashed build graphs) and so solves a lot of similar problems but there were a few important factors that made us not go with Nix (or NixOS) and instead go with Buck2.
As the blog post mentions, the ability to build directly from a wide variety of upstream distribution artefacts and maintain temporary deltas was incredibly important to us. Our team has a lot of old-school packaging experience (I've done packaging for (open)SUSE for over a decade now and we have former and current Fedora, RHEL, Ubuntu, and Debian packaging folks with even longer histories) and our view is that distributions do a lot of thankless and incredibly valuable work and the most painful part of maintaining a distribution is the deltas you have to maintain forever after you've hard-forked packages or repackaged them. Buck2 allows us to create models for these concepts (which are in tine) without needing to boil the ocean repackaging upstream packages. But Daan and Martin are far better equipped to get into the weeds on this topic.
On the more general topic of why not use NixOS, as discussed in one of our other recent blog posts[1] we are make heavy use of sysexts and the /nix/store combined with the general linking model of NixOS (while very technically impressive) does not play particularly well with that model. I should also mention that we have a NixOS guy on our team too so you'd better believe NixOS came up in conversation. :D
[1]: https://amutable.com/blog/it-starts-upstream-kernel#image-ba...
The same can be said of C or C++ constructs (and many "anti-Rust" people have historically said that) -- the point is that their use is not enforced by the language and so bugs can lead to panics.
I write a fair amount of Go and Rust so I really don't think either language's flaws are fatal, but it comes off as weirdly defensive to redefine memory and data safety to be "well if you use it properly it's safe". It's totally fine to say this is a problem the Go language did not find important enough to require compile time enforcement and so solving it is done by convention and testing with the race detector (which a similar answer C and C++ give to this problem).
Sadly, almost all language standard libraries do not provide the right abstractions for dealing with files (the primary focus is on global paths as opposed to scoped paths or file descriptors / file handles) so it's little surprise bugs like these just keep popping up every few weeks.
To eliminate these from your codebase you need to rethink and really focus on being aware of how you deal with files. If the program you're writing has root privileges then you need to be more careful about misdirected writes to /proc or other pseudofilesystems.
Truly the worst of all worlds.