# data[].attributes.attachment_link.readable_text
Introduction

The guiding principle of the App Store is simple-we want to provide a safe experience for users to get apps and a great opportunity for all developers to be successful. We do this by offering a highly curated App Store where every app is reviewed by experts and an editorial team helps users discover new apps every day. For everything else there is always the open Internet. If the App Store model and guidelines are not best for your app or business idea that's okay, we provide Safari for a great web experience too.

On the following pages you will find our latest guidelines arranged into five clear sections: Safety, Performance, Business, Design, and Legal. The App Store is always changing and improving to keep up with the needs of our customers and our products. Your apps should change and improve as well in order to stay on the App Store.

A few other points to keep in mind:

We have lots of kids downloading lots of apps. Parental controls work great to protect kids, but you have to do your part too. So know that we're keeping an eye out for the kids.

The App Store is a great way to reach hundreds of millions of people around the world. If you build an app that you just want to show to family and friends, the App Store isn't the best way to do that. Consider using Xcode to install your app on a device for free or use Ad Hoc distribution available to Apple Developer Program members. If you're just getting started, learn more about the Apple Developer Program.

We strongly support all points of view being represented on the App Store, as long as the apps are respectful to users with differing opinions and the quality of the app experience is great. We will reject apps for any content or behavior that we believe is over the line. What line, you ask? Well, as a Supreme Court Justice once said, "I'll know it when I see it". And we think that you will also know it when you cross it.

If you attempt to cheat the system (for example, by trying to trick the review process, steal user data, copy another developer's work, manipulate ratings or App Store discovery) your apps will be removed from the store and you will be expelled from the Apple Developer Program.

You are responsible for making sure everything in your app complies with these guidelines, including ad networks, analytics services, and third-party SDKs, so review and choose them carefully.

Some features and technologies that are not generally available to developers may be offered as an entitlement for limited use cases. For example, we offer entitlements for CarPlay Audio, HyperVisor, and Privileged File Operations. Review our documentation on developer.apple.com to learn more about entitlements.

We hope these guidelines help you sail through the App Review process, and that approvals and rejections remain consistent across the board. This is a living document; new apps presenting new questions may result in new rules at any time. Perhaps your app will trigger this. We love this stuff too, and honor what you do. We're really trying our best to create the best platform in the world for you to express your talents and make a living, too.

Before You Submit

To help your app approval go as smoothly as possible, review the common missteps listed below that can slow down the review process or trigger a rejection. This doesn't replace the guidelines or guarantee approval, but making sure you can check every item on the list is a good start. If your app no longer functions as intended or you're no longer actively supporting it, it will be removed from the App Store. Learn more about App Store Improvements.

Make sure you:

Test your app for crashes and bugs

Ensure that all app information and metadata is complete and accurate

Update your contact information in case App Review needs to reach you

Provide an active demo account and login information, plus any other hardware or resources that might be needed to review your app (e.g. login credentials or a sample QR code)

Enable backend services so that they're live and accessible during review

Include detailed explanations of non-obvious features and in-app purchases in the App Review notes, including supporting documentation where appropriate

Check whether your app follows guidance in other documentation, such as:

Development Guidelines Design Guidelines Brand and Marketing Guidelines
1. Safety

When people install an app from the App Store, they want to feel confident that it's safe to do so-that the app doesn't contain upsetting or offensive content, won't damage their device, and isn't likely to cause physical harm from its use. We've outlined the major pitfalls below, but if you're looking to shock and offend people, the App Store isn't the right place for your app.

1.1 Objectionable Content
Apps should not include content that is offensive, insensitive, upsetting, intended to disgust, in exceptionally poor taste, or just plain creepy. Examples of such content include:

1.1.1 Defamatory, discriminatory, or mean-spirited content, including references or commentary about religion, race, sexual orientation, gender, national/ethnic origin, or other targeted groups, particularly if the app is likely to humiliate, intimidate, or harm a targeted individual or group. Professional political satirists and humorists are generally exempt from this requirement.

1.1.2 Realistic portrayals of people or animals being killed, maimed, tortured, or abused, or content that encourages violence. "Enemies" within the context of a game cannot solely target a specific race, culture, real government, corporation, or any other real entity.

1.1.3 Depictions that encourage illegal or reckless use of weapons and dangerous objects, or facilitate the purchase of firearms or ammunition.

1.1.4 Overtly sexual or pornographic material, defined as "explicit descriptions or displays of sexual organs or activities intended to stimulate erotic rather than aesthetic or emotional feelings." This includes "hookup" apps that may include pornography or be used to facilitate prostitution.

1.1.5 Inflammatory religious commentary or inaccurate or misleading quotations of religious texts.

1.1.6 False information and features, including inaccurate device data or trick/joke functionality, such as fake location trackers. Stating that the app is "for entertainment purposes" won't overcome this guideline. Apps that enable anonymous or prank phone calls or SMS/MMS messaging will be rejected.

1.2 User-Generated Content
Apps with user-generated content present particular challenges, ranging from intellectual property infringement to anonymous bullying. To prevent abuse, apps with user-generated content or social networking services must include:

A method for filtering objectionable material from being posted to the app

A mechanism to report offensive content and timely responses to concerns

The ability to block abusive users from the service

Published contact information so users can easily reach you

Apps with user-generated content or services that end up being used primarily for pornographic content, Chatroulette-style experiences, objectification of real people (e.g. "hot-or-not" voting), making physical threats, or bullying do not belong on the App Store and may be removed without notice. If your app includes user-generated content from a web-based service, it may display incidental mature "NSFW" content, provided that the content is hidden by default and only displayed when the user turns it on via your website.

1.2.1 Creator Content
Apps which feature content from a specific community of users called "creators" are a great opportunity if properly moderated. These apps present a singular, unified experience for customers to interact with various kinds of creator content. They offer tools and programs to help this community of non-developer creators to author, share, and monetize user-generated experiences. These experiences must not change the core features and functionality of the native app-rather, they add content to those structured experiences. These experiences are not native "apps" coded by developers-they are content within the app itself and are treated as user-generated content by App Review. Such creator content may include video, articles, audio, and even casual games. The App Store supports apps offering such user-generated content so long as they follow all Guidelines, including Guideline 1.2 for moderating user-generated content and Guideline 3.1.1 for payments and in-app purchases. Creator apps should share the age rating of the highest age-rated creator content available in the app, and communicate to users which content requires additional purchases.

1.3 Kids Category
The Kids Category is a great way for people to easily find apps that are designed for children. If you want to participate in the Kids Category, you should focus on creating a great experience specifically for younger users. These apps must not include links out of the app, purchasing opportunities, or other distractions to kids unless reserved for a designated area behind a parental gate. Keep in mind that once customers expect your app to follow the Kids Category requirements, it will need to continue to meet these guidelines in subsequent updates, even if you decide to deselect the category. Learn more about parental gates.

You must comply with applicable privacy laws around the world relating to the collection of data from children online. Be sure to review the Privacy section of these guidelines for more information. In addition, Kids Category apps may not send personally identifiable information or device information to third parties. Apps in the Kids Category should not include third-party analytics or third-party advertising. This provides a safer experience for kids. In limited cases, third-party analytics may be permitted provided that the services do not collect or transmit the IDFA or any identifiable information about children (such as name, date of birth, email address), their location, or their devices. This includes any device, network, or other information that could be used directly or combined with other information to identify users and their devices. Third-party contextual advertising may also be permitted in limited cases provided that the services have publicly documented practices and policies for Kids Category apps that include human review of ad creatives for age appropriateness.

1.4 Physical Harm
If your app behaves in a way that risks physical harm, we may reject it. For example:

1.4.1 Medical apps that could provide inaccurate data or information, or that could be used for diagnosing or treating patients may be reviewed with greater scrutiny.

Apps must clearly disclose data and methodology to support accuracy claims relating to health measurements, and if the level of accuracy or methodology cannot be validated, we will reject your app. For example, apps that claim to take x-rays, measure blood pressure, body temperature, blood glucose levels, or blood oxygen levels using only the sensors on the device are not permitted.

Apps should remind users to check with a doctor in addition to using the app and before making medical decisions.

If your medical app has received regulatory clearance, please submit a link to that documentation with your app.

1.4.2 Drug dosage calculators must come from the drug manufacturer, a hospital, university, health insurance company, pharmacy or other approved entity, or receive approval by the FDA or one of its international counterparts. Given the potential harm to patients, we need to be sure that the app will be supported and updated over the long term.

1.4.3 Apps that encourage consumption of tobacco and vape products, illegal drugs, or excessive amounts of alcohol are not permitted on the App Store. Apps that encourage minors to consume any of these substances will be rejected. Facilitating the sale of controlled substances (except for licensed pharmacies and licensed or otherwise legal cannabis dispensaries), or tobacco is not allowed.

1.4.4 Apps may only display DUI checkpoints that are published by law enforcement agencies, and should never encourage drunk driving or other reckless behavior such as excessive speed.

1.4.5 Apps should not urge customers to participate in activities (like bets, challenges, etc.) or use their devices in a way that risks physical harm to themselves or others.

1.5 Developer Information
People need to know how to reach you with questions and support issues. Make sure your app and its Support URL include an easy way to contact you; this is particularly important for apps that may be used in the classroom. Failure to include accurate and up-to-date contact information not only frustrates customers, but may violate the law in some countries or regions. Also ensure that Wallet passes include valid contact information from the issuer and are signed with a dedicated certificate assigned to the brand or trademark owner of the pass.

1.6 Data Security
Apps should implement appropriate security measures to ensure proper handling of user information collected pursuant to the Apple Developer Program License Agreement and these Guidelines (see Guideline 5.1 for more information) and prevent its unauthorized use, disclosure, or access by third parties.

1.7 Reporting Criminal Activity
Apps for reporting alleged criminal activity must involve local law enforcement, and can only be offered in countries or regions where such involvement is active.

2. Performance

2.2 Beta Testing
Demos, betas, and trial versions of your app don't belong on the App Store - use TestFlight instead. Any app submitted for beta distribution via TestFlight should be intended for public distribution and should comply with the App Review Guidelines. Note, however, that apps using TestFlight cannot be distributed to testers in exchange for compensation of any kind, including as a reward for crowd-sourced funding. Significant updates to your beta build should be submitted to TestFlight App Review before being distributed to your testers. To learn more, visit the TestFlight Beta Testing page.

2.4 Hardware Compatibility

2.4.1 To ensure people get the most out of your app, iPhone apps should run on iPad whenever possible. We encourage you to consider building universal apps so customers can use them on all of their devices. Learn more about Universal apps.

2.4.2 Design your app to use power efficiently and be used in a way that does not risk damage to the device. Apps should not rapidly drain battery, generate excessive heat, or put unnecessary strain on device resources. For example, apps should not encourage placing the device under a mattress or pillow while charging or perform excessive write cycles to the solid state drive. Apps, including any third-party advertisements displayed within them, may not run unrelated background processes, such as cryptocurrency mining.

2.4.3 People should be able to use your Apple TV app without the need for hardware inputs beyond the Siri remote or third-party game controllers, but feel free to provide enhanced functionality when other peripherals are connected. If you require a game controller, make sure you clearly explain that in your metadata so customers know they need additional equipment to play.

2.4.4 Apps should never suggest or require a restart of the device or modifications to system settings unrelated to the core functionality of the app. For example, don't encourage users to turn off Wi-Fi, disable security features, etc.

2.4.5 Apps distributed via the Mac App Store have some additional requirements to keep in mind:

(i) They must be appropriately sandboxed, and follow macOS File System Documentation. They should also only use the appropriate macOS APIs for modifying user data stored by other apps (e.g. bookmarks, Address Book, or Calendar entries).

(ii) They must be packaged and submitted using technologies provided in Xcode; no third-party installers allowed. They must also be self-contained, single app installation bundles and cannot install code or resources in shared locations.

(iii) They may not auto-launch or have other code run automatically at startup or login without consent nor spawn processes that continue to run without consent after a user has quit the app. They should not automatically add their icons to the Dock or leave shortcuts on the user desktop.

(iv) They may not download or install standalone apps, kexts, additional code, or resources to add functionality or significantly change the app from what we see during the review process.

(v) They may not request escalation to root privileges or use setuid attributes.

(vi) They may not present a license screen at launch, require license keys, or implement their own copy protection.

(vii) They must use the Mac App Store to distribute updates; other update mechanisms are not allowed.

(viii) Apps should run on the currently shipping OS and may not use deprecated or optionally installed technologies (e.g. Java)

(ix) Apps must contain all language and localization support in a single app bundle.

2.5 Software Requirements

2.5.1 Apps may only use public APIs and must run on the currently shipping OS. Learn more about public APIs. Keep your apps up-to-date and make sure you phase out any deprecated features, frameworks or technologies that will no longer be supported in future versions of an OS. Apps should use APIs and frameworks for their intended purposes and indicate that integration in their app description. For example, the HomeKit framework should provide home automation services; and HealthKit should be used for health and fitness purposes and integrate with the Health app.

2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.

2.5.3 Apps that transmit viruses, files, computer code, or programs that may harm or disrupt the normal operation of the operating system and/or hardware features, including Push Notifications and Game Center, will be rejected. Egregious violations and repeat behavior will result in removal from the Apple Developer Program.

2.5.4 Multitasking apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc.

2.5.5 Apps must be fully functional on IPv6-only networks.

2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.

2.5.7 Video streaming content over a cellular network longer than 10 minutes must use HTTP Live Streaming and include a baseline 192 kbps HTTP Live stream.

2.5.8 Apps that create alternate desktop/home screen environments or simulate multi-app widget experiences will be rejected.

2.5.9 Apps that alter or disable the functions of standard switches, such as the Volume Up/Down and Ring/Silent switches, or other native user interface elements or behaviors will be rejected. For example, apps should not block links out to other apps or other features that users would expect to work a certain way. Learn more about proper handling of links.

2.5.10 Apps should not be submitted with empty ad banners or test advertisements.

2.5.11 SiriKit and Shortcuts

(i) Apps integrating SiriKit and Shortcuts should only sign up for intents they can handle without the support of an additional app and that users would expect from the stated functionality. For example, if your app is a meal planning app, you should not incorporate an intent to start a workout, even if the app shares integration with a fitness app.

(ii) Ensure that the vocabulary and phrases in your plist pertains to your app and the Siri functionality of the intents the app has registered for. Aliases must relate directly to your app or company name and should not be generic terms or include third-party app names or services.

(iii) Resolve the Siri request or Shortcut in the most direct way possible and do not insert ads or other marketing between the request and its fulfillment. Only request a disambiguation when required to complete the task (e.g. asking the user to specify a particular type of workout).

2.5.12 Apps using CallKit or including an SMS Fraud Extension should only block phone numbers that are confirmed spam. Apps that include call-, SMS-, and MMS- blocking functionality or spam identification must clearly identify these features in their marketing text and explain the criteria for their blocked and spam lists. You may not use the data accessed via these tools for any purpose not directly related to operating or improving your app or extension (e.g. you may not use, share, or sell it for tracking purposes, creating user profiles, etc.).

2.5.13 Apps using facial recognition for account authentication must use LocalAuthentication (and not ARKit or other facial recognition technology) where possible, and must use an alternate authentication method for users under 13 years old.

2.5.14 Apps must request explicit user consent and provide a clear visual and/or audible indication when recording, logging, or otherwise making a record of user activity. This includes any use of the device camera, microphone, screen recordings, or other user inputs.

2.5.15 Apps that enable users to view and select files should include items from the Files app and the user's iCloud documents.

2.5.16 App Clips, widgets, extensions, and notifications should be related to the content and functionality of your app. Additionally, all App Clip features and functionality must be included in the main app binary. App Clips cannot contain advertising.

3. Business

There are many ways to monetize your app on the App Store. If your business model isn't obvious, make sure to explain in its metadata and App Review notes. If we can't understand how your app works or your in-app purchases aren't immediately obvious, it will delay your review and may trigger a rejection. And while pricing is up to you, we won't distribute apps and in-app purchase items that are clear rip-offs. We'll reject expensive apps that try to cheat users with irrationally high prices.

If we find that you have attempted to manipulate reviews, inflate your chart rankings with paid, incentivized, filtered, or fake feedback, or engage with third-party services to do so on your behalf, we will take steps to preserve the integrity of the App Store, which may include expelling you from the Apple Developer Program.

4. Design

Apple customers place a high value on products that are simple, refined, innovative, and easy to use, and that's what we want to see on the App Store. Coming up with a great design is up to you, but the following are minimum standards for approval to the App Store. And remember that even after your app has been approved, you should update your app to ensure it remains functional and engaging to new and existing customers. Apps that stop working or offer a degraded experience may be removed from the App Store at any time.

4.2 Minimum Functionality
Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or "app-like," it doesn't belong on the App Store. If your App doesn't provide some sort of lasting entertainment value or adequate utility, it may not be accepted. Apps that are simply a song or movie should be submitted to the iTunes Store. Apps that are simply a book or game guide should be submitted to the Apple Books Store.

4.2.1 Apps using ARKit should provide rich and integrated augmented reality experiences; merely dropping a model into an AR view or replaying animation is not enough.

4.2.2 Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.

4.2.3

(i) Your app should work on its own without requiring installation of another app to function.

(ii) If your app needs to download additional resources in order to function on initial launch, disclose the size of the download and prompt users before doing so.

4.2.4 Apple Watch apps that appear to be a watch face are confusing, because people will expect them to work with device features such as swipes, notifications, and third-party complications. Creative ways of expressing time as an app interface is great (say, a tide clock for surfers), but if your app comes too close to resembling a watch face, we will reject it.

4.2.5 Apps that are primarily iCloud and iCloud Drive file managers need to include additional app functionality to be approved.

4.2.6 Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. These services should not submit apps on behalf of their clients and should offer tools that let their clients create customized, innovative apps that provide unique customer experiences. Another acceptable option for template providers is to create a single binary to host all client content in an aggregated or "picker" model, for example as a restaurant finder app with separate customized entries or pages for each client restaurant, or as an event app with separate entries for each client event.

4.2.7 Remote Desktop Clients: If your remote desktop app acts as a mirror of specific software or services rather than a generic mirror of the host device, it must comply with the following:

(a) The app must only connect to a user-owned host device that is a personal computer or dedicated game console owned by the user, and both the host device and client must be connected on a local and LAN-based network.

(b) Any software or services appearing in the client are fully executed on the host device, rendered on the screen of the host device, and may not use APIs or platform features beyond what is required to stream the Remote Desktop.

(c) All account creation and management must be initiated from the host device.

(d) The UI appearing on the client does not resemble an iOS or App Store view, does not provide a store-like interface, or include the ability to browse, select, or purchase software not already owned or licensed by the user. For the sake of clarity, transactions taking place within mirrored software do not need to use in-app purchase, provided the transactions are processed on the host device.

(e) Thin clients for cloud-based apps are not appropriate for the App Store.

4.4 Extensions
Apps hosting or containing extensions must comply with the App Extension Programming Guide or the Safari App Extensions Guide and should include some functionality, such as help screens and settings interfaces where possible. You should clearly and accurately disclose what extensions are made available in the app's marketing text, and the extensions may not include marketing, advertising, or in-app purchases.

4.4.1 Keyboard extensions have some additional rules.

They must:

Provide keyboard input functionality (e.g. typed characters);

Follow Sticker guidelines if the keyboard includes images or emoji;

Provide a method for progressing to the next keyboard;

Remain functional without full network access and without requiring full access;

Collect user activity only to enhance the functionality of the user's keyboard extension on the iOS device.

They must not:

Launch other apps besides Settings; or

Repurpose keyboard buttons for other behaviors (e.g. holding down the "return" key to launch the camera).

4.4.2 Safari extensions must run on the current version of Safari on macOS. They may not interfere with System or Safari UI elements and must never include malicious or misleading content or code. Violating this rule will lead to removal from the Apple Developer Program. Safari extensions should not claim access to more websites than strictly necessary to function.

4.4.3 Stickers
Stickers are a great way to make Messages more dynamic and fun, letting people express themselves in clever, funny, meaningful ways. Whether your app contains a sticker extension or you're creating free-standing sticker packs, its content shouldn't offend users, create a negative experience, or violate the law.

(i) In general, if it wouldn't be suitable for the App Store, it doesn't belong in a sticker.

(ii) Consider regional sensitivities, and do not make your sticker pack available in a country or region where it could be poorly received or violate local law.

(iii) If we don't understand what your stickers mean, include a clear explanation in your review notes to avoid any delays in the review process.

(iv) Ensure your stickers have relevance beyond your friends and family; they should not be specific to personal events, groups, or relationships.

(v) You must have all the necessary copyright, trademark, publicity rights, and permissions for the content in your stickers, and shouldn't submit anything unless you're authorized to do so. Keep in mind that you must be able to provide verifiable documentation upon request. Apps with sticker content you don't have rights to use will be removed from the App Store and repeat offenders will be removed from the Apple Developer Program. If you believe your content has been infringed by another provider, submit a claim here.

4.5 Apple Sites and Services

4.5.1 Apps may use approved Apple RSS feeds such as the iTunes Store RSS feed, but may not scrape any information from Apple sites (e.g. apple.com, the iTunes Store, App Store, App Store Connect, developer portal, etc.) or create rankings using this information.

4.5.2 Apple Music

(i) MusicKit on iOS lets users play Apple Music and their local music library natively from your apps and games. When a user provides permission to their Apple Music account, your app can create playlists, add songs to their library, and play any of the millions of songs in the Apple Music catalog. Users must initiate the playback of an Apple Music stream and be able to navigate using standard media controls such as "play," "pause," and "skip." Moreover, your app may not require payment or indirectly monetize access to the Apple Music service (e.g. in-app purchase, advertising, requesting user info, etc.). Do not download, upload, or enable sharing of music files sourced from the MusicKit APIs, except as explicitly permitted in MusicKit documentation.

(ii) Using the MusicKit APIs is not a replacement for securing the licenses you might need for a deeper or more complex music integration. For example, if you want your app to play a specific song at a particular moment, or to create audio or video files that can be shared to social media, you'll need to contact rights-holders directly to get their permission (e.g. synchronization or adaptation rights) and assets. Cover art and other metadata may only be used in connection with music playback or playlists (including App Store screenshots displaying your app's functionality), and should not be used in any marketing or advertising without getting specific authorization from rights-holders. Make sure to follow the Apple Music Identity Guidelines when integrating Apple Music services in your app.

