We appreciate the good luck! We're definitely going to need it. I spoke to the security side in a previous comment, but here's some thoughts on the other points you mentioned:
* A/B testing: We're grabbing the browser session data, which includes things like cookies and local storage. In our experience, this tends to be where A/B testing group identifiers are stored. But, if it was on something like the IP, then, yeah, it is pretty hard for us to get around.
* Extensions: Yeah, this is a really tricky one. We've resorted to asking some of our more active customers, who've had these issues with content blockers, to use a separate browser profile. One thing we do for this (which also can help solve the first point) is what we call "smart capture", in which we capture based on a DOM selector, instead of x/y coordinates. That way, no matter the page layout, we get it right. The hard part of this, though, is this is not reliable on every site, and we've only enabled it on sites that we know it works well on.
* Networking/auth issues: This is a really fun one! I mentioned it in another comment, but we're doing some logic around detecting logged out state, with an image classification model, and checking the HTTP status code for resource requests. When we can detect it, we send the user an email, and give them a flow where they log back in, and allow our extension to capture the state data again. On networking, we can't get around things like corporate intranets of course, but these seem to be rare for our customers. We also will just retry the capture if there's a network error, and we notify people when there are errors, so they can take action accordingly.
There is a payment provider in Europe that has become rather popular, who implement "instant" payments by asking for your online banking credentials... Security best practices always go out the window when they interfere with the business case.
Correct me if I’m wrong but this is disallowed by many end sites eg Google and circumvents oauth/any real security. If your very new business was hacked in any way you’d be solely on the hook for the massive damage a bad party could do with such an elevated session with no real boundaries.
Cool idea, but I fail to see how this is 1) legal under many ToS’s and 2) not just a dangerous XSS attack waiting to happen.
You've got it right! The KMS keys used to encrypt sensitive data are generated per customer, and the majority of our engineering team cannot access any sensitive production data at all. In theory, it would only be the select team members with privileged access that could access it, but as you mentioned, it would be logged in CloudTrail. We also have GuardDuty enabled, and it would likely alert on anomalous activity.
Personally, I think we could do a better job explaining our security model in our FAQ. I'll bring it up with the team.
Thank you! We actually do have the functionality you're mentioning. We call it "Smart capture": https://guide.plusdocs.com/snapshots-and-pages/snapshots/sit... Right now, we've only enabled it on sites where it works well, but we're hoping to bring it to more sites soon.
(I'm an EM at Plus) Yeah, we think about the permissions/data escape a lot. I'm glad to see others are commenting with scrutiny too. We've put a lot of effort into our security model, since we know that we're handling very sensitive data.
To give a bit of a peek in: All of the session data we store is encrypted with a key unique to each organization, managed through AWS KMS. We've also built a fully event driven architecture, so every action that occurs in any of our services is logged and auditable. Access to our production data is extremely limited, with our default role grants not allowing access to sensitive data at all. (We have an in-app issue reporting tool to let a customer grant us access to debug data)
Overall, our hope is that we can work with IT departments to help them understand how Plus works, and allay their concerns if a company sees value in using Plus. Making sure our security model is top notch is one of the top priorities for our engineering team.
Might be useful when an image url is embedded in another page (like notion for instance), that it become a two-step workflow, so you have to go back to your Plus dashboard and allowlist that specific page that is the requestor.
That way, if someone takes the url of the image and shares it, it doesn't work without the owner allowing it again.
Of course, this isn't meant as a security measure as it would be trivially simple to circumvent, but more of a way of keeping track of the general surface area of how widely shared and image and putting the power in the users hands to reign it in.
As someone in IT, but as a lowly technician, medium and large companies are leaning more and more towards a locked down Microsoft, Google, or Apple platform with managed browsers with extension whitelists, and whitelist allowed OS apps only via MDM.
It's both a tech and management thing. Management likes the control and less risk, and having one console to login to as opposed to 4 makes things easier for IT.
The cases I'm thinking about would more be internal data protections.
I'll give an example:
We have wikis that are internally and externally accessible, with permission systems for internal users and external partner users that carry different restrictions (e.g., VPN concentrator address range restrictions). If someone tries to access a page in the wiki that they don't have access to, the result is the same as if the page doesn't exist. This reduces leakage from link-guessing (I bet there's still a timing side-channel attack). Additionally, if someone builds a page that uses excerpts from pages that they don't have access to, the excerpt will appear blank. This has led to plenty of funny meetings where one party was talking about a status or readout and the rest of the room was deeply confused (due to a lack of access).
This particular wiki is one of dozens of internal tools with similar (but not identical) compartmentalization protections that I use weekly. Unless Plus can safely and securely account for such restrictions, it's going to be a tough sale for us, and limited coverage areas from partial integration would likely leave the tool with usage start-up issues. To some extent this is a classic uncrackable nut, as the most natural approach (integrate with services and systems) isn't entirely under the control of one party. The next left turn is to integrate with popular software/service providers, something they'll resist due to the natural incentive to avoid disintermediation and the high risk of incorporation of other access models.
Maybe in 10 years Plus will have been the source of a comprehensive delclarative permissions modeling system replete with formally verified macro system composition (boil the ocean style), or maybe I'm missing a clever simplifier to address these and other headwinds stemming from business model and tech architecture intersections. Either way, the explainability of the feature and the end-customer simplicity leave me hoping that things work out. It'll definitely be an interesting ride.
Highly tangential to Plus, but this issue is highly prevalent in IT. Usually, no one knows what systems there are and who has access to what. So Plus (or whoever) cannot really solve this problem without providing separate access management tooling
An idea, that you’ve probably thought of, but is it possible to do this without allowing others to update the screenshots? Updating would require the user(s) who produced the document to be logged in to the service.
(I'm an EM at Plus) It's a bit complex, and not quite perfect, but I'm pretty happy with what we've done so far. The first method is by looking at the HTTP status codes. Since we're running a full browser on our side, we can tell if the status codes that returned are different than the initial capture. We also have been training an image classification model on pictures of log-in screens — this has worked surprisingly well, honestly. We've started expanding it to other types of "incorrect" screenshot scenarios as well, like loading screens, and we're seeing some cool early results.
Our product works by taking a screenshot using a headless Chrome instance. In this case, it's helpful because we can look at not just the status code of the HTTP request to the page itself, but also any resources the page may fetch. This is particularly useful for SPAs, since they may return a 200 for the page itself, but an API call they make might return a non-200 when logged out.
Hey, I helped build this! Thanks for submitting this.
I'm an engineering manager at Plus — would be happy to answer anyone's questions about our product. You can also shoot me an email at zach(at)plusdocs.com if you'd like to hear more about what we're up to.
Plus | Senior Software Engineer (Full stack) | REMOTE (US & Canada only) | Full Time | https://plusdocs.com
At Plus, we're building an easier way to capture, see, and share information across different sources — without having to worry about APIs and integrations. We're looking for talented people of all backgrounds to join our fully remote team across US and Canada. We've raised 10M in funding from Madrona, BoxGroup, Positive Sum, and the founders and CEOs of companies like Auth0, Plaid, Evernote, Smartsheet, and Zapier. You can learn more about our engineering culture here: https://www.plusdocs.com/blog/how-we-use-engineering-cycles
We're looking for engineers who are passionate about working on a new product to grow our team. We've hired an amazing team so far, with everyone working on both on the front end and back end. Anyone joining our small team today would be able to contribute to our web app, Chrome extension, third party integrations, and more. We’re in private beta currently, and are working towards improving our app to gear up for a public beta next year. Our stack includes Typescript, Node.js, GraphQL, Postgres, React, and Tailwind. You can view our latest opening here: https://jobs.lever.co/plus/e11c1a8b-98cc-45b9-b23a-39757130c...
I've gotten my last two jobs at Webflow (YC S13) and Lumi (YC W15) because of a Who's Hiring thread, so if you have any questions about why I decided to join Plus, you can send me an email, at zach (at) plusdocs (dot) com.
Plus | Senior Software Engineer (Full stack) | REMOTE (US & Canada only) | Full Time | https://plusdocs.com
At Plus, we're building an easier way to capture, see, and share information across different sources — without having to worry about APIs and integrations. We're looking for talented people of all backgrounds to join our fully remote team across US and Canada. We've raised 10M in funding from Madrona, BoxGroup, Positive Sum, and the founders and CEOs of companies like Auth0, Plaid, Evernote, Smartsheet, and Zapier. You can learn more about why we're building Plus here: https://www.plusdocs.com/blog/why-we-are-building-plus
We're looking for engineers who are passionate about working on a new product to grow our team. We've hired an amazing team so far, with everyone working on both on the front end and back end. Anyone joining our small team today would be able to contribute to our web app, Chrome extension, third party integrations, and more. We’re in private beta currently, and are working towards improving our app to gear up for a public beta next year. Our stack includes Typescript, Node.js, GraphQL, Postgres, React, and Tailwind. You can view our latest opening here: https://jobs.lever.co/plus/e11c1a8b-98cc-45b9-b23a-39757130c...
I've gotten my last two jobs at Webflow (YC S13) and Lumi (YC W15) because of a Who's Hiring thread, so if you have any questions about why I decided to join Plus, you can send me an email, at zach (at) plusdocs (dot) com.
Plus | Senior / Staff Software Engineers | REMOTE (US & Canada only) | Full Time | https://plusdocs.com
At Plus, we're building an easier way to capture, see, and share information across different sources — without having to worry about APIs and integrations. We're looking for talented people of all backgrounds to join our fully remote team across US and Canada. We've raised 10M in funding from Madrona, BoxGroup, Positive Sum, and the founders and CEOs of companies like Auth0, Plaid, Evernote, Smartsheet, and Zapier. You can learn more about why we're building Plus here: https://www.plusdocs.com/blog/why-we-are-building-plus
We're hiring for senior and staff-level engineers to grow our engineering team. We're looking to grow our front-end team, who will be working on our web app, extension, and other integrations. We've launched our private beta and new marketing site, and our first customers are already using Plus every day. Our stack includes Typescript, Node.js, GraphQL, Postgres, React, and Tailwind. Our team includes our VP of Engineering who joined us from Tableau, and engineers from Microsoft and Webflow. You can view all of our positions on our careers page: https://www.plusdocs.com/careers, and apply for the position you're interested in there. I've gotten my last two jobs at Webflow (YC S13) and Lumi (YC W15) because of a Who's Hiring thread, so if you have any questions about why I decided to join Plus, you can send me an email, at zach (at) plusdocs (dot) com.
* A/B testing: We're grabbing the browser session data, which includes things like cookies and local storage. In our experience, this tends to be where A/B testing group identifiers are stored. But, if it was on something like the IP, then, yeah, it is pretty hard for us to get around.
* Extensions: Yeah, this is a really tricky one. We've resorted to asking some of our more active customers, who've had these issues with content blockers, to use a separate browser profile. One thing we do for this (which also can help solve the first point) is what we call "smart capture", in which we capture based on a DOM selector, instead of x/y coordinates. That way, no matter the page layout, we get it right. The hard part of this, though, is this is not reliable on every site, and we've only enabled it on sites that we know it works well on.
* Networking/auth issues: This is a really fun one! I mentioned it in another comment, but we're doing some logic around detecting logged out state, with an image classification model, and checking the HTTP status code for resource requests. When we can detect it, we send the user an email, and give them a flow where they log back in, and allow our extension to capture the state data again. On networking, we can't get around things like corporate intranets of course, but these seem to be rare for our customers. We also will just retry the capture if there's a network error, and we notify people when there are errors, so they can take action accordingly.