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?
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?
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.
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
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.
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.
Oh man this is really cool. I have also written a Python infrastructure-as-code project (https://pages.micahrl.com/progfiguration/), I really like the idea of using a programming language rather than a text document to define infrastructure. Yours looks very polished, and the built in support for testing in Docker is a brilliant idea.
Right, that's expanding to the rest of the subnet in their old DC. They've since migrated to the new DC with new countermeasures. Did the DDOS follow and the countermeasures are working? Or if it didn't follow, why not?
There's also the question of whether the DDOS is still even trying the old infrastructure. The post says it's unreachable, but that would be true if the null route hadn't been removed yet.
I am really curious if the DDOS tried to follow them to the new infra and failed to cause an outage or not. Apparently the perpetrator noticed when they got Cogent to narrow the null route, but the blog post notes they still can't access the original subnet in that datacenter. Are they still trying to knock Sourcehut offline? Is the DDOS still pointing at now deprecated infra for some reason?
After googling, I don't think I've seen Japanese knot-wood before. I have woody stalks and long thin leaves. My layman's understanding is that what's in my yard is running bamboo.
My optometrist told me that any pair of glasses can be made to adjust the focal point, and that if I regularly wear my prescription glasses instead of contacts, I should also buy a pair of prescription glasses with adjusted focal point for computer work. (I opted not to do that since I am almost always in contacts and because of the cost.)
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?