Show HN: A Decentralized StatusPage on IPFS • Hacker News Board

Re: Show HN: A Decentralized StatusPage on IPFS

#71

Post by fyi1183 » Wed, Jan 31, 2018, 4:54 PM UTC

vertex-four wrote: post #66

diggan wrote: post #62

Earlier quoted context omitted.

You can't prove that you got the absolute latest data (same with DNS by the way) as it's being distributed. However, a malicious node in the network can't present you with outdated information or false information, as the IPNS record is signed with the key from the peer. If the IPNS record wasn't signed, it would indeed be a huge flaw as it wouldn't be tied to a key from a peer. That would defeat the entire purpose o…

> However, a malicious node in the network can't present you with outdated information or false information, as the IPNS record is signed with the key from the peer. False information - no. Outdated information - why not? What you've described in this comment doesn't solve it. If I signed that the name N points at hash H1 yesterday, and then signed that the name N points at hash H2 today, why can a malicious node not…

IPNS records have an optional and user-configurable expiry time, but more importantly, they contain a sequence counter.

So unless an attacker can completely disconnect you from everybody else who's interested in a particular IPNS address (and in that case you're lost anyway), they can't hoodwink you into going back to an old version.

Re: Show HN: A Decentralized StatusPage on IPFS

#72

Post by KirinDave » Wed, Jan 31, 2018, 4:56 PM UTC

vertex-four wrote: post #46

paulogr wrote: post #9

Earlier quoted context omitted.

IPFS has a so called IPNS system that use mutable hashes. So when you publish using this piece of software you got always a permanent link to share with your users.

IPNS has a huge flaw, as I understand it - there is no way to prove, as a consumer of an IPNS name, that you’ve got the latest data. A malicious node in the network could present you with outdated information and you’d have no way to tell.

But since the content can include timing and date information, it's pretty straightforward to work around this. IPFS bridges to HTTP, but is fundamentally a very different protocol that gives very different guarantees. Application developers need to recognize and mitigate these.

Re: Show HN: A Decentralized StatusPage on IPFS

#73

Post by 013a » Wed, Jan 31, 2018, 4:57 PM UTC

jstanley wrote: post #63

book_mentioned wrote: post #37

This is such a natural use case for IPFS that commercial adoption seems inevitable; as first mover you can offer the concierge edition and optionally gain a ton of credibility by open sourcing some of the core bits! It sounds like your marketing will need to explain: 1. How updates work and how you guarantee staying universes away from NSFW/illegal content -- answered separately because nobody wants to find out what…

Is IPFS infamous for illegal content? My perception was that it's still much too easy to trace the origin of content on IPFS and therefore not suitable for illegal things.

It was used in Spain to host illegal websites organizing Catalonian independence. But yeah, its not a great pick for illegal activities against technically competent governments.

Re: Show HN: A Decentralized StatusPage on IPFS

#74

Post by txsh » Wed, Jan 31, 2018, 4:59 PM UTC

NickBusey wrote: post #47

txsh wrote: post #44

Earlier quoted context omitted.

If I understand it correctly, it is decentralized. When pages are accessed they are automatically copied and hosted by nodes. Eventually, garbage collection will delete the copy. Pinning prevents it from being deleted so that the node hosts it permanently.

As far as I'm aware the 'automatic copying and hosting' currently lasts for around 30 minutes. You need to manually pin anything you want to live for longer than a day for sure. Additionally, this project utilizes IPNS, which clears it's DHT of entries that haven't refreshed within the past 24 hours. So you DEFINITELY need at least one node online, pretty much always, for this content to load.

It’s like bittorrent which requires a tracker but the transferring of content is distributed.

Re: Show HN: A Decentralized StatusPage on IPFS

#75

Post by KirinDave » Wed, Jan 31, 2018, 5:00 PM UTC

andyjohnson0 wrote: post #59

yorwba wrote: post #53

Earlier quoted context omitted.

Not if the page itself contains the time it was last updated (IMO all status pages should have this, IPFS or not). Then you could still get outdated information, but you'd be able to tell.

Even with a last update time on the page, how would you know whether that was really the latest update? You'd also need to know the update schedule.

