 So, I'm putting a disclaimer right in the beginning. Some apps, some screenshots I've shown. So I've just taken some popular apps, shown how the payment process works. It does not mean any particular app I'm naming or any particular screenshot I'm using is more vulnerable than the others. One thing is that, other thing is I am talking from a technical perspective. So I'm talking about vulnerabilities leaks that are there technically. All of these payment systems, they have got some policies, some rules to follow. Whether there are gaps in that or not, that I'm not covering here. And finally, one more thing. I am in the stock, I'm just making aware of what all entities get access to your payment details. I'm not accusing any one of those entities to be actually stealing your data or sharing it with anybody. That's a different thing altogether. I'm just saying that who all are having access to it? Okay, so now if somebody gets hacked and due to some negligence, some data gets leaked. So negligence is different from having malicious intent. Just want to make that clear from the beginning. So let's start with an example that we are hungry and we want to order some food, okay? So say I order a chicken wrap from the Faso's app. I got a bill of 191 rupees, right? And then I'm selecting payment method. So let's say I'm selecting free charge out here. Then what happens is, we have this mobile verification stage where free charge automatically checks whether there is a wallet connected to my mobile phone number or not, right? Then the screen comes up. This is actually a web page from within free charge, this one. I don't have money inside my wallet. So I have to use my credit card to load some money into it. And here then another page comes up which says just pay safe, which says processing your request. Then my bank's page comes up right at the top right. You can see a little bit of the red logo that's the access bank logo, that's my bank's page. And here I have to either enter my verified by visa password or this thing, or my OTP. And this page is powered by Webmo. So basically what happened is I ordered food worth 191 rupees on Fastos and paid using free charge via just space gateway on Webmo's card processing page. And let's talk about this as well. I am, say for example, using a Xiaomi smartphone. And I have this Swift Kiki board installed with which I am typing, okay? So here's what happened. I ordered a chicken wrap. I had a credit card and a lot of entities got involved in between. Surprise facts. My bank statement says I made a payment to snapdeal.com CCA. So a lot of people would know that snapdeal has acquired free charge, but if they don't, then it would come as a surprise. Bonus gifts, these. I get three messages from Access Bank, three messages from free charge, four from Fastos. Okay, yeah. So let's discuss why everyone can see your credit card details, right? So let us just assume that everybody who has access to your credit card details can get hacked and those details can leak out somehow, okay? So you're just going to be a little paranoid here when we talk about who all has access. So let's start by discussing how exposed these details actually are, who all have access. So to start with, say, your smartphone manufacturer, okay? Now, I think I'm talking specifically about the case of Android. So in Android, the operating system is licensed by Google to the manufacturer and they compile the code. And even if you consider the case of, say, WhatsApp, which says that messages are going encrypted, but at the view layer, when you're seeing it on the screen, there is not encrypted because you can see it, right? And whoever has compiled the operating system, they can insert some code which can read data out of your screen. That's not part of the end-to-end encryption. It is on this side of the end, okay? So anything that you're doing on your phone, any view comes up, any data that you're writing, all of that, the manufacturer of your phone has access to it. Like, if they have put some malicious code into your phone, they could send that data out, okay? And there is very little you can do to prevent that. Then there's the, everybody's using some keyboard app. Some people are using Google keyboard, somebody's Swift key. So either the keyboard app is built by the OEM itself, which case it's covered by this part. Otherwise, if it's a third-party app, then it's a software keyboard, right? So it is a key logger by default because it is logging what you are typing. It's not a hardware signals. It's what you're typing on the screen. So whoever's made that keyboard app, they can read anything that you are typing into the screen. On top of that, some keyboard apps, they ask permission to read your Gmail messages, your SMSes, because they want to learn the way you type. So in a sense, they have access to your SMSes, to your mails, and you are typing everything on your phone using that app. Then there's the merchant app, which in our case here was a fast source, okay? So everything you are doing, all the transactions that you are doing is within that app. So again, they also have access to your details. Plus, one very bad practice I find in most of these apps are they do not have an opt-in for saving cards but an opt-out, and some of these apps do not even have an opt-out. So your card gets saved if you pay with a card. There's no way to get out of it other than disabling your account. There are certain cases like this. For this particular example, fast source actually does allow deleting your card, but it does save them automatically, okay? And these apps also have access to read your SMSes to find out the OTP or something. Most users give that permission. If you are below Marshmallow, you cannot prevent that permission in any case. If you are above Marshmallow, most people give that permission to the app. Coming to then, if you're developing an app, you're using some payment SDK. So there are a lot of them available, free charge as an SDK, Paytm as an SDK, PayuMoney as an SDK. You can use them to incorporate the whole payment strategy inside your app. And as a developer of that particular app, it is used in a very black box manner. You go to the website to register that I am a new merchant. I want to get paid. You get an app ID, and with that app ID, you take their simple library compiled file, include it inside your project and you build it. You don't actually look at the code or you see what's happening inside the code of that SDK. So now the code of that SDK is running within the process of that app. They are built by separate entities. It's fast source, it's free charge. Free charge is code is going to run within fast source app. Now, mostly these SDKs, they use a web view and they open a website where the payment gateway comes up and then you make your, in the entry of your card details and the payment takes place. So that brings us to the payment gateway. Now, sometimes the same entity who creates that SDK might be the payment gateway or technically I think this is called the financial settler, the entity which actually settles the transaction, which actually moves your money from one place to another. For our particular example, the gateway of the settlement was done by JustPay while the SDK involved here was free charges because I used free charge wallet to make the payment. This payment gateway is usually web based. It loads within the code of the, whatever payment SDK is used or directly within the apps, web view, okay? And since the external app itself has access to reading your SMSs to look at the OTP automatically. So the code of this thing, the payment gateway, they can also read your SMSs. They can also automatically retrieve your OTP. I mean, that is generally marketed as a user experience feature that your OTP will automatically be fed into the system. You will just enter your card details automatically, OTP becomes the payment transaction completes. Then comes the card authentication system. So this is what is implemented by your bank. So the final page that we saw where we were entering our verified by visa password or our OTP. Now, this is implemented by the bank, but usually they use some of the shelf solutions made by their many companies. Vibmo is one of them. Vibmo makes for Access Bank and I think for ICSA also, they are the ones who make it. So on that page, that solution is usually, you'll see that the page where you're entering your verified by visa password, that is a similar page for all the banks because it is an off the shelf solution. It is not, the bank has not built it on their own or it has not been customized for them. Now the question is that there are so many layers when we're doing this payment and the question is, are these underlying layers actually targeted? Do we need to worry about them? The answer is yes. So the first example, of course, the most recent one, 3.2 million debit card details allegedly were hacked. So we don't know how many of them the whole data was compromised. But this attack took place on Hitachi payment system server. It did not take place on any bank server or on visa server or master card server. It happened on the Hitachi payment system server and they are managing a lot of ATMs. They're managing a lot of point of sale systems and from there it is, I think it is feared that around 1 million debit card pins were out. A lot of banks have invalidated the debit cards. A lot of them have sent messages to reset the pin and all of that. So this is a case where the attack happened on all the underlying layers that the user does not actually see but the attack took place there and a lot of people affected. Another concerning thing is, you can just Google about this. There are reports in 2014, 15, 16 for the last three years. Various PIVAs built by ADUPS and Baidu have been found inside Blue, Lenovo, the ZTE and Xiaomi phones. Okay, so they do a lot of things. Usually they just read some identifiable data like your MAC address or your IMI details and something like, they can also sometimes read your call log and your SMS history and they phone home, they send that data back. So probably Baidu or ADUPS, they're using it to train it for some kind of advertisement, targeting or whatever, but the data is going, the whole data is going to them and there have been a lot of reports about these kind of PIVAs, okay. So let's discuss what we can do to stay safe from things like that and I would first like to explain from a user's perspective what a user can do to stay safe in a situation like this and the safest solution is cash on delivery. But, so you have to use these notes. But yeah, seriously, the level of security of COD is definitely better than any kind of online payment systems right now available and that is the truth. Another thing is payments on the web and by web I mean the desktop web is marginally more secure than mobiles and that is why because you are doing all of your transactions inside a browser and you get redirected from your merchant to the gateway and from there to your bank and then the bank generates a token and you get back to your merchant. So when you're entering your card details on your bank's page, the merchant cannot read that, okay. And all of this is happening inside a browser which is usually a more trustworthy entity because it has been built by Apple if it is Safari or Google if it is Chrome or Mozilla, okay. What is happening on mobile is there is the merchant app and inside that there is a payment SDKs code inside which there is the settler's web pages opening up and inside that you're entering a bank details and every entity outside can actually read the data that you're entering there, okay. The other thing is unless you have a key logger installed on your computer, your hardware key signals are not generally logged but it was recently found out that Windows 10 has a key logger, Microsoft has made it inside Windows 10, okay to again do that figure out the type words that the user types, okay, best excuse. On mobile the keyboard software is a key logger. There is no way out of that. The other thing is on the web you can see whether your transaction is happening over HTTPS or not. The browser shows you a green lock symbol and if it is not HTTPS then you get a warning. It's in Chrome I think you can enable a setting where you're not allowed to enter payment details on an insecure page. On mobile the user is not able to see whether the transaction, the underlying transaction, the HTTP transaction, whether it is secure or not. He's entering his data into an app and in reality all of them are using HTTPS which I have seen the network connections I've seen, decompiled apps I've seen. They are doing that but as a user you don't know they're doing that. So there is the problem, okay. So another solution is you can use virtual credit cards which I guess all of you know about. The only thing is that we don't use it because it's tedious to create them and then they are valid for a couple of days. But they're secure because once the validity period is ended which is a few days or a week or so the card is not valid. Another solution I personally use is I have considered that my account is going to get hacked. So you can create an account which you use for online spending and top it up every month with a certain amount like you put 10,000 or 100,000 bucks into that and you have net banking and debit cards and all of these IMPS and all these facilities enabled on that account. Not have them enabled on your main account in which you keep the money to buy your next year or something, right. This again a technical point here is we should be careful about the kind of permissions we are giving to the apps that we are installing and if we take an example of Android after Marshmallow we can actually find even the permission that we are giving we can revoke some of them. So one of the things is giving third party keyboards access to read your SMS and emails is a bad idea. I mean giving anybody access to read your SMS or emails is a bad idea. You can just read that SMS detail and type the OTP on your own. It's just a four digit number, right. Other than that another permission sometimes some apps might ask for the accessibility permission, okay. So apps that search what is there on your screen they use the accessibility permission. So in Android the accessibility permission is used by apps like the screen reader, okay. So you can read everything that's on the screen. So that's another place through which data can leak. So don't give accessibility permissions to apps unless like you are especially enabled and you need those accessibility apps. And yeah, do be careful about what kind of phones you're buying. There are a lot of mobile brands that come up they sell phones for three, four months then they vanish and you are stuck with using an operating system that has been built by an unverified unknown entity. If they're outside India you cannot even litigate against them, right. And a lot of Chinese mobile phone manufacturers have been guilty of putting spyware on their phones. So you need to be careful about this one. I want to cover the aspect of as a person who is building an e-commerce app what you can do to make things a little more secure. One of them is provide an app keyboard and a lot of banks already do that. SBIs app or ICICI's banking app they have an in-app keyboard so that you don't have to use a third party keyboard to enter the data. Because when you're making the app you cannot usually trust the platform, the OS, the keyboard, they might be vulnerable as well. And explain to the user why you are putting an in-app keyboard, okay. Another thing is instead of web views we can use Chrome custom tabs, okay. So this is a point that comes to say I am building an e-commerce app and the payment will happen via payment SDK. So one thing you can do is you can, if your website already has a payment method you can simply redirect the user to your website and use the payment method that's already present on your website, okay. So any other libraries that you use in your app they will not have access to the user entering his details. So you're just doing an extra step to help the user keep his data safe, okay. So Chrome custom tabs are somewhere in the middle between redirecting the user to the browser and having your own web view. In a Chrome custom tab, a tab opens up inside Chrome but you have access to a service running by inside Chrome where you can see if the URL changes. So usually what happens is the payment after the user does a payment the bank redirects the user to a URL where the token is in the URL. So you can capture the token from the URL and complete the payment details. And it would work like the desktop web example I showed it would be a redirect based process. The code inside your app won't get access to the payment details, okay. So this is a small animation from Google's page. It's in fact shows that Chrome custom tabs are the fastest to load. So they give you performance benefits as well. I just specifically for Android though and iOS there is no such solution. Try to prefer involving less number of entities in this transaction. Like if you have an entity who has their own settlement server and they have a mobile SDK, try to use them. So you're making the user trust fewer number of people, right. And another thing is try to make the bill look authenticate like don't get billed in the name of the SDK provider or the, so actually in my current example that was not wrong. So I actually added money to my wallet. So that's why I was billed to Snapdeal. And from the wallet I paid. But sometimes what happens is even when you're directly paying it shows the payee not as the app to which you are paying but to some intermediary. Okay, so the user can get confused with whom he's paying, right. Another very good example is, I don't think if it's visible or not properly, but in ICICI banks what they do is on their cards, at the back of the card, they have 16 letters A to P and inside each letter there are two digit codes are there. So every time you make a payment instead of your OTP you can also enter say the code in E, the code in J and the code in K. So this way your verification token is something that is not coming over an unencrypted channel like SMS and it is not static. A different one is going to be used every time. So even if somebody sniffs the data from your network that is not going to be enough to do a transaction again. So I have to end with a couple of questions that still remain. We talked about a lot of gaps that are there, some precautions that we can take. So some new developments are say for example, free charges using deep integration into operating systems like Indus OS and OnePlus they have done from the dialer you can enter some codes and recharges happen. So here we need to again rethink what our security strategies can be because carriers can actually send signals to the phone to dial something that is possible. There is that technology is available. So carriers can automatically bill you for some new value added services or something like that you need to take care of that. Another thing is recently Paytm announced money requests so in which you can request payment from somebody and they get an OTP. You enter the OTP inside your app and the payment is fulfilled. The problem here only is that if you do not have a secured lock screen or even if you have a secured lock screen and you have not disabled this thing the contents of the notifications if your phone is lying on the table somewhere somebody knows your mobile number they can require for some payment the notification will come up they will read the OTP from there and enter it and they steal money right from you. So there is this gap is there. So user experience point of view the person who is paying money did not have an internet connection but that opened up this vulnerability there. Similarly there are apps like Tabzo or Haptic which are adding just another layer to that nesting that we talked about in apps. So another entity getting involved because via Tabzo you're ordering a cab for which we are maybe paying through a payment as DK so another layer. So and another like say an app like Haptic where which is a chatbot. So you're keeping a credit card details on tab with that chatbot. What if there's a server glitch and instead of a 30 rupee thing you buy a 30 lakh thing right. So again the transaction is you don't require to authenticate that transaction if your card is on tap for credit cards that happens. So these things also we need to figure out how to enhance security in models like these because these are very nice models. They are they enhance the user experience a lot. Very important question is one of my favorite ending lines from a movie. This is from Shutter Island. So a lot of times companies do get hacked and bad things happen. So how do you make them admit that to the users? How do you make them tell the users that okay this happened you need to change your details. So recently you might have heard about 100 million accounts on Yahoo getting hacked. That happened three years ago. So now when that acquisition is happening by Verizon the details are coming out right. So like this is a question about losing customers versus the ethics of telling your existing customers that their details were compromised. So this is I don't know if good nature can be legislated or written down in policy but this is something that we need to figure out. Another thing is when things go wrong how much liability is covered by whom right. So the most simple case is when you have to take a refund of a transaction that was invalid or you didn't want it or mistaken transaction and your money hangs in limbo for a month sometimes. You don't know with whom that money is. Everybody says that yeah we have processed your refund it's on the way. Your bank says we have not got that refund yet. So where is that money right. So there should be a process for that. And similarly if actual payment fraud happens then who is responsible and like for banks you know that up to one lakh RBI is guaranteed you even if your bank goes bankrupt. But if your wallet goes bankrupt and how much money do you have in your wallet how much is going to get paid back to you. These questions remain. So I just ended by saying don't go penniless trying to go cashless okay. And very important thing I don't want to be alarmist here. So it's important to be aware in the same sense I am not saying get off the internet and pay by cash to everybody. So we need to figure out better ways to do online transactions. So I'd like to open up for questions. Thank you Arnav. Sure there are quite a few questions. Again just to reiterate the disclaimer whatever he said is not like supposed to say pay them is bad or free charge is awful. Just that these are the larger issues. So if you want to keep your questions at a slightly larger level of saying no actually pay them does this and then free charge others. That's fine. Or that is technically possible. Possibly possible. Not that they are stealing your data. So don't ask questions of that nature but keep it general in the sense of saying what can we do or what can we do? I just one broad advisory before you frame your questions. So any, yeah we have one question right at the back. Can you hear me? Yeah yeah. Yeah. I saw you were recommending that use web browser and not mobile. Yeah. I just want to challenge you on that a bit. Yes. Okay in the olden days feature phones we could never install apps. Yes. For phones you can install apps. Right. And that is one of the apps. Yes. But I think we are going one more level higher where in the browser you can install plugins. Right. And plugins can start reading. So right in the beginning I said when I talked about web it's a desktop web. Desktop. Not mobile web. Okay. So in the desktop web usually in mobile web actually there is a lot of, first of all there are a lot of browsers are available in the first place. Right. Okay so I was talking about desktop web. In the desktop web generally on the payments pages if there is a payment page and Chrome recently started a payment request API as well on those pages plugins get disabled as well. Insecure plugins get disabled. I see. So browsers are, because there are three main players out there. Okay. And there are a lot of transactions happening on the web. So they are doing a lot to keep those transactions secure. Okay. But I think that would be a space for us to watch out also because a browser becomes the next big platform. Yeah. Where in a browser can enable plugins which can actually slip into. A browser has been a platform since 20 years. Right. So another thing is like there's the PCI DSS compliance. Any payment SDK says that we have PCI DSS compliance. A lot of the, if you see the PCI DSS policies, they are written in the web era. And a lot of them do not cover a lot of loopholes that are there in mobile payments. So because we are doing web payments for 20 years there are a lot of already a lot of regulations out there. A lot of bad things have happened. People know what to do. So that is there. Before we take the next question a very quick announcement. Ajay Ram Subramaniam, chief of zone startups will be available in the lounge outside from 12 to one to have one-on-one discussions with participants who have ideas of payment products or want feedback for their existing payment startups. So in case you're interested, it's at, he'll be available in the lounge from 12 to one. Okay. Moving on to any further questions. Yeah, there's one here. Hi, this is Ankit from Paper. Yeah. So you are recommending to use browsers, right? Yeah. And I think even every day if any company or startup comes we always think for giving an app first rather than being on giving a support from browser. Right. So is it like raising a question on the coming up companies that they should not provide an app for payments and they should give support for browser from first? Because this is a very basic thing I think from any company can think of what you are saying, right? Yes. Data is not secure from the app. Yes. So what do you think that? What's the recommendation here? So one of the things is like I said, a bit of the nesting problem gets solved using Chrome custom tabs, for example. So you are paying on Chrome in, actually you're paying on Chrome, not inside the app. So the app or any libraries that the app uses does not have access to whatever data you're entering in the custom tab. So that one solution is there. Other than that, I, so see the thing is that if going forward the companies decide that app is a better way to distribute their content, like Ola or Uber, it has to be on an app, on a website it does not make sense. So then they have to figure out more secure ways to actually take care of these concerns of the user that right now in most cases, the web transactions are a bit more secure than the mobile transactions, right? In the mobile, how am I assured that my transaction is actually happening over HTTPS? I'm not assured of that. As a user, I'm not. Yeah, if I look at the network connection as a developer and I find out that HTTPS that's fine, but as a user, I'm not assured. On a browser, I am. Any further questions? Yeah, yeah. Hi, I'm Mayan from Bloomberg Quint. I just wanted to check if you have any thoughts on other payment methods and other payment mediums like UPI is coming around. There are other payment modes that are being published. USSD is also coming around. Do you have any thoughts on their security levels as well? So my discussion basically not just covers credit cards, but anywhere you have to put your data inside a web view inside an app that happens with net banking as well. So all of this was valid for net banking as well, okay? There is the part of the concern that the OTPs are coming through your SMS channel and they are insecure. So the same thing happens with USSD as well, right? And USSD is very easy to spoof. You can spoof phone numbers much more easily than doing payment fraud on online transactions. UPI, something I have not dabbled with a lot. So I do not know yet, but again, say, most of these payment SDKs, they are allowing UPI within that SDK itself these days. So again, these things will be there because even for the transaction, you enter your VP and you get an OTP. Coming back to the same mode on how these things are happening, okay? There's one more question at the back. Just want to know if you have any questions regarding Wi-Fi itself, because conferences like this and the railway station is actually giving out free Wi-Fi. Have you heard of anything about? Yeah, so on those Wi-Fi's, like if the transaction is happening over HTTPS, not HTTPS, then you go to a free Wi-Fi, do 10 transactions once or the other, you are definitely going to get hacked. I can almost be sure of that because people are sitting at airports, doing packets, sniffing, all of these things. These are happening a lot, right? So public Wi-Fi is definitely increase your chance of exposure a lot. I have a question. I have a question. Is there a way to, again, I'm not a tech person and I'm sure that the audience is also quite a lot of people, not tech person. Can we come up with like a list of good hygiene for engaging in transactions as a consumer? Yes, we should. I think we should and we can. Like I said that you can take a checklist of the apps which you have given SMS access, right? And you can have like, there's what is this website? I'm not remembering that. They have a list of all messaging services and whether they are end to end encrypted, whether there has been a recent audit, whether the source is open code like that. So it has to be an effort from the people side, from the civic society side, so that we can keep a database of apps and which of them have had any recent attacks on them, which of them redirect you to the merchants website, which of them do it within their app and all of that. So that mostly would be like, you collect a lot of data, keep them as a checklist and users should be made aware of that. Because there's something like the consumer credit bureau which sort of tells you how good a particular service or a company is, right? You should have something like that for security. Yeah. One last question. Moving on from Wi-Fi, other thing is Reliance Geo now, we know that data is a new oil and all this stuff which is happening and you know. So what happens at the carrier side is also, I believe we need to understand, I am not really aware, but I'm kind of a little cautious on that. Yeah. Any insights into that and how what can be done at that level? So mostly it is like, the carriers can sniff your data. They can also do another thing is, they can inject JavaScript into web pages. If you use broadband Airtel or MTN, you will see sometimes offers from those popping up into your pages, right? So they can do that. If the transport layer is not secure, there is HTTPS. There could be other security layers on top of that. HTTPS itself is not in all cases a silver bullet, but still it reduces your chances a lot. So yeah, it all comes down to the vendor who is doing the settlement. They should, they should converse over secure channels. That is important. So because your packets are going to travel over multiple entities, even if it is not geo, right? It is going to travel through multiple ISPs, multiple satellites and all of them. So packets should be end to end encrypted. That is an important part. It's a general thing. There is a privacy issue. Otherwise with geo people are saying that they're collecting data that's outside the scope here. One last question. How did Apple pay and write pay, et cetera? Because they do a form of tokenization, which I think might be more secure. So it is sometimes more secure, but the thing is the token, where it is traveling over. Again, I'm talking more about the transport layer, about the software layer. And even if you do say, say Qualcomm recently put out an article. They said all software based payment methods are insecure. We have hardware based payment methods. Well, good and fine. But your token that the hardware generates, if it is traveling over software and that software layer is vulnerable, then it all comes down to the weakest link. And the Google Wallet app had been cracked three, four times in 2011 when it came out, right? So it's not like it is going to be more secure. One thing about iPhone I can say is that, yeah, you are trusting a single entity for your, the OS code. And I think in the recent versions, custom keyboards are available. But before that, you are trusting Apple for the keyboard. You're trusting them for the OS and any network layer injection that can happen. So in that way, you're at least trusting one person, Apple. So if there is one evil guy, there is Apple, not somebody else. For Android, then there are a lot of players in that circuit itself, the OS and the keyboard and all of these things. Okay, that brings us to the end of this session. Please give him a round of applause.