stebalien

I control my domain name and its DNS but I don't have the keys used to sign my DID. I followed the instructions here: https://bsky.social/about/blog/4-28-2023-domain-handle-tutor...

From my reading of your blog post, it sounds like the DID is the ultimate authority and not my domain name, which sounds like a pretty big problem for user portability.

The recommendation to resolve from handles to DIDs for "permalinks" is concerning to me:

- My handle is something _I_ control. I can make it point at a different PDS at any time.

- My DID is something my PDS controls.

I could solve this by indirecting through a web DID under my control, but there's no recommendation anywhere in Bluesky's documentation. Is that something everyone needs to do to ensure real identity portability?

edit: I'm not sure this CAN be solved without running a PDS given that I can't use my own keys. What am I missing here?

Sure, but that means that either Google or the application author would be required to give me working keys with no restrictions, which would make the entire system rather pointless.

However, now that I think about it, the fact that "unauthorized" apps can still be installed via ADB exception may cover this?

Or one can just use semantic HTML; it's easy enough to convert semantic HTML into markdown with a tool like pandoc. That would also help screen readers, browser "reader modes", text-based web browsers, etc.

I still haven't seen anyone discuss the issues with distributing applications containing GPLv3 components under these new rules given the clause (from the GPLv3):

> “Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

At the moment, the workaround here is that keys can technically just be generated on the fly (with some caveats). With Google's new requirements, that's not possible.

See https://git-scm.com/docs/BreakingChanges#_git_3_0

You can also combine this with TRAMP to work on databases you can't directly access from your local machine. E.g.:

  #+header: :dir /ssh:user@remote-host:/
  #+begin_src sql
  ..
  #+end_src

The solution (heavily) alluded to by GrapheneOS in https://grapheneos.social/@GrapheneOS/115164212472627210 and https://grapheneos.social/@GrapheneOS/115165250870239451 is:

1. Release binary-only updates (opt-in). 2. Let the community (a) make GPL source requests for any GPLed components and (b) let the community reverse engineer the vulnerabilities from the binary updates. 3. Publish the source once everything is public anyways.

Which just shows how utterly ridiculous all this is.

The bigger headline is that Google is effectively giving attackers 3-4 months of advanced access to security patches: https://grapheneos.social/@GrapheneOS/115164183840111564.

Stellarium? https://en.wikipedia.org/wiki/Stellarium_(software)

"Decentralization" isn't the end-goal so measuring it here isn't all that meaningful. Personally, I care about:

1. How hard is it to censor the network.

2. How hard would it be for some major player to enshittify the network.

Furthermore, while the fediverse has a single axis for decentralization, BlueSky has 3: number of "big index servers", number of PDSs, number of domain names (how many people own their handle):

1. Increasing the number of PDSs doesn't make it harder to censor the network when everyone still uses the same big index node.

2. BlueSky's primary defense against enshittification is user account portability. I'd love to see metrics on how many users have their own domain names. Having many PDSs is also a good defense here because it reduces the impact of BlueSky (the company) shutting off the firehose, but I still think account portability is the primary defense here.

Yeah, I agree. Nothing will stop a determined and smart child from getting what they want. My goal is to describe a system that's as secure as ID verification without all the drawbacks.

I'm saying that devices must be sold with this parental control software, not that this software must be used/activated. Most devices already have support for restricted modes like "guest mode".

I completely agree. I'm not saying that all websites containing nudity must contain a "nudity" label as defined by some specific country, I'm saying:

1. Governments MAY define labels like "gov.texas.bill1234-compliant".

2. Websites MUST NOT apply this label to their content unless the content actually complies with Texas' bill1234.

Websites may ALSO proactively label their content with advisory labels like "advisory.may-contain-nudity", but those would have no legal meaning.

Counterfeit what? This is about labeling and filtering: the device doesn't present an ID, the device prevents the user from accessing content with/without specific labels if so configured.

Specifically, governments mandate that:

1. Websites/apps/etc. MAY label content (via headers) indicating when their content/service is/isn't appropriate for some specific audience (e.g., children) according to X/Y/Z regulations. Websites/apps/etc. MUST NOT incorrectly label their content.

2. Devices that can access the internet must not be sold directly to miners without parental consent.

3. Devices that can access the internet must include parental control software can be configured to allow/forbid all apps/content that may contain content not deemed suitable for children (in the jurisdiction where the device is sold).

Importantly, this kind of solution solves the "borderless internet" problem:

1. Device sellers are regulated in the jurisdiction where they sell the device.

2. Service providers take no (additional) per-jusrisdiction responsibility until they start labeling their content. By labeling their content, they are claiming to abide by specific regulations.

It depends on what you're trying to use it for. If you just use Emacs for coding, you're not going to gain anything from running it in a GUI. However, if you also use it to read documentation, take notes, etc.; being able to display images, different fonts, different sized fonts, etc. is pretty nice.

The main reason for CachyOS to exist is that it can take bigger risks and ship defaults more mature distros wouldn't be comfortable with.

In terms of benchmarks, gamers tend to care more about consistent responsiveness (and worstcase performance) than raw throughput. Phoronix benchmarks are probably not the best way to compare CachyOS against other distros. E.g., look at the game benchmarks you linked: all tested games were already running above 500 frames per second in the worst performing game.

Awesome! Thanks!

Will the Android companion app be open source? And/or will the watch APIs be documented such that someone could write an open source companion app?

See section 5.5 of the linked paper https://petsymposium.org/popets/2018/popets-2018-0026.php. I'm not sure if/how Kagi implemented this, but the idea is that Kagi's "public" component can be committed to publicly (e.g., in the browser extension itself).

Private companies != federal government. See https://en.wikipedia.org/wiki/Strict_scrutiny, there's no way the federal government will be able to argue that it has a legitimate interest in banning pronouns in signatures.

I have to wonder, is this (and all the rest) just an attempt to DoS civil rights groups?

If and only if your site isn't already referenced by some other site in the index (see option A).

The privacy pass extension still requires you to pass a cloudlare turnstile which is impossible in some browser configurations. E.g., if you disable browser performance-debugging/timing features (these used to be a vector for Spectre timing attacks).

3.8% below target is "way below"?

Possible supply-chain "attack" (or demonstration, from what I can tell) on wherever they get their polyfill library? It's coming from:

https://polyfill.archive.org/v3/polyfill.min.js?features=fet...

And if you want to automatically get redirected to xcancel: https://einaregilsson.com/redirector/

This attack doesn't allow anyone to, e.g., bypass any PINs you may have set on your yubikey. It allows an attacker to extract your keys if and only if they can already use your yubikey.

From what I can tell, the risk is:

1. Someone takes your yubikey without your knowledge.

2. They manage to disassemble it, extract your key, and put it back together.

3. They secretly return your yubikey.

4. You continue to use your yubikey, unaware of the fact that it has been compromised.

Try setting `ytdl-format=ytdl` in `mpv.conf`, that fixed it for me.