As someone else said, you'd have to do an email blast and hope users trust the email blast as authentic to trust your new domain, and just someone phishing.

Loss of a domain is so catastrophic for trust that passkeys don't make it much worse.

Passkeys provide perfect protection from phishing attacks, since it's impossible to send a passkey to the wrong domain. That's a huge improvement over TOTP.

Re: it being confusing where they're stored, I agree. The solution is to make sure you store your passkeys in your cross-platform password manager. The experience can be confusing though. In Chrome I've found that by default when creating a new Passkey Chrome offers to store it first. But if I click cancel, I'm then given the option to store it in 1Password where I want it.

But also, tons of news sites also only implement the paywall in client-side JS! This is so obviously easy to bypass it seems intentional, and they just don't care about the 'hackers'. Or perhaps they've know that people that are going to use tricks to access an article are very unlikely to pay for a subscription anyway.

(I wish I could just pay $1 on demand and read a paywalled article. I'd do it all the time, but I'm quite reluctant to sign up for any forever recurring subscriptions)

I'm curious what are the techniques? I'm familiar with spoofing yourself as a Googlebot, or extracting the content directly when paywall enforcement is done in client-side JS only. But surely you need more tricks than that to get around WSJ or NYTimes. Also, ironically, I assume archive.is's CAPTCHA would need bypassing to fall back to that. (but volume might be low enough you can do it with a few cookies you've established trust on)

Agreed that makes it quite nice! Though I wonder how long that will last, since I imagine archive.today is dealing with some problems that necessitated it.

> No man is an Iland, intire of it ſelf; euery man is a piece of the Continent, a part of the maine; if a clod be waſhed away by the Sea, Europe is the leſſe, as wel as if a Promõtory were, as well as if a Mannor of thy friends, or of thine owne were; Any mans death diminiſhes mee, becauſe I am inuolued in mankind; and therefore neuer ſend to know for whom the bell tols; It tols for thee.

Italics are original. Weird chars are best attempts by LLM transcription. Still quite readable, but interesting how much spelling has changed/standardized. Because its prose, I think we feel more free to modernize it than if it was poetry.

scan of it as published in 1624: https://archive.org/details/bim_early-english-books-1475-164...

and a more readable 1924 republish: https://archive.org/details/devotionsuponeme00donnuoft/page/...

It doesn't end on "It tolls for thee" or start on "No man is..". It keeps going in both direction, and no indication he every meant for this section to be pulled out into its own small piece the way it has. Here's some of what comes after:

> ... It tolls for thee. Neither can we call this a begging of Miserie or a borrowing of Miserie, as though we were not miserable enough of our selves, but must fetch in more from the next house, in taking upon us the Miserie of our Neighbours. Truly it were an excusable covetousnesse if wee did; for affliction is a treasure, and scarce any man hath enough of it....

    No man is an island,
    Entire of itself;
    Every man is a piece of the continent,
    A part of the main.
    
    If a clod be washed away by the sea,
    Europe is the less,
    As well as if a promontory were:
    As well as if a manor of thy friend's
    Or of thine own were.
    
    Any man's death diminishes me,
    Because I am involved in mankind.
    And therefore never send to know for whom the bell tolls;
    It tolls for thee

So when I heard about Jev, I was pretty excited. But as I learned more, I realized Jev can't ride horses, can't muck a stall, can't teach a flying lead change, and can't even reset a thrown shoe.

Maybe I'm doing it wrong, but I can't figure out why this exciting new thing doesn't work for my personal interest. Its lack of horseback riding support is a dealbreaker for me.

For example, the only way to make a change to an HA automation via the API is to POST a whole new copy of the YAML, even if changing one things. The skill and HA MCP I use allows the LLM to use tools which make more precise changes without excessive context usage.

Certainly still works either way though. And of course your LLM instance could just roll its own tools to do the exact same thing.

Since this has been standard ad tech for awhile, browsers have reacted to this to implement cookie partitioning for exactly these privacy reasons.

Could Google backtrack on this if they wanted? If they suddenly decided to stop releasing public code updates, what would they be violating? I can guess: Anti-trust maybe. probable at least contractual commitments Or is there some stronger forcing function?

But agreed it'd be very useful to see it deployed on other hubs, and it seems worth it to provide the bespoke API format. Perhaps Typesafe's API will end up becoming the standard for a new type of structured model, the way OpenAI's API did.

I found this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1980392 and commit: https://phabricator.services.mozilla.com/D262053

It looks like per-domain WebGPU blocking was added exclusively just for easyeda.com !

Haven't read it all, but the story seems to be that EasyEDA's WebGPU usage was broken because it relies on some aspects which Firefox hasn't implemented yet. So they made this blocklist to get Firefox to behave as if it lacked WebGPU support completely on this domain, which makes EasyEDA fallback to some other non-broken version. Maybe they couldn't get in touch with EasyEDA directly, since it seems far easier to have them just disable WebGPU for some known versions of Firefox.