(iii) Apps that access Apple Music user data, such as playlists and favorites, must clearly disclose this access in the purpose string. Any data collected may not be shared with third parties for any purpose other than supporting or improving the app experience. This data may not be used to identify users or devices, or to target advertising.

4.5.3 Do not use Apple Services to spam, phish, or send unsolicited messages to customers, including Game Center, Push Notifications, etc. Do not attempt to reverse lookup, trace, relate, associate, mine, harvest, or otherwise exploit Player IDs, aliases, or other information obtained through Game Center, or you will be removed from the Apple Developer Program.

4.5.4 Push Notifications must not be required for the app to function, and should not be used to send sensitive personal or confidential information. Push Notifications should not be used for promotions or direct marketing purposes unless customers have explicitly opted in to receive them via consent language displayed in your app's UI, and you provide a method in your app for a user to opt out from receiving such messages. Abuse of these services may result in revocation of your privileges.

4.5.5 Only use Game Center Player IDs in a manner approved by the Game Center terms and do not display them in the app or to any third party.

4.5.6 Apps may use Unicode characters that render as Apple emoji in their app and app metadata. Apple emoji may not be used on other platforms or embedded directly in your app binary.

4.6 Alternate App Icons
Apps may display customized icons, for example, to reflect a sports team preference, provided that each change is initiated by the user and the app includes settings to revert to the original icon. All icon variants must relate to the content of the app and changes should be consistent across all system assets, so that the icons displayed in Settings, Notifications, etc. match the new springboard icon. This feature may not be used for dynamic, automatic, or serial changes, such as to reflect up-to-date weather information, calendar notifications, etc.

4.7 HTML5 Games, Bots, etc.
Apps may contain or run code that is not embedded in the binary (e.g. HTML5-based games, bots, etc.), as long as code distribution isn't the main purpose of the app, the code is not offered in a store or store-like interface, and provided that the software adheres to the additional rules that follow in 4.7.1 and 4.7.2. These additional rules are important to preserve the experience that App Store customers expect, and to help ensure user safety.

4.7.1 Software offered under this rule must:

be free or purchased using in-app purchase;

only use capabilities available in a standard WebKit view (e.g. it must open and run natively in Safari without modifications or additional software); and use WebKit and JavaScript Core to run third-party software and should not attempt to extend or expose native platform APIs to third-party software;

be offered by developers that have joined the Apple Developer Program and signed the Apple Developer Program License Agreement;

not provide access to real money gaming;

adhere to the terms of these App Store Review Guidelines (e.g. do not include objectionable content); and

not offer digital goods or services for sale.

4.7.2 Upon request, you must provide an index of software and metadata available in your app. It must include Apple Developer Program Team IDs for the providers of the software along with a URL which App Review can use to confirm that the software complies with the requirements above.

4.8 Sign in with Apple
Apps that use a third-party or social login service (such as Facebook Login, Google Sign-In, Sign in with Twitter, Sign In with LinkedIn, Login with Amazon, or WeChat Login) to set up or authenticate the user's primary account with the app must also offer Sign in with Apple as an equivalent option. A user's primary account is the account they establish with your app for the purposes of identifying themselves, signing in, and accessing your features and associated services.

Sign in with Apple is not required if:

Your app exclusively uses your company's own account setup and sign-in systems.

Your app is an education, enterprise, or business app that requires the user to sign in with an existing education or enterprise account.

Your app uses a government or industry-backed citizen identification system or electronic ID to authenticate users.

Your app is a client for a specific third-party service and users are required to sign in to their mail, social media, or other third-party account directly to access their content.

4.9 Streaming games
Streaming games are permitted so long as they adhere to all guidelines-for example, each game update must be submitted for review, developers must provide appropriate metadata for search, games must use in-app purchase to unlock features or functionality, etc. Of course, there is always the open Internet and web browser apps to reach all users outside of the App Store.

4.9.1 Each streaming game must be submitted to the App Store as an individual app so that it has an App Store product page, appears in charts and search, has user ratings and review, can be managed with ScreenTime and other parental control apps, appears on the user's device, etc.

4.9.2 Streaming game services may offer a catalog app on the App Store to help users sign up for the service and find the games on the App Store, provided that the app adheres to all guidelines, including offering users the option to pay for a subscription with in-app purchase and use Sign in with Apple. All the games included in the catalog app must link to an individual App Store product page.

5. Legal

