ian-bateman

Incoggo | Software Engineer | https://incoggo.com | San Francisco | Full-time | Hybrid (Mostly Onsite)

Incoggo is building a platform + marketplace for a new kind of extension that works in browsers, desktop apps, and mobile apps. Our mission at Incoggo is to empower users to 'extend anything'! (We'll be updating our site very soon!)

You'd be our very first hire (we're currently just 2 co-founders, one engineer and one biz dev; we're VC-backed) - looking for an experienced software engineer to help develop the platform - (Networking + Golang experience are a plus, but not required) - lots and lots of greenfield opportunity, and some very spicy technical challenges!

If you're interested, shoot me your résumé or GitHub: ian[@]incoggo.com

That's all true - we mention these directly on our FAQ (https://incoggo.com/faq/) -- many are issues we plan to address as soon as possible -- the application 100% works in terms of functionality, but is definitely still under heavy development!

> i wonder how you see this playing out in the future

In the near future, we're planning to expand into more general adblocking; we're currently focused on growth & there's still a lot of internal discussion happening, but we're most seriously considering a Spotify-style or micropayments model... very early days though - we just officially launched last week!

try https://incoggo.com :)

Looks like some others beat me to it, and I just commented elsewhere on this thread - but I'd recommend checking out https://incoggo.com - works on nytimes!

Shameless plug (Founder here), but I’d highly recommend checking out Incoggo (https://incoggo.com) as an alternative!

We work on a number of major publications that 12ft does not, including NYT, WSJ, and several others. We have a full list of supported publications here: https://incoggo.com/publications/

Thanks jimpix45! Glad to hear you're enjoying Incoggo :)

It's a 'local proxy' - meaning it runs entirely on your device, and filters network traffic. Beyond this, there are a wide variety of client-side filtering techniques that we use; we mix and match these based on the specific implementation of each publication (they're all pretty different in practice).

Ah that may be a miscommunication on our part! In the context of the app, paywall block == paywall bypass.

So as a few people have asked, this actually lets us use a variety of client-side unblocking techniques (like inbound request modification) that browser extensions can't (due to extension API limitations), and effectively unblock publications that the browser extensions don't (can't) — think major ones like WaPo and Bloomberg. The app also works across all browsers, not just Chrome / Firefox. As an aside, due to limitations caused by how cellular networks handle IPs, it's next to impossible for these sites to implement IP-based metering without severe adverse side effects, but the proxy does give very fine-grained control over how the user is presented to the end-site (including apparent IP address).

Right now, we don't make money or monetize at all, and are still exploring options. For the foreseeable future, we're 100% focused on growth and plan to raise VC funding to sustain operations. Ultimately, we want to find a monetization solution that works well for everyone and keeps our interests aligned with the best interest of our users.

Yes, it definitely 100% helps in that regard!

That's understandable - if you'd like a work around for now, the app has a 'pause' feature (which, if active, will cease to proxy traffic completely - you can just turn it on briefly as needed, then 'pause' it after loading the article).

The reason for the root cert is that in short order (after cleaning up our infra, etc.) we're actually planning to expand to a full-spectrum adblocker.

Yeah that's totally fair & we try to be pretty upfront about the issues (FAQ + forum). There's definitely a lot of bubblegum and duct-tape on this at the moment - been putting a lot of work in to fix the bigger issues ASAP (been modeling a lot off the AdGuard approach / targeting parity).

Really making the longer-term bet here that with a lot of work, the underlying proxy infrastructure will enable a lot of really interesting possibilities, and the shorter-term bet that with this approach we can create the best / most effective adblocker for paywalls by far.

TL;DR - we can unblock a lot of things with this approach that browser extensions can't; it also works across all browsers (esp. relevant for Safari users).

Digging in, there are a few reasons actually - first is, Chrome removes extensions with this kind of functionality from the Web Store constantly (only option would be to sideload).

Under the hood, Incoggo is also actually a local proxy (it adds a trusted root cert during the install process - we have some details on this / other potential issues / concerns on our forum). Reason for this being, Chrome extensions can't modify inbound requests in the way that's required to unblock several of the publications we support (NYT, Bloomberg, WaPo being key examples).

>couldn’t you pause/unpause the stdout with ctrl-s/ctrl-q instead?

edit: child comment is a better solution.

Seems like this article was written by an AI… and not a very good one at that.

I think the point Ford was trying to make is that you should listen to your customers, but also think for yourself. If a customer says ‘I want a faster horse’, you need to ask, ‘what is it that they really want / what is it they’re actually saying?’.

In Ford’s case that might be something like: ‘I want it to be faster / easier / cheaper to get from point A to point B’. If the way to deliver that to a customer is better horses or a car, it doesn’t really matter so long as the desired value is provided.

Thanks! Yeah it's definitely been a challenge, but I think it's worth the effort to try to make sure we're keeping incentives properly aligned and really get things right before we try to scale up!

> I think monetizing a privacy product without having the user pay is extremely hard. There will need to be an extremely high amount of transparency everywhere.

I would agree with this wholeheartedly -- we're still very early stages, but trying to keep things as open as possible in terms of our tech & intentions with everything.

> but also receive a lot of public funding.

Curious what sources you receive public funding from?

Posted a bit about how we plan to approach this above, so just re-pasting:

  > - we plan to build in something similar to HTTPS Everywhere to the product, to automatically upgrade connections (and we only route traffic on ports 80 / 443 (optionally 53)). - we also plan to build in the ability to allow peers to block certain categories of traffic from going over their connection (using blocklists similar to those used by Fortiguard -- so you could block all torrenting sites, as an example).

And yep you can actually! Can't find better article on it at the moment (lots of search history to comb through, but this kind of touches on it a little / roughly: https://www.reddit.com/r/pihole/comments/gndbod/dns_over_htt...)

Yep, if we do go that way, it'd likely be somewhat similar to Brave. Still very much evaluating options here though.

We are still evaluating the best way to go about this, but yes, we've been looking at the way Brave approaches it as well (though of course, we'd like to do it in such a way that everyone's incentives align / we don't compromise user privacy in any way whatsoever).

Short term, I'm self-funding the company (day job + previous exit of an entirely unrelated company).

The reasoning behind a p2p model is largely so that we don't have the massive overhead of traditional VPN companies & are able to offer the service entirely for free. Not having the overhead allows us to explore different potential methods of monetization that might not be feasible otherwise.

Hi edf13 -

We're still exploring different methods of monetization, but leaning towards an Adblock-Plus style model at the moment (but would want to keep any ads we served entirely local / we'd never send any data off device & would want to be as transparent about everything as possible). Personally, I think it keeps our interests best aligned with those of our users & helps keep the focus on preserving user privacy!

