4 ms·

This is not a criticism of URLs per se, but I find it troubling that the mere act of visiting one is something that we have to warn people away from. It's like

This is not a criticism of URLs per se, but I find it troubling that the mere act of visiting one is something that we have to warn people away from. It's like: > Don't eat moldy food, else you'll get sick (unless it's bleu cheese, yum) Ok, that sounds like good advice, and easy do follow. > Don't look in the direction of modly food, else you'll get sick That's unreasonable. What kind of madman wrote the rules for this universe?! When I try to imagine a better way, it usually disallows the referents of a URL-equivalent from changing after they're created--that way trust bestowed once can be reused without prompting the user a second time for the "same" thing. For that reason, I'm not a fan of placeholder URL's like you're describing. The instability of URLs to me feels like more bug than feature.

deleted 2y ago
[deleted]
cxr 2y ago
I don't know what you're talking about at the end, but you're definitely applying an inconsistent (double) standard at at least one point in your comment. The status quo is one where the reference is either completely unresolvable, or the referent accessible only after some effort that would have been better avoided. Forward-declared identifiers don't exacerbate any of these issues. Meanwhile, the set of things ameliorated by them is non-empty.
- __MatrixMan__ 2y ago
  Basically I'd rather be using cryptographic hashes of the page instead of URLs so that if I trust the hash then I have an obvious mechanism for determining if I should trust the payload that the hash refers to. Stability like that would severely limit the places that a malicious payload could hide, and it would enable users to compare notes about what is or is not trustworthy. If the identifier can exist before its referent, then any such verify-the-payload-given-the-id activity becomes much more complicated because we now have to wonder if we're getting different versions of the page for the same identifier (e.g. like when airlines present different prices based on which browser you've used even though you used the same link in each. I'm trying to dream up a web where that's not possible).
  - figassis 2y ago
    Hashes are not memorable. I can’t give my gramma a hash, but I can give her example.com/recipe123. If she trusts example.com, or me, she should be able to trust the content. If she does neither, a hash will not save her because she needs to have seen the content first to make a decision to trust it.
    - __MatrixMan__ 2y ago
      It's fairly common to create "link" objects which have both a human readable component and a URL component. Not much would be lost if the URL got less readable, we'd just have to be more diligent about associating a human readable string with the link. This could be done automatically if the content happens to provide its own "name" field. Otherwise you'd just have to give your link a name. Links which are displaying an ad-hoc name can show up in one color. Links which display whatever the content names itself can show up in another color. We can have different fonts for whether people you trust have flagged the content as trustworthy or whether the've flagged it as malicious. Nobody needs to see the hash itself. But none of that works if a link might resolve to different content at different times. As far as needing to see the content before you know you can trust it... There's no harm in fetching malicious data and taking a peek at it. Just don't act on it. If we train people to not even look at the threats then they're not going to have a feel for what threats actually look like.
      - deleted 2y ago
        [deleted]
      - figassis 2y ago
        I think that is too much infrastructure for just a link. I think links are fine the way they are today. There are other problems with the web, but it's not links. Also, simetimes taking a look is the same as acting on it. Clicking on an link in outlook is often acting on it, if it's some script or whatever it is that people do on outlook.
        __MatrixMan__ 2y ago
ben_w 2y ago
> That's unreasonable. What kind of madman wrote the rules for this universe?! My chain of thought went: "QR code containing a bobby drop tables! What would a human version of this be? Viral memes, in the original sense, that cause psychic damage? Oh wait, photosensitive epilepsy is a thing."
- __MatrixMan__ 2y ago
  I think there was such a thing in Snow Crash
- yencabulator 2y ago
  https://www.infinityplus.co.uk/stories/blit.htm https://www.infinityplus.co.uk/stories/blit.htm
  - __MatrixMan__ 2y ago
    That was great, thanks

deleted 2y ago

[deleted]

cxr 2y ago

I don't know what you're talking about at the end, but you're definitely applying an inconsistent (double) standard at at least one point in your comment. The status quo is one where the reference is either completely unresolvable, or the referent accessible only after some effort that would have been better avoided. Forward-declared identifiers don't exacerbate any of these issues. Meanwhile, the set of things ameliorated by them is non-empty.

__MatrixMan__ 2y ago
Basically I'd rather be using cryptographic hashes of the page instead of URLs so that if I trust the hash then I have an obvious mechanism for determining if I should trust the payload that the hash refers to. Stability like that would severely limit the places that a malicious payload could hide, and it would enable users to compare notes about what is or is not trustworthy. If the identifier can exist before its referent, then any such verify-the-payload-given-the-id activity becomes much more complicated because we now have to wonder if we're getting different versions of the page for the same identifier (e.g. like when airlines present different prices based on which browser you've used even though you used the same link in each. I'm trying to dream up a web where that's not possible).
- figassis 2y ago
  Hashes are not memorable. I can’t give my gramma a hash, but I can give her example.com/recipe123. If she trusts example.com, or me, she should be able to trust the content. If she does neither, a hash will not save her because she needs to have seen the content first to make a decision to trust it.
  - __MatrixMan__ 2y ago
    It's fairly common to create "link" objects which have both a human readable component and a URL component. Not much would be lost if the URL got less readable, we'd just have to be more diligent about associating a human readable string with the link. This could be done automatically if the content happens to provide its own "name" field. Otherwise you'd just have to give your link a name. Links which are displaying an ad-hoc name can show up in one color. Links which display whatever the content names itself can show up in another color. We can have different fonts for whether people you trust have flagged the content as trustworthy or whether the've flagged it as malicious. Nobody needs to see the hash itself. But none of that works if a link might resolve to different content at different times. As far as needing to see the content before you know you can trust it... There's no harm in fetching malicious data and taking a peek at it. Just don't act on it. If we train people to not even look at the threats then they're not going to have a feel for what threats actually look like.
    - deleted 2y ago
      [deleted]
    - figassis 2y ago
      I think that is too much infrastructure for just a link. I think links are fine the way they are today. There are other problems with the web, but it's not links. Also, simetimes taking a look is the same as acting on it. Clicking on an link in outlook is often acting on it, if it's some script or whatever it is that people do on outlook.
      - __MatrixMan__ 2y ago

ben_w 2y ago

> That's unreasonable. What kind of madman wrote the rules for this universe?! My chain of thought went: "QR code containing a bobby drop tables! What would a human version of this be? Viral memes, in the original sense, that cause psychic damage? Oh wait, photosensitive epilepsy is a thing."

__MatrixMan__ 2y ago
I think there was such a thing in Snow Crash
yencabulator 2y ago
https://www.infinityplus.co.uk/stories/blit.htm https://www.infinityplus.co.uk/stories/blit.htm
- __MatrixMan__ 2y ago
  That was great, thanks