Live data from Hacker News

Show HN: Never lose a website again

fetching.io

71–80 of 80 posts

Re: Show HN: Never lose a website again

#71
post #41

Why server side indexing and not use something like lunarjs[1] from the beginning? Like the Idea of fulltext search on history, but I'm not going to send my full history to some random dude on the internet. No offence intended:) [1] ”Simple full-text search in your browser” http://lunrjs.com/

None taken! I looked at lunarjs (and a few other options) but felt that the more sophisticated features of ElasticSearch were worth it (at least to me). I'm curious, would you be more comfortable if all your content were encrypted such that not even the app developer (me) could read it? Or would only a local index do?

Most people would be okay with plaintext content sitting on your server and even publicly accessible by anyone.

But this is HN, and we wouldn't use even an AES-512-encrypted service if it has to leave our computers. Our password could still be cracked with enough computing power. So, we'd all be extremely happy if you could make a version for paranoid people like us.

Also, I don't know how your indexing works, but please make it easy to backup (just allowing us to define the index folder would do). Possible data loss is the tradeoff with local content.

Re: Show HN: Never lose a website again

#72
post #12

Earlier quoted context omitted.

Out of curiosity, what are you doing with such a simple site (and I don't mean that in a bad way) that requires any conscious effort to fix? It seems like you really need to go out of your way to fuck up the back button and for a fix to be "work". But, recent nuanced trends in web design/navigation aren't my top skill, so I'm asking the question honestly.

Honestly, I've been taken a bit by surprise that the back button bug has been such a big issue. I did some testing among friends (with a group of five or so startup, programmer types) and, believe it or not, it never came up.. That said, it'll be fixed in short order. To the other comments, the service is considerably more complex (and yes, built on Meteor, MongoDB and ElasticSearch) as it serves up search results an…

Don't mess with the back button and with the scrollbar.

Why not just elasticsearch ?

If you store texts in mongodb, look later for tokumx that compresses data.

Re: Show HN: Never lose a website again

#74
post #41

Why server side indexing and not use something like lunarjs[1] from the beginning? Like the Idea of fulltext search on history, but I'm not going to send my full history to some random dude on the internet. No offence intended:) [1] ”Simple full-text search in your browser” http://lunrjs.com/

None taken! I looked at lunarjs (and a few other options) but felt that the more sophisticated features of ElasticSearch were worth it (at least to me). I'm curious, would you be more comfortable if all your content were encrypted such that not even the app developer (me) could read it? Or would only a local index do?

It's not just about storing the history itself. I store bookmarks in the cloud as well.

My main problem is: As I understand it, the plugin sees what I see and just sends away everything. Including payments and balance in my bank account, business messages in Basecamp, code in private Github repos and content on sites that are not yet public I've signed an nda for.

The benefits don't justify the risks for me. Using incognito mode to avoid a plugin I've installed isn't really feasible.

As a second reason: I have mediocre internet connections most of the time since I'm traveling. Therefore I try to avoid as much requests as possible.

Re: Show HN: Never lose a website again

#75

Shameless plug: https://www.purplerails.com/ (1) Saves an exact copy of the page also. (2) Indexes the text. (3) Encrypted (search occurs on your computer). Been in beta for a while. Thanks for feedback.

Love the cartoon on your front page!

Thank you for your kind words!

Re: Show HN: Never lose a website again

#76

Why do so many sites require cookies just to tell me what they are all about? Yes, I am of the lunatic fringe that blocks all cookies by default... ...and by default more and more web sites lose me as a potential client/user/whatev because they require cookies just to display static welcoming information... ...I lose nothing by this, as far as I can tell. Perhaps ignorance really is bliss. :->

This is a great point and not one I'd ever even considered. You are right, the page you see first -- before signing up -- really doesn't need much. I am, in fact, using the Meteor stack for the entire thing, even the informational pages. But that was mostly a convenience.

Thanks for answering and for accepting this comment - I needed the validation, since I lost two karma points on the comment.

Ironic, no?

:->

Re: Show HN: Never lose a website again

#77
post #31

Why do so many sites require cookies just to tell me what they are all about? Yes, I am of the lunatic fringe that blocks all cookies by default... ...and by default more and more web sites lose me as a potential client/user/whatev because they require cookies just to display static welcoming information... ...I lose nothing by this, as far as I can tell. Perhaps ignorance really is bliss. :->

One legit reason is to set a CSRF cookie. If there's a login or signup form on the page, many frameworks add a CSRF field to the form that should match the cookie. When you POST the form, the cookie and the field must match.

Sure, that's legit - if login or signup is required.

But for pages containing information intended to encourage a user to spend time on a site, to get convinced they need to sign-up, it's counter-productive.

Re: Show HN: Never lose a website again

#78

To be blunt, this project will never gain traction because not enough people are willing to store their browsing history somewhere outside of their control. The back button issue shows a lack of attention to detail. Something that's extremely important when dealing with sensitive personal data.

Please know this is the first exposure this project has ever had. I really did try, in my spare time, to get this thing perfect before soliciting feedback from this wondrous community but -- alas! -- there be bugs. It's this kind of feedback that I was seeking and I intend to incorporate as I drive towards a broader release. Part of what I'm trying to validate is exactly the point you raised: will people generally be…

I think the only way people would be comfortable is if you use strong one-way encryption, meaning you yourself cannot decrypt a user's data. But to enable trust, and being a startup, you would have to have your code reviewed by a reliable third party or open-sourced for public review. Google gets away with it because they have built a brand with a reputation that some people trust enough with their data (I don't personally, but enough do). A much easier path is to create a version that works locally with no external communication. Both options would be ideal, but perhaps more work than you care to take on. No matter how it pans out it will be a great learning experience.
Post reply on HN