5 ms·

We can't and shouldn't expect people to keep their old domains forever. We need a way for pages to be signed and hyperlinks to enforce authorship. When we link

We can't and shouldn't expect people to keep their old domains forever. We need a way for pages to be signed and hyperlinks to enforce authorship. When we link to stuff, we should have a way to say whose stuff we're linking to. It's no different from installing signed software and using trusted repositories. This is one of the reasons I created a proof-of-concept web extension that verifies links and pages using PGP. On a mismatch, it flags the page and offers a web archive link instead. https://webverify.jahed.dev/ https://webverify.jahed.dev/ It was pretty fun to make, but currently due to performance, Web Extensions API doesn't provide the features to do this perfectly. Firefox provides just about enough additional APIs to hack it together.

alisonkisk 5y ago
Also, Signed Exchanges for CDNs. https://developers.google.com/web/updates/2018/11/signed-exchanges https://developers.google.com/web/updates/2018/11/signed-exc...
LinuxBender 5y ago
Could SRI be used for this? [1] [1] - https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
- ignitionmonkey 5y ago
  SRI/hashing works for static content. Though it's worth mentioning it's a SUB-resource feature (images, scripts, etc.). It doesn't work for hyperlinks to other pages. Even if it did, it's a different use case. Say I link to an article by Author A that has comments in it (or even a footer, relative timestamp, sidebar, etc.). Hashing won't work as the page is always changing. I want the link to always go to Author A but I don't care if the content changes. That's the sort of use case signed webpages and hyperlinks with enforced authorship covers. It's less about what's on the page and more about who created it.
  - LinuxBender 5y ago
    Good points. I would guess that for something to be implemented, it would have to be easy for browsers and API tools to check once per domain and cache the response and should probably be something that already exists and has been adopted. Maybe a page could have a meta tag or header that contains a hash of the destination sites DANE signature? Something like "targetref:somedomain.tld expectsig:39726a2fe2bb052cf00e6b95a8385f7" based on tools like danecheck [1] or maybe DNSSEC but that is very poorly adopted. [1] - https://github.com/vdukhovni/danecheck https://github.com/vdukhovni/danecheck
    - unilynx 5y ago
      Finding a way to embed the domain registration date might be sufficient, that would cover most of the expiry situation There was a ietf or similar registry that used your domain and registration date to carve out your namespace, ie dns.2021.07.26.com.example would be your prefix. Pretty robust. Can’t remember what it was anymore
    - ignitionmonkey 5y ago
      The solution I was going for with WebVerify is more web-centric rather than domain-driven, which I think is a better fit for webpages. It can be enforced at the hyperlink-level for shared domains (like GitHub Pages, University web spaces) and works for static resources without needing to configure external resources. The only really complicated part is PGP but that can be solved with better tooling (as seen with Keybase).
beambot 5y ago
One solution is to have a unique URI per file that is independent of DNS. Decentralized file storage (e.g. FileCoin / IPFS) might serve this purpose...
- ignitionmonkey 5y ago
  Definitely but I think we need something that will work with the web we currently have while these bigger ideas are fleshed out and adopted. Also, while IPNS covers the issue of linking to dynamic content, it's worth mentioning IPFS will have similar issues with DNS as DNSLink and similar domain-driven solutions are used to cover its usability issues (long, random URIs).
  - jeroenhd 5y ago
    I think long, random URIs are fine for embedded content, actually. Most embeds are short, random URIs prepended with a trendy domain name. If you could "permalink" certain content for embeds, that'd probably solve the issues, right?
  - AgentME 5y ago
    IPFS works pretty well in the style of progressive-enhancement with the existing web for static content specifically. If you want to link to a resource that's available through IPFS, then you make the link point to an IPFS gateway that you trust and expect to stay online (possibly your own on your own domain), like https://example.com/ipfs/Qm_IPFS_HASH_HERE/ https://example.com/ipfs/Qm_IPFS_HASH_HERE/. Anyone that has a browser with direct IPFS support (either because they're using an IPFS extension or they're using a browser with built-in support, which might get more popular if IPFS takes off) will have their browser recognize the URL format and just fetch the file by hash directly from IPFS, and it won't matter if example.com is still up and serving the file. For everyone else, the link will work as long as example.com is still up and acting as an IPFS gateway. If example.com ever goes down, then users can make the link work by installing an IPFS extension or manually replacing the example.com domain in the link with the domain of any still-active IPFS gateway, and any admin in control of the page could fix the link similarly.