Apps must comply with all legal requirements in any location where you make them available (if you're not sure, check with a lawyer). We know this stuff is complicated, but it is your responsibility to understand and make sure your app conforms with all local laws, not just the guidelines below. And of course, apps that solicit, promote, or encourage criminal or clearly reckless behavior will be rejected. In extreme cases, such as apps that are found to facilitate human trafficking and/or the exploitation of children, appropriate authorities will be notified.

5.1 Privacy
Protecting user privacy is paramount in the Apple ecosystem, and you should use care when handling personal data to ensure you've complied with privacy best practices, applicable laws, and the terms of the Apple Developer Program License Agreement, not to mention customer expectations. More particularly:

5.1.1 Data Collection and Storage

(i) Privacy Policies: All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner. The privacy policy must clearly and explicitly:

Identify what data, if any, the app/service collects, how it collects that data, and all uses of that data.

Confirm that any third party with whom an app shares user data (in compliance with these Guidelines)-such as analytics tools, advertising networks and third-party SDKs, as well as any parent, subsidiary or other related entities that will have access to user data-will provide the same or equal protection of user data as stated in the app's privacy policy and required by these Guidelines.

Explain its data retention/deletion policies and describe how a user can revoke consent and/or request deletion of the user's data.

(ii) Permission: Apps that collect user or usage data must secure user consent for the collection, even if such data is considered to be anonymous at the time of or immediately following collection. Paid functionality must not be dependent on or require a user to grant access to this data. Apps must also provide the customer with an easily accessible and understandable way to withdraw consent. Ensure your purpose strings clearly and completely describe your use of the data. Apps that collect data for a legitimate interest without consent by relying on the terms of the European Union's General Data Protection Regulation ("GDPR") or similar statute must comply with all terms of that law. Learn more about Requesting Permission.

(iii) Data Minimization: Apps should only request access to data relevant to the core functionality of the app and should only collect and use data that is required to accomplish the relevant task. Where possible, use the out-of-process picker or a share sheet rather than requesting full access to protected resources like Photos or Contacts.

(iv) Access: Apps must respect the user's permission settings and not attempt to manipulate, trick, or force people to consent to unnecessary data access. For example, apps that include the ability to post photos to a social network must not also require microphone access before allowing the user to upload photos. Where possible, provide alternative solutions for users who don't grant consent. For example, if a user declines to share Location, offer the ability to manually enter an address.

(v) Account Sign-In: If your app doesn't include significant account-based features, let people use it without a login. If your app supports account creation, you must also offer account deletion within the app. Apps may not require users to enter personal information to function, except when directly relevant to the core functionality of the app or required by law. If your core app functionality is not related to a specific social network (e.g. Facebook, WeChat, Weibo, Twitter, etc.), you must provide access without a login or via another mechanism. Pulling basic profile information, sharing to the social network, or inviting friends to use the app are not considered core app functionality. The app must also include a mechanism to revoke social network credentials and disable data access between the app and social network from within the app. An app may not store credentials or tokens to social networks off of the device and may only use such credentials or tokens to directly connect to the social network from the app itself while the app is in use.

(vi) Developers that use their apps to surreptitiously discover passwords or other private data will be removed from the Apple Developer Program.

(vii) SafariViewController must be used to visibly present information to users; the controller may not be hidden or obscured by other views or layers. Additionally, an app may not use SafariViewController to track users without their knowledge and consent.

(viii) Apps that compile personal information from any source that is not directly from the user or without the user's explicit consent, even public databases, are not permitted on the App Store.

(ix) Apps that provide services in highly-regulated fields (such as banking and financial services, healthcare, gambling, legal cannabis use, and air travel) or that require sensitive user information should be submitted by a legal entity that provides the services, and not by an individual developer. Apps that facilitate the legal sale of cannabis must be geo-restricted to the corresponding legal jurisdiction.

(x) Apps may request basic contact information (such as name and email address) so long as the request is optional for the user, features and services are not conditional on providing the information, and it complies with all other provisions of these guidelines, including limitations on collecting information from kids.

5.1.2 Data Use and Sharing

(i) Unless otherwise permitted by law, you may not use, transmit, or share someone's personal data without first obtaining their permission. You must provide access to information about how and where the data will be used. Data collected from apps may only be shared with third parties to improve the app or serve advertising (in compliance with the Apple Developer Program License Agreement). You must receive explicit permission from users via the App Tracking Transparency APIs to track their activity. Learn more about tracking. Apps that share user data without user consent or otherwise complying with data privacy laws may be removed from sale and may result in your removal from the Apple Developer Program.

(ii) Data collected for one purpose may not be repurposed without further consent unless otherwise explicitly permitted by law.

(iii) Apps should not attempt to surreptitiously build a user profile based on collected data and may not attempt, facilitate, or encourage others to identify anonymous users or reconstruct user profiles based on data collected from Apple-provided APIs or any data that you say has been collected in an "anonymized," "aggregated," or otherwise non-identifiable way.

(iv) Do not use information from Contacts, Photos, or other APIs that access user data to build a contact database for your own use or for sale/distribution to third parties, and don't collect information about which other apps are installed on a user's device for the purposes of analytics or advertising/marketing.

(v) Do not contact people using information collected via a user's Contacts or Photos, except at the explicit initiative of that user on an individualized basis; do not include a Select All option or default the selection of all contacts. You must provide the user with a clear description of how the message will appear to the recipient before sending it (e.g. What will the message say? Who will appear to be the sender?).

(vi) Data gathered from the HomeKit API, HealthKit, Clinical Health Records API, MovementDisorder APIs, ClassKit or from depth and/or facial mapping tools (e.g. ARKit, Camera APIs, or Photo APIs) may not be used for marketing, advertising or use-based data mining, including by third parties. Learn more about best practices for implementing CallKit, HealthKit, ClassKit, and ARKit.

(vii) Apps using Apple Pay may only share user data acquired via Apple Pay with third parties to facilitate or improve delivery of goods and services.

5.1.3 Health and Health Research
Health, fitness, and medical data are especially sensitive and apps in this space have some additional rules to make sure customer privacy is protected:

(i) Apps may not use or disclose to third parties data gathered in the health, fitness, and medical research context-including from the Clinical Health Records API, HealthKit API, Motion and Fitness, MovementDisorderAPIs, or health-related human subject research-for advertising, marketing, or other use-based data mining purposes other than improving health management, or for the purpose of health research, and then only with permission. Apps may, however, use a user's health or fitness data to provide a benefit directly to that user (such as a reduced insurance premium), provided that the app is submitted by the entity providing the benefit, and the data is not shared with a third party. You must disclose the specific health data that you are collecting from the device.

(ii) Apps must not write false or inaccurate data into HealthKit or any other medical research or health management apps, and may not store personal health information in iCloud.

(iii) Apps conducting health-related human subject research must obtain consent from participants or, in the case of minors, their parent or guardian. Such consent must include the (a) nature, purpose, and duration of the research; (b) procedures, risks, and benefits to the participant; (c) information about confidentiality and handling of data (including any sharing with third parties); (d) a point of contact for participant questions; and (e) the withdrawal process.

(iv) Apps conducting health-related human subject research must secure approval from an independent ethics review board. Proof of such approval must be provided upon request.

5.1.4 Kids
For many reasons, it is critical to use care when dealing with personal data from kids, and we encourage you to carefully review all the requirements for complying with laws like the Children's Online Privacy Protection Act ("COPPA"), the European Union's General Data Protection Regulation ("GDPR"), and any other applicable regulations or laws.

Apps may ask for birthdate and parental contact information only for the purpose of complying with these statutes, but must include some useful functionality or entertainment value regardless of a person's age.

Apps intended primarily for kids should not include third-party analytics or third-party advertising. This provides a safer experience for kids. In limited cases, third-party analytics and third-party advertising may be permitted provided that the services adhere to the same terms set forth in Guideline 1.3.

Moreover, apps in the Kids Category or those that collect, transmit, or have the capability to share personal information (e.g. name, address, email, location, photos, videos, drawings, the ability to chat, other personal data, or persistent identifiers used in combination with any of the above) from a minor must include a privacy policy and must comply with all applicable children's privacy statutes. For the sake of clarity, the parental gate requirement for the Kid's Category is generally not the same as securing parental consent to collect personal data under these privacy statutes.

As a reminder, Guideline 2.3.8 requires that use of terms like "For Kids" and "For Children" in app metadata is reserved for the Kids Category. Apps not in the Kids Category cannot include any terms in app name, subtitle, icon, screenshots or description that imply the main audience for the app is children.

5.1.5 Location Services
Use Location services in your app only when it is directly relevant to the features and services provided by the app. Location-based APIs shouldn't be used to provide emergency services or autonomous control over vehicles, aircraft, and other devices, except for small devices such as lightweight drones and toys, or remote control car alarm systems, etc. Ensure that you notify and obtain consent before collecting, transmitting, or using location data. If your app uses location services, be sure to explain the purpose in your app; refer to the Human Interface Guidelines for best practices for doing so.

5.2 Intellectual Property
Make sure your app only includes content that you created or that you have a license to use. Your app may be removed if you've stepped over the line and used content without permission. Of course, this also means someone else's app may be removed if they've "borrowed" from your work. If you believe your intellectual property has been infringed by another developer on the App Store, submit a claim via our web form. Laws differ in different countries and regions, but at the very least, make sure to avoid the following common errors:

5.2.1 Generally: Don't use protected third-party material such as trademarks, copyrighted works, or patented ideas in your app without permission, and don't include misleading, false, or copycat representations, names, or metadata in your app bundle or developer name. Apps should be submitted by the person or legal entity that owns or has licensed the intellectual property and other relevant rights.

5.2.2 Third-Party Sites/Services: If your app uses, accesses, monetizes access to, or displays content from a third-party service, ensure that you are specifically permitted to do so under the service's terms of use. Authorization must be provided upon request.

5.2.3 Audio/Video Downloading: Apps should not facilitate illegal file sharing or include the ability to save, convert, or download media from third-party sources (e.g. Apple Music, YouTube, SoundCloud, Vimeo, etc.) without explicit authorization from those sources. Streaming of audio/video content may also violate Terms of Use, so be sure to check before your app accesses those services. Documentation must be provided upon request.

5.2.4 Apple Endorsements: Don't suggest or imply that Apple is a source or supplier of the App, or that Apple endorses any particular representation regarding quality or functionality. If your app is selected as an "Editor's Choice," Apple will apply the badge automatically.

5.2.5 Apple Products: Don't create an app that appears confusingly similar to an existing Apple product, interface (e.g. Finder), app (such as the App Store, iTunes Store, or Messages) or advertising theme. Apps and extensions, including third-party keyboards and Sticker packs, may not include Apple emoji. iTunes music previews may not be used for their entertainment value (e.g. as the background music to a photo collage or the soundtrack to a game) or in any other unauthorized manner. If your app displays Activity rings, they should not visualize Move, Exercise, or Stand data in a way that resembles the Activity control. The Human Interface Guidelines have more information on how to use Activity rings. If your app displays Apple Weather data, it should follow the attribution requirements provided in the WeatherKit documentation.

5.3 Gaming, Gambling, and Lotteries
Gaming, gambling, and lotteries can be tricky to manage and tend to be one of the most regulated offerings on the App Store. Only include this functionality if you've fully vetted your legal obligations everywhere you make your app available and are prepared for extra time during the review process. Some things to keep in mind:

5.3.1 Sweepstakes and contests must be sponsored by the developer of the app.

5.3.2 Official rules for sweepstakes, contests, and raffles must be presented in the app and make clear that Apple is not a sponsor or involved in the activity in any manner.

5.3.3 Apps may not use in-app purchase to purchase credit or currency for use in conjunction with real money gaming of any kind.

5.3.4 Apps that offer real money gaming (e.g. sports betting, poker, casino games, horse racing) or lotteries must have necessary licensing and permissions in the locations where the app is used, must be geo-restricted to those locations, and must be free on the App Store. Illegal gambling aids, including card counters, are not permitted on the App Store. Lottery apps must have consideration, chance, and a prize.

5.4 VPN Apps
Apps offering VPN services must utilize the NEVPNManager API and may only be offered by developers enrolled as an organization. You must make a clear declaration of what user data will be collected and how it will be used on an app screen prior to any user action to purchase or otherwise use the service. Apps offering VPN services may not sell, use, or disclose to third parties any data for any purpose, and must commit to this in their privacy policy. VPN apps must not violate local laws, and if you choose to make your VPN app available in a territory that requires a VPN license, you must provide your license information in the App Review Notes field. Parental control, content blocking, and security apps, among others, from approved providers may also use the NEVPNManager API. Apps that do not comply with this guideline will be removed from the App Store and you may be removed from the Apple Developer Program.

5.6 Developer Code of Conduct
Please treat everyone with respect, whether in your responses to App Store reviews, customer support requests, or when communicating with Apple, including your responses in App Store Connect. Do not engage in harassment of any kind, discriminatory practices, intimidation, bullying, and don't encourage others to engage in any of the above. Repeated manipulative or misleading behavior or other fraudulent conduct will lead to your removal from the Apple Developer Program.

Customer trust is the cornerstone of the App Store's success. Apps should never prey on users or attempt to rip off customers, trick them into making unwanted purchases, force them to share unnecessary data, raise prices in a tricky manner, charge for features or content that are not delivered, or engage in any other manipulative practices within or outside of the app.

Your Developer Program account will be terminated if you engage in activities or actions that are not in accordance with the Developer Code of Conduct. To restore your account, you may provide a written statement detailing the improvements you plan to make. If your plan is approved by Apple and we confirm the changes have been made, your account may be restored.

5.6.1 App Store Reviews
App Store customer reviews can be an integral part of the app experience, so you should treat customers with respect when responding to their comments. Keep your responses targeted to the user's comments and do not include personal information, spam, or marketing in your response.

Use the provided API to prompt users to review your app; this functionality allows customers to provide an App Store rating and review without the inconvenience of leaving your app, and we will disallow custom review prompts.

5.6.2 Developer Identity
Providing verifiable information to Apple and customers is critical to customer trust. Your representation of yourself, your business, and your offerings on the App Store must be accurate. The information you provide must be truthful, relevant, and up-to-date so that Apple and customers understand who they are engaging with and can contact you regarding any issues.

5.6.3 Discovery Fraud
Participating in the App Store requires integrity and a commitment to building and maintaining customer trust. Manipulating any element of the App Store customer experience such as charts, search, reviews, or referrals to your app erodes customer trust and is not permitted.

5.6.4 App Quality
Customers expect the highest quality from the App Store, and maintaining high quality content, services, and experiences promotes customer trust. Indications that this expectation is not being met include excessive customer reports about concerns with your app, such as negative customer reviews, and excessive refund requests. Inability to maintain high quality may be a factor in deciding whether a developer is abiding by the Developer Code of Conduct.

After You Submit

Once you've submitted your app and metadata in App Store Connect and you're in the review process, here are some things to keep in mind:

Timing: App Review will examine your app as soon as we can. However, if your app is complex or presents new issues, it may require greater scrutiny and consideration. And remember that if your app is repeatedly rejected for the same guideline violation or you've attempted to manipulate the App Review process, review of your app will take longer to complete. Learn more about

Status Updates: The current status of your app will be reflected in App Store Connect, so you can keep an eye on things from there.

Expedite Requests: If you have a critical timing issue, you can request an expedited review. Please respect your fellow developers by seeking expedited review only when you truly need it. If we find you're abusing this system, we may reject your requests going forward.

Release Date: If your release date is set for the future, the app will not appear on the App Store until that date, even if it is approved by App Review. And remember that it can take up to 24-hours for your app to appear on all selected storefronts.

Rejections: Our goal is to apply these guidelines fairly and consistently, but nobody's perfect. If your app has been rejected and you have questions or would like to provide additional information, please use App Store Connect to communicate directly with the App Review team. This may help get your app on the store, and it can help us improve the App Review process or identify a need for clarity in our policies.

Appeals: If you disagree with the outcome of your review, or would like to suggest a change to the guideline itself, please submit an appeal. This may help get your app on the store, and it can help us improve the App Review process or identify a need for clarity in our policies.

Bug Fix Submissions: For apps that are already on the App Store, bug fixes will no longer be delayed over guideline violations except for those related to legal or safety issues. If your app has been rejected, and qualifies for this process, please use App Store Connect to communicate directly with the App Review team indicating that you would like to take advantage of this process and plan to address the issue in your next submission.

We're excited to see what you come up with next!

Last Updated: June 06, 2022

# data[].attributes.attachment_link.description
The App Store Review Guidelines provide guidance and examples across a range of development topics, including user interface design, functionality, content, and the use of specific technologies. These guidelines are designed to help you prepare your Apps for the approval process.

# data[].attributes.attachment_link.readable_text
> Le Mooc " l'atelier RGPD " fait peau neuve !

Le Mooc " l'atelier RGPD " est actuellement indisponible.
Des évolutions sont en cours pour accueillir de nouveaux contenus.
Merci pour votre patience et à très bientôt !

Les mots clés associés à cet article

Ceci peut également vous intéresser ...

# data[].attributes.attachment_link.title
Le Mooc " l'atelier RGPD " fait peau neuve !

# data[].attributes.attachment_link.description
Le Mooc " l'atelier RGPD " fait peau neuve ! Le Mooc " l'atelier RGPD " est actuellement indisponible. Des évolutions sont en cours pour accueillir de nouveaux contenus. Merci pour votre patience et à très bientôt ! Les mots clés associés à cet article Ceci peut également vous intéresser ...

# data[].attributes.attachment_link.readable_text
Fonction créée par le règlement européen à la protection des données (RGPD) entré en vigueur le 25 mai dernier, le Délégué à la protection des données (abrégé DPD, DPO en anglais) est la personne qui veille au respect du cadre légal concernant la protection des données au sein d'une organisation.

La nomination d'un DPD est obligatoire pour toute autorité publique ou tout organisme public (collectivités territoriales, État, établissements publics, etc.).

Contacter le délégué à la protection des données

Rôle et activités du délégué à la protection des données

Le délégué à la protection des données veille au respect du RGPD par les responsables des traitements de données personnelles mis en œuvre dans le ministère et les établissements sous sa tutelle ainsi qu'aux sous-traitants et prestataires prenant part à ces traitements. Le DPD est associé à la mise en place de tout nouveau traitement ou à toute modification d'un traitement en cours et doit donner son avis ou faire des recommandations.

Les missions principales du Délégué à la protection des données sont :

Veiller au respect du cadre légal : le DPD veille en toute indépendance au respect du RGPD et plus largement de l'ensemble des normes applicables par les responsables des traitements ou des sous-traitants en matière de protection des données à caractère personnel. Ses analyses et conseils s'étendent aux sous-traitants et prestataires prenant part aux traitements mis en place par les responsables de traitement. Il est obligatoirement consulté avant la mise en œuvre d'un nouveau traitement ou la modification substantielle d'un traitement en cours et peut faire toute recommandation aux responsables de traitement de l'administration centrale des deux ministères.

Alerter les responsables de traitement : Le DPD informe sans délai les responsables de traitement de tout risque que le non-respect de ses recommandations ou toute initiative des utilisateurs ou de concepteurs de traitements feraient courir à l'institution. Il veille à formaliser une procédure pour informer directement les responsables de traitement d'une non-conformité majeure.

Analyser, investiguer, auditer et contrôler : Le DPD pilote, de façon maîtrisée et indépendante, toute action permettant de juger du degré de conformité au RGPD, de mettre en évidence les éventuelles non-conformités, de vérifier la bonne application de procédures, méthodes ou consignes relatives à la protection des données personnelles. Il est en relation avec le DPD ministériel sur ces questions.

Établir et maintenir une documentation sur les traitements effectués : Le DPD s'assure de l'existence d'une documentation relative aux traitements de données à caractère personnel (dont le registre des traitements) et de sa bonne conservation et veille à son accessibilité par l'autorité de contrôle (CNIL).

Assurer la médiation avec les personnes concernées : Le DPD reçoit les réclamations éventuelles des personnes concernées par les traitements et veille au respect du droit des personnes. Il traite ces réclamations et plaintes avec impartialité, ou met en œuvre les procédures propres à assurer leur bon traitement en lien avec les services académiques.

Accompagner et sensibiliser : le DPD assure une mission d'information et de sensibilisation des services académiques au travers notamment d'actions de formation et de diffusion de supports de communication sur la protection des données personnelles.

Interagir avec l'autorité de contrôle : Le DPD est, pour l'académie, le point de contact privilégié de l'autorité de contrôle (CNIL), avec laquelle il communique en toute indépendance sur les questions relatives aux traitements mis en œuvre.

Présenter un rapport annuel au secrétaire général : Le DPD rend compte de son action en présentant chaque année un rapport secrétaire général du Ministère.

# data[].attributes.attachment_link.title
Délégué à la protection des données (DPD)

# data[].attributes.attachment_link.description
Fonction créée par le règlement européen à la protection des données (RGPD) entré en vigueur le 25 mai dernier, le Délégué à la protection des données (abrégé DPD, DPO en anglais) est la personne qui veille au respect du cadre légal concernant la protection des données au sein d'une

# data[].attributes.headline
Le RGPD expliqué par un développeur [Conférence AFUP 05/2018 [PHP Tour Montpellier 2018]]

# data[].attributes.subject
Le RGPD expliqué par un développeur [Conférence AFUP 05/2018 [PHP Tour Montpellier 2018]]

# data[].attributes.attachment_link.readable_text
Description

Souvent, le métier du développeur est bouleversé par une nouvelle technologie, qu'elle soit un nouveau langage, un nouvel outil ou un nouveau concept. Mais il arrive également qu'il le soit par quelque chose qui n'a rien à voir avec la technologie, et le RGPD est l'un de ces choses. Derrière cet acronyme se cache en effet un texte de loi dont nous allons devoir à l'avenir, et très rapidement, tenir compte à la fois lors de nos développement et dans nos relations avec nos client et nos utilisateurs. À moins d'une dizaine de jours de la fin du délai de mise en conformité, je vous propose de faire le point sur l'impact du RGPD dans notre quotidien de développeur !

Vidéo

Le speaker

Frédéric HARDY

Frédéric Hardy utilise PHP professionnellement depuis seize ans. Architecte logiciel, administrateur système, infographiste ergonome, consultant et formateur, il aime la programmation orientée objet, UNIX, les méthodes agiles, la facilitation graphique, les discussions intéressantes ainsi que la bonne cuisine et la bière. Il est de plus le créateur et le développeur principal de atoum, un framework de test unitaire simple, moderne et intuitif pour PHP.

# data[].attributes.attachment_link.title
AFUP - Le RGPD expliqué par un développeur

# data[].attributes.attachment_link.description
Souvent, le métier du développeur est bouleversé par une nouvelle technologie, qu'elle soit un nouveau langage, un nouvel outil ou un nouveau concept. Mais il arrive également qu'il le soit par quelque chose qui n'a rien à voir avec la technologie, et le RGPD est l'un de ces choses.

# data[].attributes.attachment_link.readable_text
Avec une fonction située au cœur de la conformité au règlement européen sur la protection des données (RGPD), le délégué à la protection des données (DPO) conseille et accompagne les organismes qui le désignent.

# data[].attributes.attachment_link.title
Le délégué à la protection des données (DPO)

# data[].attributes.attachment_link.description
Avec une fonction située au cœur de la conformité au règlement européen sur la protection des données (RGPD), le délégué à la protection des données (DPO) conseille et accompagne les organismes qui le désignent.

# data[].attributes.attachment_link.readable_text
Asking Permission to Track

With iOS 14.5, iPadOS 14.5, and tvOS 14.5 and later, you need to receive the user's permission through the AppTrackingTransparency framework in order to track them or access their device's advertising identifier. Tracking refers to the act of linking user or device data collected from your app with user or device data collected from other companies' apps, websites, or offline properties for targeted advertising or advertising measurement purposes. Tracking also refers to sharing user or device data with data brokers.

Examples of tracking include, but are not limited to:

Displaying targeted advertisements in your app based on user data collected from apps and websites owned by other companies.

Sharing device location data or email lists with a data broker.

Sharing a list of emails, advertising IDs, or other IDs with a third-party advertising network that uses that information to retarget those users in other developers' apps or to find similar users.

Placing a third-party SDK in your app that combines user data from your app with user data from other developers' apps to target advertising or measure advertising efficiency, even if you don't use the SDK for these purposes. For example, using an analytics SDK that repurposes the data it collects from your app to enable targeted advertising in other developers' apps.

The following use cases are not considered tracking, and do not require user permission through the AppTrackingTransparency framework:

When user or device data from your app is linked to third-party data solely on the user's device and is not sent off the device in a way that can identify the user or device.

When the data broker with whom you share data uses the data solely for fraud detection, fraud prevention, or security purposes. For example, using a data broker solely to prevent credit card fraud.

When the data broker is a consumer reporting agency and the data is shared with them for purposes of (1) reporting on a consumer's creditworthiness, or (2) obtaining information on a consumer's creditworthiness for the specific purpose of making a credit determination.

Using the AppTrackingTransparency Framework

To request permission to track the user and access the device's advertising identifier, use the AppTrackingTransparency framework. You must also include a purpose string in the system prompt that explains why you'd like to track the user. Unless you receive permission from the user to enable tracking, the device's advertising identifier value will be all zeros and you may not track them as described above.

While you can display the AppTrackingTransparency prompt whenever you choose, the device's advertising identifier value will only be returned once you present the prompt and the user grants permission. Use the purpose string to explain what this data will be used for to help the user understand what they're opting in to share. If the user allows apps to request to track, but has turned tracking off for your app, you can ask the user to change their preference for your app by providing a shortcut to Settings where they can change the tracking permission.

The ID for Vendors (IDFV), may be used for analytics across apps from the same content provider. The IDFV may not be combined with other data to track a user across apps and websites owned by other companies unless you have been granted permission to track by the user.

For more information, see:

# data[].attributes.attachment_link.title
User Privacy and Data Use - App Store - Apple Developer

# data[].attributes.attachment_link.description
With iOS 14.5, iPadOS 14.5, and tvOS 14.5 and later, you need to receive the user's permission through the AppTrackingTransparency framework in order to track them or access their device's advertising identifier. Tracking refers to the act of linking user or device data collected from your app with user or device data collected from other companies' apps, websites, or offline properties for targeted advertising or advertising measurement purposes.

# data[].attributes.attachment_link.readable_text
The main purpose of this document is to describe how to install and use the Privacy Manager SDK (in further text: SDK). The aim of the SDK is to enable App or embedded software developers to create ePrivacy and GDPR compliant apps without deep knowledge about underlying technical compliance procedures. The SDK is fully TCF 2.0 compliant.
Objectives of This Article
The content of this document is intended to be sufficient for:

Application software developers to find out how to install the SDK and use implemented features of the SDK.

The stakeholders to determine whether their needs are sufficiently covered.

The Product Manager to determine whether the product features are sufficiently documented and meet customer needs.

SDK Features
The main purpose of the SDK is to help mobile application developers to:

Control the vendors they wish to allow to access and process their users' personal data, and disclose these choices to other parties in the online advertising ecosystem;

Seek user consent under the ePrivacy Directive (for setting cookies or similar technical applications that access information on a device) and/or the GDPR in line with applicable legal requirements and signal the consent status through the online advertising ecosystem.

On the iOS platform, SDK is implemented as LRPrivacyManager.xcframework (it is compatible with applications written in Swift and Objective-C programming languages).

The main module for the communication with the SDK is the instance of singleton class with the delegate/ protocol.

SDK requires a configuration file, which enables the publisher to customize how the consent wall will look (colors, text, buttons) and also enables the content (vendors) filtering when presented.

SDK supports TCF v2.0 CMP API.

For the full reference click here.

All the TCF v2.0 functions are implemented as module-level global functions.
SDK Installation
To proceed with the SDK installation:

Add iOS SDK to Your Project (GDPR for Mobile)

We offer our SDK as a pre-compiled package that you can add to your application. We support the latest three major versions of iOS and Swift 5.2 and newer. The package can be added using CocoaPods or manually.

Note

Starting from version 1.1.5 of LRPrivacyManagerSDK, Xcode 11 is not supported. Please update Xcode to 12+.

1. If you haven't already, install the latest version of CocoaPods.

2. Add this line to your Podfile:

# Uncomment the next line to define a global platform for your project
 platform :ios, '10.0'

pod 'LRPrivacyManagerSDK'

target 'YOUR_PROJECT' do
  # Comment the next line if you don't want to use dynamic frameworks
  use_frameworks!

  # Pods for YOUR_PROJECT

end

3. Run pod install in your terminal to install the Privacy Manager SDK.

Note

When you integrate LRPrivacyManagerSDK with CocoaPod, make sure you have cleared (build) cache and derived data in Xcode so you always use the latest Privacy Manager SDK version.

SDK could be added manually to Xcode Project, in the usual manner like any other Cocoa Touch Framework. You can find .xcframework file on the next link.

Caution

Starting from version 1.1.5, LRPreferenceLinkSDK is a dependency of the LRPrivacyManagerSDK. Therefore it is required to include LRPreferenceLinkSDK in your project. Download the latest version of LRPreferenceLinkSDK from this link and include it in your project following the same procedure described below.

1. It is a good idea to create a separate group for the third-party framework. Drag & drop LRPrivacyManager.xcframework to the newly created group,

2. If not already checked, check 'Copy items if needed' check box.

Once the SDK has been successfully imported, continue with this procedure.

3. In the Project Navigator select your Project,

4. Select the desired target,

5. Make sure that LRPrivacyManagerSDK.xcframework exists in 'Frameworks, Libraries and Embedded Content' section. 'Embed & Sign' option needs to be selected, as well.

SDK initialization requires App ID and fallback configuration.

App ID is generated through App creation process on Console. If you didn't already create an app, for details how to do it, see " Create New Configuration ."

Fallback configuration is also generated through the same process.

The initialization runs on a background thread to avoid blocking UI. Initialization status is handled through delegate events, defined by the LRPrivacyManagerDelegate. Also, check API reference for more information regarding usage of the SDK.
Step-by-step Guide
When LRPrivacyManager SDK is added to the project, it is needed to initialize it. The initialization process will prepare the SDK for the interactions with the user and the application. It is important to launch the SDK initialization as soon as possible to ensure that the consent status is available.

It is recommended to do SDK configuration in the AppDelegate, but not necessary. The only required is to configure SDK before initialization.

Configure SDK by Providing Application App ID and Fallback Configuration:

Fallback configuration is used in case there is no Internet connection.

Fallback configuration needs to be shipped as an asset with host application and file url needs to be passed as an argument (configuration file URL or configuration Data).

Fallback configuration can be downloaded through Console.

Swift

// Configure with file URL
guard let fallbackConfiguration = LRConfiguration(configurationURL: <#URL#>) else {
    fatalError("Fallback configuration file not available in resources") }
let config = LRPrivacyManagerConfig(appId: <#String#>,
                                    fallbackConfiguration: fallbackConfiguration)

or

// Configure with configuration Data
guard let fallbackConfiguration = LRConfiguration(configurationData: <#Data#>) else {
    fatalError("Fallback configuration couldn't be created from data") }
let config = LRPrivacyManagerConfig(appId: <#String#>,
                                    fallbackConfiguration: fallbackConfiguration)

Objective-C

// Configure with file URL
LRConfiguration *config = [[LRConfiguration alloc] initWithConfigurationURL:<#(NSURL * _Nonnull)#>];
LRPrivacyManagerConfig *lrpConfig = [[LRPrivacyManagerConfig alloc] initWithAppId:<#(NSString * _Nonnull)#> fallbackConfiguration:config];

or

// Configure with configuration Data
LRConfiguration *config = [[LRConfiguration alloc] initWithConfigurationData:<#(NSData * _Nonnull)#>];
LRPrivacyManagerConfig *lrpConfig = [[LRPrivacyManagerConfig alloc] initWithAppId:<#(NSString * _Nonnull)#> fallbackConfiguration: config];

Examples on How You Can Properly Initialize LRPrivacyManager SDK

Swift

import UIKit
import LRPRivacyManagerSDK

// Add inside AppDelegate
@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        if let filePath = Bundle.main.path(forResource: <#String#>, ofType: "json"),
           let fallbackConfiguration = LRConfiguration(configurationURL: URL(fileURLWithPath: filePath)) {
            let config = LRPrivacyManagerConfig(appId: <#String#>,
                                                fallbackConfiguration: fallbackConfiguration)
            LRPrivacyManager.configure(with: config)
        }
        return true
    }
}

extension AppDelegate: LRPrivacyManagerDelegate {
    func eventFired(event: LREvent) {
        switch event {
        case .tcloaded:
            print("LRPrivacyManagerDelegate, eventFired: tcloaded")
        case .cmpuishown:
            print("LRPrivacyManagerDelegate, eventFired: cmpuishown")
        case .useractioncomplete:
            print("LRPrivacyManagerDelegate, eventFired: useractioncomplete")
        case .stub:
            print("LRPrivacyManagerDelegate, eventFired: stub")
        case .loading:
            print("LRPrivacyManagerDelegate, eventFired: loading")
        case .disabled:
            print("LRPrivacyManagerDelegate, eventFired: disabled")
        case .auditIdChanged:
            print("LRPrivacyManagerDelegate, eventFired: auditIdChanged")
        case .acceptAllButtonClicked:
            print("LRPrivacyManagerDelegate, eventFired: acceptAllButtonClicked")
        case .denyAllButtonClicked:
            print("LRPrivacyManagerDelegate, eventFired: denyAllButtonClicked")
        case .saveAndExitButtonClicked:
            print("LRPrivacyManagerDelegate, eventFired: saveAndExitButtonClicked")
        case .exitButtonClicked:
            print("LRPrivacyManagerDelegate, eventFired: exitButtonClicked")
        case .shouldPresentConsentWall:
            print("LRPrivacyManagerDelegate, eventFired: shouldPresentConsentWall")
        case .userInterfaceAlreadyPresented:
            print("LRPrivacyManagerDelegate, eventFired: userInterfaceAlreadyPresented")
        case .notSubjectToGDPR:
            print("LRPrivacyManagerDelegate, eventFired: notSubjectToGDPR")
        case .loaded:
            print("LRPrivacyManagerDelegate, eventFired: loaded")
        case .dauLogSent:
            print("LRPrivacyManagerDelegate, eventFired: dauLogSent")
        case .syncedWithPreferenceLink:
            print("LRPrivacyManagerDelegate, eventFired: syncedWithPreferenceLink")
        case .attInitialContinue:
            print("LRPrivacyManagerDelegate, eventFired: attInitialContinue")
        case .attInitialCanceled:
            print("LRPrivacyManagerDelegate, eventFired: attInitialCanceled")
        case .attReminderSettings:
            print("LRPrivacyManagerDelegate, eventFired: attReminderSettings")
        case .attReminderCanceled:
            print("LRPrivacyManagerDelegate, eventFired: attReminderCanceled")
        @unknown default:
            print("Unhandled case")
        }
    }

    func didReceiveError(_ error: Error) {
      print("LRPrivacyManagerDelegate, didReceiveError: \(error)")
    }
}


// Add inside ViewController
import UIKit
import LRPrivacyManagerSDK

class ViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        LRPrivacyManager.shared.initialize { success, error in
            if success {
                print("SDK is Ready")
            } else {
                print("SDK init error: \(String(describing: error))")
            }
        }
    }
    // Example of adding action on button to force present userInterface
    @IBAction func presentUI(_ sender: Any) {
        LRPrivacyManager.shared.presentUserInterface(callback: nil)
    }
}

Objective-C

// Add inside AppDelegate
#import "AppDelegate.h"
#import <LRPrivacyManagerSDK/LRPrivacyManagerSDK-Swift.h>
...
@interface AppDelegate () <LRPrivacyManagerDelegate>

@end
...
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // Override point for customization after application launch.
    NSURL *configURL = [[NSBundle mainBundle] URLForResource: @"tcf_fallback_configuration" withExtension: @"json"];

    LRConfiguration *config = [[LRConfiguration alloc] initWithConfigurationURL: configURL]
    LRPrivacyManagerConfig *lrpConfig = [[LRPrivacyManagerConfig alloc] initWithAppId:<#(NSString * _Nonnull)#> fallbackConfiguration: config];
    // Subscribe to receive SDK events
    [LRPrivacyManager setLRPrivacyManagerDelegateWithDelegate:self];
    // Apply configuration
    [LRPrivacyManager configureWith: lrpConfig];

    return YES;
}

- (void)eventFiredWithEvent:(enum LREvent)event {
    switch (event) {
        case LREventTcloaded:
            NSLog(@"LRPrivacyManagerDelegate, eventFired: tcloaded");
            break;
        case LREventCmpuishown:
            NSLog(@"LRPrivacyManagerDelegate, eventFired: cmpuishown");
            break;
        case LREventUseractioncomplete:
            NSLog(@"LRPrivacyManagerDelegate, eventFired: useractioncomplete");
            break;
        case LREventStub:
            NSLog(@"LRPrivacyManagerDelegate, eventFired: stub");
            break;
        case LREventLoading:
            NSLog(@"LRPrivacyManagerDelegate, eventFired: loading");
            break;
        case LREventDisabled:
            NSLog(@"LRPrivacyManagerDelegate, eventFired: disabled");
            break;
        case LREventAuditIdChanged:
            NSLog(@"LRPrivacyManagerDelegate, eventFired: auditIdChanged");
            break;
        case LREventAcceptAllButtonClicked:
            NSLog(@"LRPrivacyManagerDelegate, eventFired: acceptAllButtonClicked");
            break;
        case LREventDenyAllButtonClicked:
            NSLog(@"LRPrivacyManagerDelegate, eventFired: denyAllButtonClicked");
            break;
        case LREventSaveAndExitButtonClicked:
            NSLog(@"LRPrivacyManagerDelegate, eventFired: saveAndExitButtonClicked");
            break;
        case LREventExitButtonClicked:
            NSLog(@"LRPrivacyManagerDelegate, eventFired: exitButtonClicked");
            break;
        case LREventShouldPresentConsentWall:
            NSLog(@"LRPrivacyManagerDelegate, eventFired: shouldPresentConsentWall");
            break;
        case LREventUserInterfaceAlreadyPresented:
            NSLog(@"LRPrivacyManagerDelegate, eventFired: userInterfaceAlreadyPresented");
            break;
        case LREventNotSubjectToGDPR:
            NSLog(@"LRPrivacyManagerDelegate, eventFired: notSubjectToGDPR");
            break;
        case LREventLoaded:
            NSLog(@"LRPrivacyManagerDelegate, eventFired: loaded");
            break;
        case LREventDauLogSent:
            NSLog(@"LRPrivacyManagerDelegate, eventFired: dauLogSent");
            break;
        case LREventSyncedWithPreferenceLink:
            NSLog(@"LRPrivacyManagerDelegate, eventFired: syncedWithPreferenceLink");
            break;
    }
}

- (void)didReceiveError:(NSError * _Nonnull)error {
    NSString *errorString = [NSString stringWithFormat: @"%@ %@", @"LRPrivacyManagerDelegate, didReceiveError: ", error];
    NSLog(@"%@", errorString);
}
...

// Add inside ViewController.m
#import "ViewController.h"
#import <LRPrivacyManagerSDK/LRPrivacyManagerSDK-Swift.h>

@interface ViewController ()
@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];

    [[LRPrivacyManager shared] initializeWithSdkInitializedHandler:^(BOOL success, NSError *error) {
        if (success) {
            NSLog(@"init success");
        } else {
            NSLog(@"init fail");
        }
    }];
}

// Example of adding action on button to force present userInterface
- (IBAction)presentUI:(id)sender {
    [[LRPrivacyManager shared] presentUserInterfaceWithCallback:nil];
}

@end

Note

Have in mind that it is recommended that initialization should be called once application is ready to show consent wall. Do not call it while application is in initialization process or on intro screen.

SDK has its own algorithms for automatic presenting consent wall and can be bad for user experience if it is shown when user is not expecting to see it.

Automatic presenting consent wall is done only in fully featured SDK version, not in headless implementation

In order to make sure that configuration for the SDK is present when starting first time in offline mode, the SDK will check if configuration is provided. The configuration must be provided in the file .json format in your application's bundle. After saving file to the application's bundle, it is recommended to provide file's URL to the SDK. Without this file SDK will not work.

Swift

// Load offline configuration from file
if let filePath = Bundle.main.path(forResource: "tcf_fallback_configuration", ofType: "json"),
   let fallbackConfiguration = LRConfiguration(configurationURL: URL(fileURLWithPath: filePath)) {
   // use fallbackConfiguration here...
}

Objective-C

NSURL *configURL = [[NSBundle mainBundle] URLForResource: @"tcf_fallback_configuration" withExtension: @"json"];

