when I’m in a sentry issue description page I can see some information collected by the sentry service and I’d like to avoid collecting them to avoid privacy issues.
The information that I’d like to not see are: app.device and user id as you can see here:
Is it possible? I’m concern about new apple privacy restrictions. I don't know if I understood them correctly, but it is necessary to explain to the user, using a pop up or something similar, that the app is using a third party software to collect data about "app crashing" and "app performance". Giving to the user the possibility to choose to not collect those data would bring to developers a lot of headaches.
I searched in all project settings and documentation but I found only a way to hide certain tags/data but the point is not hiding information, but not collecting them at all.
Thanks
The 'user.id' that Sentry creates is not an identifier that can be used to track the user across apps or devices. It's a random id created when the app runs for the first time and it's sent with all errors that happens.
The sole goal of this ID is to give the developer an idea of how many different users are affected by an issue. The developer (owner of the app) doesn't know exactly who the user is and if that same users reinstalls the app, a new id is generated so technically Sentry would report all new errors as a new user. Which is fine given the goal is to give an approximation of impact of an issue.
Developers might focus on issues that affect more customer than not.
That said, you can strip data in many ways. Through the SDK or in Sentry itself.
If you drop data in Sentry, that is done before the event is written to disk.
Sentry's documentation talks about Scrubbing Sensitive Data here.
Doing it on the SDK side, for example for React Native, you could do:
Sentry.init({
dsn: "https://examplePublicKey#o0.ingest.sentry.io/0",
beforeSend(event) {
// Modify the event here
if (event.user) {
// Don't send user id
delete event.user.id;
}
return event;
},
});
There's also a page talking about Data Privacy in the context of Google and Apple:
https://docs.sentry.io/product/security/mobile-privacy/
Related
First of all this is my 1st stackoverflow post so sorry if I am missing context or do if the question is too out of the ordinary.. Onto some context and example use case for my question.
Context
I'm making a simple app for an uni assignment in React-Native but one of the requirements client we are making it for is that the text (copy) in the app can be adjusted by him after we deliver it to him.
Example Use Case
They want to change the text on the welcome screen from "Welcome, [Name]" to "Hello there, [Name]". But they aren't technical so they expect to be able to change this in a simple UI.
I've tried googling for solutions but keep finding Localization solutions instead and all I've found so far require in-code edits.
Example:
🌍 react-native-localize & Expo Localization Docs
Any help/pointers are much appreciated!
There are two basic ways to solve this issue.
Create an API that the app calls to get the text. Make web or app tools for the client to edit the text in the API. This is usually called a CMS (content-management solution). There are a huge range of options, including building your own.
Pros:
the client can maybe manage their own content without intervention... sometimes
content changes are "instant" - without an app release
Cons:
non-trivial to plan and set up
requires support/maintenance
additional costs for hosting
additional app complexity (need to think about error states, caching, polling?)
app NEEDS to be online to have content
OR
The client submits a ticket for the text changes and a developer makes them.
Pros:
doesn't require the creation/ maintenance of additional tools
app doesn't need to make network requests for content
Cons:
changes take longer and require a new release of the app
I recently asked this question and user's #DalmTo and #Sergio NH they gave me an exhaustive answer for which I thank them very much.
Moving forward to question, we started publishing the application, and its verification was not required, since no scope was added (here it is a little unclear why the requests worked in an application with a test mode in which these scope were not added (google drive, google sheet and google ads)).
However, this time the application in the "In Production" mode began to give us an "Unverified app screen" (see Unverified app screen). We decided that we still need to add scope to the list, and, of course, that the scope list (their list is described above) requires verification by Google.
We started filling in the necessary fields, while studying the Google documentation at the same time, and came across the following information (see block Verification process -> What are the requirements for verification?):
Apps not applicable for verification
Apps for internal use only
(single domain use) Apps for personal use only Apps that are Gmail
SMTP plugins for WordPress Apps that are in development or
staging/testing
Apps for personal use only
And this is just our case: we have already received permission from Google Ads and are just generating simple reports that we want to integrate with Google Sheet. I.e., this is an elementary script that works within this account (however, we still need to request the first concert screen, even for this developer account) and cannot be distributed to any other accounts.
But when adding our scope, Google requires us to pass verification, forcing us to fill in the required fields, in the form of domains and their verification via the Search Console (we have already done this and this stage does not cause difficulties) and links to Youtube videos - where we must show how scope is used.
And just this stage is not clear. We do not allow other people's accounts to connect to this application, and the software does not have any interface, it is just a script that receives data from Google Ads and saves it to Google Sheet (creating a file via Google Drive). We have described all this in the scope usage description field. But the link to the Youtube video is require field, and we sincerely do not understand why (considering our case) we should record something, and most importantly, what exactly we should record in this case. If the documentation itself says that in our case we do not even need a verification.
Maybe we did not understand something and now we are doing it wrong? We will be glad to receive any tips from experts working with Google Cloud Console and apologize in advance for broken English.
We also apologize in advance to the StackOverflow community that we have to publish such elementary (which we are absolutely sure of from our side) questions here. We come here from Google Cloud Console - > Support - > Community support, and we must first try to publish posts in the Google Groups specified there, but they simply do not answer us, apparently considering our questions too elementary and not worthy of attention (however, these same questions in Google Groups are moderated) (for example, the previous question). And we are no longer able to contact any other support. Once again, we apologize for having to ask about this here.
It is true that if your app is a single use app then you do not need to be verified.
However if you don't get your app verified then there will be some restrictions.
you will see the unverified app screen
your refresh tokens will probably only be good for two weeks.
In the case of the YouTube api uploaded videos will be suck private.
If you can live with those points then you don't need to verify your app and you can continue as is.
If on the other hand you don't want to see the unverified app screen and you want a refresh token that will last longer then two weeks. You will need to verify your app. Yes, Even if your app is a console application running as a job some where you still show the consent screen. This is the YouTube video you will need to show Google. Show the consent screen popping up show the URL bar and then show your script running. You also need to set up the homepage and privacy policy screens. Yes i 100% agree with you that this is silly.
When you go though the process. Explain to google that this is a single use script running as a job some where.
Unfortunately when Google changed it so that Refresh tokens expire for unverified apps they pretty much tied the hands of all developers who are running such single user scripts. We now have to get our apps verified if we don't want to have to request a new refresh token every two weeks.
If your program needs to access the requested scopes of the Google account privacy, even though the user is yourself, you also need to provide a youtube video to demonstrate how you use this program. The auditor cannot guarantee whether you will make this program public.
On the submission properties tab on my UWP application, I cannot select "No" for the "Does this product access, collect, or transmit personal information (data that could be used to identify a person)?" question.
It is saying "Based on the capabilities your submission declares, a privacy policy URL is required."
I have reviewed my capabilities (which is empty), and I am not using any personal information on my application.
If the internetCapability is enabled, you will be required to provide a privacy policy, as your app could theoretically send any personal data over the internet.
You can easily generate a privacy policy with a tool like this.
Although #Martin's response is technically correct, it's incomplete.
Because you are submitting a Desktop Bridge app (with runFullTrust capability) your app has access to essentially everything the user has access to, and thus internetClient is redundant (unless you also have UWP components like a background task). According to the Store product page, your app has access to "all system resources" so in your privacy policy you might want to mention more than just network usage - you could mention that you don't collect or use any personal data, won't read files or access the microphone or the camera or location etc. I don't believe that's required, but it might make customers feel better.
(Note that the Store text might change to something more descriptive in the future).
I have a Crashlytics issue with a large number of affected users (400+). Our most recent release addresses this issue and I would like to know which users were affected directly. I know Crashlytics displays user information with a particular crash. However, does Crashlytics offer some sort of way to access information in bulk?
Edit:
Fabric.io added a new Export id's feature which makes this much easier.
Original:
As a workaround for this issue I built a user script that is run on Tampermonkey on Chrome. While this script can break very easily it currently(12/11/2014) works to skim though all the crashes of an issue and document the username.
Gist
While not a real answer to the question this at least makes it a bit easier to get the information in question.
How does the Dropbox Datastore API differ from similar offerings like Parse? One difference that I see is that my users pay for server storage instead of me. Are there other differences?
Disclaimer: I'm a Dropbox engineer who worked on the Datastore API, and know about the Parse API only indirectly. Weigh my opinion appropriately. Major differences I know of (pro and con):
Dropbox Datastores are free to the developer, and free the user for the first 5MB per-app (after which their Dropbox quota applies). Parse charges developers based on how many API requests they’re making.
Parse has minimal offline support, while Dropbox has full offline operation. With Dropbox, if the developer modifies data while offline, those modifications will be reflected in subsequent queries (with Parse, those changes are not reflected). Dropbox provides on-device query logic (unlike Parse) so that apps can continue to generate the views they need to, even when there’s no Internet available. In addition, Parse does not provide conflict resolution or querying offline.
Parse provides the ability to share data between users, and global data for all users of the app. Dropbox Datastores only support per-user data (for each app) for now (sharing is on the roadmap).
I would also add that:
Parse is full feature of backend of as service. You can find a pretty complete list of the other player in this field: http://en.wikipedia.org/wiki/Backend_as_a_service. They provide feature like:
Data service
User registration/auth
Push notification
Social
The dropbox Datastore APIs is more focusing on data services. (You also got the User part for free too?) Also it works full offline.
The Parse framework can store data that can be ready by any user in the application.
The Dropbox datastore, store data for each user, and you can't accesss data from other user. That's the main difference.
So easy to get lost in this since you have to read between the lines. My take is that with Datastore you are working with objects stored offline locally as json. I'm hoping they will soon release a Xamarin Android component - they released an IOS component last month. Since Xamarin targets both Android and IOS and Winphone, who knows why they made a dedicated IOS DLL for Xamarin but I digress. With Parse, it appears to me their intent is the always-connected-device. Sure you can save queries locally and you can save (save eventually) locally where Parse will push to the server when it is connected. But saving "eventually" and saving queries for offline work is a different design than just saving and letting Parse do it all in the background for you - which it does not unless I have missed something that would make this attractive to me. I cannot see Parse useable for devices that you know will be sometimes-connected, without a lot of code to make this happen and sync.