mrled

Well, mostly I was thinking about code, and aside from the specific exceptions of trading algorithms (which I was trying to get at when I said hedge fund strategies), and now PhD theses (good point, at least if you're talking pre-publication), I'm still having trouble understanding the threat model even if AI did train on most proprietary, private business code. Can AI training on a CRUD app's code damage a business?

And I have the same question about private notes, or even a diary. Can an AI training on a bunch of personal stuff damage the person that wrote it?

Do you really keep trading algorithms on github?

I'm curious about specific consequences of this. I tend to think the importance of code secrecy has always been exaggerated (there are specific exceptions like hedge fund strategies and malware), even more so now in this post-Claude world. Does anyone have specific things they're trying to avoid by opting out of this?

They've got a new web viewer in this issue that can be used to link to individual articles and might be nicer than reading a PDF on some screens: https://pagedout.institute/webview.php?issue=8&page=1

The recountings of the generosity of strangers reminded me of this post: https://kk.org/thetechnium/how-will-the-miracle-happen-today...

Maybe there is some generosity in western countries that is obscured by western norms.

Archive link: https://archive.is/2024.08.01-162440/https://www.latimes.com...

I am kind of syntax agnostic and would be happy to use more complicated syntax in exchange for more power. (I have a lot of HTML inside my Markdown files, too.) However, my use of rST has been in Sphinx, and I want to love it because it's quite powerful, but it's so slow. Am I missing some configuration or third party package to fix this? I wrote about 15k words of English text in rST in Sphinx to document a project[^1], and Sphinx's build speed was many times more an impediment than my unfamiliarity with rST.

[1]: https://pages.micahrl.com/progfiguration/

The notes on browser privacy imo are too significant to have been relegated to a footnote:

As part of the drafting of the 2015 finding on Unsanctioned Web Tracking, the then-TAG (myself included) spent a great deal of time working through the details of potential fingerprinting vectors. What we came to realise was that only the Tor Browser had done the work to credibly analyise fingerprinting vectors and produce a coherent threat model. To the best of my knowledge, that remains true today.

Other vendors continue to publish gussied-up marketing documents and stroppy blog posts that purport to cover the same ground, but consistently fail to do so. It's truly objectionable that those same vendors also prevent users from chosing disciplined privacy-focused browsers.

To understand the difference, we can do a small thought experiment, enumerating what would be necessary to sand off currently-identifiable attributes of individual users. Because only 31 or 32 bits are needed to uniquely identify anybody (often less), we want a high safety factor. This means bundling users into very large crowds by removing distinct observable properties. To sand off variations between users, a truly private browser might:

- Run the entire browser in a VM in order to:

  - Cap the number of CPU cores, frequency, and centralise on a single instruction set (e.g., emulating ARM when running on x86). Will likely result in a 2-5x slowdown.

  - Ensure (high) fixed latency for all disk access.

  - Set a uniform (low) cap on total memory.

- Disable hardware acceleration for all graphics and media.

- Disable JIT. Will slow JavaScript by 3-10x.

- Only allow a fixed set of fonts, screen sizes, pixel densities, gamuts, and refresh rates; no more resizing browsers with a mouse. The web will pixelated and drab and animations will feel choppy.

- Remove most accessibility settings.

- Remove the ability to install extensions.

- Eliminate direct typing and touch-based interactions, as those can leak timing information that's unique.

- Run all traffic through Tor or a similarly high-latency VPN egress nodes.

- Disable all reidentifying APIs (no more web-based video conferencing!)

Only the Tor project is shipping a browser anything like this today, and it's how you can tell that most of what passes for "privacy" features in other browsers are anti-annoyance and anti-creep-factor interventions; they matter, but won't end the digital panopticon.

I can't replicate on mine. If this is due to nested styles, I think you are behind on your software updates :). But also, maybe I need to hold off a bit longer before moving to nested styles.

Ohhh interesting. To anyone hitting this, I'm curious what specific browser you're using - I thought it was available ~everywhere now? https://caniuse.com/css-nesting

Oh man, you're right, I didn't realize they worked this way. This basically means there is no compromise at all, I'm going to update the post. Thanks!

Ohh, interesting, I have never heard of SMIL. For this post I was thinking mostly of static styling (... and got a little carried way with interactive stuff in the diagram...) but I'll have to look into SMIL in the future.

This is a great point. I'm going to test some of the `<use>` suggestions I got in this thread, but if those don't pan out I'll definitely do this.

Huh. I'm the OP, and I do have a dark mode that respects `prefers-color-scheme: dark` -- or at least, it works for me (tm). Would you mind sharing details about your dark mode theme? Is it a third party extension or maybe a browser I haven't tested?

I agree that it's not an unqualified win. If sites block passkey apps that allow exporting unencrypted passkeys, that probably will prevent some accidental passkey leaks.

It's just that it's not an unqualified win to allow sites to block passkey apps either. If we allow that, we can get to a place where sites block apps for the wrong reason, or it becomes more expensive to develop passkey apps so there is less competition for secure passkey apps.

It's not just whether it's a good idea to allow unencrypted exports. It's whether it's a good idea to give websites a say in how we manage credentials.

I think this is more like a webserver sniffing the user agent and choosing not to serve the request, not like sending a webserver bad data such that it isn't able to serve the request. I'm concerned that passkeys end up in a "This site is best viewed in Internet Explorer" mindset, where passkey providers that would work fine are detected and prohibited because the website operators want them to enforce user behavior.