The kicker for this is whether the user is in control of the amount of masking going on or not.
If the app maker is in control, and the user can do nothing but use the app or not, then while the new defaults are better than nothing, I will continue to have all known FS domain names blocked on my devices / not use said apps at all.
Can the user permanently set and forget a "I don't care if the devs want analytics, they aren't getting them from me" flag in the app? If yes, good. If yes by default, better.
Can the user see what the analytics wants to unmask? If yes, good. Can they permanently make surgical tweaks to the unmasks to not unmask certain fields? If yes, better and impressive.
Edit: the wireframing and reconstructing from xaml views is quite the technical innovation, better than screenshots indeed.
mmastrac 1479 days ago [-]
We offer a small level of control via the FS.consent API that we have available across platforms (https://developer.fullstory.com/consent), but at this time the app maker is really in control.
I'd love to have us give better controls to end-users -- we're still investigating ways for users to better control things like that on their own devices. The web makes this a bit easier with adchoices (ie: setting cross-domain cookies opting out) and the ability to more easily block domain patterns with browser plugins.
We have an internal team that is dedicated purely to privacy innovation and I'll bring this up with them.
> Edit: the wireframing and reconstructing from xaml views is quite the technical innovation, better than screenshots indeed.
Thanks! This took us a _long_ time to get right, as you can imagine.
Dustie 1479 days ago [-]
Seems simple enough: To turn on any analytics users should be redirected from the app to the webpage. Anyone that doesn't go there and turn it on should have it off no matter what the app developer does. But I'm guessing you don't really want to make it a user choice.
mmastrac 1479 days ago [-]
Hey all - we've been working on a brand new approach to mobile analytics and session capture for the last 4 1/2 years. Our team is ultra-focused on building something that we can be comfortable with using in apps on our own devices and we're very happy with the balance we have struck.
This blog post scratches the surface on the approach we're taking and how we've balanced privacy and fidelity.
The product page has some additional info as well:
Happy to answer any questions about how we are doing this, how we're putting privacy first, or technical questions. Some other folks from the team will be around as well.
ThePhysicist 1479 days ago [-]
How is recording every single user interaction with an app “private by default?” The data is tied to a user ID as far as I understand, so it is personally identifiable information.
I appreciate that you think about privacy but you really can’t call this “private by default” as the amount of information you collect from every user is extensive. Privacy by default requires that you have the user opt in to the tracking (i.e. privacy is the default setting) and minimize information collection, which you really don’t.
If you really care about privacy you should consider going through a formal privacy by design & default process and certification.
lachyg 1479 days ago [-]
There is a demo request form, but no information on whether it's generally available. Is it?
mmastrac 1479 days ago [-]
It is generally available, but we're throttling new customers while we scale up as the privacy features require a slightly higher level of hand-holding (we'd rather launch slower than risk someone accidentally capturing sensitive information).
Sephr 1479 days ago [-]
Apps should prompt me for my permission to share any analytics data if they want to claim that they are "private-by-default". It would be nice if FullStory also provided first-class example UIs to app developers to help them correctly obtain user consent while locally buffering tracking events in the background.
I helped build a product for site owners that automatically quarantines tracking events (including FullStory) for replay with consent at a later time[1]. This product enables sites to include scripts with potentially risky privacy implications like FullStory without ever having to worry about unconsensual PII data emissions. Blog post coming soon!
The documentation doesn't specify this (yet), but no data leaves the device if recording is shut down.
k2xl 1479 days ago [-]
love fullstory - great atlanta company, and i know a bunch of people that work there are stellar! an issue i've had with them is the cost is very high in comparison to other products in the space.
something that is interesting to note is how similar to UI is to their competitor LogRocket. I don't know who copied who (or maybe they both copied someone else?), but the similarities in look and feel were very uncanny
akarma 1479 days ago [-]
LogRocket (~2016) is much younger than FullStory (2012) - as an aside, though, I didn't find their UIs to be that similar.
FullStory feels like its UI has certainly received more thought and care over time, whereas LogRocket is full of lots of new bells and whistles, but they're still sorting out how to put the experience together elegantly. LogRocket has this problem because they're building features so quickly (though I'm sure a couple good UI/UX hires could help with the UI keeping pace with features).
Agreed on price, by the way! We were happy with the FullStory product and don't utilize LogRocket's additional dev tools, but switched to LogRocket due to cost.
necovek 1478 days ago [-]
I love that it starts off with "I've worked with some of the best engineers in the world" — do they really need that much pampering, or is there a ranking list that I missed on?
tedmielczarek 1478 days ago [-]
I dunno, personally I enjoy working with Matt and like that he feels this way about us. FWIW I don't really believe it's even possible to rank people based purely on talent. I worked with some incredibly talented engineers in my time at Mozilla and I came to realize that we all have our specialties and we work best by using our individual skills to work together. (I was a little fanboy-ish about working with Brendan Eich when I started but had my "aha" moment when he started asking me toolchain questions. :)
necovek 1478 days ago [-]
I am happy to hear that: maybe I am just too much of a cynic and appreciate more "real praise" (for particular accomplishments) vs "empty praise" — I understand it could be just me, even in establishing what's real or empty, so whatever works for you :)
wilg 1479 days ago [-]
Finally a privacy-aware digital experience product for mobile apps!
1479 days ago [-]
Rendered at 21:49:24 GMT+0000 (Coordinated Universal Time) with Vercel.
If the app maker is in control, and the user can do nothing but use the app or not, then while the new defaults are better than nothing, I will continue to have all known FS domain names blocked on my devices / not use said apps at all.
Can the user permanently set and forget a "I don't care if the devs want analytics, they aren't getting them from me" flag in the app? If yes, good. If yes by default, better.
Can the user see what the analytics wants to unmask? If yes, good. Can they permanently make surgical tweaks to the unmasks to not unmask certain fields? If yes, better and impressive.
Edit: the wireframing and reconstructing from xaml views is quite the technical innovation, better than screenshots indeed.
I'd love to have us give better controls to end-users -- we're still investigating ways for users to better control things like that on their own devices. The web makes this a bit easier with adchoices (ie: setting cross-domain cookies opting out) and the ability to more easily block domain patterns with browser plugins.
We have an internal team that is dedicated purely to privacy innovation and I'll bring this up with them.
> Edit: the wireframing and reconstructing from xaml views is quite the technical innovation, better than screenshots indeed.
Thanks! This took us a _long_ time to get right, as you can imagine.
This blog post scratches the surface on the approach we're taking and how we've balanced privacy and fidelity.
The product page has some additional info as well:
https://www.fullstory.com/mobile-apps/
Happy to answer any questions about how we are doing this, how we're putting privacy first, or technical questions. Some other folks from the team will be around as well.
I appreciate that you think about privacy but you really can’t call this “private by default” as the amount of information you collect from every user is extensive. Privacy by default requires that you have the user opt in to the tracking (i.e. privacy is the default setting) and minimize information collection, which you really don’t.
If you really care about privacy you should consider going through a formal privacy by design & default process and certification.
I helped build a product for site owners that automatically quarantines tracking events (including FullStory) for replay with consent at a later time[1]. This product enables sites to include scripts with potentially risky privacy implications like FullStory without ever having to worry about unconsensual PII data emissions. Blog post coming soon!
1. https://transcend.io/consent-manager/
The documentation doesn't specify this (yet), but no data leaves the device if recording is shut down.
something that is interesting to note is how similar to UI is to their competitor LogRocket. I don't know who copied who (or maybe they both copied someone else?), but the similarities in look and feel were very uncanny
FullStory feels like its UI has certainly received more thought and care over time, whereas LogRocket is full of lots of new bells and whistles, but they're still sorting out how to put the experience together elegantly. LogRocket has this problem because they're building features so quickly (though I'm sure a couple good UI/UX hires could help with the UI keeping pace with features).
Agreed on price, by the way! We were happy with the FullStory product and don't utilize LogRocket's additional dev tools, but switched to LogRocket due to cost.