5 ms·

This seems like a spectacular way to break permissions restrictions and escape data to non-authorized entities. If it's successful, it's the sort of thing that

This seems like a spectacular way to break permissions restrictions and escape data to non-authorized entities. If it's successful, it's the sort of thing that will be brutally blocked by IT all over the place. Very slick, though.

jszymborski 4y ago
Is it all that much more a risk than taking a screenshot, putting it on cloud storage like OneDrive/GDrive, and sharing with a "anyone who has the link" permission? B/c I feel like that is super common and kind of impossible to stop with a permissions approach.
- ceejayoz 4y ago
  Yes? 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?
  - marktolson 4y ago
    Perhaps they can make it so that the element's XPath / node id is stored and used for capture rather than X + Y coordinates. Still prone to failure I know, but ultimately more reliable.
- croes 4y ago
  One manually taken screenshot vs dozens of screenshot taken automatically
- graypegg 4y ago
  That screenshot possibly becomes outdated the second after it’s snapped. This seems to be able to store session data from the user that took the screenshot, and will happily allow anyone access to view it. 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.
- olalonde 4y ago
  My guess is this works by uploading your browser's data (cookies, local storage, etc.) to Plus so that it can retake the screenshot with a headless browser even if the web page requires authentication. So if someone hacks Plus or if some employee goes rogue, they can potentially access any web app you are taking screenshots of. In other words, if Plus becomes popular, its database will become a prime target for hackers and three letter agencies.
  - blowski 4y ago
    All tech companies, if succesful, will one day be a target for hackers and security agencies.
  - btown 4y ago
    Based on the Chrome extension's minified source code (via https://chrome.google.com/webstore/detail/plus/bnebanooamokkihfjepphafoekheipfh https://chrome.google.com/webstore/detail/plus/bnebanooamokk...), with files like runReloadCurrentSnapshot.js, it seems that Plus's background worker is loading pages (possibly as pop-unders) in your browser as you use it, using whatever your current cookies & localStorage credentials happen to be. 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.
- hnlmorg 4y ago
  A lot of orgs lock down access to cloud storage (eg only company managed OneDrive on company managed devices) to prevent these kinds of data leakage. So they’d block access to this tool too.
- rejectfinite 4y ago
  Well managed companies will use one approved cloud tool like Onedrive or Gdrive and turn that off in permissions if they want. Just like this site will and should be blocked if it gets popular enough.
remixz 4y ago
(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.
- ac2u 4y ago
  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.
- app4soft 4y ago
  Guess, adding source string at the bottom on Plus screenshots might be at least a partial solution: > Source: <URL/WebsiteName>, <AccessDate>
- Guillaume86 4y ago
  Do you support apps that do proper session invalidation (auth cookie can't be reused after the user signs out for example)?
- rejectfinite 4y ago
  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. Just a general comment.

jszymborski 4y ago

Is it all that much more a risk than taking a screenshot, putting it on cloud storage like OneDrive/GDrive, and sharing with a "anyone who has the link" permission? B/c I feel like that is super common and kind of impossible to stop with a permissions approach.

ceejayoz 4y ago
Yes? 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?
- marktolson 4y ago
  Perhaps they can make it so that the element's XPath / node id is stored and used for capture rather than X + Y coordinates. Still prone to failure I know, but ultimately more reliable.
croes 4y ago
One manually taken screenshot vs dozens of screenshot taken automatically
graypegg 4y ago
That screenshot possibly becomes outdated the second after it’s snapped. This seems to be able to store session data from the user that took the screenshot, and will happily allow anyone access to view it. 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.
olalonde 4y ago
My guess is this works by uploading your browser's data (cookies, local storage, etc.) to Plus so that it can retake the screenshot with a headless browser even if the web page requires authentication. So if someone hacks Plus or if some employee goes rogue, they can potentially access any web app you are taking screenshots of. In other words, if Plus becomes popular, its database will become a prime target for hackers and three letter agencies.
- blowski 4y ago
  All tech companies, if succesful, will one day be a target for hackers and security agencies.
- btown 4y ago
  Based on the Chrome extension's minified source code (via https://chrome.google.com/webstore/detail/plus/bnebanooamokkihfjepphafoekheipfh https://chrome.google.com/webstore/detail/plus/bnebanooamokk...), with files like runReloadCurrentSnapshot.js, it seems that Plus's background worker is loading pages (possibly as pop-unders) in your browser as you use it, using whatever your current cookies & localStorage credentials happen to be. 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.
hnlmorg 4y ago
A lot of orgs lock down access to cloud storage (eg only company managed OneDrive on company managed devices) to prevent these kinds of data leakage. So they’d block access to this tool too.
rejectfinite 4y ago
Well managed companies will use one approved cloud tool like Onedrive or Gdrive and turn that off in permissions if they want. Just like this site will and should be blocked if it gets popular enough.

remixz 4y ago

(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.

ac2u 4y ago
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.
app4soft 4y ago
Guess, adding source string at the bottom on Plus screenshots might be at least a partial solution: > Source: <URL/WebsiteName>, <AccessDate>
Guillaume86 4y ago
Do you support apps that do proper session invalidation (auth cookie can't be reused after the user signs out for example)?
rejectfinite 4y ago
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. Just a general comment.