elihu 5y ago
One idea that's been around for awhile is to identify files by their hash. That has pros and cons. The good side of that is that the file is immutable; you can't accidentally link to something else unless someone can manufacture a hash collision somehow. The down side is that if the file is corrected in some way, you don't get the fixes. In a lot of the peer-to-peer distributed hash table designs, all you need to retrieve a file is its hash. https://en.wikipedia.org/wiki/Content_addressable_network https://en.wikipedia.org/wiki/Content_addressable_network
- kazinator 5y ago
  Problem is, you have to download the entire video to check the hash. That's not how video embedding works; the client browser is just handed some link, and it obtains pieces of the video, rendering it instantly. Basically, little segments of the video have to have a signature which is continuously validated. Or something like that.
  - skipants 5y ago
    I don't have expertise in video codecs or file formats, but couldn't you hash the first N bytes of a stream? Stream those N bytes to the client and if it matches start the video, else stop the download and not start the video.
    - jodrellblank 5y ago
      Presumably for SHA256 you only need to hash ~256 bits; what's anyone gonna do, try all possible combinations to find a collision?
      - mkl 5y ago
        256 bits is only 32 bytes, and most file formats have standard stuff right at the start. Collisions would be very common.
    - tomjakubowski 5y ago
ff7c11 5y ago
I had a personal project that I got bored with so I let the domain expire. Then I got emails from former users saying that the domain was now hosting malware. So yeah I would like it for all the old links to the site to somehow know that the owner has changed. Not sure what a reasonable solution would look like though.
strogonoff 5y ago
Could URL authorship confirmation be implemented on top of TLS? If someone takes over a domain, the final certificate in the chain will be issued to another entity, and that could be enough to trigger a notice. Could be achievable with a centralized registry/crawler like Internet Archive, but one that only keeps track of domain:certificate mapping. Of course, the devil’s in the details (infrastructure/organizational changes can trigger false positives; shared hosting setup can cause false negatives; it presumes that if the original entity abandons a domain they’d revoke the cert; etc.), but IMO it wouldn’t be worthless as it is.
- account42 5y ago
  Most certificates (including all free ones) are domain validated only so the entity being certified is just the domain and will not change with a new owner.
  - strogonoff 5y ago
    If you’re talking about shared hosting, yes, it wouldn’t be covered by this model. But other than that, if I have a cert fo xyz.com, and I abandon the domain, even if you buy it you’ll be forced to issue another cert for it. If it was recorded somewhere that xyz.com = my cert, it could serve as a mechanism to verify that given URL is at least is supposed to be under my control and a warning could be shown if another certificate is being served now. Kind of like HPKP, but with longer lifetime (longer than domain name registration term) and a centralized registry tracking certificate:domain mappings rather than each individual user agent cache. Obviously, no one would adopt it due to being a devops nightmare.
    - account42 5y ago
      Right, you can pin the certificate or the public key in it - but that's much more specific than the entity that the cert is issued to and as you correctly noted is not practical for browsers to do automatically since keys and certs do get rotated without a change in owner.
paulddraper 5y ago
It's not a solvable problem. Domains need to be short to be memorized, which makes them scare and valuable. And having two forms of URLs is undesirable; just look at AMP.

alisonkisk 5y ago

Also, Signed Exchanges for CDNs. https://developers.google.com/web/updates/2018/11/signed-exchanges https://developers.google.com/web/updates/2018/11/signed-exc...

LinuxBender 5y ago

Could SRI be used for this? [1] [1] - https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

ignitionmonkey 5y ago
SRI/hashing works for static content. Though it's worth mentioning it's a SUB-resource feature (images, scripts, etc.). It doesn't work for hyperlinks to other pages. Even if it did, it's a different use case. Say I link to an article by Author A that has comments in it (or even a footer, relative timestamp, sidebar, etc.). Hashing won't work as the page is always changing. I want the link to always go to Author A but I don't care if the content changes. That's the sort of use case signed webpages and hyperlinks with enforced authorship covers. It's less about what's on the page and more about who created it.
- LinuxBender 5y ago
  Good points. I would guess that for something to be implemented, it would have to be easy for browsers and API tools to check once per domain and cache the response and should probably be something that already exists and has been adopted. Maybe a page could have a meta tag or header that contains a hash of the destination sites DANE signature? Something like "targetref:somedomain.tld expectsig:39726a2fe2bb052cf00e6b95a8385f7" based on tools like danecheck [1] or maybe DNSSEC but that is very poorly adopted. [1] - https://github.com/vdukhovni/danecheck https://github.com/vdukhovni/danecheck
  - unilynx 5y ago
    Finding a way to embed the domain registration date might be sufficient, that would cover most of the expiry situation There was a ietf or similar registry that used your domain and registration date to carve out your namespace, ie dns.2021.07.26.com.example would be your prefix. Pretty robust. Can’t remember what it was anymore
  - ignitionmonkey 5y ago
    The solution I was going for with WebVerify is more web-centric rather than domain-driven, which I think is a better fit for webpages. It can be enforced at the hyperlink-level for shared domains (like GitHub Pages, University web spaces) and works for static resources without needing to configure external resources. The only really complicated part is PGP but that can be solved with better tooling (as seen with Keybase).

