4 ms·

This is basically stealing bandwidth from sites like bit.ly, getting them to host your webpages for you. There might be legitimate uses for this, right now I c

This is basically stealing bandwidth from sites like bit.ly, getting them to host your webpages for you. There might be legitimate uses for this, right now I can't think of one. Clever hack though.

WesleyJohnson 15y ago
Is this really the case? Bit.ly would still have to forward the user over to the hashify.me site, where the hash would be decoded server-side and the content would have to be sent back over the wire to the client. That's still eating the same amount of bandwidth on hashify.me, no?
- HelloBeautiful 15y ago
  No ;-)
- uxp 15y ago
  Bit.ly has to store the entire document encoded in base64 as the URL of the destination in their database in order to return to users the value of the given bit.ly URL hash. In essence, yes, bit.ly is storing the entire document on their servers anytime anyone shortens a hashify.me link. Think if it like the difference between the postal service letting you know there is a package that you can go pick up at the post office, and the postal service giving you a package at your home or work that cannot be opened until you go to the store to buy a box cutter, but you have to bring the package with you. The first example is cheap, since you only receive a pointer or link to where the package is, but you have to do all the work to get it. The second is not cheap, since if the package was a bed from Ikea (for a random large example), the postal service (bit.ly) has to deliver the package to you, and then you have to go somewhere (hashify.me) while carrying that package in order to see what's inside.
  - deleted 15y ago
    [deleted]
  - WesleyJohnson 15y ago
    Ok, that makes sense. I thought we were debating on whether or not bit.ly incurred ALL the load and hashify.me incurred NONE, but that doesn't seem to be the case.
- TimothyBurgess 15y ago
  No. From what I understand, hashify does no intensive server side processing beyond providing the functions that allow the visitor to process the encoded string on its end; i.e., all intensive processing is done on the client's side. But as people above mentioned, the data is still being uploaded unnecessarily, due to a little short sightedness by the hashify creator(s). The hash should be stored after a pound (#) character to ensure that the data isn't sent to the hashify server via the URL (i.e., the GET method), since all processing of the hash is done client-side anyway.

This is basically stealing bandwidth from sites like bit.ly, getting them to host your webpages for you. There might be legitimate uses for this, right now I can't think of one. Clever hack though.

WesleyJohnson 15y ago

Is this really the case? Bit.ly would still have to forward the user over to the hashify.me site, where the hash would be decoded server-side and the content would have to be sent back over the wire to the client. That's still eating the same amount of bandwidth on hashify.me, no?

HelloBeautiful 15y ago
No ;-)
uxp 15y ago
Bit.ly has to store the entire document encoded in base64 as the URL of the destination in their database in order to return to users the value of the given bit.ly URL hash. In essence, yes, bit.ly is storing the entire document on their servers anytime anyone shortens a hashify.me link. Think if it like the difference between the postal service letting you know there is a package that you can go pick up at the post office, and the postal service giving you a package at your home or work that cannot be opened until you go to the store to buy a box cutter, but you have to bring the package with you. The first example is cheap, since you only receive a pointer or link to where the package is, but you have to do all the work to get it. The second is not cheap, since if the package was a bed from Ikea (for a random large example), the postal service (bit.ly) has to deliver the package to you, and then you have to go somewhere (hashify.me) while carrying that package in order to see what's inside.
- deleted 15y ago
  [deleted]
- WesleyJohnson 15y ago
  Ok, that makes sense. I thought we were debating on whether or not bit.ly incurred ALL the load and hashify.me incurred NONE, but that doesn't seem to be the case.
TimothyBurgess 15y ago
No. From what I understand, hashify does no intensive server side processing beyond providing the functions that allow the visitor to process the encoded string on its end; i.e., all intensive processing is done on the client's side. But as people above mentioned, the data is still being uploaded unnecessarily, due to a little short sightedness by the hashify creator(s). The hash should be stored after a pound (#) character to ensure that the data isn't sent to the hashify server via the URL (i.e., the GET method), since all processing of the hash is done client-side anyway.