Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Old Vidme embeds turn into porn after domain purchase

theverge.com

Post reply on HN
Print view View original

91–100 of 125 posts

Re: Old Vidme embeds turn into porn after domain purchase

#91

Post by jeroenhd »

ignitionmonkey wrote: post #45
beambot wrote: post #39

Earlier quoted context omitted.

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...

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).

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?

Re: Old Vidme embeds turn into porn after domain purchase

#92

Post by AgentME »

skipants wrote: post #62
kazinator wrote: post #59

Earlier quoted context omitted.

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.

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.

Merkle trees basically accomplish this with separate hashes over every N bytes, so that the content can be verified continuously as it's downloaded.

Re: Old Vidme embeds turn into porn after domain purchase

#93

Post by AgentME »

ignitionmonkey wrote: post #45
beambot wrote: post #39

Earlier quoted context omitted.

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...

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).

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/. 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.

Re: Old Vidme embeds turn into porn after domain purchase

#94

Post by Scoundreller »

darrylb42 wrote: post #84
alexjplant wrote: post #83

Earlier quoted context omitted.

I have the opposite problem... I give money to OpenBSD but can't claim it on my taxes since they're Canadian :-(.

Are they a registered non-profit now? I donated when I used OpenBSD but don't think I got a tax receipt, just my name on one of the releases.

Was hoping there was maybe opportunity for corresponding donations that maximizes deductions.

Looks like openBSD isn't deductible either for Canadian donoUrs. Theo's registered address has lots of cool wifi links though. I count 4! (one is on the gutter)

https://www.google.com/maps/place/812+23+Ave+SE,+Calgary,+AB...

Re: Old Vidme embeds turn into porn after domain purchase

#97

Post by mkl »

jodrellblank wrote: post #72
skipants wrote: post #62

Earlier quoted context omitted.

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.

Presumably for SHA256 you only need to hash ~256 bits; what's anyone gonna do, try all possible combinations to find a collision?

256 bits is only 32 bytes, and most file formats have standard stuff right at the start. Collisions would be very common.

Re: Old Vidme embeds turn into porn after domain purchase

#98

Post by [deleted] »

elihu wrote: post #48
ignitionmonkey wrote: post #13

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.…

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 ret…

[deleted]

Re: Old Vidme embeds turn into porn after domain purchase

#99

Post by grumbel »

kazinator wrote: post #59
elihu wrote: post #48

Earlier quoted context omitted.

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 ret…

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.

That's already how it works in IPFS or Freenet. The hash is not for the data itself, but for a metadata document that contains a list of hashes to the data broken up into smaller blocks.

Re: Old Vidme embeds turn into porn after domain purchase

#100

Post by anfilt »

elihu wrote: post #48
ignitionmonkey wrote: post #13

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.…

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 ret…

This is were a signature would come in handy, if you want the resource to be updated. Just keep track that it was signed by the same private key.
Post reply on HN