beambot 5y ago

One solution is to have a unique URI per file that is independent of DNS. Decentralized file storage (e.g. FileCoin / IPFS) might serve this purpose...

ignitionmonkey 5y ago
Definitely but I think we need something that will work with the web we currently have while these bigger ideas are fleshed out and adopted. Also, while IPNS covers the issue of linking to dynamic content, it's worth mentioning IPFS will have similar issues with DNS as DNSLink and similar domain-driven solutions are used to cover its usability issues (long, random URIs).
- jeroenhd 5y ago
  I think long, random URIs are fine for embedded content, actually. Most embeds are short, random URIs prepended with a trendy domain name. If you could "permalink" certain content for embeds, that'd probably solve the issues, right?
- AgentME 5y ago
  IPFS works pretty well in the style of progressive-enhancement with the existing web for static content specifically. If you want to link to a resource that's available through IPFS, then you make the link point to an IPFS gateway that you trust and expect to stay online (possibly your own on your own domain), like https://example.com/ipfs/Qm_IPFS_HASH_HERE/ https://example.com/ipfs/Qm_IPFS_HASH_HERE/. Anyone that has a browser with direct IPFS support (either because they're using an IPFS extension or they're using a browser with built-in support, which might get more popular if IPFS takes off) will have their browser recognize the URL format and just fetch the file by hash directly from IPFS, and it won't matter if example.com is still up and serving the file. For everyone else, the link will work as long as example.com is still up and acting as an IPFS gateway. If example.com ever goes down, then users can make the link work by installing an IPFS extension or manually replacing the example.com domain in the link with the domain of any still-active IPFS gateway, and any admin in control of the page could fix the link similarly.

elihu 5y ago

One idea that's been around for awhile is to identify files by their hash. That has pros and cons. The good side of that is that the file is immutable; you can't accidentally link to something else unless someone can manufacture a hash collision somehow. The down side is that if the file is corrected in some way, you don't get the fixes. In a lot of the peer-to-peer distributed hash table designs, all you need to retrieve a file is its hash. https://en.wikipedia.org/wiki/Content_addressable_network https://en.wikipedia.org/wiki/Content_addressable_network

kazinator 5y ago
Problem is, you have to download the entire video to check the hash. That's not how video embedding works; the client browser is just handed some link, and it obtains pieces of the video, rendering it instantly. Basically, little segments of the video have to have a signature which is continuously validated. Or something like that.
- skipants 5y ago
  I don't have expertise in video codecs or file formats, but couldn't you hash the first N bytes of a stream? Stream those N bytes to the client and if it matches start the video, else stop the download and not start the video.
  - jodrellblank 5y ago
    Presumably for SHA256 you only need to hash ~256 bits; what's anyone gonna do, try all possible combinations to find a collision?
    - mkl 5y ago
      256 bits is only 32 bytes, and most file formats have standard stuff right at the start. Collisions would be very common.
  - tomjakubowski 5y ago

ff7c11 5y ago

I had a personal project that I got bored with so I let the domain expire. Then I got emails from former users saying that the domain was now hosting malware. So yeah I would like it for all the old links to the site to somehow know that the owner has changed. Not sure what a reasonable solution would look like though.

strogonoff 5y ago

Could URL authorship confirmation be implemented on top of TLS? If someone takes over a domain, the final certificate in the chain will be issued to another entity, and that could be enough to trigger a notice. Could be achievable with a centralized registry/crawler like Internet Archive, but one that only keeps track of domain:certificate mapping. Of course, the devil’s in the details (infrastructure/organizational changes can trigger false positives; shared hosting setup can cause false negatives; it presumes that if the original entity abandons a domain they’d revoke the cert; etc.), but IMO it wouldn’t be worthless as it is.

account42 5y ago
Most certificates (including all free ones) are domain validated only so the entity being certified is just the domain and will not change with a new owner.
- strogonoff 5y ago
  If you’re talking about shared hosting, yes, it wouldn’t be covered by this model. But other than that, if I have a cert fo xyz.com, and I abandon the domain, even if you buy it you’ll be forced to issue another cert for it. If it was recorded somewhere that xyz.com = my cert, it could serve as a mechanism to verify that given URL is at least is supposed to be under my control and a warning could be shown if another certificate is being served now. Kind of like HPKP, but with longer lifetime (longer than domain name registration term) and a centralized registry tracking certificate:domain mappings rather than each individual user agent cache. Obviously, no one would adopt it due to being a devops nightmare.
  - account42 5y ago
    Right, you can pin the certificate or the public key in it - but that's much more specific than the entity that the cert is issued to and as you correctly noted is not practical for browsers to do automatically since keys and certs do get rotated without a change in owner.

paulddraper 5y ago

It's not a solvable problem. Domains need to be short to be memorized, which makes them scare and valuable. And having two forms of URLs is undesirable; just look at AMP.