Fillr integration?

[anthonycr]

I'm interested in seeing what people think about http://www.fillr.com/ and whether I should consider integrating support into the browser, a couple users have requested it and their team has been pinging me for a couple weeks. Here is a mildly technical document explaining its functionality

Basically, it does form filling (which Lightning currently does not do). It does not fill passwords/usernames, only other form information (email, address, payment info, etc.). It was suggested by a couple users who would like to see it in the browser, but I personally don't see the big benefits... I'd much prefer to add some sort of password manager. I don't have any metrics on how many people visit commerce sites using the browser, so I can't really determine if it's something many users would benefit from.

I created an unscientific twitter poll yesterday to gauge interest and the result was in favor of fillr: 73%. However, the fillr account, which apparently follows me, saw the poll and @ tweeted to it, so I have no idea if they could have had people vote in favor of it or not and skewed it.

Then I created a google plus poll in the browser beta community interested in the response, and the response was exactly the opposite, against fillr: 78%. So now I have two unscientific polls saying the opposite thing. Not super helpful, as the G+ responses are more highly correlated with interest in Lightning though through the requirement to be part of the community, I am taking that result as more important.

I figured I would create an issue and see what those of you who contribute to the project have to say as your opinion is the most valuable.

My 2 cents is that I think the idea is cool, form filling is better than nothing - which is the way Lightning currently operates. The company claims to heavily encrypt the data locally and not send it to the server, and seems reputable. But, I'm concerned with a company that has no clear monetization strategy having so much access to important personal data. Their sdk works by injecting JS into a webpage as far as I can understand from the above document, which seems concerning from a security standpoint as we cannot directly audit their code as it is not open source. Also their sdk regularly updates the JS and mapping used to work rather than requiring a library update, so that seems like a potential security risk as JS is being downloaded and executed without control in lightning... of course websites everywhere do exactly that all the time so on the other hand is it really a problem.

Please comment with your thoughts even if it's just a simple yes or no. I really want to make good decisions for this app as I've gained the trust of many people and I don't want to violate that.

