If running NewRelic (with and without Realtime User Monitoring) what do I need to state in a privacy policy on a website for users? ie what information is collected, what cookies (if any) are set. Security of their data, aggregate vs individual.
New Relic has doc covering these issues in some detail. You can read specifically about Privacy with real-user monitoring, What types of cookies New Relic sets, and some broader information about security and privacy.
The gist, I think, is given in the Real User Monitoring article:
New Relic's Real User Monitoring (RUM) feature details the time it takes for your users' browsers to load your webpages, where they come from, and what browsers they use. To protect your web application's security and your users' privacy, New Relic only collects performance data with RUM. New Relic does not collect any data used or stored by the monitored app.
The data collected from your application server might also capture user data in the form of transaction traces. You can use obfuscation to block user data from appearing in your traces.
Note that both RUM and transaction traces are optional features.
For further details about privacy, I'd recommend contacting New Relic directly.
Related
My organization set up Cloud SQL as the default for Google App Maker about one month ago. In the last week, we have been unable to preview or publish apps that use Cloud SQL data sources, including the sample applications which worked perfectly before. The failure occurs during the authorization process. When previewing or publishing an app, Google App Maker displays a dialog stating "Deploying this app requires authorization". Next it prompts the user for their Google account and then requests approval for the necessary authorizations (e.g., "Manage the data in your Google SQL Service instances"). After approving the authorization, the prompts to authorize begin over with the dialog stating "Deploying this app requires authorization".
Observations:
We have repeated this problem on multiple different computers, networks, and four different user accounts.
In the SQL cloud console, our Cloud SQL instance shows new databases being created for each app along with new database-specific user accounts
All of the databases appear as expected when I log directly into the Cloud SQL database using phpMyAdmin
Other apps which don't use a Cloud SQL datasource work fine, including an app that uses a calculated data source which is hosted in the same Cloud SQL instance
The only errors in the Stack driver logs for the Cloud SQL database showed "INFO" level communication errors with the database (aborted connection...Got an error reading communication packets)
I'm unable to find Stack driver logs for the apps because I cannot preview or publish them (either option would provide a link to the Stack driver logs)
There are now approximately 20 databases in our SQL instance (mostly associated with simple app tests) and we have only used 1 GB of 10 GB of space in our SQL instance
I haven't seen any related problems on the Google Issue Tracker for Google App Maker
I'd appreciate any help or suggestions on what to check in order to resolve this issue.
I posted an issue to Google Issue Tracker and Google corrected the problem. They also provided a workaround if this problem happens again.
Here is the response from the Google development team posted on Google Issue Tracker: https://issuetracker.google.com/issues/145345198
It's great to hear your up and working again! We are aware of this issue and are working through a longer term fix. The specific bug appears to be related to some changes made in the Google Cloud session policy control that may have rolled out to your domain recently interacting with AppMaker in a way that was not expected. We've spent time diagnosing the underlying issue and we beleive we know the root cause. I suspect your domain admin did a version of the workaround below.
Without getting too far into the details, the specific bug is that for a Deployer of an AppMaker application, if the Google Cloud Session policy is set with any expiration time, the returned token AppMaker sees is invalid, triggering a loop in AppMaker trying to generate a valid security token. Historically, these session tokens never expired but recently there was beta feature launch that allowed domain admins to set them to expire. We strongly suspect your domain recently set this expiration policy explicitly and that's what is causing the bug.
The good news is that these policies are overridable per Organizational Unit and we have tested that OUs which have the original classic Never Expire setting do, in fact, allow AppMaker to work.
My suspicion is that your domain admin has reverted recent, local changes to your organizational policy under the admin.google.com console, specifically under Security > Google Cloud session control (Beta).
If this happens again, here the workaround we would recommend. Note you don't need to do this if you're currently up and working. You will need the help of someone with admin.gogole.com powers, specifically User and Organizational Unit powers at your organization. It is a slight increase in security risk but it restores some classic behavior that was standard until recently.
The summary of the workaround is to override the Google Cloud session control expiration setting such that individuals who need access to AppMaker deployments can have it. To mitigate systemic security risk, this is best done by creating a limited purpose Organizational Unit with just that setting different than the parent OU settings.
The workaround is to:
Contact someone in your domain with Admin powers for your Google for Business license.
Have your admin proceed to https://admin.google.com. The actions below need to be performed by a domain admin.
Under the Users section, identify the specific user account that needs the ability to deploy AppMaker Apps.
Identify the Organizational Unit of that Appmaker dev user and make a note of it.
Under the Organization Units settings, locate the Organization Unit you identified above.
Create a new Organization Unit underneath that user's current Organizational Unit with some descriptive identifying it as special w.r.t AppMaker. So for Developers, make something like DevelopersWhoAreAlsoAppMakerDevs.
Back under the Users tab, locate the user from step 3. Move this user into the new Organizational Unit you've just created. This change can take a while to propagate.
-Interlude- At this point, you've made a new Organizational Unit for just that individual and added them to it. You can certainly add multiple people to that OU, especially if they're already in the same parent OU. Use your discretion as to what amount of Organizational rework you wish to pursue. You may not be using OUs at all or you may decide to just turn off this control for the whole domain. It's up to you.
Under admin.google.com's Security settings, locate the Google Cloud session control (beta) settings.
Under this panel, from the dropdown menu on the left, locate the Organization Unit you just created.
Be sure to select ONLY the OU you intend to change.
Change the "Google Cloud Console and Google Cloud SDK session control" from expiring to "Session Never Expires".
Save your changes.
The account you selected in step 3 should now be able to deploy AppMaker apps.
It appears this OU change is only necessary for the deployer of an AppMaker app, not an individual user. Note also that if you have multiple AppMaker developers who all have different current OU settings, you may need to create multiple daughter OUs to avoid a sudden radical shift in OU settings for an individual account.
I'm building a shiny app where users upload transaction data to get access to an analytics dashboard. Can I assure these people that their data is secure from sniffers/hackers and will be removed from the shiny server when their session expires? How does this actually work in Shiny? (Note that I'll be hosting my app on shinyapps.io)
This is not to do with shiny, but whatever server you're storing the data on, how you're using encryption/hashing, and software/app security methods you've used to protect against specific vulnerabilities.
Having said that, here's the (rather minimal, IMHO) security statement for shinyapps.io:
shinyapps.io is secure-by-design. Each Shiny application runs in its
own protected environment and access is always SSL encrypted. Standard
and Professional plans offer user authentication, preventing anonymous
visitors from being able to access your applications.
I would say that the burden will heavily fall on you to use good encryption and data storage practices.
There are many official and unofficial guidelines you can look to for guidance on data storage. One which big companies, particularlly companies going public, must follow is Sarbanes-Oxley.
From grtcorp.com:
The Sarbanes-Oxley Act (SOX Act) was passed by Congress and signed
into law in 2002 in response to major cases of financial fraud, of
which the rise and collapse of Enron is the best known. The overall
focus of the measure is on financial reporting responsibilities, and
ensuring that financial audits are genuinely independent.
However, SOX also includes provisions that relate to the security and
preservation of financial data. And the standards set out for its
implementation "recognized that senior management can't just certify
controls ON the system, these controls also have to control the way
financial information is generated, accessed, collected, stored,
processed, transmitted, and used through the system."
Senior management is thus held ultimately responsible for financial
data security, including putting in place appropriate controls and
procedures to ensure this data security. The good news is that
powerful tools, including data discovery and Data Masking, are
available to meet these standards.
I would also encourage you to familiarize yourself with OWASP's list of the top 10 major web app vulnerabilities:
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
I am about to submit an app to the Apple AppStore built in Swift that uses Crashlytics to capture crash information. As users of Crashlytics know, some information about usage, duration, crashes, etc. is captured and stored on the Crashlytics servers. My application does not ask for, store or attempt to capture any user data.
My question is about the privacy policy for my application. Since I don't capture any user data, I want to state that in my privacy policy but I'm not sure that's factual since I am using Crashlytics. Any feedback on people that have used Crashlytics in their app and have an actual privacy policy?
Thanks
--Vinny
Quick answer: yes, you need that privacy policy. There are ways to get it done fast, too.
Longer answer:
Third parties (here Crashlytics)
When dealing with a third party service like this, often a quick look into their legal documents will help (for Crashlytics in this case as described in your question).
(...) At all times during the term of this Agreement, Developer shall
maintain a privacy policy (a) that is readily accessible to users from
its website or within its online service (as applicable), (b) that
fully and accurately discloses to its users what information is
collected about its users and (c) that states that such information is
disclosed to and processed by third party providers like Crashlytics
in the manner contemplated by the Services, including, without
limitation, disclosure of the use of technology to track users’
activity and otherwise collect information from users. (...)
And
Developer shall at all times comply with all applicable laws, rules
and regulations relating to data collection, privacy and security,
including, without limitation, the Children’s Online Privacy
Protection Act (“COPPA”). Crashlytics may, at its sole discretion from
time to time during the Term of this Agreement, audit Developer Data
to verify compliance.
Crashlytics is actually being unusually vocal about this topic.
The App Store
At the time of writing (and since iOS8) Apple requires privacy policies for 5 categories:
Kids Category, HomeKit, HealthKit, Apple Pay, and Keyboard Extentions. Also they require privacy policies for user registrations (more). I can't tell if any of the above for your app is true. Apple still says in their App Store Review Guidelines that you need to be compliant with all applicable laws. This brings us to the third and most important reason.
Privacy related regulations
All of the above is just there because of global privacy regulations, these companies would most likely not care otherwise. As soon as you work with User data you are mostly under an obligation to disclose these facts. It's personal data like names, addresses or the tracking of user behaviour. It's been written at length why analytics services need privacy policies. All of it is more important as soon as you share data and use third party services for it. Mostly the disclosure or some kind of consent is the condition for it's compliant usage.
If you are interested in reading more about the matter in the context of mobile apps I'd suggest any of these documents:
ICO UK
Ireland
USA/California
Canada
Australia
Hope this helps.
(For proper disclosure: I do some work for iubenda, a tool that helps creating privacy policies for apps and websites)
Vinny, I think it's not mandatory (I've seen apps using Crashlytics wihtout a privacy policy), but it's recommended to have transparency in the communications with your users.
Crashlytics already has a privacy policy so you can just use that policy and add a statement informing that you are not collecting any sensitive information from the user, such as email or phone number.
I am new in programming ,specially in web base programming. i want to learn best practices about state management techniques. I mean
when we have to create sessions?,
when to use sessions how to check null sessions? ,
when to use cookies ?
when to use hidden fields ?.
what are differences between all ?
which technique to use at certain time ?
how application may get crashes due to unsuccessful state management?.
which things we need to keep in mind about state management when we are developing the web applications...???
there so many questions . perhaps you guys known . please help me out to sort my confusion .
Thanks in advance !
http://www.thedevheaven.com/2012/05/state-management.html
State management is the process by which you maintain state and page information over multiple requests for the same or different pages.
Types of State Management
There are 2 types State Management:
Client – Side State Management
This stores information on the client's computer by embedding the information into a Web page, a uniform resource locator(url), or a cookie. The techniques available to store the state information at the client end are listed down below:
a. View State – Asp.Net uses View State to track the values in the Controls. You can add custom values to the view state. It is used by the Asp.net page framework to automatically save the values of the page and of each control just prior to rendering to the page. When the page is posted, one of the first tasks performed by page processing is to restore view state.
b. Control State – If you create a custom control that requires view state to work properly, you should use control state to ensure other developers don’t break your control by disabling view state.
c. Hidden fields – Like view state, hidden fields store data in an HTML form without displaying it in the user's browser. The data is available only when the form is processed.
d. Cookies – Cookies store a value in the user's browser that the browser sends with every page request to the same server. Cookies are the best way to store state data that must be available for multiple Web pages on a web site.
e. Query Strings - Query strings store values in the URL that are visible to the user. Use query strings when you want a user to be able to e-mail or instant message state data with a URL.
Server – Side State Management
a. Application State - Application State information is available to all pages, regardless of which user requests a page.
b. Session State – Session State information is available to all pages opened by a user during a single visit.
Both application state and session state information is lost when the application restarts. To persist user data between application restarts, you can store it using profile properties.
Advantages
Advantages of Client – Side State Management:
Better Scalability: With server-side state management, each client that connects to the Web server consumes memory on the Web server. If a Web site has hundreds or thousands of simultaneous users, the memory consumed by storing state management information can become a limiting factor. Pushing this burden to the clients removes that potential bottleneck.
Supports multiple Web servers: With client-side state management, you can distribute incoming requests across multiple Web servers with no changes to your application because the client provides all the information the Web server needs to process the request. With server-side state management, if a client switches servers in the middle of the session, the new server does not necessarily have access to the client’s state information. You can use multiple servers with server-side state management, but you need either intelligent load-balancing (to always forward requests from a client to the same server) or centralized state management (where state is stored in a central database that all Web servers access).
Advantages of Server – Side State Management:
Better security: Client-side state management information can be captured (either in transit or while it is stored on the client) or maliciously modified. Therefore, you should never use client-side state management to store confidential information, such as a password, authorization level, or authentication status.
Reduced bandwidth: If you store large amounts of state management information, sending that information back and forth to the client can increase bandwidth utilization and page load times, potentially increasing your costs and reducing scalability. The increased bandwidth usage affects mobile clients most of all, because they often have very slow connections. Instead, you should store large amounts of state management data (say, more than 1 KB) on the server
follow the links :-
Client - server difference in state management:
http://www.techbaba.com/q/858-difference+clint+side+management+server+side+management.aspx
http://www.dotnetfunda.com/articles/article61.aspx
Caching best practices :
http://msdn.microsoft.com/en-us/library/aa478965.aspx
state management Best practices :
http://msdn.microsoft.com/en-us/library/z1hkazw7.aspx
Use state management techniques in c# :
http://www.c-sharpcorner.com/UploadFile/freelance91/ASPNETstatemanagementtechniques01012007212655PM/ASPNETstatemanagementtechniques.aspx
Sounds like you should just need to do some reading.
Pro ASP.NET - This book has a chapter about state management, but I am betting the rest of the book would be helpful to you as well since you are a beginner.
Also, MSDN has some good information about state management and when to use what.
My company is building an ASP.NET HR application and we have decided to create one database per client. This ensures that clients cannot accidentally view another client's data, while also allowing for easy scalability (among other benefits, already discussed here).
My question is - what is the best way to handle security and data access in such a scenario? My intent is to use a common login/account database that will direct the user to the correct server/database. This common database would also contain the application features that each user/role has access.
I was not planning to put any user information in each individual client database, but others on my team feel that the lack of security on each database is a huge hole (but they cannot articulate how duplicating the common access logic would be useful).
Am I missing something? Should we add an extra layer of security/authentication at the client database level?
Update:
One of the reasons my team felt dual user management was necessary is due to access control. All users have a default role (e.g. Admin, Minimal Access, Power User, etc.), but client admins will be able to refine permissions for users with access to their database. To me it still seems feasible for this to be in a central database, but my team doesn't agree. Thoughts?
We have a SaaS solution that uses the one DB per client model. We have a common "Security" database too. However, we store all user information in the individual client databases.
When the user logs into the system they tell us three pieces of information, username, password and client-id. The client-id is used to lookup their home database in the "security" database, and then the code connects to their home database to check their username/password. This way a client is totally self-contained within their database. Of course you need some piece of information beyond username to determine their home database. Could be our client-id approach, or could be the domain-name requested if you're using the sub-domain per client approach.
The advantage here is that you can move "client" databases around w/out having to keep them synced up with the security database. Plus you don't need to deal w/cross-db joins when you're trying to lookup user information.
Update: In response to your update... One of the advantages to each customer having their own DB is also the ability to restore a customer if they really need it. If you've split the customer's data into two databases how do you restore it? Also, again, you'll need to worry about cross-db data access if the users are defined in a DB other than the home DB.
I've always been of the opinion that security should be enforced at the application level, not the database level. With that said, I see no problem with your intended approach. Managing accounts and roles through a central database makes the application more maintainable in the long run.
You may want to look into using the ASP.NET membership provider for handling the authentication plumbing. That would work with your stated approach and you can still keep all of the authentication data in a separate database. However, I agree with Chris that keeping one DB will utlimately be more maintainable.