86 Matching Annotations
  1. Mar 2024
    1. some of our older applications rely substantially on manual extract, transform and load (ETL)processes to pass data from one system to another. This substantially increases the volumeof customer and staff data in transit on the network, which in a modern data managementand reporting infrastructure would be encapsulated in secure, automated end-to-end

      Reliance on ETL seen as risky

      I’m not convinced about this. Real-time API connectivity between systems is a great goal…very responsive to changes filtering through disparate systems. But a lot of “modern” processing is still done by ETL batches (sometimes daily, sometimes hourly, sometimes every minute).

  2. Jul 2023
    1. Code for processing data samples can get messy and hard to maintain; we ideally want our dataset code to be decoupled from our model training code for better readability and modularity.

      Code for data processing and model training should be separated as different modules.

  3. Jul 2021
    1. whereas now, they know that user@domain.com was subscribed to xyz.net at some point and is unsubscribing. Information is gold. Replace user@domain with abcd@senate and xyz.net with warezxxx.net and you've got tabloid gold.
  4. Nov 2020
  5. Oct 2020
  6. Aug 2020
  7. Jul 2020
    1. As mentioned earlier in these guidelines, it is very important that controllers assess the purposes forwhich data is actually processed and the lawful grounds on which it is based prior to collecting thedata. Often companies need personal data for several purposes, and the processing is based on morethan one lawful basis, e.g. customer data may be based on contract and consent. Hence, a withdrawalof consent does not mean a controller must erase data that are processed for a purpose that is basedon the performance of the contract with the data subject. Controllers should therefore be clear fromthe outset about which purpose applies to each element of data and which lawful basis is being reliedupon.
    2. If there is no other lawful basisjustifying the processing (e.g. further storage) of the data, they should be deleted by the controller.
    3. In cases where the data subject withdraws his/her consent and the controller wishes to continue toprocess the personal data on another lawful basis, they cannot silently migrate from consent (which iswithdrawn) to this other lawful basis. Any change in the lawful basis for processing must be notified toa data subject in accordance with the information requirements in Articles 13 and 14 and under thegeneral principle of transparency.
    1. Some vendors may relay on legitimate interest instead of consent for the processing of personal data. The User Interface specifies if a specific vendor is relating on legitimate interest as legal basis, meaning that that vendor will process user’s data for the declared purposes without asking for their consent. The presence of vendors relying on legitimate interest is the reason why within the user interface, even if a user has switched on one specific purpose, not all vendors processing data for that purpose will be displayed as switched on. In fact, those vendors processing data for that specific purpose, relying only on legitimate interest will be displayed as switched off.
    2. Under GDPR there are six possible legal bases for the processing of personal data.
  8. Jun 2020
  9. May 2020
    1. learn how to be a data steward or data ally. Help organizations proactively think about what data they collect and how it is governed after its collected. Help organizations get their collective head around all the data they possess, how they curate it, how they back it up, and how over time they minimize it.
    1. Services generally fall into two categories: Services related to your own data collection activities (eg. contact forms)Services related to third-party data collection activities (eg. Google Analytics)
    1. Sure, anti-spam measures such as a CAPTCHA would certainly fall under "legitimate interests". But would targeting cookies? The gotcha with reCAPTCHA is that this legitimate-interest, quite-necessary-in-today's-world feature is inextricably bundled with unwanted and unrelated Google targeting (cookiepedia.co.uk/cookies/NID) cookies (_ga, _gid for v2; NID for v3).
    1. Because consent under the GDPR is such an important issue, it’s mandatory that you keep clear records and that you’re able to demonstrate that the user has given consent; should problems arise, the burden of proof lies with the data controller, so keeping accurate records is vital.
    2. The records should include: who provided the consent;when and how consent was acquired from the individual user;the consent collection form they were presented with at the time of the collection;which conditions and legal documents were applicable at the time that the consent was acquired.
    3. Non-compliant Record Keeping Compliant Record Keeping
    1. there’s no need to send consent request emails — provided that this basis of processing was stated in your privacy policy and that users had easy access to the notice prior to you processing their data. If this information was not available to users at the time, but one of these legal bases can currently legitimately apply to your situation, then your best bet would be to ensure that your current privacy notice meets requirements, so that you can continue to process your user data in a legally compliant way.
    2. Here’s why sending GDPR consent emails is tricky and should be handled very carefully.
    1. they sought to eliminate data controllers and processors acting without appropriate permission, leaving citizens with no control as their personal data was transferred to third parties and beyond
    1. Consent receipt mechanisms can be especially helpful in automatically generating such records.
    2. With that guidance in mind, and from a practical standpoint, consider keeping records of the following: The name or other identifier of the data subject that consented; The dated document, a timestamp, or note of when an oral consent was made; The version of the consent request and privacy policy existing at the time of the consent; and, The document or data capture form by which the data subject submitted his or her data.
    3. Where a processing activity is necessary for the performance of a contract.

      Would a terms of service agreement be considered a contract in this case? So can you just make your terms of service basically include consent or implied consent?

    4. “Is consent really the most appropriate legal basis for this processing activity?” It should be taken into account that consent may not be the best choice in the following situations:
    1. “Until CR 1.0 there was no effective privacy standard or requirement for recording consent in a common format and providing people with a receipt they can reuse for data rights.  Individuals could not track their consents or monitor how their information was processed or know who to hold accountable in the event of a breach of their privacy,” said Colin Wallis, executive director, Kantara Initiative.  “CR 1.0 changes the game.  A consent receipt promises to put the power back into the hands of the individual and, together with its supporting API — the consent receipt generator — is an innovative mechanism for businesses to comply with upcoming GDPR requirements.  For the first time individuals and organizations will be able to maintain and manage permissions for personal data.”
    2. CR 1.0 is an essential specification for meeting the proof of consent requirements of GDPR to enable international transfer of personal information in a number of applications.
    3. Its purpose is to decrease the reliance on privacy policies and enhance the ability for people to share and control personal information.
    1. It’s useful to remember that under GDPR regulations consent is not the ONLY reason that an organization can process user data; it is only one of the “Lawful Bases”, therefore companies can apply other lawful (within the scope of GDPR) bases for data processing activity. However, there will always be data processing activities where consent is the only or best option.
    2. Under EU law (specifically the GDPR) you must keep and maintain “full and extensive” up-to-date records of your business processing activities, both internal and external, where the processing is carried out on personal data.
    3. However, even if your processing activities somehow fall outside of these situations, your information duties to users make it necessary for you to keep basic records relating to which data you collect, its purpose, all parties involved in its processing and the data retention period — this is mandatory for everyone.
    1. If you’re a controller based outside of the EU, you’re transferring personal data outside of the EU each time you collect data of users based within the EU. Please make sure you do so according to one of the legal bases for transfer.

      Here they equate collection of personal data with transfer of personal data. But this is not very intuitive: I usually think of collection of data and transfer of data as rather different activities. It would be if we collected the data on a server in EU and then transferred all that data (via some internal process) to a server in US.

      But I guess when you collect the data over the Internet from a user in a different country, the data is technically being transferred directly to your server in the US. But who is doing the transfer? I would argue that it is not me who is transferring it; it is the user who transmitted/sent the data to my app. I'm collecting it from them, but not transferring it. Collecting seems like more of a passive activity, while transfer seems like a more active activity (maybe not if it's all automated).

      So if these terms are equivalent, then they should replace all instances of "transfer" with "collect". That would make it much clearer and harder to mistakenly assume this doesn't apply to oneself. Or if there is a nuanced difference between the two activities, then the differences should be explained, such as examples of when collection may occur without transfer occurring.

    2. If you profile your users, you have to tell them. Therefore, you must pick the relevant clause from the privacy policy generator.
    3. If you’re selling products and keep record of users’ choices for marketing purposes, dividing them into meaningful categories, such as by age, gender, geographical origin etc., you’re profiling them.
    1. you can think “sold” here as “shared with third parties for any profit, monetary or otherwise”
    2. under most legislations you’re required to inform extensively about the processing activities, their purposes and the rights of users.
    3. Full and extensive records of processing are expressly required in cases where your data processing activities are not occasional, where they could result in a risk to the rights and freedoms of others, where they involve the handling of “special categories of data” or where your organization has more than 250 employees — this effectively covers almost all data controllers and processors.
    1. If you have fewer than 250 employees, you only need to document processing activities that: are not occasional; or
    2. Most organisations are required to maintain a record of their processing activities, covering areas such as processing purposes, data sharing and retention; we call this documentation.
    1. it buys, receives, sells, or shares the personal information of 50,000 or more consumers annually for the business’ commercial purposes. Since IP addresses fall under what is considered personal data — and “commercial purposes” simply means to advance commercial or economic interests — it is likely that any website with at least 50k unique visits per year from California falls within this scope.
    1. You must disclose how the add-on collects, uses, stores and shares user data in the privacy policy field on AMO. Mozilla expects that the add-on limits data collection whenever possible, in keeping with Mozilla’s Lean Data Practices and Mozilla’s Data Privacy Principles, and uses the data only for the purpose for which it was originally collected.
  10. Apr 2020
    1. If the PIA identifies risks or high risks, based on the specific context and circumstances, the organization will need to request consent.
    2. Privacy impact assessments or data protection impact assessments under the EU GDPR, before the collection of personal data, will have a key role
    3. U.K. Information Commissioner Elizabeth Denham clearly states that consent is not the "silver bullet" for GDPR compliance. In many instances, consent will not be the most appropriate ground — for example, when the processing is based on a legal obligation or when the organization has a legitimate interest in processing personal data.
    4. data processing limited to purposes deemed reasonable and appropriate such as commercial interests, individual interests or societal benefits with minimal privacy impact could be exempt from formal consent. The individual will always retain the right to object to the processing of any personal data at any time, subject to legal or contractual restrictions.
    5. organizations may require consent from individuals where the processing of personal data is likely to result in a risk or high risk to the rights and freedoms of individuals or in the case of automated individual decision-making and profiling. Formal consent could as well be justified where the processing requires sharing of personal data with third parties, international data transfers, or where the organization processes special categories of personal data or personal data from minors.
    6. First, organizations must identify the lawful basis for processing prior to the collection of personal data. Under the GDPR, consent is one basis for processing; there are other alternatives. They may be more appropriate options.
    1. The data is stored in log files to ensure the functionality of the website. In addition, the data serves us to optimize the website and to ensure the security of our information technology systems. An evaluation of the data for marketing purposes does not take place in this context. The legal basis for the temporary storage of the data and the log files is Art. 6 para. 1 lit. f GDPR. Our legitimate interests lie in the above-mentioned purposes.
    2. The temporary storage of the IP address by the system is necessary to enable the website to be delivered to the user's computer. For this the IP address of the user must remain stored for the duration of the session.
    3. The collection of the data for the provision of the website and the storage of the data in log files is absolutely necessary for the operation of the website. Consequently, there is no possibility of objection on the part of the user.
    4. The legal basis for the processing of personal data using cookies is Art. 6 para. 1 lit. f GDPR. Our legitimate interests lie in the above-mentioned purposes.
  11. Mar 2020
    1. legitimate interest triggers when “processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject
    2. of the six lawful, GDPR-compliant ways companies can get the green light to process individual personal data, consent is the “least preferable.” According to guidelines in Article 29 Working Party from the European Commission, "a controller must always take time to consider whether consent is the appropriate lawful ground for the envisaged processing or whether another ground should be chosen instead." 
    3. “It is unfortunate that a lot of companies are blindly asking for consent when they don’t need it because they have either historically obtained the consent to contact a user,” said digital policy consultant Kristina Podnar. “Or better yet, the company has a lawful basis for contact. Lawful basis is always preferable to consent, so I am uncertain why companies are blindly dismissing that path in favor of consent.”
    1. Data has become a “natural resource” for advertising technology. “And, just as with every other precious resource, we all bear responsibility for its consumption,”
    2. To join the Privacy Shield Framework, a U.S.-based organization is required to self-certify to the Department of Commerce and publicly commit to comply with the Framework’s requirements. While joining the Privacy Shield is voluntary, the GDPR goes far beyond it.
    1. it would appear impossible to require a publisher to provide information on and obtain consent for the installation of cookies on his own website also with regard to those installed by “third parties**”
    2. Our solution goes a bit further than this by pointing to the browser options, third-party tools and by linking to the third party providers, who are ultimately responsible for managing the opt-out for their own tracking tools.
    3. You are also not required to manage consent for third-party cookies directly on your site/app as this responsibility falls to the individual third-parties. You are, however, required to at least facilitate the process by linking to the relevant policies of these third-parties.
    4. the publisher would be required to check, from time to time, that what is declared by the third parties corresponds to the purposes they are actually aiming at via their cookies. This is a daunting task because a publisher often has no direct contacts with all the third parties installing cookies via his website, nor does he/she know the logic underlying the respective processing.
    1. Decision point #2 – Do you send any data to third parties, directly or inadvertently? <img class="alignnone size-full wp-image-10174" src="https://www.jeffalytics.com/wp-content/uploads/7deb832d95678dc21cc23208d76f4144_Flowchart.png" alt="GDPR cookie consent flowchart" width="1451" height="601" srcset="https://www.jeffalytics.com/wp-content/uploads/7deb832d95678dc21cc23208d76f4144_Flowchart.png 1451w, https://www.jeffalytics.com/wp-content/uploads/7deb832d95678dc21cc23208d76f4144_Flowchart-300x124.png 300w, https://www.jeffalytics.com/wp-content/uploads/7deb832d95678dc21cc23208d76f4144_Flowchart-981x406.png 981w, https://www.jeffalytics.com/wp-content/uploads/7deb832d95678dc21cc23208d76f4144_Flowchart-761x315.png 761w, https://www.jeffalytics.com/wp-content/uploads/7deb832d95678dc21cc23208d76f4144_Flowchart-611x253.png 611w, https://www.jeffalytics.com/wp-content/uploads/7deb832d95678dc21cc23208d76f4144_Flowchart-386x160.png 386w, https://www.jeffalytics.com/wp-content/uploads/7deb832d95678dc21cc23208d76f4144_Flowchart-283x117.png 283w, https://www.jeffalytics.com/wp-content/uploads/7deb832d95678dc21cc23208d76f4144_Flowchart-600x249.png 600w, https://www.jeffalytics.com/wp-content/uploads/7deb832d95678dc21cc23208d76f4144_Flowchart-1024x424.png 1024w, https://www.jeffalytics.com/wp-content/uploads/7deb832d95678dc21cc23208d76f4144_Flowchart-50x21.png 50w, https://www.jeffalytics.com/wp-content/uploads/7deb832d95678dc21cc23208d76f4144_Flowchart-250x104.png 250w, https://www.jeffalytics.com/wp-content/uploads/7deb832d95678dc21cc23208d76f4144_Flowchart-241x100.png 241w, https://www.jeffalytics.com/wp-content/uploads/7deb832d95678dc21cc23208d76f4144_Flowchart-400x166.png 400w, https://www.jeffalytics.com/wp-content/uploads/7deb832d95678dc21cc23208d76f4144_Flowchart-350x145.png 350w, https://www.jeffalytics.com/wp-content/uploads/7deb832d95678dc21cc23208d76f4144_Flowchart-840x348.png 840w, https://www.jeffalytics.com/wp-content/uploads/7deb832d95678dc21cc23208d76f4144_Flowchart-860x356.png 860w, https://www.jeffalytics.com/wp-content/uploads/7deb832d95678dc21cc23208d76f4144_Flowchart-1030x427.png 1030w" sizes="(max-width: 1451px) 100vw, 1451px" /> Remember, inadvertently transmitting data to third parties can occur through the plugins you use on your website. You don't necessarily have to be doing this proactively. If the answer is “Yes,” then to comply with GDPR, you should use a cookie consent popup.
    1. You must clearly identify each party that may collect, receive, or use end users’ personal data as a consequence of your use of a Google product. You must also provide end users with prominent and easily accessible information about that party’s use of end users’ personal data.
    1. GDPR introduces a list of data subjects’ rights that should be obeyed by both data processors and data collectors. The list includes: Right of access by the data subject (Section 2, Article 15). Right to rectification (Section 3, Art 16). Right to object to processing (Section 4, Art 21). Right to erasure, also known as ‘right to be forgotten’ (Section 3, Art 17). Right to restrict processing (Section 3, Art 18). Right to data portability (Section 3, Art 20).
    1. An example of reliance on legitimate interests includes a computer store, using only the contact information provided by a customer in the context of a sale, serving that customer with direct regular mail marketing of similar product offerings — accompanied by an easy-to-select choice of online opt-out.
    1. This is no different where legitimate interests applies – see the examples below from the DPN. It should also be made clear that individuals have the right to object to processing of personal data on these grounds.
    2. Individuals can object to data processing for legitimate interests (Article 21 of the GDPR) with the controller getting the opportunity to defend themselves, whereas where the controller uses consent, individuals have the right to withdraw that consent and the ‘right to erasure’. The DPN observes that this may be a factor in whether companies rely on legitimate interests.

      .

    1. Consent is one of six lawful grounds for processing data. It may be arguable that anti-spam measures such as reCaptcha can fall under "legitimate interests" (ie you don't need to ask for consent)
  12. Aug 2018
    1. This is related to the fact that biology researchers are in a creative process and reflect on their decisions in order to explore new leads or justify their decisions. Paper laboratory notebooks show this temporality ofthoughts.

      The iterative self-reflection process described in biology research seems relatively undeveloped in DHN work. I don't know that I've seen much negotiation/reflection/critical analysis take place between the moment the data is collected by volunteers and the maps/viz/data/after-action reports created after the fact by the Core Team.

      Perhaps that's a missing element that should be more deeply explored in thinking about data having both a time attribute and being in a state of change? Is there a needed intermediate validation step between data cleaning and creating a data analysis product.