Procedurally; since updating IPNS records is free it's pretty straightforward to continuously deploy a tree.

What's obnoxious about that is that existing IPFS daemons aren't really good at managing multiple identities so if you have multiple trees to maintain you're left writing custom software or using docker containers.

Re: Show HN: A Decentralized StatusPage on IPFS

#76

Post by fyi1183 » Wed, Jan 31, 2018, 5:00 PM UTC

tw1010 wrote: post #28

Naive question: if data on IPFS is permanent, meaning it's hard or impossible to remove things from it, what mechanisms, if any, exists to prevent unlawful content from being uploaded to it?

You don't really upload things to IPFS, since it works like Bittorrent: you make files available by adding them, but that doesn't copy those files anywhere. They're only transferred via the network to clients that specifically request them, which makes this a non-issue.

Now FileCoin, that's a different issue...

Re: Show HN: A Decentralized StatusPage on IPFS

#77

Post by vertex-four » Wed, Jan 31, 2018, 5:01 PM UTC

KirinDave wrote: post #72

vertex-four wrote: post #46

Earlier quoted context omitted.

IPNS has a huge flaw, as I understand it - there is no way to prove, as a consumer of an IPNS name, that you’ve got the latest data. A malicious node in the network could present you with outdated information and you’d have no way to tell.

But since the content can include timing and date information, it's pretty straightforward to work around this. IPFS bridges to HTTP, but is fundamentally a very different protocol that gives very different guarantees. Application developers need to recognize and mitigate these.

Being able to recognise the protocol's limitations and guarantees depends on those limitations and guarantees, as well as best practices for developing applications using the protocol, being openly documented.

Re: Show HN: A Decentralized StatusPage on IPFS

#78

Post by KirinDave » Wed, Jan 31, 2018, 5:03 PM UTC

vertex-four wrote: post #77

KirinDave wrote: post #72

Earlier quoted context omitted.

But since the content can include timing and date information, it's pretty straightforward to work around this. IPFS bridges to HTTP, but is fundamentally a very different protocol that gives very different guarantees. Application developers need to recognize and mitigate these.

Being able to recognise the protocol's limitations and guarantees depends on those limitations and guarantees, as well as best practices for developing applications using the protocol, being openly documented.

Are you suggesting that IPFS doesn't document the behavior of IPNS?

Re: Show HN: A Decentralized StatusPage on IPFS

#79

Post by vertex-four » Wed, Jan 31, 2018, 5:07 PM UTC

KirinDave wrote: post #78

vertex-four wrote: post #77

Earlier quoted context omitted.

Being able to recognise the protocol's limitations and guarantees depends on those limitations and guarantees, as well as best practices for developing applications using the protocol, being openly documented.

Are you suggesting that IPFS doesn't document the behavior of IPNS?

Indeed I am - can you find me a document which describes whether IPNS is or is not currently vulnerable to replay attacks, in which scenarios its assumptions are broken, and/or best practices for handling any shortcomings of IPNS?

Re: Show HN: A Decentralized StatusPage on IPFS

#80

Post by vertex-four » Wed, Jan 31, 2018, 5:13 PM UTC

fyi1183 wrote: post #71

vertex-four wrote: post #66

Earlier quoted context omitted.

> However, a malicious node in the network can't present you with outdated information or false information, as the IPNS record is signed with the key from the peer. False information - no. Outdated information - why not? What you've described in this comment doesn't solve it. If I signed that the name N points at hash H1 yesterday, and then signed that the name N points at hash H2 today, why can a malicious node not…

IPNS records have an optional and user-configurable expiry time, but more importantly, they contain a sequence counter. So unless an attacker can completely disconnect you from everybody else who's interested in a particular IPNS address (and in that case you're lost anyway), they can't hoodwink you into going back to an old version.

I see. So if they can disconnect you from everybody else (for example, if they control the internet connection you're connected to), you have no way of telling whether they're replaying IPNS records to you.

The traditional internet solves the problem of not being able to trust your internet connection (say, in a coffee shop) with public key infrastructure so that the most a rogue internet provider can do is DoS you (they can't get a certificate for google.com and TLS is protected against replay attacks), so this sounds like a downgrade in actual security.