It also circumvents 2fa, because sessions are leaked to Plus after you've used your TOTP code or Yubi key. How can any business be OK with this??
First step is probably "don't look too closely" (:
I agree though — I would not want this thing doing who-knows-what-unverifiable-fiddling with my data and credentials.
So I wish the team good luck, and especially with issues like:
* A/B testing. How can you ensure that what your clients are seeing is the same thing you are seeing? Maybe you've been assigned to different A/B groups.
* Extensions. What if your clients are using Chrome extensions that affect how the page is rendered? How can you replicate that?
* Networking/auth issues. What do you render if you're unable to connect or log in?
* 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.
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 should not rely on anything on the client side, just accept the fact you don't control the code that is run there.
If you care about a few cases like adblockers, just test them in a headless browser.
Do not know how much money it brings in though.
Fakespot and Bubbles have raised millions. Will see how they go
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.
Very slick, though.
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.
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.
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.
Just a general comment.
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.
> Source: <URL/WebsiteName>, <AccessDate>
B/c I feel like that is super common and kind of impossible to stop with a permissions approach.
When you take a screenshot, its contents are known and fixed.
When you regularly and automatically refresh a screenshot of a particular x/y coordinate part of a specific screen on a website, what happens when "positive customer interactions" gets moved, and "internal notes on this customer, not for sharing with them" gets put in that spot?
In other words, if Plus becomes popular, its database will become a prime target for hackers and three letter agencies.
What this means is that (whether now, or with an update that could easily slip the notice of Chrome Web Store auditors) Plus could direct your browser to take these actions on a domain where you had never explicitly told it to take a screenshot, using not only the credentials from when you installed Plus but whatever credentials exist on an ongoing basis.
Of course, this is also true of any extension that you grant permission to access all websites. But Plus has already shipped the code to access the DOM of arbitrary tabs already loaded in everyone's browser, and communicate that information to the cloud, without an auditable open-source core. I have a lot of trust, for instance, that if uBlock Origin were to start sending my data to the cloud, someone would post about it on HN. An attacker with the ability to send updates to the Chrome Web Store as Plus, and operate Plus servers as command-and-control servers, could do this a lot more subtly, and that's definitely a yellow flag.
The example video shows him taking a screenshot of an Amplitude dashboard using a browser plug-in. Thinking about how that’s possible, it must be skimming the session cookie off the browser, and using it to request the same page on Plus’s side to generate an image. You can imagine how that might be compromising.
Edit: you log in within the plus web app itself, which feels a little better. Still no totally secure way to do this but seems really useful.
Arc browser https://arc.net/
Basically, it lets you select a range on a worksheet, and then shows a live updating picture of that range in a new region (possibly in a different sheet). Why is that useful? Well, the range can contain charts in addition to just cells with data. It can be handy to have the charts actually defined in the sheet where the data is stored, so that let you do this while still displaying the chart in the sheet where you want to show it.
Free to use for now.
Was it an intention to make the design similar to https://gumroad.com/? Or am I the only one seeing an uncanny resemblance?
We were looking for something that felt approachable and fun, magical but not mysterious. After trying a bunch of different things, this is where we landed.
Also, does anyone know what this new design trend is called? The bordered / minimal-but-not look?
> Today, we encrypt all sensitive data on your computer before it is sent to our servers, your data is encrypted in transit and at rest. Our employees do not have access to the private key to decrypt sensitive data.
I wonder how this works. I assume Plus works by storing the cookies present in the user's browser so that it can inject those cookies in a headless browser to take a Snapshot. In order to do that, it would need to decrypt the cookie (if it was encrypted in the first place, which the FAQ seems to suggest). For that, the headless process needs the encryption key. That would mean that employees can also access that encryption key.
What am I missing here?
I suspect there must be a handful of SREs who, who could access it if they really wanted to - though that access would still be logged in cloudtrail.
Personally, I think we could do a better job explaining our security model in our FAQ. I'll bring it up with the team.
So this is literally a lie?
Anyone do something similar?
Images are great but for doing anything more complex than just viewing charts scraping the data would be a huge plus
Or a probably another common potential use-case... I want to create an alert if a value is above/below a certain threshold.
Apart from the security issues mentioned by others (related to storing user auth/session data), what happens if there's an update to the website/application where the screenshot is being taken from? Or if they add an announcement banner at the top, all content will be displaced.
Truth be told, I have no clue how the live-updating feature works when I share an Easel but it does capture the page as I see it
Edit: It does change on my local "Easel" almost instantly with my reply, but we'll see if that screenshot updates for others. A little experiment, I guess.
However with each version, Apple is killing the original, today's widget this app needs.