Note

SDK initialization and setting delegate can be called anywhere in the application, but it is required that configuration is called first. Delegate is responsible for handling SDK states. Please be informed that only after the SDK has been initialised and consent preference is provided, the TC Consent String as well as LiveRamp Consent String would be made available in UserDefaults for the Vendors to verify.

API Reference iOS SDK (GDPR for Mobile)

LRPrivacyManager.shared should be used to reference the LiveRamp SDK.

For API methods that are not returning immediately SDK communicates via callbacks. These callback are mostly consisting of a boolean value for success/failure of the operation and an error if operation failed. Some specific callbacks return a data object and a possible error.

If using full featured SDK (not the headless version), SDK will automatically present user interface when needed. Also in some cases it can be forced to show UI (e.g. when user wants to change previous consent).

When option for automatically consent wall display is disabled, it is your responsibility to call this method at the appropriate time. Event shouldPresentConsentWall is sent when SDK determines that consent wall should be presented.

Calling this method forces presenting user interface to the user. SDK will use callback, if provided, to inform about UI presentation status.

No return parameter

Returns consent data which represents decoded Consent strings, IAB and LR strings, that are stored inside the UserDefaults.

ConsentData object which consists out of:

specialFeatures: Included special features (mandatory)

purposes: Included purposes (mandatory)

purposesLegInt: Included legitimate interest for purposes (mandatory)

vendors: Included vendors which will be filtered inside function (mandatory)

vendorsLegInt: Included vendors legitimate interest (mandatory)

publisherTCConsent(optional): data is build out of 2 Bool values, givenConsent and givenLegIntConsent

No parameter

ConsentData object -> consists of five lists ( specialFeatures, purposes, purposesLegInt, vendors, vendorsLegInt) and publisherTCConsent which represents publisher consent if defined through configuration.

Returns AC string from UserDefaults if it exists, otherwise returns empty string.

No parameters

AC String -> stored inside UserDefaults under IAB key IABTCF_AddtlConsent.

Returns purposeOneTreatment from configuration which is represented as Bool value.

Parameters

No parameter

This function should be called when developer want to clear standard UserDefaults. It will preserve SDK related keys from the standard UserDefaults.

In the process, key-value pairs are saved in-memory. After clearing standard UserDefaults it is mandatory to restore them.

Restoring keys is done by calling restoreUserDefaultsKeys() function.

No parameter

No return parameter

Restore SDK related keys into the standard UserDefaults.

This function should be called to restore SDK related key-value pairs, previously temporary saved in-memory by persistUserDefaultsKeys() function.

No parameter

No return parameter

Give consent and save IAB TCF related Keys into the standard UserDefaults. For consent string(s) itself, beside predefined key used for standard TCString, there is also saved one for the custom, LRTCString.

No return parameter

Give full consent and save it under the IAB TCF Keys into the standard UserDefaults.

After calling this function full consent will be generated and the consent will be saved into the standard UserDefaults as per IAB standard under the IAB TCF keys and LR keys.

No return parameter

Revoke consent and save it under the IAB TCF Keys into the standard UserDefaults.

After calling this function revoke consent will be generated and the result will be saved into the standard UserDefaults as per IAB standard under the IAB TCF keys and LR keys.

No return parameter

Note

Available for V1.1.10 and Above

This API can be programatically called by configuring a text in Console to link to executeCommand(rejectAll) instead of a URL.

Set Privacy Manager language. If available (that means selected language code is in the list of available languages in configuration).

This language (if available) will override SDK configuration preferred language.

No return parameter

Processing data to check if vendor has consents inside TCString or LiveRampString. For checking consents it is needed to pass array of VendorData objects.

VendorData object has 3 parameters:

If no purposesIds and/or specialFeaturesIds are not added to VendorData object, consent will be checked for vendorId and all of his purposesIds and/or specialFeaturesIds. Otherwise, consents will be checked for vendorId and passed purposesIds and/or specialFeaturesIds inside VendorData object.

Array of vendor objects with pairs ( VendorData, hasConsent) for each object.

If SDK is not initialized properly nil will be returned for vendorConsents array and error will be logged.

Returns which consent type is given.

Tip

getConsentType() can be called when the .dauLogSent event is triggered to retrieve which consent type is sent.

No parameters

Consent type for a user which can be value defined in LRConsentType enumeration.

Removes all data from the UserDefaults that is set by LRPrivacyManagerSDK. Use this method in case it is required to remove all consent data related to the user. For example user signs out from the app and all consent must be removed.

Important

Keys required by IAB standard are not deleted from UserDefaults.

Synchronize privacy manager related data from UserDefaults with PreferenceLink. This method should be used for headless implementation of LRPrivacyManagerSDK.

When to call this method (suggestions):

When consent is given/changed

In
LRPrivacyManager.initialize(sdkInitializedHandler:)
handler

Before presenting consent wall

After returning to the app from the background

Important

Available from: v1.1.6 (iOS 14 only)

This method can be used to present the user with an IDFA explainer message (ATT - App Tracking Transparency) pre-prompt. To configure look and content of the ATT prompt screens, enable ATT for the application in the console.

Caution

This method must be called after SDK is initialized, otherwise it won't have desired configuration (you can use LRPrivacyManagerDelegate.eventFired(:) and wait for .loaded event)

NSUserTrackingUsageDescription must be set in Info.plist

Decide when to present ATT pre-prompt

Before consent wall

In order to present ATT pre-prompt before consent wall, you must disable automatic presenting of consent wall in the configuration settings. When 'Control when to surface Privacy Manager' is enabled, it is your responsibility to call presentUserInterface(callback: LRCompletionHandler?) at the appropriate time. Event shouldPresentConsentWall is sent when SDK determines that consent wall should be presented.

After consent wall

To show ATT pre-prompt after consent wall is closed use event userInteractionCompleted. After that event is received, you can call presentATTPrePrompt().

There are two types of ATT screens:

Following events are related to the ATT pre-prompt:

For more details please check events documentation.

This method will exit and no events will be triggered in following cases:

ATT is not enabled and configured in the console

SDK is not fully initialized and configuration is not available

User already authorized app tracking for the app

Get generated cookie sharing URL with query items that allows sharing consent with the WEB SDK through external browsers.

Generated cookie sharing URL.

In case cookie sharing URL couldn't be generated, unmodified URL will be returned.

SDK error states are defined with LRError enum (sdkError in future text).

SDK will return errors as standard Error type, to get more information you can cast it to LRError please cast it error as? LRError

missingConfiguration

Fallback configuration is missing. Please provide valid fallback LRConfiguration when initializing SDK.

Offline global vendor list is not provided. Please add fallback_vendor_list.json to your application.

To get string representation of LRConsentType call .description on enumeration case.

let consentType = LRConsentType.rejectAll
print(consentType.description) // NO_CONSENT

LRPrivacyManager SDK has one public __tcfapi function that can be universally used to get getTCData, ping, addEventListener and removeEventListener.

Function is called with 4 parameters. 2 parameters are optionals:

public func __tcfapi(command: String, version: Int, callback: Any?, parameter: Any?)

Note

When __tcfapi function is called command and version parameters are checked. If parameters are not valid error will be logged and execution will stop, so it is required to use function as per required usage.

First parameter is command. This parameter is used as String and valid values are:

These parameters are described in detail in continuance of this documentation.

Caution

If any other value is used for command parameter it will be invalid, error will be logged and execution will stop.

Second parameter is version. Required value for this parameter is 2.

Caution

If any other value is used for value parameter it will be invalid, error will be logged and execution will stop.

Third parameter is callback. This parameter is required to support format required for specific callback of required function. Different callback parameter is used for:

Note

For more information about callback for specific function, please check documented functions below.

Fourth parameter is called parameter and it is required to pass valid parameters to execute __tcfapi function properly.

Note

For more information about parameter for specific function, please check documented functions below.

Tip

As per IAB Documentation: All CMPs must support four required API commands: getTCData, ping, addEventListener and removeEventListener.

For more detailed documentation regarding tcfapi method parameters visit IAB's official How does the CMP provide the API?

LRPrivacyManager SDK provides the required API functions.

This section is a reference for the events exposed by the iOS SDK that you can leverage in your application.

In order to subscribe and listen to LRPrivacyManager event, follow the next steps:

1. In any class (AppDelegate or any ViewController) conform to LRPrivacyManagerDelegate protocol:

extension AppDelegate: LRPrivacyManagerDelegate {
   func eventFired(event: LREvent) {
        switch event {
        case .stub:
            print("LRPrivacyManagerDelegate, eventFired: stub")
        default:
            print("LRPrivacyManagerDelegate, eventFired: \(event.rawValue)")
        }
    }
    func didReceiveError(_ error: Error) {
        print("LRPrivacyManagerDelegate, didReceiveError: \(error)")
    }
}

@implementation AppDelegate

- (void)eventFiredWithEvent:(enum LREvent)event {
    switch (event) {
        case LREventStub:
            NSLog(@"LRPrivacyManagerDelegate, eventFired: stub");
            break;
        default:
            NSLog(@"LRPrivacyManagerDelegate, event fired %ld", (long)event);
            break;
    }
}

- (void)didReceiveError:(NSError * _Nonnull)error {
    NSLog(@"LRPrivacyManagerDelegate, didReceiveError: %@", error);
}

2. After that, set that class to the LRPrivacyManager delegate. This can be done using setLRPrivacyManagerDelegateclass method of LRPrivacyManager class.

LRPrivacyManager.setLRPrivacyManagerDelegate(delegate: self)

[LRPrivacyManager setLRPrivacyManagerDelegateWithDelegate:self];

Note

For full reference see public class LREvent.

Fired when the Accept all button is clicked.

Fired when the Deny all button is clicked.

Fired when the Save and exit button is clicked.

Fired when the Close 'x' button is clicked.

Fired when DAU log is successfully sent to server.

Note

This event can be used to check which consent type is given by calling

LRPrivacyManager.shared.getConsentType()

# data[].attributes.attachment_link.title
iOS SDK Implementation (GDPR for Mobile)

# data[].attributes.attachment_link.description
The main purpose of this document is to describe how to install and use the Privacy Manager SDK (in further text: SDK). The aim of the SDK is to enable App or embedded software developers to create ePrivacy and GDPR compliant apps without deep knowledge about underlying technical compliance procedures.

# data[].attributes.attachment_link.provider_name
General Data Protection Regulation (GDPR)

# data[].attributes.attachment_link.readable_text
Welcome to gdpr-info.eu. Here you can find the official PDF of the Regulation (EU) 2016/679 (General Data Protection Regulation) in the current version of the OJ L 119, 04.05.2016; cor. OJ L 127, 23.5.2018 as a neatly arranged website. All Articles of the GDPR are linked with suitable recitals. The European Data Protection Regulation is applicable as of May 25th, 2018 in all member states to harmonize data privacy laws across Europe. If you find the page useful, feel free to support us by sharing the project.

Quick Access

Key Issues

Table of Contents

Chapter 1 General provisions

Chapter 4 Controller and processor

Section 1 General obligations

Section 2 Security of personal data

Section 4 Data protection officer

Section 1 Independent status

Chapter 11 Final provisions

# data[].attributes.attachment_link.title
General Data Protection Regulation (GDPR) - Legal Text

# data[].attributes.attachment_link.description
The official PDF of the Regulation (EU) 2016/679 - known as GDPR - its recitals & key issues as a neatly arranged website.

# data[].attributes.attachment_link.readable_text
Le 25 mai 2018, le règlement européen est entré en application. De nombreuses formalités auprès de la CNIL disparaîssent. En contrepartie, la responsabilité des organismes est renforcée. Ils doivent désormais assurer une protection optimale des données à chaque instant et être en mesure de la démontrer en documentant leur conformité.

# data[].attributes.attachment_link.description
Le 25 mai 2018, le règlement européen est entré en application. De nombreuses formalités auprès de la CNIL disparaîssent. En contrepartie, la responsabilité des organismes est renforcée. Ils doivent désormais assurer une protection optimale des données à chaque instant et être en mesure de la démontrer en documentant leur conformité.

# data[].attributes.attachment_link.readable_text
Si vous vous demandiez comment le montant des amendes pour non-respect du RGPD étaient fixées, à voir les listes régulières qui les énumèrent, publiées à intervalles réguliers, les lignes directrices de l'EDPB (European Data Protection Board) qui regroupe les CNIL européennes vont vous aider. Le RGPD prévoit quelques principes : le montant de l'amende doit être proportionnel, efficace et dissuasif. Le montant dépendra aussi du type d'infraction, sous toutes ses formes. Nous voilà bien avancés. C'est vrai que les amendes RPGD n'ont pas un montant fixé à l'avance comme les amendes routières même si ce n'est pas formellement interdit par le RGPD.

Il faut d'abord établir si on a à faire à un ou plusieurs comportements anti-RGPD à sanctionner. Et dans le cas d'un seul comportement sanctionnable, y a-t-il plusieurs infractions (qui peuvent être chacune la conséquence des autres ou non) ou une seule infraction. Par comportement, il faut entendre une série d'actions qui forment un tout, comme la collecte et le stockage de données sans autorisation pour ensuite l'exploiter même si elles sont exploitées de manières diverses. L'unicité d'action prévaut. Ceci n'empêche pas un comportement unique de contenir plusieurs infractions si plusieurs dispositions du RGPD sont concernées mais si une infraction doit forcément en précéder une autre pour que cette dernière ait lieu, il faut en tenir compte. Il y a aussi le principe de subsidiarité : une infraction est-elle subsidiaire à l'autre ou non. Toutes ces circonstances peuvent amener à des amendes séparées, groupées ou à une amende unique.

On l'oublie mais il y a deux montants maximums pour les amendes RGPD d'ailleurs : 10 millions d'euros maximum ou 2 % du chiffre d'affaires, plutôt liées à une mauvaise organisation du RGPD sur place, dans l'entreprise ou 4 % du chiffre d'affaires ou 20 millions d'euros du chiffre d'affaires quand cela craint.

La gravité de l'infraction

La gravité de l'infraction doit ensuite être évaluée ainsi que la durée, en tenant compte de la nature, de l'étendue et du but du traitement de données qui a eu lieu. Le dommage subi par les personnes concernées interviendra aussi. Bien sûr, le caractère intentionnel ou négligent qui entoure l'infraction jouera aussi. La gravité dépendra de la nature du traitement : était-elle de nature commerciale ou pour une bonne cause ou émanant d'un parti politique. Quand le traitement possédait intrinsèquement plus de risques, c'est un facteur aggravant. L'étendue du traitement va aussi intervenir : est-il local, national ou international. Plus le traitement est à large échelle, plus il sera difficile, dit l'EDPB pour la personne et l'autorité de protection des données d'intervenir et de l'infléchir, à son échelle.

Le but du traitement importe aussi : est-il dans le core business de l'entreprise. Si c'est le cas, elle a moins d'excuses dit l'EDPB. Bien sûr le nombre de personnes concernées intervient aussi ainsi que le dommage infligé aux personnes dont les données ont été malmenées par le non-respect du RGPD. La durée de l'infraction est un facteur aggravant et on peut même, dit l'EDPB, considérer la durée avant que le RGPD ne soit d'application légale (avant mai 2018).

Était-ce intentionnel?

Le caractère intentionnel consiste à considérer qu'il y avait connaissance et volonté d'agir en infraction du RGPD. La négligence n'est pas aussi grave que le caractère intentionnel toutefois et peut même ne pas être pris en considération.

Tout dépendra aussi des catégories de données affectées : et de citer comme données, des données de géolocalisation, des communications privées, les numéros d'identification national ou des données financières, cartes de crédit. Leur dissémination est de nature à porter un préjudice immédiat. La quantité de données qui aura fuité par personne est aussi un facteur aggravant.

Tout ce qui précède doit servir, dit l'EDPB, à caractériser la gravité de l'infraction dans une des trois catégories de gravité, basse, moyenne ou sérieuse ce qui donne lieu à un point de départ pour l'amende, entre 0 et 10 % du montant maximum, entre 10 % et 20 % et entre 20 % et 100 %.

Vient ensuite la question du chiffre d'affaires comme base " imposable " pour l'amende. C'est là que l'EDPB revient aux fondamentaux : le montant de l'amende doit être efficace, proportionnel et surtout dissuasif. Et de faire une distinction entre différentes catégories d'entreprise selon leur chiffre d'affaires, inférieur à 2 millions d'euros, à 10 millions d'euros, 50 millions d'euros. Ce n'est pas la peine de s'acharner. Plus le chiffre d'affaires est élevé, plus le montant de départ pour l'amende, on va dire le montant minimum, sera élevé.

Facteurs aggravants et circonstances atténuantes

Après il y a les facteurs aggravants ou les circonstances atténuantes. Y avait-il des mesures pour atténuer le dommage aux personnes affectées par une brèche de données si elle a eu lieu. Le data controller ou processor a-t-il pris les mesures de protection par design ou par défaut pour protéger les données, le traitement était-il sûr ? Ceci influencera son niveau de responsabilité.

Evidemment, si l'entreprise a été déjà condamnées dans le passé pour mauvais traitement de données, cela interviendra. Plus c'était loin dans le passé, moins grave c'est. Si la condamnation a eu lieu dans les mêmes matières, c'est aussi une mauvaise chose. Plus étonnant, si ce sont d'autres autorités que celles relatives à la protection des données qui ont condamné les pratiques de l'entreprise, cela doit être pris en compte. Si l'entreprise a coopéré avec les autorités, si l'infraction a été déclarée ou découverte par les autorités, tout cela va aussi intervenir dit l'EDPB. S'agit d'une plainte, d'une déclaration ou d'une inspection ? L'adhésion à des codes de conduite ou avoir une certification peuvent être des facteurs atténuants. L'entreprise pourrait d'ailleurs être exclue de la communauté sous-jacente au code de conduite ou pire voir sa certification malmenée. Mais cette punition ne doit pas être forcément prise en compte par les autorités de protection des données.

Enfin, il y a d'autres facteurs aggravants comme les gains financiers obtenus de cette infraction. Par contre des circonstances exceptionnelles comme des pandémies qui ont amené à un dérapage peuvent être des facteurs atténuants.

Efficace, dissuasif

Mais on en revient au but de l'amende : elle doit être efficace, c'est-à-dire forcer la compagnie à revenir dans les rails de la conformité, proportionnelle, c'est-à-dire notamment en ligne avec la gravité de la sanction et la taille de l'entreprise qui sera punie, avec un bémol sur la capacité à payer. Si l'entreprise est en difficulté, il faut en tenir compte. L'entreprise peut négocier une réduction de l'amende si elle prouve qu'elle pourrait arrêter ses activités à cause de cela et, enfin, l'amende doit être dissuasive selon qu'il s'agit de montrer l'exemple aux autres entreprises qui seraient tentées de prendre les mêmes libertés avec le RGPD pour faire de même, vérifier chez elles que tout est en ordre face à ce cas-là ou uniquement pour l'entreprise à question.

__________
Pour en savoir plus: Guidelines 04/2022 on the calculation of administrative fines under the GDPR Version 1.0, Adopted on 12 May 2022, European Data Protection Board.

# data[].attributes.attachment_link.description
OPINION. L'EDPB (European Data Protection Board) qui regroupe les CNIL européennes a édicté quelques principes pour fixer les amendes en cas d'infractions. Mais le système s'avère plus complexe que les amendes routières. (*) Par Francis Hayen, Belfius Banque, et Charles Cuvelliez, Université de Bruxelles et Belfius Banque.

# data[].attributes.attachment_link.readable_text
Le règlement général européen sur la protection des données personnelles (RGPD) n'est "pas suffisamment appliqué" contre les géants de la tech, a estimé vendredi le Contrôleur européen de la protection des données (CEPD), Wojciech Wiewiorowski. Lors d'une conférence à Bruxelles sur "l'avenir de la protection des données", le responsable a déploré que "trop souvent, le RGPD impose des contraintes aux petites entités mais épargne les grosses". Il a aussi souligné que "des individus attendent des années pour obtenir justice, même dans des petits dossiers simples". M. Wiewiorowski a mis en cause une "répartition inégale de l'effort" entre les pays européens pour faire appliquer le RGPD. Le règlement, entré en vigueur en mai 2018, a mis en place un système de "guichet unique" qui définit comme autorité "chef de file" celle du pays où se trouve l'établissement principal de l'entreprise. Ce qui met le régulateur irlandais en première ligne - des géants du numérique comme Meta, Google ou Twitter y ayant établi leur siège européen -, et aussi le Luxembourg, où Amazon est implanté.

Vers un modèle pan-européen d'application

Le Contrôleur européen s'est demandé s'il était "optimal d'attendre des résultats de la part d'une ou deux autorités (nationales) tandis que les autres sont moins impliquées". Il s'est dit "convaincu (...) qu'à un moment donné, un modèle pan-européen d'application de la protection des données sera une étape nécessaire". "Un tel modèle permettrait non seulement d'atténuer le problème de la répartition inégale des responsabilités, mais aussi de garantir une réelle cohérence du droit de la protection des données dans l'ensemble de l'UE", a-t-il estimé, suggérant que des "enquêtes clés", sur les affaires transfrontalières les plus importantes, "pourraient être menées à un niveau central".

La plus grosse amende prononcée jusqu'à présent pour non-respect du RGPD est celle de 746 millions d'euros infligée en 2021 à Amazon par le régulateur luxembourgeois. La deuxième est celle de 225 millions d'euros, contre WhatsApp, décidée par la Commission irlandaise de protection des données (CPC) en août 2021. Des recours ont été introduits contre ces décisions. En décembre 2020, la Cnil française avait quant à elle condamné Google à une amende de 100 millions d'euros et Amazon à 35 millions d'euros pour non-respect de la législation sur les "cookies", les traceurs publicitaires. En vertu du RGPD, les entreprises doivent demander le consentement des citoyens lorsqu'elles réclament leurs données personnelles, les informer de l'usage qui en sera fait et leur permettre de supprimer les données. Les manquements sont passibles d'une amende pouvant aller jusqu'à 4% du chiffre d'affaires mondial du groupe.

# data[].attributes.attachment_link.title
Des " insuffisances " dans l'application du RGPD par les géants de la Tech

# data[].attributes.attachment_link.description
Le règlement général européen sur la protection des données personnelles (RGPD) n'est "pas suffisamment appliqué" contre les géants de la tech, a estimé vendredi le Contrôleur européen de la protection des données (CEPD), Wojciech Wiewiorowski. Lors d'une conférence à Bruxelles sur "l'avenir de la ...