I will also add that this would be a monetization opportunity for the browser according to fillr (based on the app's MAU).

As a random aside, I'd personally much rather do search engine monetization than any other kind as I find that it's non-intrusive to the user and basically just as privacy safe as regular browsing (but unfortunately no one has reached out to me to do).

Privacy policy here: http://www.fillr.com/privacy-policy-app Terms located here: http://www.fillr.com/terms-app

[alt-grr]

I created an unscientific twitter poll yesterday to gauge interest and the result was in favor of fillr: 73%. However, the fillr account, which apparently follows me, saw the poll and @ tweeted to it, so I have no idea if they could have had people vote in favor of it or not and skewed it.

It would be very surprising, if Fillr followers were voting AGAINST it...

Also their sdk regularly updates the JS and mapping used to work rather than requiring a library update, so that seems like a potential security risk as JS is being downloaded and executed without control in lightning...

That's horrible. I don't have 100% trust in security of servers of random startup.

of course websites everywhere do exactly that all the time so on the other hand is it really a problem.

No, it's not the same, because every single website is sandboxed from other websites.

---

I don't like the idea of deeply, non-removable integration with some commercial, closed-source, this-month-trendy service. Especially, if you will be doing all job for their favor in writing this integration, for free.

---

I'd personally much rather do search engine monetization than any other kind as I find that it's non-intrusive to the user and basically just as privacy safe as regular browsing (but unfortunately no one has reached out to me to do).

Maybe try to start with allowing voluntary donations? E.g using something like https://gratipay.com/ or just PayPal.

[anthonycr]

That's horrible. I don't have 100% trust in security of servers of random startup.

I completely agree I don't trust some random startup with executing code into an app. They are very privacy focused, but I think the fact that that executing JS in browser that they retrieve from their servers is not acceptable.

I don't like the idea of deeply, non-removable integration with some commercial, closed-source, this-month-trendy service.

This is a very good point, although if this was something more useful like lastpass or 1password I might disagree.

Kinda wish some others could have spoken up for/against here, but anyway, I am leaning heavily toward not integrating this sdk (almost concluded this as i wrote the issue). If the SDK is standalone and does not involve JavaScript injection which I was lead to believe it does, then it is 100% out as that is a huge security issue. I am going to clarify how the SDK works and unless it works much differently then I will close the issue and move on.

[anthonycr]

I could always add it in as an opt-in option... assuming their SDK won't be running without being initialized. I will find out.

[schiegl]

Although I am not exactly a contributor, I hope I still can share my opinion.

I'd much prefer to add some sort of password manager.

I do as well.. Furthermore the main incentive for Lightning, for me at least, is to have a quick browser (Firefox is too heavy) that focuses on privacy and openness. Which fillr doesn't seem to value as much.

[3000]

Hi Anthony! I'm the dev lead on Fillr and would like to chuck in my 2 cents worth if possible.

You are being very thorough and reasonable in evaluating Fillr and i have plenty of respect for that.

I thought i would go ahead and submit a pull request for the Fillr integration as it would help with a few of the questions you and your users have raised. I'm hoping it will help with the privacy concerns, the question around your effort, the opt-in option, and demonstrate a bit of openness from Fillr.

This is the pull request: https://github.com/anthonycr/Lightning-Browser/pull/341

Firstly the privacy concerns, and I can completely understand users not wanting random startup downloading and running javascript. When we built the SDK we had to balance the benefits of providing users with the latest filling accuracy against the potential privacy concerns. Given that when we made that design choice we were making multiple updates to the widget daily to improve accuracy in large jumps, the default was to download the widget.

The pull request has the variation of loading the widget resource from local assets. The JS source is minified but you can at least see that there are no external resources loaded and nothing malicious. The script simply collects metadata about the form, passes it to the app, and then receives data to fill from the app. It runs very fast and it does not affect a user's browsing experience in any way.

As of version 1.4.0 of the widget we are at about 95% filling accuracy so the regular widget updates with big accuracy gains are probably going to be rarer, and a library update might become the default.

As far as our overall stance on privacy, i can tell you and other users that we have a pretty significant track record with privacy sensitive applications. In the Fillr case, I sleep very well at night knowing that i don't and never will have to handle anyone's personal data, as we never ever see it. It never leaves the device via the Fillr app. We are a small well funded team so our preferred business model is evolving as we grow our userbase and learn. But i can tell you this; the model will never involve mining or selling user's personal data.

We have been so privacy focussed in fact that we intentionally haven't put password filling in our app while we worked through the initial startup phase. We are currently proceeding with password filling features though so stay tuned for that. We'll always be a form autofill solution rather than trying to compete with the other password managers, but i feel like our password offering will hold its own.

Hopefully the pull request answers a few of the questions raised but let me know if there is anything further i can do to help out!

[alt-grr]

Hopefully the pull request answers a few of the questions raised but let me know if there is anything further i can do to help out!

@3000 I would be nice if your PR also don't break the tests. And if all Fillr integration would be disabled by default.

[3000]

@kuc yep i will touch it up in the morning, time got away from me today :+1:

[JonasCz]

My $0.02: If you do do this, have it off (like really off, so that the SDK does not load) by default.

My concerns:

• Privacy: I don't like the idea of my personal data being sent off to somewhere obscure, as others also mentioned. I also don't like the Idea of an app downloading and running random, potentially untrustworthy code off the internet. Also, if Fillr is pushing this as a possible monetization opportunity for Lightning, surely they must be making money out of my data somehow. How ?
• Also, what is the performance of this ? I love Lightning because it is lightweight and fast, how would the injected JavaScript impact the performance ?

Also, (dumb question), is the SDK open source ?

[3000]

@JonasCz Hey Jonas! As stated above, Fillr never ever see your data. It never leaves the device (until you submit it in the web-form you fill). You can verify this by sniffing the traffic out of the app when you use it. The only data Fillr captures is your email address on sign up and even that is not tied to a device or account id, its simply used for comms from Fillr and Fillr only.

The javascript does not impact performance in any noticeable way at all. It is only called when you tap the autofill button. The Fillr JS widget only resides in a window property and does not bind itself to the DOM in any other way prior to a fill by the user, and after a fill only in very specific circumstances do we leave anything attached to the DOM (and even this is a tiny listener on a single field with almost 0 overhead).

The Android SDK is apache licensed, the JS widget is proprietary.

Hope that helps!

[JonasCz]

@3000

My bad for skimming things and not reading them.

However, nothing prevents your injected JavaScript from sending data somewhere, should you decide to do this in the future, right ?

I don't want to be mean, but I don't really like the idea of some obscure company having access to all of my data. (And this includes everything I ever type into a webpage, passwords, browsing history of those pages where your script runs, cookies, and other stuff)

You may not be collecting this data now, but can you guarantee that you won't do so in the future ?

If this is implemented as a completely OSS library, with no additional code being downloaded and run, I would probably like it, but this way, no.

Also, from your terms:

The Company may amend, replace or add to these terms and conditions at any time. The Company will notify you of this by:

(a)    posting information on the Fillr website at https://www.fillr.com/terms-app; or

(b)    written or electronic notice to you (including via your Mobile Device).

(emphasis mine)

So, if you decide to start collecting and selling my data and change the terms accordingly, you only have to write something on your website (Which I will probably not look at regularly) and then you can change your JavaScript code and just start using my data ?

Oh, and from a brief glance through your PR, it seems like the Fillr SDK always loads, and only then is it enabled / disabled used on the user preference. Does this mean that your JavaScript can run at any time, even if Filler is disabled ?

[3000]

@JonasCz

In answer to your second question, i feel like you have 2 guarantees that Fillr will never collect your personal data: one from me (Fillr) saying it's not even on the radar as a business model for us, and another assuming Anthony is never going to merge in a pull request from Fillr containing anything resembling code to post personal data anywhere.

That in part addresses your first question as well; given Lightning is a public repo and the widget JavaScript is a part of the pull request, it would be very hard for Fillr to slip a change through un-noticed that begins to post personal data back to our servers.

I fully understand that words from 'random startup' don't carry much weight as far as a guarantee, but given that it has been publicly stated we don't collect/sell personal data, i think we can all see how that would not work out well for Fillr if we decided to go in to that business.

As far as the OSS question, just about all the SDK code is OSS. It's all Apache licensed except the JS widget. Having said that the JS widget in full is included in the pull request, so it's there plain as day to analyse and see that there is no call (or even a URL endpoint from memory) to any remote service.

As far as the terms, i think that clause is pretty standard across services. IF we were to make a big change to the terms of service then it carries provision (b) to notify users via email. Again i'm pretty sure that would be a bad move to try and slip a huge change like beginning to sell bulk data through to the keeper. I'm pretty sure no one wants an email every time we fix a typo on the terms so its a reasonable compromise.

On your last point: no if the SDK is disabled, the JS does not get injected in to the page. I would consider it a bug if that is happening.

In summary:

• Collecting or selling personal data is not our current business model
• Collecting or selling personal data is not our future business model. (In fact i can't remember that option ever even being considered or spoken of in any way for Fillr and i've been here since the beginning). We are 100% focussed on privacy and security for users.
• Fillr as a business never even sees your data. It only lives on your device and we don't have access to it at all. At the moment we don't even allow you to sync your profile between devices, so there are just no scenarios where your data hits any of our APIs in any form.
• All the code for the Fillr integration is there in the pull request to vet publicly. If you are still worried about what data Fillr sends to remote services, go ahead and proxy your phone traffic through Charles/mitmproxy/Fiddler as you make a fill and examine.

And no malice taken! Your core concern is clearly trust, and that can really only be built with time and transparency, so i'm happy to answer any questions here on Fillr while the opportunity is available.

[leonghui]

@3000

Collecting or selling personal data is not our future business model.

There is no guarantee that your T&C and business model will never change given the volatile nature of startups.

I read up on Fillr and its past as Pop!. I also did a quick diff between Pop!'s and Fillr's privacy policies and some of the changes are troubling. I am not a developer, but I use Lightning daily. I have some questions:

1. Will Lightning users be subjected to "third party services" and mobile analytics as stated in the new privacy policy?
2. Will Lightning users have their device IDs being sent to Fillr servers? https://github.com/3000/Lightning-Browser/blob/feature/fillr-integration-dev/FillrSDK/src/main/java/com/fillr/browsersdk/utilities/FillrUtils.java#L61
3. Will Lightning still work on devices without Google Play Services (many low-cost tablets, including Amazon Fire devices)? https://github.com/3000/Lightning-Browser/blob/feature/fillr-integration-dev/.travis.yml#L11
4. If Pop! failed due to the lack of businesses adopting the Pop! code (and therefore being charged a fee), what makes Fillr different?
5. Could you please consider forking Lightning for Fillr's users instead?

@anthonycr Is it possible to split the release such that the Fillr SDK (and therefore remote JS injection) will never be executed (e.g. Lite, Plus, Lite with Fillr, Plus with Fillr)?

What is your stance and direction on privacy features in Lightning? While I very much appreciate the privacy-focused efforts (Tor/Orbot integration, removal of tracking headers), integration with Fillr (or any other closed-source, proprietary 3rd parties) seems like a major step backwards.

[3000]

Hey @leonghui!

All fair questions!

Im kind of glad you found Pop! as it shows we've had a similar privacy focus since well before Fillr. In the end we pivoted to Fillr to focus on the autofill tech we originally had in Pop. You'll notice though, that instead of compromising our core value of a secure and private data wallet, our core principle of user privacy has been persisted through both products. I hope you can see how privacy for users has been paramount for us all along - not just with Fillr, and that this is a value we have held and demonstrated for some time, and have no intention of changing.

I think an unwavering pattern of behaviour and a public declaration are about as good a guarantee as you are going to find surely!

1) I'm not sure if Anthony will look/need to change the Lightning terms; as you should be able to see in the pull request, the SDK does not inject any mobile analytics in to Lightning at all.