Hi coddle-hark -

- Right now we're still undecided / exploring different ways of monetizing the product! (something similar to Adblock-Plus though is our leading idea). - We're working on a way to disallow users from acting as exits for certain kinds of traffic - so you'll be able to categorically block certain kinds of sites through the UI in the near future. - Even with DoH on by default in the browser, we can still override / specify a DNS server.

Let me know if you still have questions / any of the above is unclear!

No catch! We're genuinely trying to build a product that will help protect user privacy online :)

There are a lot more technical details on the project README page here!: https://github.com/freepn/fpnd/blob/master/README.rst

(Hopefully) it's a bit easier to use than SoftEther!

Also, unlike SoftEther, we don't depend on volunteers for our network - the network is largely made up of the users themselves!

Hi eightails -

Our posts a few months back were largely exploratory posts - seeing if there was actually demand for the product (or at least enough to pursue the project!).

Since FreePN is such a technical product, we've been iterating a lot on our messaging. We are still in very early stages, but we do have some mechanisms planned to mitigate the effect of bad actors on the network:

- we plan to build in something similar to HTTPS Everywhere to the product, to automatically upgrade connections (and we only route traffic on ports 80 / 443 (optionally 53)). - we also plan to build in the ability to allow peers to block certain categories of traffic from going over their connection (using blocklists similar to those used by Fortiguard -- so you could block all torrenting sites, as an example).

Early days still, but much to come!