shrink (u/shrink) - Readit News

shrink commented on Retiring Test-Ipv6.com retire.test-ipv6.com/... · Posted by u/birdculture

shrink · 2 months ago

Reach out to ben[1] from IPinfo, he took over ip4.me, ip6.me and a number of other websites following the passing of Kevin Loch earlier this year[2]. I am sure he would be happy to keep test-ipv6.com running without compromising it :) Very reputable, a great track record!

[1] https://news.ycombinator.com/user?id=coderholic

[2] https://news.ycombinator.com/item?id=43256298

shrink commented on A new form of verification on Bluesky bsky.social/about/blog/04... · Posted by u/ink_13

shrink · 8 months ago

I built handles.net[1] to make it easy for organisations to manage their member's handles, I think that using domain names for identity is neat and valuable, I have a vested interest in its success as a paradigm but... domain name "verification" is not the right solution today for non-technical people. I shared this sentiment a few months ago[2] and I have only become more confident in that assessment since.

The approach they've taken ("trusted verifiers") is an approach aligned with their values, as it is an extension of the labelling concept that is already well established in the ecosystem. As an idealist, it is a shame that they gave up, I think they could have had an impact on shifting how non-technical people view domain names and understand digital identity... but as a pragmatist, this is the right choice. Bluesky has to pick their battles, and this isn't a hill to die on.

[1] https://handles.net [2] https://news.ycombinator.com/item?id=42749786

shrink commented on ATProto and the ownership of identity anirudh.fi/blog/identity/... · Posted by u/icy

shrink · a year ago

I like the domain name identity model used by AT (so much so I built handles.net[1] for managing domain name based handles) but during my time reading opinions on Bluesky it has become apparent there's a lot more confusion about and distrust towards domain names amongst non-technical people than I previously thought.

I thought that people generally understood that domain names are owned and that their provenance can be independently verified (which is why they're valuable for identity) but there's a fairly large and vocal contingent of Bluesky users that are frustrated by domain names, so much so there are multiple efforts to establish a private verification system on Bluesky like verified.quest[2].

A lot of people do not want to look at and understand domain names, instead they want to see a name and a check mark. They want a central authority to tell them who is trustworthy and who is not. Domain names are a great solution for technology-adjacent people and I hope that they become more widely accepted, but I'm not too optimistic.

I am optimistic and hopeful that AT has a bright future ahead of it. I think AT has a lot going for it... but I do not think that identity will be a part of that. I suspect many apps built on AT will not bother with handles and will just use local display names.

[1] https://handles.net [2] https://verified.quest

shrink commented on Tell HN: Google OAuth consent screen issue could be costing you signups · Posted by u/Aalk4308

Aalk4308 · a year ago

Interesting! It's certainly possible there are additional factors at play beyond what I've found to this point.

Curiously, in all other apps I tested and mentioned, I don't see the screen changing to "loading" on them. Do you?

Meantime, I'm checking the OAuth consent screen settings to see if there's anything relevant.

shrink · a year ago

After watching network requests, I think it's based on the use of the Javascript login functionality vs. the redirect functionality.

If the "Login with Google" button opens in a new tab and the Google OAuth flow completes in the second tab, then the process will have the "loading" screen after clicking "continue" because "loading" indicates Google OAuth is communicating back to the original tab. If the "Login with Google" button opens in the same tab, clicking "continue" triggers a 302 redirect to your callback URL of which the loading speed is controlled by your website.

The immediate workaround is to switch to opening the Google OAuth login page in a new window.

edit: "Sign In with Google for Web" appears to be what provides the new tab for login functionality https://developers.google.com/identity/gsi/web/guides/overvi...

edit edit: that's not to say you're wrong, Google should definitely fix this but "Sign In with Google for Web" is not impacted in case anyone needs an immediate fix for their own apps, they can switch to "Sign In with Google for Web" (a difference user interface for OAuth).

shrink commented on Tell HN: Google OAuth consent screen issue could be costing you signups · Posted by u/Aalk4308

Aalk4308 · a year ago

Interesting! It's certainly possible there are additional factors at play beyond what I've found to this point.

Curiously, in all other apps I tested and mentioned, I don't see the screen changing to "loading" on them. Do you?

Meantime, I'm checking the OAuth consent screen settings to see if there's anything relevant.

shrink · a year ago

According to Google Cloud, our App was created in 2018.

ChatGPT, Retool, Ramp, PostHog and HubSpot have the behaviour you've described.

I checked my browser history for `oauth/consent` and found the following examples with the loading behaviour:

HelpScout, Google Cloud, Termly.io

shrink commented on Tell HN: Google OAuth consent screen issue could be costing you signups · Posted by u/Aalk4308

shrink · a year ago

We use Google OAuth to handle hundreds of registrations each day and haven't encountered this before. No errors, no customer reports. Following your instructions, I logged in to my own Google account, removed the connection to our app (via "Third-party apps & services") and then did the login again: after clicking "continue" the screen changes to "loading" instantly before redirecting after a few seconds. There's no ability to click "continue" twice. I then tried to sign up to your app following your instructions and I can reproduce the issue there: the screen doesn't change to "loading" view that I get for our app.

Can you share a copy of your OAuth consent screen settings? Maybe there's an option influencing this behaviour.

edit: we do not use Auth0, our Google OAuth connection is built in house.

edit edit: comparing the URLs, our flow redirects from `https://accounts.google.com/signin/oauth/id` to `https://accounts.google.com/signin/oauth/consent` after clicking "continue" whereas yours remains on `https://accounts.google.com/signin/oauth/id` before redirecting to your app so there's definitely something different in the behaviour.

shrink commented on Intentionally Blank Page en.wikipedia.org/wiki/Int... · Posted by u/diggan

shrink · 2 years ago

If you have an unused domain that you'd like to be a page intentionally left blank you can use defunct.net[1] via DNS:

1. Point your domain to `a.defunct.website` or `34.36.101.120`

2. Add a TXT record containing `defunct.theme=intentionally-blank`

Voila, you have an intentionally blank page, e.g: https://theme-blank.examples.dfnct.net

[1] https://defunct.net (my service)