# data[].attributes.body
Mode d'emploi pour les entreprises

# data[].attributes.attachment_link.readable_text
La CNIL publie un guide RGPD pour les développeuses et développeurs

Afin de vous accompagner dans la mise en conformité de vos développements projet web ou applicatif, la CNIL a élaboré un guide de bonnes pratiques des développements en open source.

Ce guide est publié sous licence GPLv3 et sous licence ouverte 2.0 (explicitement compatible avec CC-BY 4.0 FR). Vous pouvez donc librement contribuer à son enrichissement.

Ce guide s'adresse-t-il uniquement aux développeuses et développeurs ?

Que vous travailliez seul(e) ou en équipe au développement d'un projet, que vous soyez amené(e) à gérer une équipe de développement, que vous soyez un prestataire, ou simplement curieux, ce guide contient une première approche des grands principes du RGPD et des différents points d'attention à prendre en compte dans le déploiement d'applications respectueuse de la vie privée de ses utilisateurs.

Il propose des conseils et des bonnes pratiques, et offre ainsi des clés de compréhension du RGPD utiles pour tous les acteurs, quelle que soit la taille de leur structure. Il peut également faire l'objet d'échanges au sein des services et dans la relation avec vos clients.

Que contient le guide ?

Ce guide est découpé en 18 fiches thématiques et complété par des exemples de codes qui couvrent la plupart des besoins des développeuses et développeurs pour les accompagner à chaque étape de leur projet, de la préparation du développement au déploiement de nouveaux services.

Le règlement général sur la protection des données (ou RGPD) précise que la protection des droits et libertés des personnes physiques exige de prendre des " mesures techniques et organisationnelles appropriées afin de garantir que les exigences du présent règlement sont respectées " (considérant 78).

