Gdpr Policy In The Eu

This is set to come into force for the EU, in May 2018.

has anyone implemented anything different to comply with this in CS cart sites yet.

http://www.itpro.co.uk/it-legislation/27814/what-is-gdpr-everything-you-need-to-know

John

I would also like to know this. I guess cs-cart will have to implement changes so that it complies with the new regulations. For example, we need to be able to delete all customer data, as well as his/her personal info from orders in 1 go if someone would request that.

Its also started to gain momentum in the USA

I would also like to know this. I guess cs-cart will have to implement changes so that it complies with the new regulations. For example, we need to be able to delete all customer data, as well as his/her personal info from orders in 1 go if someone would request that.

Ive added info to my site stating the way we sue the info. I will also add that if anyone requires their personal info removing this would mean all orders or info relating to orders would be deleted completely making "re ordering" more difficult.

For an addon, there would have to be rules for when this is to be allowed. I.e. what order statuses or payment status must be achieved before any data can be obscured. And where does the customer initiate this? Link in order confirmation email? You'd also want to only obscure enough data to make it unusable but so that the customer can recognize what was used. I.e. an address changed from "4433 SW 40th AV" to something like "44********** AV" instead and "John Doe" to "Jo****oe". Same for the other personally identifiable fields. But note that (and I'm not entirely sure) if a customer happened to do a 'repay' or "order this order again" and did NOT adjust the fields back to normal that it *might* update their profile with the obscured data.

I'm assuming this only relates to billing/shipping info. I'm not in EU so not sure what the law actually states.

Cookies: "... first‑party persistent cookies DO require informed consent. Use only when strictly necessary. The expiry period must not exceed one year." ( http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm )

Some CS-Cart cookies have exceed period far more than year:

* serp_cookies[referrers][****] --- Friday, November 09, 2035

* ne_user_type --- Wednesday, May 07, 2036,

* __utma --- Sunday, August 11, 2019,

Is this expiry period necessary or may be changed? CS-Cart have plans about changing cookies policy?

Good question, well if everything else fails...just blame it on #Russians ... LOL no seriously.

This EU is getting bit on my nerves. At any rate what would it take for a few merchants like me to put a small fund together from which we pay guys like Tony to make it profitable for him to build such an addon.

Just thinking out loud.

Hi Guys,

We are considering this feature for CS-Cart / Multi-Vendor.

Right now I'm trying to find answer to questions: what kind of personal data should customer have access to (export/modify/delete) in CS-Cart.

It looks like:

- User & profile data

- Orders

- Cart & Wishlist content