Once a user is within the Fillr app, they will naturally be subject to the Fillr terms.

Fillr use Google Analytics within the Fillr app to do standard things like report on the core funnels and abandonment points so we can improve the UX on the app. There is no PID collected here.

Im comfortable with our privacy practices but if you feel we need to modify im happy to look at a set of terms you find most satisfactory for a startup business that is looking to do the right thing as well as learn from their users usage patterns to improve product.

2) So thats a firm no, device ids are not sent to Fillr.

You'll notice getDeviceId is not called from anywhere. The method is used in one of our internal builds of the Fillr SDK that we use for A/B testing. The device id is simply used to make sure a user gets assigned to the correct AB testing variation consistently. We use Mixpanel for AB testing but i know of only one commercial browser that uses this test version of the Fillr SDK.

3) Yes. Google play services is only needed in our internal/testing version of the SDK. I have removed the repo reference from the travis config.

4) The user growth for Fillr has been amazing. Pop growth was ok, but not enough to get the required enterprise integrations across the line. Hence we pivoted.

Fillr - a much more focussed product - has significant value to users standalone.

Fillr also has clear value to browsers that lack an autofill feature, and this is why we have seen dozens of integrations in to mobile browsers recently.

So from the business perspective (which is where you are asking from), uptake, usage and retention so far are the key differences. And users as you may well imagine make a large amount of difference when asking a business to partner.

Fillr will likely not be going back to the 'pop code' model, but we do hope that business will find value in Fillr's ability to streamline their mobile conversions through integrations (particularly multi-page forms. Think 1 click checkout but not just for ecommerce). The gap between rates of mobile browsing and rate of transacting on mobile is still huge, so we think there is value in Fillr for business there that we can unlock. But again, i can't stress enough that nothing will ever involve collecting user data for sale.

5) We would rather focus on creating the best autofill than maintaining a browser and take users from Lightning.

From my reading of the comments here so far people have concerns, but that those concerns have either been directly addressed, or are based on hypothetical scenarios. If Anthony doesn't see the value in autofill thats completely cool, we can focus on other opportunities, but it seems given the issue is still open that there is some support for the feature being available to Lightning users.