True privacy by design vs. Privacy by promise
· GDPR, CCPA, CDR and the like try to promote true privacy by design, not privacy by promise
· Statements like “We are good people; your data is safe with us; we follow standards” are not the goals of these regulations
· The highest level of protection and privacy by design can be achieved when no private data remains available in plain format outside of stakeholders’ private computing zone and that is HARD to do!
· Xiippy.ai is a true manifestation of privacy by design, where sales data and purchase data remain available only to their true owners, not to Xiippy, not to anyone else
· Future of data-rich payments lie within end-to-end encrypted data transfer as part of payments via Mobile Operating System offerings of APIs and SDKs
Privacy by design is the process of embedding mechanisms in the design of a system that assures privacy is preserved for the relevant stakeholders.
Privacy by design has become more of a patch word these days! Like the term “gourmet” for food. Nowadays, everyone is making gourmet food and everyone is following “privacy by design”.
Accordingly, privacy by design has been translated into a wide spectrum of statements. Some have translated this into “we have the right policies in place” and some have translated it into “we have made private data even unavailable to us, the designers of the system, with true zero knowledge, let alone attackers”.
Where one party stands in this spectrum has significant implications.
First and foremost, “we have the right policies” and “we are good people with the right standards in place” are quite different from “we have designed the system so that we remain unable to access your private data even though you, as the owner of the data, still can”.
The first one is “easy” to do. Anyone can write a policy and “luckily” follow it as well, which mostly focuses on ‘people and process’ to achieve the goal of ‘respecting privacy’ but not necessarily ‘protecting it’.
The latter one is “hard” to do. It needs competencies not owned by every organization and it also needs much bigger upfront investment of time, money and resources for a slight moderate return, which predominantly is nothing but ‘alignment with people’s high-order motives and organizational social responsibility’. Are these returns big enough for the investment? Not for everyone.
For example, Xiippy’s current size of codebase is over 1.1 million lines of heavy-duty complex code.
GDPR, CCPA, CDR and the like try to ‘enforce’ that initial investment in some ways but yet, they are quite vague and weak in doing so. Still, the door is open for big claims to be made without big enough work being put down!
The Xiippy Difference
Many take the easy way out to achieve the claim of ‘privacy by design’ but at Xiippy.ai, despite being a start-up, we have set a new standard in zero-knowledge software design, either client-side mobile or web apps, or, enterprise SaaS products.
· We enrich payments with data via transferring end-to-end encrypted data as part of payments without the payer or merchant doing anything extra (yes, it is all done by the tap of the card!)
· We transfer data end to end encrypted. This means we remain unaware of the data transferred between payers and payees.
· People’s private purchase history and businesses’ private sales history remains theirs despite the benefits of such data becoming available to them and them only
· Every user accessing our Business Owner’s Dashboard generate their own personal private keys and certificates that they will require to view private data in our SaaS web-based dashboards. We truly maintain no knowledge of such data. As a result, if you lose that key, your access to data can be gone forever.
· Xiippy already has a QR-code based payment which adds world’s first and only end-to-end encrypted smart receipts to ApplePay and GooglePay payments.
· Xiippy started before COVID with our patents encompassing a way forward to include private payment data as part of payments seamlessly and privately. The way Xiippy apps determine rewards eligibility at client side is based upon edge computing against your private data in your own private computing zone. Later on, Google and Apple used the same mindsets for privacy-preserving COVID exposure tracking (i.e. by cross checking BLE signals at client). Google and Apple made COVID exposure racking part of OS offerings later.
· The Xiippy client-side libraries — that make end-to-end encrypted payment data transfer to consumers’ devices happen — should actually be part of the operating system offerings, not Xiippy’s. This would be the most logical future state whereby any merchant should remain able to send private invoices and receipts as part of payments without extra information or actions required, quite seamlessly and privately.
At Xiippy.ai, we strongly believe the future of data rich payments is linked to Mobile Operating System APIs and offerings to make end-to-end encrypted transfer of payment data possible directly to your ApplePay and GooglePay enabled personal device.
That would mean, Xiippy’s client-side SDKs and APIs must actually be part of the Operating System to be open and available to anyone, not just being proprietary to Xiippy users.
Xiippy has already done it! This is merely a matter of time before data-rich payments become a true reality without the disclosure of private data to any other unauthorized parties!
And this is what Apple, Google and Microsoft can think of, as the developers of Operating Systems. Until that time….