Launch HN: Insight (YC W19) – an iOS browser with easy-to-make extensions
I'm Archa, one of the cofounders of Insight Browser (https://insightbrowser.com/). We let you deeply customize your search and browsing experience on iOS. You can create extensions on the phone itself, using simple if-then conditions and often without writing any code. For more advanced extensions, you can use JS.
14 years after iOS Safari brought the mobile browser to near-parity with desktop, most mobile browsers are still one-size-fits-all, but the internet isn't one-size-fits-all. It's very long tailed, both in content and in how differently people use it. There is now a generation of users growing up with iOS who still crave the power that's available on desktop. Some mobile browsers come bundled with ad-blocking, and there is a limited way to do extensions in Safari, but extensibility on mobile has been nowhere near desktop. Apple has restricted what developers can do with WKWebView, so we started to look into whether there's ways to work with that but preserve most of the usefulness of extensions.
We surveyed existing extensions on the Chrome extensions store and realized that most of them fit one of two patterns — augment pages with content or remove content from pages. (There's a third major category of scrapers or dev tools, but we felt that was less relevant for a mobile browser) Inspired by that and frustrated by missing what we had on desktop, we built Insight, where 90% of extensions can be built on the phone with if-then conditions (e.g. if searching Amazon, then search Google Shopping with the same query). Extensions are designed for mobile first. They are swipe gesture friendly and don't clutter up pages. For more advanced extensions, you can use Javascript to write a script that's injected into webpages you pick. For example, the extension to invert bright website colors for better dark mode (https://share.insightbrowser.com/10) works like this.
Some of my personal favorite extensions on Insight right now are — Detect fake Amazon reviews (using Fakemeta) and set price alerts (using CamelCamelCamel); Open a page with cookies disabled or a JS-free version of the page (https://share.insightbrowser.com/11); Make reading articles easier by injecting eye-guiding color gradient on the text (powered by Beeline Reader).
Extensions are automatically suggested as you browse pages, simplifying discovery. We do not log identifiable user data, and if you want to be extra safe about privacy, you can disable all communication with our servers in the settings.
Insight is still very early. On iOS, it's built on top of Firefox. We're excited about open sourcing the iOS Insight codebase once it's better documented, as well as making Insight available on Android and desktop soon. (Btw, if any of this is interesting to you, we're hiring: https://jobs.ashbyhq.com/insight-browser)
A couple of caveats — we don't currently support Apply Pay through Insight. Apple does not allow a regular WKWebView to use Apple Pay, just Safari and SFSafariViewController (https://developer.apple.com/documentation/apple_pay_on_the_w...). We also cannot support syncing bookmarks from other iOS browsers directly, because apps can not access each other's data in any way on iOS. We are however working on a way to import bookmarks from your desktop browsers, and hoping to push that soon!
We'd love to hear what you think of Insight. You can download it on iOS at https://...
50 comments
[ 3.2 ms ] story [ 113 ms ] threadFor no-code extensions, the logic is represented in simple base64 encoded JSON.
For extensions that use Javascript, it's a very simple model where a script is injected at the end using Javascript. You can develop these using just console on any regular desktop browser's JS console and mobile emulator (Firefox, Edge, Chrome, etc.)
It's also been great working with you on the dev side, as you ported my Chrome extension to Insight. You made quick work of getting BeeLine Reader into your Reader Mode, and I've heard from many of our users who have switched over to your browser as a result. Really excited to be working with you and seeing how you transform web browsing on iOS!
I now use both Twitter and LinkedIn via the web because I find the apps to be annoying (and for the most part, unnecessary). It would be great if you could take the functionality to the next level by allowing content blocking that removed the massive cruft that these platforms bombard us with.
Apple's terms clearly don't allow us building a store within the app (Fortnite vs. Apple) so we're not going to distribute paid extensions directly but it sounds like you use Gumroad and probably a secret link to distribute?
Also, there's some OS enforced limitations on compared to the full WebExtensions spec, but if you share the extension with me, I'm happy to take a look. I'm abhinav@insightbrowser.com if you'd like to reach out directly.
I would work now on adding shortcuts for automating browser actions & interacting with content.
I'd love to hear some workflow examples of things you'd automate that involve the browser. That would really help us guide how to elegantly integrate shortcuts.
We all know how "we will never store this" becomes "we will never sell this" becomes "well, we need to make money", all with privacy policy changes that no-one reads.
Extension suggestions can also be implemented client side.
You need to re-think your architecture to do these checks locally in-browser in order to protect user privacy. If you're concerned about scaling issues, take inspiration from how Google Safe Browsing works (local hash prefix matching & partial hash queries).
As uMatrix user, I see a lot of potential, and love the no-code approach to let users build extensions themselves to suit their needs. Can't wait to see this go cross-platform: I get it is going to take a while but any tentative dates for Linux (deb) and Android flavours?
That said, I want to point that the FAQ on the homepage for "What about privacy?" is a bit incomplete, "Insight disables trackers by default with a much larger blocklist than Safari. It uses server-side logic to suggest extensions as you browse. This data is never logged, but you can also turn this setting off so Insight does not make any calls to its servers at all."
'Cause the privacy policy [0] reveals that Insight may collect information including IP addresses, device-ids, location, and browsing history and share them with third-parties; which is not really what a few folks (like me) who block trackers in expectation of better privacy (and not just speed) want to hear, especially with the monetization strategy unclear at this stage.
[0] https://archive.is/q4u4R
This reminds me of Kitt Browser, which brought some of the Chrome extension APIs to iOS. Eyeo acquired it to make Adblock Browser for iOS, and Kitt has since been removed from the App Store.
Some resources relating to it are still online [1, 2] and Adblock Browser, which is derived from Kitt Browser, is open source [3, 4].
[1]: https://github.com/kitt-browser
[2]: https://youtube.com/watch?v=nfoWMgNYMkE
[3]: https://github.com/adblockplus/adblockbrowserios-core
[4]: https://github.com/adblockplus/adblockbrowserios
What other features from Adblockers are you missing with Insight that would be helpful?
Our ad blocker (https://www.magiclasso.co/) on iOS / macOS has less than 5,000 rules and performs as well as, it not better, than other ad blockers with larger rule sets. We're also happy to partner with like minded startups – feel free to get in touch if you're interested in working together.
Prove it?
Apple added Apple Pay to WKWebView in iOS 13. Release notes are here:
https://developer.apple.com/documentation/safari-release-not...
It won’t work for you out of the box because you inject scripts onto the page, which automatically disables Apple Pay for that view. But I expect you can do something useful here, like detect when a page is attempting to use Apple Pay and present a new view with injected scripts disabled and a note to the user about what has happened. Having Apple Pay work in an unmodified WKWebView is probably better than not having it work in a modified WKWebView.
I have a question about security, as I started porting my *Monkey scripts over, I notice there’s no API around access or security. If domain-specific extensions are shared in the community, what’s to prevent someone from developing a malicious script POSTing someone’s document.cookies to a DB?
The userscripts should be relatively close to what you guys do right now.