(no title)
remixz | 3 years ago
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|3 years ago
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.
rejectfinite|3 years ago
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.
Guillaume86|3 years ago
chaboud|3 years ago
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.
friendzis|3 years ago
twobitshifter|3 years ago
app4soft|3 years ago
> Source: <URL/WebsiteName>, <AccessDate>