Besides if client want to be "forgotten" should we erase all the records or we can just anonymize this data - like replace with "deleted user". This is need in order to maintain sychrnonization process - a lot of stores have some kind of synchronisations like CRM, Accounting programms etc. Documentations says there should be 2 optins erase of anonymize, and this is not good(

This is a very important point I think.

Feel free to share you thoughts on this.

An order is a contract between a customer and a merchant. You will need to be very careful on how much you redact so that the "contractual nature" remains between the original two entities (merchant and customer). I would NEVER want you to remove orders upon customer request. I would do a general redacting of info similar to:

John Doe
123 Somestreet Av
Box 12
Some City, Some state, Country Postal Code

to become something like:

Jxxx Dxx
1xx Sxxxsxxxxet Ax
Bxx 1x
Sxxx Cxxx, Sxxx sxxxe, Cxxxxry Pxxxxl Cxxx

Basicaly replace every 4 chars of a word , then leave a letter in place, and replace next 4 letters.

If the merchant were to then keep a paper or electronic copy of the order (no idea if that would be allowed by the law or not) then a compare could be made to demonstrate they were in fact the same order.

Once a user is "redacted", then their user_id should become disabled. But then not sure what you do with the email address. I guess you could redact it too but then duplication becomes a higher risk.ted@example.com and red@example.com might redact to the same values.

Gonna need to read the law very carefully (and understand existing contractual law) before deciding on action.

I have read quite a bit of guidance and like always, very ambiguous, but thei seems to make sense

https://businessvalueexchange.com/blog/2016/10/18/gdpr-effectively-protect-personal-data/

One approach to meet the requirements of large parts of the GDPR is tokenization. In this process, sensitive personal data is replaced with randomly generated tokens before it is processed or stored by third-parties, such as cloud providers. The original identifiable data and token maps are stored locally in a database controlled exclusively by the company responsible for the data. Security vendors such as CipherCloud offer solutions designed to automatically tokenize sensitive data. Unlike encryption, with tokenization, there is no mathematical relationship to the between the original data and the random tokens. This dramatically reduces the risk of data being compromised.

Tokenized data maintains the same data structure – for example a credit card number of “4362 4890 2300 8650” could be replaced by the token “4362 0405 3604 8650” making it unusable by data thieves. Because the data structure does not change the process does not interfere with external applications or processes, enabling tokens to function just like the original data.

According the CipherCloud, this method is widely used and proven in regulated industries. For example, at least 40 percent of the banks and financial service providers already use tokenization to protect sensitive personal data such as social security numbers, dates of birth and tax numbers.

Protection against access by service providers and government organizations

If the data is tokenized properly, this can also meet the requirements of the GDPR regarding the transfer of personal data to third countries outside the European Union or international organizations. “The protection of data by encryption or tokenization before it is transferred to the cloud, is a good step to prevent legal challenges for any companies that are thinking about implementing a cloud solution,” write to Dr. Patrick Van Eecke, Partner at the international law firm DLA Piper, in a White Paper. The key part of this statement is “before it transfers to the cloud.”

However, if you leave encryption the cloud provider, then a third-party can access the keys and could thus restore the original data again. “If the cloud provider is not in possession of the decryption key, then the customer can be reasonably sure that the data is safe from government intervention” Van Eecke continues. This addresses the concerns of IT managers are invalidated, who fear that they will give control of sensitive data to cloud applications.

Complete package of measures to protect data

While tokenization is powerful, it is not all-purpose solution. “Tokenization is ideal when it comes to protecting structured data within databases, such as a CRM,” explains Holger Moenius, Regional Sales Director at CipherCloud. “But to protect files, and other unstructured data, then it makes sense to consider encryption.”

Tokenization and encryption are elements of a comprehensive package of security measures which can help meet the legal requirements for protection of personal data and company data. “Data security is always about a range of technologies that must be tailored to the individual circumstances of each company,” emphasizes HPE manager Wohler, whose company has recently entered into a technology partnership with CipherCloud.

I think these are two different things. Having a 3rd party send you info that you respond to with a token; that when subsequently submitted will use the data previously sent is a pretty standard protocol with payment providers and others who use "access tokens" to ensure secure access to information.

But I thought this was about a customer requesting (or taking an action) to redact all their personal information on your site. I.e. it has nothing to do with 3rd parties unless an access token is used like is done in many parts of cs-cart using an "e-key". I.e. password reset requests, download links, etc.

So I guess now I'm confused on what is being requested.

Well, we in the EU also have to use and display a privacy policy and the 2 of them overlap in my eyes. We have ahd the auditor in my company today and he seems to feel as long as we are clear on what info we store, how long, where its stored and who has access then also a way for therm to have us delete it then its covered.

The jurys out !

Well, we in the EU also have to use and display a privacy policy and the 2 of them overlap in my eyes. We have ahd the auditor in my company today and he seems to feel as long as we are clear on what info we store, how long, where its stored and who has access then also a way for therm to have us delete it then its covered.

The jurys out !

Then I'd go with the redaction method I described above.

If there was a demand, I'd do it as an addon but demand for "production" addons now days is so weak that I'm reluctant to build any more because they just aren't profitable. I've lost money on almost every one over the past 2 years.

Well, we in the EU also have to use and display a privacy policy and the 2 of them overlap in my eyes. We have ahd the auditor in my company today and he seems to feel as long as we are clear on what info we store, how long, where its stored and who has access then also a way for therm to have us delete it then its covered.

The jurys out !

Would you mind if we free ride on these conclusions ?

Would you mind if we free ride on these conclusions ?

fill your boots

fill your boots

LOL, Christmas is coming early this year :mrgreen:

The customer does not have to be able to delete his account information himself, however he should be able to file in a form with a request to delete his account information.

It should be clear to the customer which information is collected by CS.cart and why it is.

The customer has to authorize that the shop stores his information.

If customer information or name is indexed by searchengines that information has to be re-indexed when a customer's profile is being deleted.

As far as i can tell it IS allowed to save the data, like products, but everything that has to do with the customer, cookies, ip address, name, contact information, everything has to be erased. Changing a name to "DELETED" with a number or something IS allowed as long everything else is destroyed.

You'll be able to control that on-site, but for 3rd parties like Google, various post-sale email services, etc. it will be difficult since very few of them provide any "delete" function within their API's. And many just give the merchant a chunk of javascript to integrate into their post-order processing and many merchants usually have very little idea what they are sending to the 3rd parties.

Not sure if you've ever tried to delete a post somewhere, but sending info out is made very easy. Getting it back (or deleting it) is much more problematic especially after big-data gets their hands on it.

You'll be able to control that on-site, but for 3rd parties like Google, various post-sale email services, etc. it will be difficult since very few of them provide any "delete" function within their API's. And many just give the merchant a chunk of javascript to integrate into their post-order processing and many merchants usually have very little idea what they are sending to the 3rd parties.

Not sure if you've ever tried to delete a post somewhere, but sending info out is made very easy. Getting it back (or deleting it) is much more problematic especially after big-data gets their hands on it.

That's why services like Google have to provide a function to "forget" aswell in the EU, Google actually already has it, same thing for every other Bigdata collector that operates or provides services in the EU

The right to forget does not apply to order information, unless you are somehow making the order information displayable in a public manner. (e.g. Bob just purchased x,y,z on our store)