La détermination de ces mesures est forcément liée au contexte des traitements mis en place, et le responsable de traitement (l'entité publique ou privée qui traite des données personnelles) doit à ce titre assurer la sécurité des données qu'il est amené à traiter.

Les bonnes pratiques de ce guide n'ont donc pas vocation à couvrir l'ensemble des exigences des règlementations ni à être à prescriptives, elles apportent un premier niveau de mesures permettant de prendre en compte les problématiques de protection de la vie privée dans les développements informatiques qui ont vocation à être appliquées à tous les projets traitant des données. En fonction de la nature des traitements opérés, des mesures complémentaires devront être mises en œuvre dans certains cas afin de respecter pleinement la réglementation.

Tables des matières

1. Développer en conformité avec le RGPD

2. Identifier les données à caractère personnel

3. Préparer son développement

4. Sécuriser son environnement de développement

5. Faire un choix éclairé de son architecture

6. Sécuriser vos sites web, vos applications et vos serveurs

7. Minimiser les données collectées

8. Gérer les profils utilisateurs

9. Maîtriser vos bibliothèques et vos SDK

10. Veiller à la qualité de votre code et sa documentation

11. Tester vos applications

12. Informer les utilisateurs

13. Préparer l'exercice des droits des personnes

14. Gérer la durée de conservation des données

15. Prendre en compte les bases légales dans l'implémentation technique

16. Analyser les pratiques en matière de traceurs sur vos sites et vos applications

17. Mesurer la fréquentation de vos sites web et de vos applications

18. Se prémunir contre les attaques informatiques

Ce guide est disponible en deux versions :

La contribution se fait en quelques étapes :

Inscrivez-vous sur la plateforme Github ;

Rendez-vous sur la page du projet ;

Vous pouvez :

Utiliser l'onglet "Issue" pour ouvrir des commentaires ou participer à la discussion

Utiliser l'option "Fork" pour faire vos propres modifications et proposer leur inclusion via le bouton "Pull Requests"

Votre proposition de contribution sera examinée par la CNIL avant sa publication. La version web du guide RGPD de l'équipe de développement sera régulièrement mise à jour.

Usage

Pour faire vous-même une " release " de ce repository, vous pouvez utiliser l'outil Pandoc. Cet outil vous permettra de convertir les fiches en un fichier docx ou bien un document HTML.

Vous pouvez retrouver les instructions pour installer cet outil ici

Pour générer un fichier .docx :

pandoc -s --toc --toc-depth=1 -o Guide_RGPD_developpeur.docx [0-9][0-9]*.md

Pour générer un fichier .html :

pandoc -s --template="templates/mytemplate.html" -H templates/pandoc.css -o index.html README.md [0-9][0-9]*.md

Que vous travailliez seul⋅e ou en équipe au développement d'un projet, que vous soyez amené⋅e à gérer une équipe de développement, ou que vous soyez un prestataire réalisant des développements pour des tiers, il est indispensable de s'assurer durant toute la vie du projet que les données de vos utilisateurs ainsi que toutes les opérations effectuées sur celles-ci soient protégées en permanence.

Les étapes suivantes vous aideront dans le développement d'applications ou de sites web respectueux de la vie privée :

1. Priorisez les actions à mener. Sur la base du registre des activités de traitement, identifiez en amont du développement les actions à mener pour vous conformer aux obligations du RGPD et priorisez les points d'attention au regard des risques pour les personnes concernées par la collecte de données. Ces points d'attention concernent notamment la nécessité et les types de données collectées et traitées par votre programme, la base légale sur laquelle se fonde vos traitements de données, les mentions d'information de votre programme ou de votre application, les clauses contractuelles vous liant à vos sous-traitants, les modalités d' exercice des droits, les mesures mises en place pour sécuriser vos traitements.

2. Gérez les risques. Lorsque vous identifiez que des traitements de données personnelles sont susceptibles d'engendrer des risques élevés pour les personnes concernées, assurez-vous que vous gérez ces risques de façon appropriée au regard du contexte. Une analyse d'impact relative à la protection des données (AIPD) peut vous accompagner dans la maîtrise de ces risques. La CNIL a élaboré une méthode, des modèles de documents et un outil qui vous aideront à identifier ces risques ainsi qu'un catalogue de bonnes pratiques qui vous accompagnera dans la mise en place de mesures permettant de traiter les risques identifiés. Par ailleurs, la réalisation d'une analyse d'impact relative à la protection des données est obligatoire pour tous les traitements susceptibles d'engendrer des risques élevés pour les droits et libertés des personnes concernées. La CNIL propose, sur son site web, une liste des types d'opérations de traitement pour lesquelles une AIPD est requise ou, au contraire, non requise.

Le site de la CNIL fournit de nombreuses fiches pratiques qui vous accompagneront dans la mise en place de traitements respectueux de la loi suivant votre secteur d'activité.

Comprendre les notions de " données personnelles ", de " finalité " et de " traitement " est indispensable pour le développement d'une application respectueuse de la loi et des données des utilisateurs. Attention, à ne pas confondre " anonymisation " et " pseudonymisation " qui ont des définitions précises dans le RGPD.

Définition

Toute opération sur ce type de données (collecte, enregistrement, transmission, modification, diffusion, etc.) constitue un traitement au sens du RGPD et doit donc répondre aux exigences fixées par ce règlement. Ces traitements doivent être licites et avoir un objectif (une " finalité ") déterminée. Les données personnelles collectées et traitées doivent être pertinentes et limitées à ce qui est strictement nécessaire pour atteindre la finalité.

Exemples de données à caractère personnel

Lorsqu'elles sont relatives à des personnes physiques, les données suivantes sont des données à caractère personnel :

nom, prénom, pseudonyme, date de naissance ;

photos, enregistrements sonores de voix ;

numéro de téléphone fixe ou portable, adresse postale, adresse e-mail ;

adresse IP, identifiant de connexion informatique ou identifiant de cookie ;

empreinte digitale, réseau veineux ou palmaire de la main, empreinte rétinienne ;

numéro de plaque d'immatriculation, numéro de sécurité sociale, numéro d'une pièce d'identité ;

données d'usage d'une application, des commentaires, etc.

L'identification des personnes physiques peut se réaliser :

à partir d'une seule donnée (exemples : nom et prénom) ;

à partir du croisement d'un ensemble de données (exemple : une femme vivant à telle adresse, née tel jour et membre de telle association).

Certaines données sont considérées comme particulièrement sensibles. Le RGPD interdit de recueillir ou d'utiliser ces données, sauf, notamment, si la personne concernée a donné son consentement exprès (démarche active, explicite et de préférence écrite, qui doit être libre, spécifique, et informée).

Ces exigences concernent les données suivantes :

les données relatives à la santé des individus ;

les données concernant la vie sexuelle ou l'orientation sexuelle ;

les données qui révèlent une prétendue origine raciale ou ethnique ;

les opinions politiques, les convictions religieuses, philosophiques ou l'appartenance syndicale ;

les données génétiques et biométriques utilisées aux fins d'identifier une personne de manière unique.

L'anonymisation des données à caractère personnel

Un processus d'anonymisation de données à caractère personnel vise à rendre impossible toute identification des individus au sein de jeux de données. Il s'agit donc d'un processus irréversible. Lorsque cette anonymisation est effective, les données ne sont plus considérées comme des données personnelles et les exigences du RGPD ne sont plus applicables.

Par défaut, nous vous recommandons de ne jamais considérer des jeux de données brutes comme anonymes. Un jeu de données anonyme doit nécessairement résulter d'un processus d'anonymisation qui éliminera toute possibilité de ré-identification des individus, que ce soit par :

individualisation : il n'est pas possible d'isoler une partie ou la totalité des enregistrements relatifs à un individu ;

corrélation : le jeu de données ne permet pas de relier deux enregistrements se rapportant à une même personne ou à un groupe de personnes ;

inférence : il est impossible de déduire la valeur d'un attribut d'une personne depuis des informations internes ou externes au jeu de données.

Le projet CabAnon, développé par le Laboratoire d'Innovation Numérique de la CNIL en 2017, évalue les performances de différentes techniques d'anonymisation sur des trajets des taxis tels que rendus publics par la New-York TLC. Ce projet présente différents scénarios d'usages pour lesquels les techniques d'anonymisation utilisées n'altèrent pas significativement la qualité du résultat final. Le code utilisé pour anonymiser ces données est également publié sous licence libre.

La pseudonymisation des données à caractère personnel

La pseudonymisation constitue un compromis entre la conservation de données brutes et la production de jeux de données anonymisées.

Elle se réfère à un traitement de données personnelles réalisé de manière à ce qu' on ne puisse plus attribuer les données relatives à une personne physique sans avoir recours à des informations supplémentaires. Le RGPD insiste sur le fait que ces informations supplémentaires doivent être conservées séparément et être soumises à des mesures techniques et organisationnelles afin d'éviter la ré-identification des personnes concernées. Contrairement à l'anonymisation, la pseudonymisation est un processus réversible.

Les données résultant d'une pseudonymisation sont considérées comme des données à caractère personnel et restent donc soumises aux obligations du RGPD. Toutefois, le règlement européen encourage l'utilisation de la pseudonymisation dans le cadre du traitement des données à caractère personnel. Par ailleurs le RGPD considère que la pseudonymisation permet de réduire les risques pour les personnes concernées et de contribuer à la mise en conformité au règlement.

Les principes de la protection des données à caractère personnel doivent être intégrés aux développements informatiques dès les phases de conception afin de protéger la vie privée des personnes dont vous allez traiter les données, et de leur offrir une meilleure maîtrise de leurs données et de limiter les erreurs, pertes, modifications non autorisées, ou mauvais usages de celles-ci dans les applications.

Choix méthodologiques

Pour tout développement à destination du grand public, menez une réflexion sur les paramètres relatifs à la vie privée, et notamment sur le paramétrage par défaut, par exemple les caractéristiques et les contenus des utilisateurs visibles par défaut.

Choix technologiques

Architecture et fonctionnalités

Gardez la maîtrise de votre système. Il est important de garder la maîtrise de votre système, autant afin d'en assurer le bon fonctionnement que de garantir un haut niveau de sécurité. Garder un système simple permet d'en comprendre précisément les rouages et d'identifier ses points de fragilité. Dans le cas où une certaine complexité est nécessaire, il est conseillé de démarrer d'un système simple, correctement conçu et sécurisé. Ensuite, il est possible d'en augmenter la complexité petit à petit, tout en continuant de sécuriser les nouveautés qui s'ajoutent.

Ne vous reposez pas sur une seule ligne de défense. Malgré toutes les dispositions prises pour concevoir un système sécurisé, il peut arriver que certains composants rajoutés ultérieurement ne soient pas suffisamment sécurisés. Pour minimiser les risques sur les utilisateurs finaux, il est conseillé de défendre le système en profondeur. Exemple : contrôler les données entrées dans un formulaire en ligne fait partie des défenses de périphérie. Dans le cas où cette défense est détournée, une protection des requêtes en base de données pourra prendre le relais.

Outils et pratiques

Utilisez des normes de programmation prenant en compte la sécurité. Souvent, des listes de normes, bonnes pratiques ou guides de codage améliorant la sécurité de vos développements sont déjà disponibles. Des outils annexes peuvent également être intégrés dans vos environnements de développement intégrés (" IDE " en anglais) afin de vérifier automatiquement que votre code respecte les différentes règles faisant partie de ces normes ou bonnes pratiques. Vous trouverez facilement sur internet des listes de bonnes pratiques pour votre langage de programmation favori. Par exemple ici pour C, C++ ou Java. Pour le développement d'application web, des guides de bonnes pratiques spécifiques existent, tels que ceux publiés par l'OWASP.

Le choix des technologies utilisées est crucial. Un certain nombre de points sont à prendre en compte :

En fonction du domaine d'application ou de la fonctionnalité développée, un langage ou une technologie peut être plus approprié qu'une autre.

Les langages et technologies éprouvés sont plus sûrs. Ils ont fait, en général, l'objet d'audits afin de corriger les vulnérabilités les plus connues. Il faut cependant faire attention à utiliser les dernières versions de chacune des briques technologiques que vous utiliserez.

Il faut à tout prix éviter de coder sa solution définitive dans un langage tout juste appris et pas encore maîtrisé. Dans le cas contraire, vous vous exposez à un risque accru de faille de sécurité du fait du manque d'expérience.

La sécurité des serveurs de production, de développement, d'intégration continue ainsi que les postes de travail des développeuses et développeurs doit être une priorité car ils centralisent l'accès à un grand nombre de données.

Évaluez vos risques et adoptez les mesures de sécurité adéquates

Évaluez les risques dans les outils et les processus utilisés pour vos développements. Recensez vos mesures de sécurité existantes et définissez un plan d'action permettant d'améliorer la couverture de vos risques. Désignez une personne responsable de sa mise en œuvre.

Pensez à prendre compte les risques sur tous les outils que vous utilisez, notamment les risques liés aux outils SaaS ( Software as a Service) et collaboratifs dans le cloud (type Slack, Trello, GitHub, etc.).

Sécurisez vos serveurs et vos postes de travail d'une façon homogène et reproductible

Des listes de recommandations concernant la sécurisation des serveurs, postes de travail et réseaux internes sont disponibles dans les fiches n°5 à 8 du guide sécurité des données personnelles de la CNIL.

Rédigez un document regroupant ces mesures et expliquant leur configuration : il permet de s'assurer d'une mise en place homogène des mesures de sécurité sur les serveurs et les postes de travail. Afin de réduire la charge de travail, des outils de gestion de configuration, tels qu' Ansible, Puppet ou Chef, peuvent être utilisés.

Mettez à jour les serveurs et postes de travail, si possible de manière automatique. Vous pouvez vous constituer une liste de veille recensant les vulnérabilités les plus importantes, par exemple les alertes de sécurité, avis de sécurité et les bulletins d'actualité du CERT-FR.

Maîtrisez vos accès et tracez les opérations

Documentez la gestion de vos clés SSH (utilisation d'algorithmes de cryptographie et de longueur de clés à l'état de l'art, protection des clés privées par une passphrase, rotation des clés). Pour des exemples de bonnes pratiques, consulter le document sur l'usage sécurisé d'(open)SSH.

Si vous devez vous connecter à un service en ligne ou à l'un de vos serveurs, faites le choix d'algorithme asymétriques, ECDSA ou bien RSA.

Par exemple en utilisant l'outil ssh-keygen (disponible sous linux et OSX), utiliser les commandes :

Cette commande va créer ou utiliser votre répertoire de clés SSH, par exemple sur Linux /home/username/.ssh/), et y écrire deux éléments : une clé privée et une clé publique.

Vous pouvez alors soit envoyer la clé publique au serveur pour le configurer (si vous avez un moyen d'authentification préexistant), soit la copier dans votre presse-papier pour la fournir au service que vous souhaitez utiliser :

#Pour envoyer : ssh-copy-id -i ~/.ssh/key.pub user@host #Pour copier sur des systèmes Debian ou Ubuntu: sudo apt install xclip xclip -sel clip < ~/.ssh/key.pub

La clé privée ne doit jamais être envoyée ou partagée avec un tiers. Pour plus d'info sur les mesures organisationnelles à mettre en place pour une bonne gestion des clés, voir la norme NISTIR 7966.

Favorisez une authentification forte sur les services utilisés par l'équipe de développement.

La plupart des services centralisés (Gitlab ou Jenkins par exemple) nécessite la création de jetons individuels pour authentifier les requêtes ("Webhook"). Il est recommandé d'associer une durée de vie limitée à ces jetons et de les révoquer lorsqu'ils ne sont plus utilisés.

Quelle que soit l'ampleur de votre projet, il est très fortement recommandé d'utiliser un outil de gestion de code source pour suivre dans le temps ses différentes versions.

Paramétrez efficacement votre gestionnaire de code source, en pensant à sa sécurité

Par ailleurs, attribuez aux utilisateurs de votre gestionnaire de code source des niveaux d'accès à votre projet et définissez pour chacun des niveaux les permissions correspondantes (par exemple, un niveau " invité " avec des droits limités en lecture, un niveau " équipe de développement " avec des droits en écriture, etc.).

Faites des sauvegardes régulières de votre système de gestion de code source. En particulier, pensez à sauvegarder votre serveur principal où toutes les modifications sont enregistrées.

Mettez en place des procédures de développement pour travailler efficacement même si plusieurs personnes développent en même temps. Par exemple, vous pouvez décider de ne pas travailler sur la même branche ( master ou main), mais de mettre en place des branches par fonctionnalité, qui seront fusionnées dans la branche principale au fur et à mesure du développement. De telles stratégies de développement sont déjà bien documentées, par exemple dans Git Flow. Par ailleurs, certains gestionnaires de code source proposent de configurer des branches protégées qui empêchent des modifications non autorisées sur les fichiers contenus dans ces branches.

Soyez vigilant sur le contenu de votre code source

Mettez en œuvre des outils de métriques de qualité de code qui scanneront votre code dès son commit pour vérifier sa bonne qualité. Vous pouvez également ajouter des scripts de contrôle de ces métriques dans la configuration du gestionnaire de code source : le commit sera alors annulé si le code source n'est pas d'une qualité suffisante.

Conservez vos secrets et mots de passe en dehors de votre dépôt de code source :

dans des fichiers à part, qui n'ont pas fait l'objet d'un commit. Pensez à utiliser les fichiers spéciaux de votre gestionnaire de code source (tels que .gitignore pour Git) afin de ne pas commiter les fichiers sensibles par erreur.

dans des variables d'environnement, en prenant soin de vérifier que les variables d'environnement ne sont pas accidentellement écrites dans des logs ou affichées lors d'une erreur de l'application.

en les stockant dans des enclaves sécurisées ou des dépots séparés avec accès restreint que vous pourrez appeler comme dépendance externe de votre projet.

en utilisant des logiciels spécifiques de gestion de secrets ou de gestion de configuration (par exemple Vault de la société HashiCorp, Keywhiz de la société Square ou Knox de la société Pinterest).

Enfin, si vous devez inclure de telles données dans votre dépôt, pensez à chiffrer/déchiffrer automatiquement les fichiers en utilisant un greffon de votre gestionnaire de code source (par exemple ).

Après un commit qui contient des données personnelles ou d'autres données critiques, n'oubliez pas de purger complètement le dépôt de code source : même après modification, les données peuvent rester disponibles dans l'historique de votre dépôt.

Exemples d'outils

À l'inverse d'outils tels que Subversion, qui ont besoin d'un serveur central pour fonctionner, les principaux gestionnaires de code source ( Git, Mercurial par exemple) sont décentralisés.

Lors de la conception de l'architecture de votre application, vous devez identifier les données personnelles qui seront collectées et définir un parcours et un cycle de vie pour chacune d'entre elles. Le choix des supports de données (stockage local, serveur, service cloud) est une étape cruciale, qui doit être adaptée à vos besoins, mais aussi à vos connaissances techniques. Le registre des activités de traitement et une analyse d'impact peuvent vous accompagner dans ce choix.

Étudier le parcours de ses données

Les packs de conformité sectoriels sur les compteurs communicants, les véhicules connectés et la silver économie, ainsi que le livre blanc sur les assistants vocaux peuvent vous accompagner dans l'identification des parcours de données de votre produit.

Chaque cas d'usage met ainsi en œuvre des parcours distincts pour lesquels la création d'un compte et l'intervention d'un ou plusieurs acteurs externes peuvent être nécessaires.

La conformité de ces parcours est étudiée suivant 3 étapes :

l'identification du traitement, du responsable et de sa base légale,

l'identification des données collectées ainsi que de leur durée de conservation,

l'information et la garantie des droits des personnes concernées.

Ces analyses peuvent vous accompagner dans l'identification des développements à prévoir, suivant les caractéristiques du traitement, la base juridique applicable et l'identification des données qui nécessitent une attention particulière du fait de leur caractère sensible.

En cas de recours à un prestataire pour l'hébergement

Les autres points de vigilance sont notamment :

l'existence d'une politique de sécurité accessible ;

les mesures de sécurité et sûreté physique sur le site d'hébergement ;

le chiffrement des données et les autres procédés garantissant que le prestataire n'a pas accès aux données qui lui sont confiées ;

la gestion des mises à jour, la gestion des habilitations, l'authentification des personnels et la sécurité des développements applicatifs ;

la réversibilité/portabilité aisée des données dans un format structuré et couramment utilisé, sur demande et à tout moment.

Tout site web, application ou serveur doit intégrer les règles élémentaires de sécurité à l'état de l'art, tant sur les communications que sur les authentifications ou son infrastructure.

Sécuriser les communications

Mettez en œuvre le protocole TLS version 1.2 ou 1.3 (en remplacement de SSL) sur tous les sites web et pour les transmissions de données de vos applications mobiles en utilisant uniquement les versions les plus récentes et en vérifiant sa bonne mise en œuvre.

Rendez l'utilisation de TLS obligatoire pour toutes les pages de votre site et pour vos applications mobiles.

Limitez les ports de communication strictement nécessaires au bon fonctionnement des applications installées. Si l'accès à un serveur web n'est possible qu'à l'aide du protocole HTTPS, seul le ports 443 de ce serveur, et éventuellement le port 80 afin de rediriger vers le protocole HTTPS, doit être accessible sur Internet. Les autres ports doivent alors être bloqués au niveau du pare-feu.

La sécurisation des communications des sites et applications mobiles nécessite d'utiliser le protocole "TLS". La combinaison de ce protocole avec le protocole "HTTP" permet un échange par "HTTPS". Certains algorithmes cryptographiques employés dans TLS, et ses versions précédentes "SSL", sont réputées vulnérables à différentes attaques. Vous pouvez vous faire accompagner dans le choix de ces algorithmes au moyen de générateurs de configuration TLS. Celui de Mozilla supporte par exemple de très nombreux serveurs.

Deux exemples de configuration Apache et Nginx commentés sont disponibles en annexe de ce guide. Vous pouvez vous référer au Wiki Mozilla pour plus de détails.

Sécuriser les authentifications

Dans sa délibération du 10 janvier 2017 portant adoption d'une recommandation relative aux mots de passe, la CNIL spécifie que si le mot de passe n'est pas utilisé en conjonction avec un second facteur, et sans blocage de fréquence ("frequency capping"), un mot de passe devrait être constitué de 12 caractères et comprendre majuscule, minuscule, chiffres et caractères spéciaux.

En conséquence, pour vérifier l'adhérence à ces règles, le code suivant est adéquat :

Cela doit également s'accompagner d'une vérification backend de la force du mot de passe.

Ne stockez jamais les mots de passe en clair. Stockez-les sous forme de hachage (hash) au moyen d'une librairie éprouvée, comme Argon2, yescrypt, scrypt, balloon, bcrypt et, dans une moindre mesure, PBKDF2.

Il ne faut jamais stocker les mots de passe des utilisateurs en clair dans vos bases de données, il faut systématiquement les hasher, avec un sel specifique. En pratique, bcrypt est sans doute la solution la plus simple d'utilisation. Elle utilise un sel aléatoire pour chaque hash et l'inclue dans le hash résultant pour la vérification d'un mot de passe.

Par exemple en node.js :

#Pour installer: npm install bcrypt #Pour utiliser: const bcrypt = require('bcrypt'); const saltRounds = 10; // Niveau de difficulté de bcrypt #Enregistrer un mot de passe en DB const passwordAStocker = '*********'; bcrypt.genSalt(saltRounds, function(err, salt) { bcrypt.hash(passwordAStocker, salt, function(err, hash) { // stockez le résultat 'hash' en DB }); }); #Verifier un mot de passe const passwordAVerifier = '*********'; bcrypt.compare(passwordAVerifier, hash, function(err, result) { // 'result' vaut true si le mot de passe est le bon });

Les fonctions de hachage permettent d'assurer l'intégrité des données. Elles doivent reposer sur un algorithme reconnu et sûr. La famille de fonctions SHA-2 (par exemple SHA-256 et SHA-512) comporte des fonctions de hachage génériques qu'il ne faut pas utiliser directement pour certaines tâches spécifiques.En revanche, elles sont tout à fait acceptables comme fonction de base pour des fonctions de hachage spécialisées. Par exemple, la fonction HMAC utilisée avec SHA-256 ou SHA-512 est adaptée à la signature numérique.

Pour stocker les mots de passe, les fonctions adaptées sont les suivantes : Argon2, yescrypt, scrypt, balloon, bcrypt et, dans une moindre mesure, PBKDF2. À noter que les fonctions balloon et PBKDF2 peuvent êtres utilisées avec plusieurs fonctions de hachage sous-jacentes, le choix devant donc être fait sur une fonction reconnue (par exemple une fonction des familles SHA-2, SHA-3, Blake2 ou Blake3).

N'utilisez jamais d'algorithmes obsolètes, comme les chiffrements DES et 3DES ou les fonctions de hachage MD5 et SHA1. Leur utilisation peut permettre à un attaquant ayant connaissance du mot de passe haché de déchiffrer celui-ci sans difficulté et en un temps très court.

Les fonctions de hachage à clé permettent de rendre le calcul de l'empreinte différent en fonction de la clé utilisée. Pour deux clés différentes l'empreinte obtenue sur un même message sera différente.

Utilisez des tailles de clés suffisantes, au minimum de 128 bits suivant l'algorithme utilisé. Protégez ces clés secrètes, au minimum par la mise en œuvre de droits d'accès restrictifs et d' un mot de passe sûr.

Rédiger une procédure indiquant la manière dont les clés vont être gérés en prenant en compte les cas d'oubli de mot de passe de déverrouillage.

import bcrypt #importation de la bibliothèque bcrypt sel = bcrypt.gensalt() #Génération d'un sel aléatoire à conserver de manière sécurisée hache_du_mot_de_passe = bcrypt.hashpw(mot_de_passe, sel) #Génération du hachage du mot de passe avec le sel généré mot_de_passe_valide = bcrypt.checkpw(mot_de_passe, hache_du_mot_de_passe) #Test de la validité du mot de passe depuis son haché

Dans le cas où des cookies sont utilisés pour permettre l'authentification, il est recommandé :

de protéger les cookies contre des lectures via des canaux de non chiffrées, en forcant l'utilisation d'HTTPS via l' HSTS, ainsi que par l'utilisation des indicateurs Secure et HttpOnly ;

d'utiliser des protections contre des injections de requêtes illégitimes par rebond (cross-site request forgery ou CSRF) en utilisant des mesures de protection comme le CSRF Token et l'indicateur SameOrigin sur les requêtes. L'indicateur SameSite des cookies doit avoir la valeur Strict lorsque c'est possible ;

d'utiliser un sous-domaine spécifique pour déposer le token d'authentification avec l'indicateur domain des cookies laissés vides pour exclure les domaines tiers dans le cas où de la délégation de sous-domaine est utilisée (par exemple à travers l'usage de CNAME), ou bien des serveurs avec un faible niveau de sécurité sont destinataires des requêtes HTTP sur le domaine principal.

Adoptez une politique spécifique de mots de passe pour les administrateurs. Changez les mots de passe, au moins, lors de chaque départ d'un administrateur et en cas de suspicion de compromission. Favorisez l'authentification forte lorsque c'est possible.

Limitez l'accès aux outils et interfaces d'administration aux seules personnes habilitées. Favoriser l'usage des comptes de moindres privilèges pour les opérations courantes.

L'accès depuis Internet aux interfaces d'administration doit faire l'objet de mesures de sécurité renforcées. Par exemple, pour les serveurs internes, la mise en œuvre d'un VPN avec authentification forte de l'utilisateur ainsi que du poste qu'il utilise peut être une bonne solution.

Limiter la divulgation d'information sur les comptes existants

Concevoir les processus d'authentification, de réinitialisation des mots de passe et de création de compte de manière à ce qu'un attaquant ne puisse savoir si une adresse mail spécifique possède un compte utilisateur.

Généraliser les messages d'erreurs d'authentification pour ne pas divulguer d'information sur l'existence d'un compte : "ce couple identifiant/mot de passe est inconnu".

Ne pas confirmer l'existence d'un compte utilisateur en cas d'utilisation de la fonctionnalité de réinitialisation des mots de passe : "Si un compte existe avec cette adresse un mail de réinitialisation lui a été envoyé"

Faire valider l'adresse mail du compte utilisateur en tant que première étape de la création d'un compte utilisateur avant toute collecte d'autres données personnelles, et envoyer soit un mail de validation de l'adresse si celle-ci ne dispose pas encore d'un compte, soit un mail de réinitialisation du mot de passe si l'adresse existe, en n'affichant qu'un message générique sur le service : "un mail de validation de votre adresse ou de réinitialisation de votre mot de passe vous a été envoyé"

Sécuriser les infrastructures

Effectuez des sauvegardes, si possible chiffrées et vérifiées régulièrement. C'est particulièrement utile en cas d'attaque d'un rançongiciel sur vos systèmes, le fait de disposer de sauvegardes pour tous vos systèmes sera la seule mesure qui pourra vous permettre de remettre en état vos systèmes.

Limitez le nombre de composants mis en œuvre, et pour chacun de ces composants :

Utilisez des outils de détection des vulnérabilités pour les traitements les plus critiques afin de détecter d'éventuelles failles de sécurité. Des systèmes de détection et prévention des attaques sur des systèmes ou serveurs critiques peuvent aussi être utilisés. Ces tests doivent être menés régulièrement et avant toute mise en production d'une nouvelle version logicielle.

Les outils de détection des vulnérabilités, comme OpenVAS et Metasploit, permettent d'identifier certaines vulnérabilités connus au sein d'applications. Certaines solutions se spécialisent sur des services particuliers, par exemple Wordpress ou Joomla.

Il est recommandé de vérifier l'état et la fraicheur des bases de données des vulnérabilités. Ces analyses peuvent également nuire au bon fonctionnement des serveurs, elles sont donc plutôt à réaliser sur des environnements en préproduction.

Restreignez ou interdisez l'accès physique et logique aux ports de diagnostic et de configuration à distance. Vous pouvez par exemple lister l'ensemble des ports ouverts au moyen de l'outil .

La commande netstat permet de lister les ports TCP ou UDP ouverts sur un serveur. Sur l'exemple suivant, les ports standards HTTP, HTTPS et SSH d'un serveur sont ouverts vers l'extérieur, un serveur de base de données (MariaDB) est en écoute local et des tentatives connexions sont en cours sur les ports SSH et HTTPS :

$ netstat -alpe --ip Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name tcp 0 0 localhost:mysql 0.0.0.0:* LISTEN mysql 14492 - tcp 0 0 0.0.0.0:http 0.0.0.0:* LISTEN root 50278 - tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN root 12948 - tcp 0 0 0.0.0.0:https 0.0.0.0:* LISTEN root 50280 - tcp 0 0 mon-serveur.fr:https adresse1.fr:38056 TIME_WAIT root 0 - tcp 0 0 mon-serveur.fr:ssh adresse2.com:45302 TIME_WAIT root 0 - tcp 0 0 mon-serveur.fr.:https adresse3.eu:56277 FIN_WAIT2 root 0 - tcp 0 0 mon-serveur.fr:https adresse4.be:56306 ESTABLISHED www-data 380689 - tcp 0 524 mon-serveur.fr:ssh adresse1.fr:65137 ESTABLISHED root 382490 -

Le logiciel Nmap permet de réaliser cette analyse depuis un réseau de communication. Sur l'exemple suivant, le protocole d'administration SSH du serveur est accessible sur Internet.

$ nmap mon-serveur.fr Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-11 18:13 CEST Nmap scan report for mon-serveur.fr Host is up (0.011s latency). Not shown: 997 filtered ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 443/tcp open https Nmap done: 1 IP address (1 host up) scanned in 4.99 seconds

Il nécessite donc une attention particulière, comme l'utilisation d'une authentification forte et/ou d'un filtrage par IP.

Protégez les bases de données que vous rendez accessibles sur Internet, au moins en restreignant au maximum les accès (par exemple par filtrage IP) et en changeant le mot de passe par défaut du compte administrateur.

En matière de gestion de bases de données, les bonnes pratiques sont notamment de :

utiliser des comptes nominatifs pour l'accès aux bases de données et créer des comptes spécifiques à chaque application ;

révoquer les privilèges d'administration des comptes nominatifs ou applicatifs pour empêcher la modification de la structure de la base de données des applications (tables, vues, procédures, etc.) ;

mettre en œuvre des mesures contre les attaques par injection de code SQL, de scripts, etc. ;

favoriser le chiffrement des données sur les disques de stockage et dans les bases de données.

Compartimentez vos différents environnements d'exécution afin d'être en mesure d'appliquer le principe de moindre privilège sur chaque sous-partie des ces environnements.

Vous ne devez collecter que les données personnelles qui sont adéquates, pertinentes et nécessaires au regard des finalités de votre traitement telles que définies au moment de la collecte.

Avant la collecte, pensez aux différents types de données que vous devez collecter et essayez de restreindre votre collecte au strict nécessaire

Si des données spécifiques ne sont pas nécessaires pour une certaine catégorie de personnes, ne les collectez pas.

Traitez et stockez les données de façon à réduire leur précision (à l'instar de la pseudonymisation). Par exemple, stockez seulement l'année de naissance au lieu d'une date de naissance complète si l'application n'a besoin que de l'année.

En cas de collecte de données particulièrement sensibles, par exemple celles relatives à la santé ou à des condamnations pénales, veillez bien à ne collecter que le minimum requis. En raison de ces contraintes réglementaires, le plus simple est encore de ne pas les collecter si vous pouvez vous en passer.

Minimisez la quantité de données collectées également dans les données de journalisation et n'y stockez pas de données sensibles ou critiques (données de santé, mots de passe, etc.).

Pensez à associer des durées de conservation pour chaque catégorie de données, en fonction de la finalité du traitement et des obligations légales ou réglementaires relative à leur conservation. Les journaux doivent également avoir une durée de conservation. Documentez les durées de conservation définies. Vous devrez être en mesure de les justifier.

Une fois les données collectées, mettez en place des mécanismes d'effacement automatique

Mettez en œuvre un système de purge automatique à l'expiration de la durée de conservation. Vous pouvez également mettre en place des revues manuelles des données stockées de façon périodique.

En MySQL, l' event scheduler permet de supprimer les données périmées automatiquement. Par exemple :

CREATE EVENT e_mensuel ON SCHEDULE EVERY 30 DAY COMMENT 'supprime automatiquement les lignes inscrites de plus d un an' DO BEGIN DELETE from votreTable WHERE datediff(now(), votreTable.votreColonneDate) > 365; END

Son pré-requis est d'associer une date d'inscription à chacune des lignes de la base de données afin de permettre le calcul de sa date de péremption.

Afin de garantir un effacement complet, effacez physiquement toutes les données qui ne sont plus nécessaires grâce à des outils spécialisés ou en détruisant les supports physiques.

Si les données sont encore utiles, vous pouvez réduire leur sensibilité en les pseudonymisant, voire en les anonymisant. En cas de pseudonymisation, ces données restent soumises à la réglementation sur les données personnelles ( voir la fiche 1).

La manière de gérer les profils de vos collaborateurs et de vos utilisateurs finaux doit être pensée en amont de vos développements. Elle consiste à définir différents profils d'accès et d'habilitation afin que chaque personne ne puisse accéder qu'aux seules données dont il a effectivement besoin.

Les bonnes pratiques de gestion des utilisateurs

Tout commence par l' utilisation d'identifiants uniques et propres à chaque individu, qu'ils soient utilisateurs de votre application ou collaborateurs dans le développement.

La gestion des profils utilisateurs peut s'accompagner d' un système de journalisation (c'est-à-dire un enregistrement dans des " fichiers journaux " ou " logs ") afin de tracer les activités, et détecter toutes anomalies ou évènements liés à la sécurité, comme les accès frauduleux et les utilisations abusives de données personnelles. L'utilisation de ces dispositifs ne doit en aucun cas servir à d'autres fins que celles de garantir le bon usage du système informatique et les logs ne doivent pas être conservés plus longtemps que nécessaire. Ces systèmes de journalisation ne doivent pas amener à stocker des données au-delà de leur durée de conservation. De manière générale, une durée de six mois est adéquate. Assurez-vous enfin que ces traces ne comportent aucune donnée sensible.

Vous pouvez également prévoir des audits de code ou des tests d'intrusion au sein de votre environnement de développement afin de vous assurer de la robustesse de votre système de gestion des profils.

Fluidifier la gestion des profils d'habilitation

La gestion de vos utilisateurs et collaborateurs implique une revue régulière des droits accordés suivant l'évolution des usages et des mouvements organisationnels au sein de votre projet. L'utilisation de services d'annuaire, comme Lightweight Directory Access Protocol ( LDAP), vous aidera à suivre ces évolutions et vous permettra d'affiner vos stratégies d'accès, par exemple en attribuant des rôles suivant les profils d'usage. Cela vous permet de mieux respecter le principe de moindre privilège.

L'utilisation de compte "suprême" (type root, administrateur, etc.) est à proscrire pour les opérations conventionnelles, car elle constitue la clé de voute de votre système et une cible privilégiée pour un éventuel attaquant externe. Nous vous recommandons d'y associer une politique de mot de passe fort (suite de 10 à 20 caractères ou multifacteur) et de limiter à son plus strict nécessaire le nombre de personnes ayant connaissance de celui-ci.

Favorisez l'usage d'un gestionnaire de mots de passe au sein de votre projet et privilégiez le passage à une authentification forte lorsque c'est possible. Évitez également les comptes génériques partagés entre plusieurs personnes.

Les gestionnaires de mots de passe permettent de centraliser l'ensemble des identifiants et des mots de passe dans une base de données unique. Certains d'entres permettent également de tester la robustesse des mots de passe et d'en générer automatiquement et de manière aléatoire tout en répondant aux contraintes imposées par les systèmes. Assurez-vous avant tout usage que les mots de passes conservées par le logiciel sont chiffrés et protégés par un mot de passe suffisamment robuste.

Le gestionnaire de mots de passe libre KeePass, dans sa en version 2.10, a obtenu la Certification de Sécurité de Premier Niveau (CSPN) de l'ANSSI.

Ressources utiles

Vous utilisez des bibliothèques, kits de développement (" SDK " en anglais), ou d'autres composants logiciels écrits par des tiers ? Voici quelques conseils pour intégrer ces outils tout en gardant la maîtrise de vos développements.

Faire un choix éclairé

Évaluez l'intérêt de l'ajout de chaque dépendance. Certaines briques logicielles couramment utilisées ne font que quelques lignes. Cependant chaque élément rajouté est une augmentation de la surface d'attaque de vos systèmes. Dans le cas où une seule bibliothèque propose plusieurs fonctionnalités, n'intégrez que les fonctionnalités dont vous avez effectivement besoin : en activant le minimum de fonctionnalités, vous réduisez le nombre de bugs potentiels qui pourraient survenir.

Choisissez des logiciels, bibliothèques et SDK maintenus :

Si vous souhaitez utiliser du logiciel libre ou open source, essayez de choisir des projets ou des solutions avec une communauté active, des mises à jour régulières et une bonne documentation ;

Si vous utilisez d'autres types de solutions avec un support commercial, assurez-vous contractuellement que le code sera maintenu et mis à jour pendant toute la durée de vie de votre projet.

Prenez en compte la question de la vie privée. Certains SDK et certaines bibliothèques collectent des données personnelles depuis les applications et les sites sur lesquels ils sont intégrés. Vérifiez les engagements pris par le fournisseur de ces solutions, les directives mise en œuvre fournies. Assurez-vous enfin que l'intégration respecte les conditions suivantes :

l'utilisateur final est informé de ces opérations de traitements ;

un mécanisme est prévu pour recueillir le consentement des utilisateurs lorsqu'une collecte de données non strictement nécessaires pour la fourniture du service est mis en œuvre depuis son terminal ;

les éventuels transferts de données hors de l'union européenne sont correctement encadrés ;

la relation avec le tiers est encadré par un contrat de sous-traitance conforme à l'article 28 du RGPD.

Ces obligations s'appliquent particulièrement aux " SDK " permettant d'afficher de la publicité ciblée sur les terminaux. Ils s'appliquent également à certains outils de sécurisation des terminaux et des sites web, tel que le système de détection d'utilisateurs reCAPTCHA de Google, qui indique dans ses conditions d'utilisation qu'en raison des traitements mise en œuvre, son usage est soumis au consentement des utilisateurs.

Si vous utilisez des mécanismes cryptographiques, il est fortement déconseillé d'implémenter des algorithmes ou des protocoles cryptographiques vous-mêmes. Essayez plutôt de choisir des bibliothèques cryptographiques maintenues, reconnues et faciles d'utilisation.

Évaluer les éléments choisis

Lisez leur documentation et changez leur configuration par défaut. Il est important de connaître le fonctionnement de vos dépendances. Les bibliothèques et SDK tiers sont souvent fournis avec des fichiers de configuration par défaut, qui ne sont que trop rarement modifiés par manque de temps, ce qui provoque de nombreuses failles de sécurité ;

Auditez vos bibliothèques et SDK. Savez-vous vraiment ce que font toutes les bibliothèques et SDK que vous intégrez ? Quelles sont les données qui sont envoyées à travers ces dépendances et quelles sont les destinataires de ces données ? Cet audit vous permettra de déterminer les obligations à respecter en matière de protection des données et d'établir la responsabilité des acteurs ;

Cartographiez vos dépendances. Les bibliothèques et SDK tiers peuvent également intégrer d'autres composants : auditer leur code vous permettra de mieux cartographier toutes vos dépendances et de mieux agir si un problème affecte l'une d'elles. Il est aussi recommandé de faire des audits sécurité de vos composants tiers et d'effectuer une veille sur ceux-ci ;

Les gestionnaires de dépendances intègrent des fonctionnalités de suivi et d'audit. A titre d'exemple, la commande npm audit affiche un rapport des vulnérabilités connues de chaque dépendance d'un projet node.js.

La visualisation des dépendances des applications compilées, ou "packagées", nécessitent des outils plus élaborés. En voici quelques exemples :

L' association Exodus Privacy met librement à disposition la plateforme d'analyse des applications Android εxodus.

L'outil otool liste les dépendances des bibliothèques d'applications macOS et iOS.

L'outil dependency-cruiser affiche sous forme de graphique les dépendances de projet javascript.

Faites attention aux tentatives de typosquattage et autres techniques malveillantes. Vérifiez les noms des dépendances, ainsi que de leurs propres dépendances pour éviter des attaques. Ne copiez-collez pas de lignes de commandes depuis des sites inconnus.

Maintenir les bibliothèques et SDK

Utilisez des systèmes de gestion de dépendances (tels que yum, apt, maven, pip, etc.) afin de maintenir une liste à jour de vos dépendances.

Gérez les mises à jour de vos dépendances, particulièrement dans le cas de mises à jour de sécurité qui corrigent des vulnérabilités. Vous devez mettre en place une procédure documentée pour les gérer et les déployer le plus vite possible ;

Faites attention aux versions des bibliothèques et SDK en fin de support qui ne seront plus maintenues : essayez de trouver une autre solution (choisir une nouvelle bibliothèque, renouveler un support commercial) ;

Surveillez les statuts des projets open-source, notamment le changement de propriétaire du domaine ou du package, certaines attaques utilisant des mises à jour malicieuses de dépendances populaires.

Ressources utiles

Il est indispensable d'adopter au plus tôt une bonne hygiène d'écriture de code. Une bonne lisibilité de votre code permettra de réduire l'effort de maintenance, d'audit et de corrections des bogues dans le temps, que vous, vos collaborateurs ou vos futurs contributeurs devront fournir.

Documentez le code et l'architecture

La documentation est parfois laissée de côté au moment du développement, par manque de temps ou de visibilité sur l'ensemble du projet. Elle est pourtant cruciale pour la maintenabilité de votre projet : elle permet de comprendre globalement le fonctionnement du code, et de savoir quelles parties du code sont affectées par une modification.

Documentez l'architecture, pas uniquement le code : vous devez être en capacité de garder une vision d'ensemble lorsque vous écrivez votre documentation et d'aider les développeuses et développeurs à comprendre de manière globale le fonctionnement de tous vos composants. En conséquence, privilégiez les schémas et des explications claires lorsque vous documentez votre projet.

Maintenez la documentation en même temps que le code : la meilleure façon d'avoir une documentation à jour est de la modifier au fil de l'eau en même temps que le code.

" Versionnez " la documentation avec le code : si vous utilisez un gestionnaire de code source vous pouvez pour chaque " commit " modifiant votre code inclure également les changements de documentation (voir notamment la fiche " Gérer son code source ").

Certains systèmes de documentation utilisent le code lui-même comme support. La documentation est ainsi écrite directement dans les commentaires du programme.

Doxygen, par exemple, offre une syntaxe permettant de générer de la documentation, qui est compatible avec les langages de programmation les plus utilisés. L'exemple suivant est une classe C++ commentée suivant son paradigme :

//! Une classe d'exemple /*! Description plus approfondie de la classe. (Et n'oubliez pas de documenter sans mettre de descriptions génériques dans votre projet.) */ class Example { public: //! Le constructeur de la classe /*! Description plus approfondie du constructeur. */ Example(); //! Le destructeur de la classe. /*! Description plus approfondie du destructeur. */ virtual ~Example(); //! Une méthode qui fait quelque chose /*! \param param1 un paramètre important \param param2 un deuxième paramètre aussi important \return le résultat qui dépend des deux paramètres et de l'état interne de l'instance */ int doSomething(int param1, const char *param2); //! Une variable membre publique /*! Description plus approfondie de la variable membre. */ int attr_; };

Certains langages de programmation supportent également nativement l'utilisation des commentaires pour documenter du code. Par exemple, les "docstrings" en Python :

class Example: """Une classe d'exemple Description plus approfondie de la classe. """ def __init__(self): """Le constructeur de la classe Description plus approfondie du constructeur. """ self.attr = None def do_something(self, param1, param2): """Une méthode qui fait quelque chose param1: un paramètre important param2: un deuxième paramètre aussi important return: le résultat qui dépend des deux paramètres et de l'état interne de l'instance """ [...] return result help(Example) # affiche la documentation complète de la classe, qui est générée en partie à partir des docstrings help(Example.do_something) # affiche uniquement la documentation de la méthode

Pensez à aborder la sécurité dans votre documentation : n'oubliez pas d'envisager la dimension sécurité dans la documentation utilisateur ou développeur. Vous pouvez notamment documenter les différents choix de configuration de votre application, et expliquer quels sont les réglages les plus sécurisés.

Contrôlez la qualité de votre code et de sa documentation

Un code de qualité passe par l' adoption de bonnes pratiques et de conventions de codage appliquées de manière cohérente sur l'ensemble de votre programme. Pour choisir votre convention de codage, le mieux est de se référer à des conventions existantes. Voici quelques exemples de bonnes pratiques supplémentaires :

Des outils peuvent vous aider à contrôler la qualité de votre code. Une fois correctement paramétrés, ils éviteront de relire le code pour vérifier la bonne mise en place des conventions de codage. En voici quelques exemples :

les environnements de développement intégrés (" IDE "), éventuellement à l'aide de greffons (" plugins "), peuvent être configurés pour respecter les règles d'indentation du code, les sauts de ligne entre les différentes portions de code ou encore la position des accolades et autres parenthèses ;

les logiciels de mesure de la qualité du code source peuvent signaler les duplications de code, le respect des règles de programmation ou des bugs potentiels.

Certains langages de programmation disposent d'un style de programmation standard, par exemple PEP8 pour le langage Python. Des outils automatiques peuvent contrôler le respect de ces styles, par exemple pep8.py pour la PEP8. Pour les langages ne disposant pas de styles de programmation standard, différents styles ont été créés, avec des outils automatiques permettant de les vérifier, par exemple SonarQube ou checkstyle pour Java.

Des outils de qualité de code plus généraux peuvent détecter un certain nombre de problèmes : variables non utilisées ou non définies, duplication de code, etc. Par exemple ESLint pour Javascript ou Clippy pour Rust.

Enfin, des outils d'analyse statique permettent une analyse plus fine du code, afin d'évaluer son comportement sans pour autant exécuter le programme, par exemple SpotBugs pour Java ou Frama-C pour le C.

Tester son produit permet de vérifier son bon fonctionnement, de s'assurer d'une bonne expérience utilisateur ainsi que de trouver et prévenir des défauts avant sa mise en production. Tester son produit permet également de réduire les risques d'atteinte aux données personnelles.

Automatisez les tests

Les tests de développement (unitaires, fonctionnels, etc.) vont vérifier l'adéquation entre les spécifications et le fonctionnement du produit. Les tests de sécurité (tests à données aléatoires aussi appelés " fuzzing ", scan de vulnérabilités, etc.), vont vérifier que le produit continue d'avoir un fonctionnement acceptable quand on s'éloigne de son utilisation normale et qu'il ne présente pas de vulnérabilité qui pourrait permettre à des tiers de compromettre sa sécurité. Ces deux types de tests sont importants pour le bon fonctionnement de votre application.

Mettez en place un système d'intégration continue afin de lancer les tests automatiquement après chaque modification dans votre code source.

Les logiciels d'intégration continue permettent d'automatiser les vérifications de code et d'y associer des métriques à chaque modification de code source. Cette pratique vise à détecter les problèmes d'intégration au plus tôt dans le stade de développement comme des modifications à la mise en production.

Des solutions propriétaires et libres existent pour interfacer cette automatisation avec les outils de gestion de code source, entre autres Jenkins et GitLab CI/CD.

Une attention particulière doit être portée sur la sécurisation de ce type de solution. Veillez notamment à ce que la solution dispose pas d'accès privilégiés au gestionnaire de code source ou aux systèmes les hébergeant.

Intégrez les tests dans votre stratégie d'entreprise

Dans la mise en place de l'environnement de tests dans la stratégie de l'entreprise, les métriques acceptables doivent être définies conjointement par toutes les parties avant le développement.

Les métriques auxquelles il faut réfléchir sont par exemple :

Attention aux données de test !

Lors du développement de votre service, il est toujours préférable d'utiliser des données fictives. A défaut, les environnement des tests doivent faire l'objet des mêmes mesures de sécurité que l'environnement de production.

La génération de données fictives peut se faire au travers d'outils construits pour tester vos services en générant des données variées et parfois inattendues. Par exemple, en python, la librairie Faker permet simplement de générer de nombreux types de données :

from faker import Faker # Définit une instance localisée en France fake = Faker("fr_FR") # Numéro de téléphone fake.phone_number() # '+33 3 38 24 21 94' # Adresse email fake.ascii_email() # 'lorraineboutin@live.com' # Numéro de carte de crédit fake.credit_card_number() # '180009753513939' # IBAN fake.iban() # 'FR05660487647593824219489241'

Si vous avez besoin d'importer des configurations existantes depuis la production dans vos scénarios de test, pensez à anonymiser les données personnelles qui peuvent être présentes.

Le principe de transparence du RGPD exige que toute information ou communication relative au traitement de données à caractère personnel soit concise, transparente, compréhensible et aisément accessible en des termes simples et clairs.

Qui informer et quand le faire ?

Quelles informations dois-je donner ?

Dans tous les cas, il faut préciser :

l'identité et les coordonnées de l'organisme qui collecte les données (qui traite les données ?) ;

les finalités (à quoi vont servir les données collectées ?) ;

la base légale sur laquelle repose le traitement des données (retrouvez toutes les informations sur les bases légales) ;

le caractère obligatoire ou facultatif du recueil des données (ce qui suppose une réflexion en amont sur l'utilité de collecter ces données au vu de l'objectif poursuivi - principe de " minimisation " des données) et les conséquences pour la personne en cas de non-fourniture des données ;

les destinataires ou catégories de destinataires des données (qui a besoin d'y accéder ou de les recevoir au vu des finalités définies, y compris les sous-traitants ?) ;

la durée de conservation des données (ou critères permettant de la déterminer) ;

l'existence des droits des personnes concernées ainsi que les moyens de les exercer ( les droits d'accès, de rectification, d'effacement et à la limitation sont applicables pour tous les traitements) ;

les coordonnées du délégué à la protection des données de l'organisme, s'il a été désigné, ou d'un point de contact sur les questions de protection des données personnelles ;

le droit d'introduire une réclamation auprès de la CNIL.

Dans certains cas particuliers, il faut fournir des informations supplémentaires, comme dans le cas de transferts de données hors UE, de prise de décision entièrement automatisée ou de profilage, ou encore lorsque la base légale du traitement est l'intérêt légitime poursuivi par l'organisme qui collecte les données ( voir le site de la CNIL pour en savoir plus).

En cas de collecte indirecte, il faut ajouter :

Sous quelle forme dois-je fournir ces informations ?

L'information doit être facile d'accès : l'utilisateur doit la trouver sans difficultés.

Elle doit être fournie de manière claire et compréhensible, c'est-à-dire avec un vocabulaire simple (phrases courtes, sans termes juridiques ou techniques, sans ambiguïtés) et une information adaptée au public visé (avec une attention particulière à l'égard des enfants et personnes vulnérables).

Elle doit être écrite de manière concise. Afin d'éviter l'écueil du déluge d'informations noyant l'utilisateur, il faut amener les informations les plus pertinentes au bon moment. Vous pouvez adopter une approche à plusieurs niveaux, en veillant à ce que les personnes bénéficient d'un aperçu clair des informations qui leur sont accessibles sur le traitement de ses données à caractère personnel et du moyen de trouver les informations détaillées.

Elle doit être adaptée au support d'usage. Par exemple, pour des dispositifs sans écran comme des enceintes connectées, vous pouvez vous reposer sur un dispositif externe ("application compagnon") pour délivrer une information exhaustive aux utilisateurs. Un premier niveau d'information doit également être accessible par l'interface d'usage du dispositif.

Les informations en rapport avec la protection des données doivent pouvoir être distinguées de celles qui ne sont pas spécifiquement liées à la vie privée (comme les clauses contractuelles ou les conditions générales d'utilisation).

Les méthodes et techniques choisies pour rendre l'information accessible peuvent varier en fonction du contexte et des modalités d'interaction avec les personnes : pop-in, bulles, pages dédiées, QR code, messages audio, vidéos, panneaux d'affichage, documentation papier, campagne d'information, etc.

De plus, le moment de présentation de l'information est crucial : il faut veiller à faire en sorte qu'elle soit délivrée " à froid " pour que la personne en prenne pleinement connaissance. Une information claire donnée en amont d'un acte d'achat ou de souscription et, à l'inverse, en aval après un temps d'appropriation du service sont ainsi généralement plus accessibles et mieux prises en compte qu'une information placée au moment où la personne vient de décider d'acheter ou de souscrire car elle est généralement soumise à un biais de confirmation à ce moment-là.

Le site Données & Design développe ces concepts et fournit des exemples d'interfaces et d'informations permettant de faciliter la compréhension du traitement. Le site de la CNIL comprend également des exemples de notices d'information à plusieurs niveaux d'information à adapter ou à adapter suivant le contexte de votre traitement.

Quelle communication effectuer lorsque la sécurité des données est compromise ?

Si ces risques sont élevés, l'organisme doit également en informer les personnes concernées le plus rapidement possible et leur adresser des conseils pour protéger leurs données (ex. annulation d'une carte bancaire compromise, modification d'un mot de passe, modification des paramétrages vie privée...).

La notification de la violation à la CNIL doit se faire via le site web de la CNIL. La fiche 18 Se prémunir contre les attaques informatiques donne quelques exemples d'attaques qui peuvent conduire à devoir notifier la CNIL et, le cas échéant, les personnes concernées.

Ressources utiles

Les personnes dont vous traitez les données ont des droits sur ces données : droit d'accès, de rectification, d'opposition, d'effacement, à la portabilité et à la limitation du traitement. Vous devez leur donner les moyens d'exercer effectivement leurs droits et prévoir dans vos systèmes informatiques les outils techniques qui permettront la bonne prise en compte de leurs droits.

Les mesures minimales à mettre en place

Tous les organismes qui utilisent des données personnelles ont l'obligation d'indiquer où et comment les personnes peuvent exercer leurs droits relatifs à ces données. Vous pouvez par exemple mentionner une adresse e-mail ou un formulaire web au moment de l'information des personnes, ainsi que dans votre politique de vie privée.

Voici quelques exemples de droits et leur possible implémentation

Droit à l'effacement : les personnes ont le droit de demander l'effacement de l'intégralité des données que vous détenez sur elles.
Possibles implémentations :

1. Prévoyez une fonctionnalité permettant d'effacer toutes les données relatives à une personne.

2. Prévoyez aussi une notification automatique des sous-traitants afin qu'ils effacent eux aussi les données relatives à cette personne.

3. Prévoyez un effacement des données également dans les sauvegardes, ou une autre solution permettant de ne pas restaurer les données effacées relatives à cette personne.

L'exercice d'un droit peut constituer un événement exceptionnel dans le parcours utilisateur classique d'un service. De fait, il est d'autant plus important de bien la guider dans cette démarche qui peut paraître intimidante : proposer des étapes simples pour formuler une demande, rappeler l' utilité des droits et des résultats attendus, mettre à disposition des modèles de demande pour faciliter les démarches.

L'exercice d'un droit peut s'effectuer par différentes modalités et différents formats: formulaire, mail, comptes en ligne, courrier. Le site Données & Design fournit des exemples d'interfaces pour faciliter les exercices de droits.

Tout au long du processus d'exercice des droits, il est important de veiller à ce que la personne soit informée de l'évolution de sa demande. Lui faire des retours régulièrement, pour attester de la bonne réception de sa demande ou encore pour lui faire des retours sur les décisions prises suite à celle-ci, dans un format accessible et correspondant à celui avec lequel elle vous a contacté est donc nécessaire.

Afin d'assurer à la personne une bonne continuité dans sa démarche d'exercice de droit, ou en cas de contestation de sa part de la décision que vous prenez auprès d'une autorité de protection, il est recommandé de permettre à la personne de pouvoir garder facilement une trace de sa démarche. Un système d'impression de demandes, d'archivage ou de téléchargements des échanges, etc. peuvent ainsi être mis en place.

En conclusion

Le site Données & Design développé par le Laboratoire d'Innovation Numérique de la CNIL (LINC).

Enfin, soyez inventifs ! (En cas de doute, demandez conseil à la CNIL.)

Les données personnelles ne peuvent pas être conservées pour une durée indéfinie : celle-ci doit être définie en fonction des objectifs poursuivis par le traitement. Une fois cet objectif atteint, ces données devraient être archivées, supprimées ou anonymisées (par exemple afin de produire des statistiques).

Les cycles de conservation des données

Le cycle de conservation des données à caractère personnel peut être divisé en trois phases successives distinctes :

Les mécanismes de suppression de données personnelles des bases actives permettent de garantir que les données sont conservées et accessibles par les services opérationnels uniquement le temps nécessaire à l'accomplissement de l'objectif poursuivi par le traitement.

Veillez également à prévoir des modalités d'accès spécifiques aux données archivées du fait que l'utilisation d'une archive doit intervenir de manière ponctuelle et exceptionnelle.

Si possible, utilisez la même implémentation lors de la mise en œuvre de la purge ou l'anonymisation des données que celle gérant le droit à l'effacement (cf. fiche sur l'exercice des droits), afin de garantir un fonctionnement homogène de votre système.

Quelques exemples de durée de conservation

Les données relatives à la gestion de la paie ou au contrôle des horaires des salariés peuvent être conservées pendant 5 ans.

Les données figurant dans un dossier médical doivent être conservées 20 ans.

Les coordonnées d'un prospect ne répondant à aucune sollicitation peuvent être conservées pendant 3 ans.

Les données de journalisation peuvent être conservées entre 6 mois et un an. Cette durée peut être allongée dans des cas spécifiques, lorsque la loi l'impose sur certaines catégories de traitements et suivant le risque de détournement de la finalité de l'utilisation des données.

Pour pouvoir être mis en œuvre, les traitements de données personnelles doivent se fonder sur l'une des " bases légales " mentionnées à l'article 6 du RGPD. La base légale d'un traitement est en quelque sorte la justification de l'existence même du traitement. Le choix d'une base légale va directement impacter les conditions de mise en œuvre du traitement et les droits des personnes. Ainsi, prévoir en amont d'un développement les bases légales des traitements prévus dans le projet vous permettra d'intégrer au mieux les fonctions nécessaires à la conformité à la loi de ces traitements et au respect des droits des personnes.

Définition des bases légales prévues par le RGPD

Dans le cadre d'un développement pour un organisme privé (entreprises, associations, etc.), les bases légales les plus souvent utilisées sont :

Si vous êtes une autorité publique ou un organisme poursuivant des missions d'intérêt public, d'autres bases légales peuvent également être utilisées :

Vous trouverez sur le site de la CNIL un ensemble de fiches pratiques qui vous permettra de vous accompagner dans le choix des bases légales les plus adaptées à vos traitements.

Enfin, dans des cas très spécifiques, la sauvegarde des intérêts vitaux peut être retenue comme base légale, par exemple lorsque le traitement est nécessaire pour suivre la propagation d'épidémies ou dans les cas d'urgence humanitaire.

Choisir la base légale adéquate

Une seule base légale doit être choisie pour une finalité donnée. Les bases légales ne peuvent être cumulées pour une même finalité. Un même traitement de données peut poursuivre plusieurs finalités, c'est-à-dire plusieurs objectifs, et une base légale devra alors être définie pour chacune d'elles.

Comme évoqué ci-dessus, si vous êtes un organisme public, l'obligation légale et la mission d'intérêt public seront les plus pertinentes dans la majorité des cas.

Si votre traitement s'inscrit dans une relation contractuelle et que sa finalité est objectivement et strictement nécessaire à la fourniture du service de l'utilisateur (par exemple, le nom, le prénom et l'adresse pour créer un compte sur un site de e-commerce) alors la base légale du contrat devrait être appropriée.

Si votre traitement ne s'inscrit pas dans une relation contractuelle avec l'utilisateur, alors les bases légales du consentement ou de l'intérêt légitime peuvent être mobilisées. Si votre traitement est potentiellement intrusif (profilage, collecte de données de géolocalisation, etc.), le consentement est susceptible d'être la base légale appropriée.

Les bases légales utilisées doivent toujours figurer dans les informations transmises à la personne.

Il est recommandé de documenter le choix de vos bases légales. Ces choix peuvent par exemple être indiqués dans une cartographie des traitements ou associés à votre documentation technique.

Le tableau suivant récapitule les exercices des droits à prévoir suivant les bases légales choisies :

* Lorsque votre traitement est fondé sur l'intérêt légitime, vous devrez également indiquer les intérêts légitimes poursuivis (lutte contre la fraude, sécurité du système, etc.)

** Lorsque votre traitement est fondé sur l'obligation légale, le droit à l'effacement peut s'appliquer si le traitement répond aux conditions suivantes :

1. les données à caractère personnel ne sont plus nécessaires au regard des finalités pour lesquelles elles ont été collectées ou traitées d'une autre manière; ou

2. les données à caractère personnel ont fait l'objet d'un traitement illicite; ou

3. les données à caractère personnel doivent être effacées pour respecter une obligation légale qui est prévue par le droit de l'Union ou par le droit de l'État membre auquel le responsable du traitement est soumis.

La directive européenne ePrivacy requiert le consentement de l'utilisateur avant toute action visant à stocker des informations - via des cookies, identifiants ou autres traceurs (empreintes logiciels, pixels) - ou à accéder à des informations stockées dans l'équipement terminal de l'utilisateur. Afin de se conformer à ses obligations, tout éditeur de site ou d'application doit analyser ses pratiques en terme d'usage des traceurs selon les principes présentés ci-après.

Les traceurs visés par l'obligation du recueil du consentement préalablement à leur usage

Cette obligation s'applique à toutes les solutions techniques reposant sur des opérations de lecture ou écriture dans le terminal et désignées par la CNIL sous le terme de " traceur ". Elles s'appliquent notamment aux cookies, mais aussi aux " local shared objects " appelés parfois les " cookies Flash ", le " local storage " mis en œuvre au sein du standard HTML 5, les identifications par calcul d'empreinte du terminal ou " fingerprinting ", les identifiants générés par les systèmes d'exploitation (qu'ils soient publicitaires ou non : IDFA, IDFV, Android ID, etc.) ou les navigateurs (identifiants de cohorte,etc.), les identifiants matériels (adresse MAC, numéro de série ou tout autre identifiant d'un appareil), etc.

La CNIL a identifié cinq catégories de finalité qui nécessitent obligatoirement un consentement préalable de l'utilisateur avant leur dépôt:

la publicité personnalisée ;

la mesure de la publicité (non ciblée) ;

la publicité geolocalisée ;

la personnalisation du contenu (éditorial ou en termes de produits) ;

le partage sur les réseaux sociaux.

Les traceurs qui ne sont pas visés par ces obligations

Certains traceurs peuvent être exemptés du recueil de consentement : les traceurs destinés à l'authentification auprès d'un service, ceux destinés à garder en mémoire le contenu d'un panier d'achat sur un site marchand, certains traceurs visant à générer des statistiques de fréquentation, ou encore ceux permettant aux sites payants de limiter l'accès gratuit à un échantillon de contenu demandé par les utilisateurs.

Le fait d'utiliser un seul traceur pour de multiples finalités n'exonère pas de recueillir le consentement pour chacune des finalités qui le nécessite. Par exemple, si un cookie d'authentification est également utilisé à des fins de ciblage publicitaire, le consentement de l'internaute devra être recueilli pour cette dernière finalité, de la même manière que pour un site non " loggué ".

Sous certaines conditions, les cookies relatifs à la mesure d'audience peuvent être exempté du recueil de consentement. La CNIL a mis en place un programme permettant de connaître les configurations à suivre pour différents outils.

Le chargement de ressources statiques sans traceurs, c'est-à-dire les images, les scripts et les feuilles de styles, n'est pas considéré en tant que tel comme un accès ou une inscription de données dans le terminal d'utilisateur au sens de ePrivacy, et n'est pas soumis à des obligations spécifiques à ce titre.

En pratique

Si vous utilisez des traceurs visées par ces obligations, il vous faut suivre les étapes suivantes :

1- Lister les traceurs utilisés (tous les types de traceurs) et les classer par finalité en fonction des catégories identifiées.

2- Lister les tiers qui déposent ces traceurs.

3- Mettre en place un blocage des scripts ou appels HTTP déposant et accédant aux traceurs nécessitant le consentement afin de s'assurer de l'absence d'opération avant tout consentement ou bien mettre en place une solution technique permettant de garantir l'absence d'opération de lecture ou écriture tant que l'utilisateur n'a pas consenti..

4- Mettre en place une interface qui propose à l'utilisateur de consentir au dépôt de ces traceurs.

5- Sur chaque page, intégrer une icône ou lien pour faire réapparaitre l'interface afin de permettre le retrait du consentement.

6- Régulièrement, tester votre site ou votre application pour bien s'assurer qu'aucun traceur non nécessaire n'est déposé sans consentement et documentez votre conformité.

Les finalités choisies doivent être formulées de manière intelligible et dans un langage adapté et suffisamment clair pour permettre aux utilisateurs de comprendre précisément ce à quoi ils consentent.

Il est fortement recommandé de hiérarchiser les informations délivrées à l'utilisateur sur plusieurs niveaux pour plus de clarté.

Le premier niveau de l'interface doit comprendre :

une liste des finalités poursuivies,

un lien vers la liste les tiers,

une explication des conséquences qui s'attachent à une acceptation ou un refus,

un bouton pour accepter et refuser (refuser les traceurs devant être aussi aisé que de les accepter).

Le second niveau d'interface doit permettre à l'utilisateur de faire un choix sur la finalité de traceurs:

D'autres exemples d'interface, notamment pour les applications, sont disponibles dans la recommandation de la CNIL proposant des modalités pratiques de mise en conformité en cas de recours aux "cookies et autres traceurs".

Des sociétés proposent également des outils de Consent Management Platform (CMP) ou des Tag Managers pour faciliter la mise en conformité des sites.

La gestion d'un site web ou d'une application mobile requiert généralement l'utilisation de statistiques de fréquentation ou de performance. Utilisant des cookies ou d'autres traceurs, ils peuvent être exemptés de consentement sous certaines conditions.

Bénéficier de l'exemption de consentement

Pour bénéficier de l'exemption de consentement sur les traceurs de mesure d'audience, et afin de limiter à ce qui est strictement nécessaire à la fourniture du service, la CNIL demande de respecter les conditions suivantes :

La CNIL recommande par ailleurs que :

Il est par ailleurs possible pour un sous-traitant de fournir un service de mesure d'audience comparatif à de multiples éditeurs, sous réserve que les données soient collectées, traitées et stockées de manière indépendante pour chaque éditeur et que les traceurs soient indépendants les uns des autres.

En pratique

La destruction, la perte, l'altération, ou la divulgation non autorisée de données à caractère personnel transmises, conservées ou traitées par un organisme constituent une violation de données personnelles. En tant que développeuse ou développeur, vous êtes tenu*e*s de mettre en œuvre toutes les mesures nécessaires dans vos applications pour prévenir les attaques ou les négligences pouvant entrainer de telles violations.

Cette fiche dresse une liste non-exhaustive de vulnérabilités ayant conduit à des violations de données notifiées à la CNIL. Elle liste des exemples de mesures qui auraient permis de les éviter.

Manipulation d'URL

La manipulation d'URL consiste à modifier les éléments d'une URL dans le navigateur en vue d'accéder à une ressource non ou mal sécurisée et auquel l'internaute ne devrait normalement pas avoir accès (page web, document accessible en ligne...).

Différents modes opératoires existent :

Des mesures permettent de limiter ce risque :

Ressources :

Bourrage d'identifiants ("Credential stuffing")

Le bourrage d'identifiants (" credential stuffing ") consiste à réaliser des tentatives d'authentification massives sur des sites et services web à partir de couples identifiants/mots de passe. Il est le plus souvent la conséquence de violations de données ayant préalablement affecté d'autres sites web, par le biais desquelles des listes de couples d'identifiants/mots de passe sont alors disponibles en très grande quantité au sein du web caché (" dark web ").

Il est rendu possible par la réutilisation par les utilisateurs de couples d'identifiants/mots de passe communs pour des services en ligne différents, et permet aux attaquants de prendre le contrôle de comptes utilisateurs parfois sensibles (emails, banque, réseaux sociaux)

Des mesures permettent de limiter ce risque :

Ressources :

Attaques par force brute et par dictionnaire

Ressources :

Injection de code indirecte ("Cross-Site Scripting"/XSS)

Les attaques par " injection de code indirecte " (de l'anglais Cross-Site Scripting, abrégé XSS) consistent à insérer un contenu malveillant dans une page d'un serveur de confiance afin qu'il soit affiché sur le navigateur de la victime.

Ces injections peuvent permettrent l'exécution de scripts malveillants sur le navigateur de l'internaute. Elle peuvent notamment donner lieu : à l'affichage d'une fausse fenêtre d'authentification afin de dérober les identifiants et le mot de passe de l'utilisateur, à l'exécution de commandes système, à la redirection vers un site malveillant, à la récupération des cookies présents sur la machine (ex : cookie d'authentification), au téléchargement de programmes malveillants ou encore à l'enregistrement des frappes clavier (key logging), etc.

Ces injections peuvent prendre plusieurs formes :

le contenu malveillant peut être injecté directement sur le site par l'attaquant, par exemple dans ses champs de commentaires ;

le contenu malveillant peut être inclus dans les paramètres des requêtes envoyées aux serveurs afin d'exploiter ses vulnérabilités, par exemple pour obtenir un accès complet à sa base de données ;

le contenu malveillant peut être injecté dans les paramètres d'une URL et affiché sur le navigateur de l'utilisateur comme un contenu "légitime" du site.

Des mesures permettent de limiter ces risques :

mettre à jour les composants logiciels régulièrement ;

diligenter des audits de sécurité (tests de pénétration) de façon périodique et après chaque mise à jour significative ;

neutraliser les caractères utilisés pour l'insertion de script (> < /) lorsque c'est possible (cf. nettoyage " HTML escape ") ;

vérifier les éléments récupérés en paramètre et rejeter tous ceux qui ne sont pas attendus par l'application ;

vérifier que les téléversements (upload) légitimes (photos de profil, par exemple) sur le serveur soient au format attendu et placés dans un répertoire ne permettant pas leur exécution ;

exécuter des outils automatisés de détection de failles et de flux " anormaux " (présence de scripts dans les journaux et requêtes serveurs).

Ressources :

Injection SQL (SQLi)

L'injection SQL est une technique permettant d'injecter du code de type SQL (langage utilisé pour manipuler certaines bases de données) dans les données envoyées au serveur web au lieu de données valides. Par exemple, un attaquant peut injecter du code SQL dans les champs des formulaires HTML ou dans les URL des pages web.

De cette façon, les attaquants outrepassent les contrôles de sécurité et peuvent consulter ou modifier des éléments présents dans une base de données. D'autres types d'injection de code sont également possibles (par exemple : les injections LDAP, si le serveur web contacte un annuaire via une requête LDAP, ou du code bash si le serveur appelle une commande externe en passant les paramètres à un shell).

Des mesures permettent de limiter ce risque :

utiliser des requêtes préparées ( Prepared Statements) exclusivement, lorsque cela est possible ;

échapper les caractères susceptibles de provoquer une injection, en utilisant des fonctions spécialisées ;

restreindre et contrôler les entrées externes autant que possible. Par exemple, si l'identifiant est un chiffre, n'accepter que des chiffres ;

vérifier les données externes (notamment lorsqu'il est impossible de les restreindre ou lorsque certains caractères spéciaux utilisés en SQL sont des données acceptables en entrée) ;

mettre en œuvre une gestion fine des droits d'accès à la base de données. Par exemple, il est inutile d'accorder un accès total en lecture et écriture à un service qui ne fait que lire des données. Il est également possible de restreindre les droits de l'utilisateur à une seule table ou une seule base de données ;

neutraliser les messages d'erreur afin d'éviter la divulgation d'informations techniques recherchées par les attaquants (en affichant un message de type " erreur 403 ", par exemple).

Ressources :

Les programmes malveillants et les rançongiciels

Ainsi, tout téléchargement ne provenant pas d'une source fiable est potentiellement un programme malveillant. Dans la majorité des cas, il est téléchargé en :

ouvrant la pièce jointe d'un email provenant d'une source inconnue ;

ou en téléchargeant un logiciel mis à disposition sur un site inconnu (ou n'étant pas de confiance) ;

ou en téléchargeant des logiciels associés à un logiciel connu ou provenant d'une source non fiable ;

ou en visitant un site web malveillant.

Le rançongiciel ( ransomware, cryptolocker) se transmet souvent via une pièce jointe de courriel ou via des liens permettant le téléchargement de logiciels ou de contenus. Une fois présent sur son hôte, ce programme va progressivement chiffrer tous les fichiers qui lui sont accessibles afin de les rendre illisibles par les utilisateurs. Dans le cas d'un réseau d'entreprise, le logiciel va chercher à se propager sur les ressources accessibles via le réseau en utilisant des failles connues, des mots de passe faibles ou réutilisés. L'attaquant demande alors une rançon à la personne ou à l'organisme victime en échange de la clé permettant de déchiffrer les fichiers.

Le rançongiciel est un malware très répandu car très rentable pour les attaquants. En effet, celui-ci exige une rançon rapide et le plus souvent en cryptomonnaie. Si ce type d'attaque est parfois opportuniste, pour des rançons correspondant généralement à quelques centaines d'Euros, certains attaquants ciblent également depuis plusieurs années des entités de tailles importantes (grandes entreprises, collectivités, etc.) pour des montants pouvant atteindre plusieurs dizaines de millions d'Euros.

Les mesures à mettre en œuvre afin de réduire le risque d'attaque sont surtout d'ordre organisationnel :

maintenir à jour ses systèmes et logiciels (antivirus, équipements pare-feu, etc.) ;

faire des sauvegardes régulières des données, les tester régulièrement et en conserver au moins une copie hors du réseau de l'organisme ;

sensibiliser les utilisateurs aux risques et aux bonnes pratiques : ne pas ouvrir les pièces jointes, ni cliquer sur les liens présents dans les courriels dont la provenance n'est pas fiable (surtout lorsque les pièces jointes ont une extension suspecte), ne pas installer d'application ou de programme dont l'origine n'est pas de confiance, éviter les sites non sûrs ou illicites ;

ne pas utiliser de compte ayant des droits " administrateur " pour l'usage quotidien (le recours aux droits " administrateur " doit être limité aux seules actions le nécessitant) ;

ne pas installer de logiciels piratés ou issus de sources non fiables ;

cloisonner son réseau interne, notamment au moyen de VLAN afin de limiter la propagation de l'attaquant, le cas échéant ;

utiliser un proxy web permettant de bloquer les sites pouvant diffuser de tels logiciels.

Ressources :

# data[].attributes.attachment_link.title
Fiche n°18 : Se prémunir contre les attaques informatiques

# data[].attributes.attachment_link.description
La CNIL publie un guide RGPD pour les développeuses et développeurs Afin de vous accompagner dans la mise en conformité de vos développements projet web ou applicatif, la CNIL a élaboré un guide de bonnes pratiques des développements en open source. Ce guide est publié sous licence GPLv3 et sous licence ouverte 2.0 (explicitement compatible avec CC-BY 4.0 FR).

# data[].attributes.body
Guide CNIL des bonnes pratiques développeur(euses) prenant en compte le RGPD

# data[].attributes.attachment_link.readable_text
Ce guide s'adresse-t-il uniquement aux développeurs ?

Ce guide s'adresse principalement aux développeurs travaillant seuls ou en équipe, aux chefs d'équipe, aux prestataires mais également à toute personne s'intéressant au développement web ou applicatif.

Il propose des conseils et des bonnes pratiques, et offre ainsi des clés de compréhension du RGPD utiles pour tous les acteurs, quelle que soit la taille de leur structure. Il peut également faire l'objet d'échanges au sein des services et dans la relation avec les clients.

Que contient le guide ?

Le guide RGPD du développeur offre une première approche des grands principes du RGPD et des différents points d'attention à prendre en compte dans le déploiement d'applications respectueuses de la vie privée de ses utilisateurs.

Il comprend 16 fiches thématiques qui couvrent la plupart des besoins des développeurs pour les accompagner à chaque étape de leur projet, de la préparation du développement à la mesure de l'audience :

1. Développer en conformité avec le RGPD

2. Identifier les données personnelles

3. Préparer son développement

4. Sécuriser son environnement de développement

5. Gérer son code source

6. Faire un choix éclairé de son architecture

7. Sécuriser vos sites web, vos applications et vos serveurs

8. Minimiser les données collectées

9. Gérer les utilisateurs

10. Maîtriser vos bibliothèques et vos SDK

11. Veiller à la qualité de votre code et sa documentation

12. Tester vos applications

13. Informer les personnes

14. Préparer l'exercice des droits des personnes

15. Gérer la durée de conservation des données

16. Prendre en compte les bases légales dans l'implémentation technique

17. Mesurer la fréquentation des sites web et des applications

Ces bonnes pratiques n'ont pas vocation à répondre à l'ensemble des exigences des règlementations ni à être à prescriptives. Cependant, elles apportent une réflexion sur les exigences du RGPD à garder en tête lors du développement de projets.

Comment contribuer à ce guide ?

Ce guide est disponible en deux versions :

La contribution se fait en quelques étapes :

inscrivez-vous sur la plateforme Github ;

rendez-vous sur la page du projet ;

vous pouvez alors :

utiliser l'onglet " Issue " pour ouvrir des commentaires ou participer à la discussion ;

utiliser l'option " Fork " pour faire vos propres modifications et proposer leur inclusion via le bouton " Pull Requests ".

Contribuer au guide RGPD du développeur
Votre proposition de contribution sera examinée par la CNIL avant sa publication. La version du guide RGPD du développeur publiée sur le site de la CNIL sera régulièrement mise à jour.

# data[].attributes.attachment_link.title
La CNIL publie un guide RGPD pour les développeurs

# data[].attributes.attachment_link.description
Ce guide s'adresse-t-il uniquement aux développeurs ? Ce guide s'adresse principalement aux développeurs travaillant seuls ou en équipe, aux chefs d'équipe, aux prestataires mais également à toute personne s'intéressant au développement web ou applicatif. Il propose des conseils et des bonnes pratiques, et offre ainsi des clés de compréhension du RGPD utiles pour tous les acteurs, quelle que soit la taille de leur structure.

# data[].attributes.body
Définition de la notion de donnée personnelle

# data[].attributes.attachment_link.readable_text
1. Accueil

2. RGPD : de quoi parle-t-on ?

Une " donnée personnelle " est " toute information se rapportant à une personne physique identifiée ou identifiable ".

Une personne peut être identifiée :

directement (exemple : nom, prénom)

ou indirectement (exemple : par un identifiant (n° client), un numéro (de téléphone), une donnée biométrique , plusieurs éléments spécifiques propres à son identité physique, physiologique, génétique, psychique, économique, culturelle ou sociale, mais aussi la voix ou l'image).

L'identification d'une personne physique peut être réalisée :

à partir d'une seule donnée (exemple : numéro de sécurité sociale, ADN)

à partir du croisement d'un ensemble de données (exemple : une femme vivant à telle adresse, née tel jour, abonnée à tel magazine et militant dans telle association)

Un traitement de données doit avoir un objectif, une finalité, c'est-à-dire que vous ne pouvez pas collecter ou traiter des données personnelles simplement au cas où cela vous serait utile un jour. A chaque traitement de données doit être assigné un but, qui doit bien évidemment être légal et légitime au regard de votre activité professionnelle.

Un " traitement de données personnelles " est une opération, ou ensemble d'opérations, portant sur des données personnelles, quel que soit le procédé utilisé (collecte, enregistrement, organisation, conservation, adaptation, modification, extraction, consultation, utilisation, communication par transmission diffusion ou toute autre forme de mise à disposition, rapprochement).

Par contre, un fichier ne contenant que des coordonnées d'entreprises (par exemple, entreprise " Compagnie A " avec son adresse postale, le numéro de téléphone de son standard et un email de contact générique " compagnieA@email.fr ") n'est pas un traitement de données personnelles.

Un traitement de données personnelles n'est pas nécessairement informatisé : les fichiers papier sont également concernés et doivent être protégés dans les mêmes conditions.

Le sigle RGPD signifie " Règlement Général sur la Protection des Données " (en anglais " General Data Protection Regulation " ou GDPR). Le RGPD encadre le traitement des données personnelles sur le territoire de l'Union européenne.

Le contexte juridique s'adapte pour suivre les évolutions des technologies et de nos sociétés (usages accrus du numérique, développement du commerce en ligne...).

Ce nouveau règlement européen s'inscrit dans la continuité de la Loi française Informatique et Libertés de 1978 et renforce le contrôle par les citoyens de l'utilisation qui peut être faite des données les concernant.

Il harmonise les règles en Europe en offrant un cadre juridique unique aux professionnels. Il permet de développer leurs activités numériques au sein de l'UE en se fondant sur la confiance des utilisateurs.

# data[].attributes.attachment_link.title
Données de santé : l'enquête choc de Cash Investigation - C à Vous - 20/05/2021

# data[].attributes.attachment_link.readable_text
Quel bilan tirer de la première année d’application du règlement général sur la protection des données (RGPD) ? Les citoyens européens connaissent-ils bien ce nouveau règlement et leurs droits ? Un Eurobaromètre spécial sur la protection des données publié par la Commission européenne le 13 juin 2019 fait le point.

Publié le 24 juin 2019

Temps de lecture  3 minutes

Si 60% d’Européens lisent les déclarations de confidentialité, seuls 13% les lisent jusqu'au bout car elles sont trop longues ou difficiles à comprendre. © jijomathai - stock.adobe.com

Des Européens relativement bien informés mais qui exercent peu leurs droits

Selon l’Eurobaromètre publié par la Commission, sur les 27 000 Européens interrogés, 67% ont connaissance du RGPD et 57% sont informés de l’existence d’une autorité publique dans leur pays chargée de la protection des données. Toutefois, seuls 20% savent de quelle autorité il s’agit.

Les Européens sont un peu plus nombreux à avoir entendu parler d’au moins un des six droits garantis par le RGPD sur lesquels ils ont été questionnés. 73% déclarent en être informés. Les droits qu’ils connaissent le mieux sont :

le droit d’accéder à ses données personnelles à 65% (18% l’ont déjà exercé et 47% savent qu’il existe) ;

le droit de corriger ses données si elles sont erronées à 61% (16% l’ont déjà exercé et 45% savent qu’il existe) ;

le droit de s’opposer au marketing direct à 59% (24% l’ont déjà exercé et 35% savent qu’il existe) ;

le droit à l’effacement et à l’oubli de ses données personnelles à 57% (13% l’ont déjà exercé et 44% savent qu’il existe).

L’Eurobaromètre montre, en outre, que 62% des personnes interrogées sont préoccupées par le fait qu’elles ne contrôlent pas totalement leurs données en ligne.

Une nouvelle campagne de sensibilisation lancée par la Commission européenne

Le même jour que la publication de l’Eurobaromètre sur la protection des données, la Commission a lancé une campagne de sensibilisation afin "d’encourager les citoyens à lire les déclarations de confidentialité et à optimiser leurs paramètres de confidentialité".

Si 60% d’Européens lisent les déclarations de confidentialité, seuls 13% les lisent jusqu’au bout car elles sont trop longues ou difficiles à comprendre. C’est pourquoi la commissaire pour la justice, les consommateurs et l’égalité des genres, Vera Jourová, a invité de nouveau l’ensemble des entreprises en ligne à fournir "des déclarations de confidentialité concises, transparentes et faciles à comprendre pour tous les utilisateurs".

Le RGPD a posé un nouveau cadre juridique en matière de protection des données personnelles des citoyens européens. Il est applicable depuis le 25 mai 2018 dans tous les pays de l’Union européenne (UE).

# data[].attributes.attachment_link.title
67% des Européens connaissent le RGPD, un an après son entrée en vigueur

# data[].attributes.attachment_link.description
Quel bilan tirer de la première année d'application du règlement général sur la protection des données (RGPD) ? Les citoyens européens connaissent-ils bien ce nouveau règlement et leurs droits ? Un Eurobaromètre spécial sur la protection des données publié par la Commission européenne le 13 juin 2019 fait le point.

# data[].attributes.wish_content.attachment_props.text
What GDPR does: makes 100 companies ask me to opt in to their marketing lists.

What I wish GDPR did: made those same 100 companies tell me where they got my data from in the first place.

# data[].attributes.wish_content.attachment_props.original_text
What GDPR does: makes 100 companies ask me to opt in to their marketing lists.

What I wish GDPR did: made those same 100 companies tell me where they got my data from in the first place.

# data[].attributes.attachment_link.readable_text
Something went wrong, but don’t fret — let’s give it another shot.

# data[].attributes.attachment_link.embed_code
What GDPR does: makes 100 companies ask me to opt in to their marketing lists.

What I wish GDPR did: made those same 100 companies tell me where they got my data from in the first place.
— Paul Hudson (@twostraws) May 25, 2018

# data[].attributes.attachment_link.metadata.attachment_props_source.data.text
What GDPR does: makes 100 companies ask me to opt in to their marketing lists.

What I wish GDPR did: made those same 100 companies tell me where they got my data from in the first place.

# data[].attributes.attachment_link.metadata.attachment_props.original_text
What GDPR does: makes 100 companies ask me to opt in to their marketing lists.

What I wish GDPR did: made those same 100 companies tell me where they got my data from in the first place.

# data[].attributes.attachment_link.metadata.attachment_props.text
What GDPR does: makes 100 companies ask me to opt in to their marketing lists.

What I wish GDPR did: made those same 100 companies tell me where they got my data from in the first place.

# data[].attributes.attachment_link.readable_text
Something went wrong, but don’t fret — let’s give it another shot.