| 09:04 | <annevk> | It's so frustrating GitHub only allows you to report a single user within a short period of time |
| 09:05 | <annevk> | Especially considering I'm logged in and have a track record of reporting actual spammers |
| 09:05 | <annevk> | And usually they're pretty good about feedback but I reported this issue twice and they're just like shrug |
| 09:48 | <MikeSmith> | annevk: I didn’t know they had such a limit |
| 09:49 | <MikeSmith> | I guess I’ve never reported multiple problems in close succession |
| 09:49 | <annevk> | MikeSmith: I often hit it in the morning as when dealing with GitHub notifications I try to deal with spam first |
| 09:49 | <MikeSmith> | ah yeah |
| 09:50 | <MikeSmith> | their entire reporting system opaque, unnecessarily |
| 09:51 | <annevk> | You do make me wonder if this is a timezone problem where the spam doesn't pile up in other timezones as much so it's not perceived as a problem |
| 09:58 | <annevk> | I have created another ticket, maybe three times works |
| 09:59 | <annevk> | Oh cool, for support requests there's now a ticket center where you can keep track of things online |
| 09:59 | <annevk> | Though I cannot view my spam reports there |
| 14:35 | <annevk> | Domenic: I haven't pinged plinss explicitly anywhere because it seems most of csswg.org is down, e.g., https://drafts.csswg.org/css-inline/ |
| 14:35 | <Domenic> | Fun |
| 14:35 | <annevk> | So I would expect this to be known |
| 15:04 | <annevk> | Domenic: now I'm also doubting "and public-suffix roots need to be considered same-site to their subdomains." |
| 15:04 | <annevk> | Domenic: annevk.github.io is not same site with github.io, right? |
| 15:06 | <annevk> | Domenic: it might be that only your statement there was wrong as it seems the same site check does account for it |
| 15:06 | <annevk> | Domenic: but let's note that in the parenthesis fix commit message |
| 15:06 | <Domenic> | Sounds good |
| 15:06 | <Domenic> | I thought they would be considered same-site, hmm |
| 15:06 | <Domenic> | But yeah I guess that would be bad |
| 15:07 | <Domenic> | Will walk myself back through the algorithms after this meeting |
| 15:11 | <annevk> | 👍🏻 |
| 15:17 | <Domenic> | annevk: OK, that all makes sense. But as a related non-blocking question, I'm wondering why we define registrable domain at all? Instead of defining eTLD+1? Then we could say that site is always (scheme, eTLD+1) instead of branching on nullness of registrable domain. |
| 15:23 | <annevk> | Domenic: so how do you obtain eTLD+1 from a host? |
| 15:23 | <Domenic> | annevk: a modification of the https://url.spec.whatwg.org/#host-registrable-domain algorithm to return the host instead of null. |
| 15:24 | <annevk> | Domenic: it seems that would make github.io same site with annevk.github.io |
| 15:24 | <Domenic> | Hmm OK maybe what I am suggesting is not in fact an eTLD+1 |
| 15:25 | <Domenic> | Is there a name for a thing where it's https://url.spec.whatwg.org/#host-registrable-domain but with step 1 returning host instead of null? |
| 15:25 | <annevk> | I think Gecko might call that effective domain |
| 15:25 | annevk | looks |
| 15:26 | <annevk> | Hmm maybe not |
| 15:36 | <annevk> | Domenic: I can't really find anything obvious, mostly it seems to be dealt with through fallback. I do wonder if implementations are truly consistent about all this though |
| 15:36 | <Domenic> | Hmm hmm |
| 15:37 | <annevk> | Domenic: it does seem like you need something like registrable domain; or you would need a separate type essentially |
| 15:37 | <Domenic> | When is it useful for it to be null? |
| 15:37 | <annevk> | Domenic: for the same site check |
| 15:38 | <Domenic> | I think same site could just become "is siteA[1] === siteB[1]" |
| 15:38 | <Domenic> | Where site[1] is this new thing |
| 15:38 | <annevk> | Well, if you look at how schemelessly same site is defined, I don't see how that's possible without it either being a distinct type somehow or having registrable domain |
| 15:39 | <annevk> | If we're talking about no functional changes |
| 15:39 | <Domenic> | No functional changes indeed |
| 15:39 | <annevk> | Basically, what's the definition of === as it cannot really be identity I think |
| 15:41 | <Domenic> | annevk: https://gist.github.com/domenic/49d7d2ec209bfae109ce6ec52148dffc is what I'm thinking |
| 15:42 | <annevk> | Domenic: sure, but what's equals? |
| 15:42 | <Domenic> | The same thing it is currently> |
| 15:42 | <Domenic> | If site[1] is a host, it's host-equals |
| 15:43 | <Domenic> | If site[1] is a registrable-domain-or-host, it's host-equals for hosts, string-equals for registrable domain |
| 15:43 | <annevk> | Okay, so you'd have an explicit registrable domain type |
| 15:43 | <annevk> | Currently it's just another domain |
| 15:43 | <Domenic> | No you'd use string |
| 15:44 | <annevk> | But how would you tell it's the registrable domain and not a domain? |
| 15:44 | <annevk> | Or not the public suffix, rather |
| 15:44 | <Domenic> | How would it matter? |
| 15:44 | <Domenic> | You already computed that in "obtain a site" |
| 15:44 | <Domenic> | Now you just have a string-or-IP-address |
| 15:44 | <Domenic> | or opaque host |
| 15:44 | <Domenic> | or empty host |
| 15:44 | <annevk> | yeah, but we obtain the registrable domain from it |
| 15:44 | <Domenic> | Oh wait those are both strings |
| 15:45 | <Domenic> | But you don't need to |
| 15:45 | <Domenic> | By the time you're in "same site" you just have a string-or-IP address |
| 15:45 | <Domenic> | You can compare those using normal === |
| 15:45 | <annevk> | Oh that might be true, yes, hmm |
| 15:48 | <Domenic> | I'll raise an editorial PR for changing same-site and schemeless-same-site for discussion. That's separate from potentially changing the definition of registrable domain/obtain a site, I guess. |
| 15:49 | <annevk> | Domenic: there's also the question of what we'd want to expose to APIs, if ever |
| 15:50 | <annevk> | Domenic: for an API you might want to have registrable domain, but on the other hand maybe you don't to enforce consistency |
| 15:51 | <Domenic> | Yeah, I dunno, the API discussion seems rather theoretical to me |
| 15:52 | <annevk> | Domenic: it keeps coming up as we expose this in more and more places |
| 15:52 | <annevk> | Domenic: it seems we call this "base domain" in Firefox (frontend code at least; getBaseDomainFromHost) |
| 15:52 | <Domenic> | When I looked on Friday Chrome's code was not very good at mapping to the spec |
| 15:53 | <annevk> | Domenic: but that's implemented on top of registrable domain |
| 15:53 | <annevk> | (which is called eTLD+1 for reasons) |