Permissions & Security

[00:00:00]
>> So let's go over permissions and security and how that works before actually starting seeing those APIs, those capabilities that I'm promising. So permissions and security. So some permissions, so some APIs are harmless. So they have no cost, no cost in money, no cost in privacy. I don't know, like it's just some information, some ability or I don't know - playing a sound.

[00:00:32]
Playing a sound over the speakers, it can harm your ears, yeah, but it has no cost. Some other APIs and permissions, they open a privacy risk. For example, opening the camera, opening the microphone, getting the user's location, the geolocation, so where you are on Earth. And yeah, there is a privacy risk there.

[00:00:58]
And sometimes it can involve a cost, such as making a call, sending an SMS. Okay, so there is a real cost there. So when there are costs or risks, some browsers decide to put a limit on the usage of that capability. The W3C specs of the standard for the web platform, typically that's not to say what you do.

[00:01:24]
So sometimes there are recommendations that the standard recommends the user-agent. So the browser to limit this API, but each browser decides how to implement that. Okay, let's say that most of the browser's are kind of the same but there are some API's that are different. So for example, on Firefox, you might see a permission dialog for using that API and in Chrome, you don't.

[00:01:52]
Okay, so it's not the same experience on every browser for some API's. Sometimes they just need user engagement requirements, for example, Chrome. Remember I mentioned one API that we won't cover today, that was known as Background Sync. Background Sync lets you sync your data in the background a few minutes later or a few hours later.

[00:02:16]
Let's say you're on an app, I know it's a calendar app, webapp. You're storing your new kind of entry but for some reason the server is down or you don't have connection you're offline for whatever reason you are on a plane and that plane has no Wi Fi.

[00:02:36]
So what to do with that? Yeah, you can save it on IndexedDB locally, but yeah, if you don't open that up again, that new entry will never hit the server. Well, with Background Sync, you can ask the browser, hey browser, I know we don't have connection right now, but can we try later, even if the user forgets about this?

[00:02:59]
Well, background sync will do that. When you get out of the plane and you turn off airplane mode, the browser, even if the user is not opening the browser. The browser is running in the background and it will know that now we do have connection. Okay, I have a pending thing.

[00:03:15]
Let's try to do that Chrome will not give the permission to the user permission dialog at all. So if you're the developer, you're asking for that sync operation the requirement to use that capability is a user engagement requirement, which roughly means. That Chrome will check if the user is currently using your app or not.

[00:03:40]
If it's using your app frequently, and that algorithm is, I don't want to say secret because it's open source, but it's not something that you can manage. So if there is enough user engagement, when you try to use the API, it will grant you access. If not, it will deny you access.

[00:04:03]
But the most common scenario, and probably you know that as a user, is to see a permission dialog. You enter a Zoom call from the website, or a Google Meet call, or a Microsoft Teams call, from the browser, and the first thing you see is a dialogue asking you for a camera and microphone access, okay?

[00:04:23]
Or Google Maps asking you for geolocation access. Well, that's a permission dialogue, okay? cool, most capabilities these days, require HTTPS. Mostly on Chromium-based browsers. Safari is still supporting HTTP for that, so if you want to get users location, if you want to connect to a bluetooth device, you must be in HTTPS.

[00:04:49]
And you know that that's a restriction for having a website today. So also some capabilities will need the user interaction to be enabled. For example, microphone and camera, or what that depends on the browser, but geolocation, bluetooth, Web Push, sometimes for the user to see a dialog with the permission dialog.

[00:05:16]
The user has to first click on a button you can not request that permission when the page loads, because that's a user experience problem. Before this we were getting into websites that were asking for permissions all the time you don't know why you're there yet, so you typically say no.

[00:05:37]
So now you require a user interaction before actually asking for permission. Permissions are granted on an origin base, so if the user is granting you permission for a capability, you will get that permission for the whole origin, so the whole domain. Different HTMLs, different folders in the same domain will also get granted that permission.

[00:05:59]
You cannot narrow that permission per folder, or per file, or per PWA, or per manifest, or per service worker, no, it's per origin. Okay, which is good and bad, it's just what it is. If the user denies a permission, the API won't be able to ask again. You can ask, but it will be automatically denied.

[00:06:24]
So if the user said no, you as a JavaScript developer, you don't have a way to request that dialogue again. The only way you have, if it's denied immediately, you can show a message to the user. The user needs to go manually to the browser settings. I will show you where they are on each browser and re-enable that permission.

[00:06:47]
Okay, If the user grants the permission, depending on the capability, it may have no time limit. So it will be like forever, you are granted forever, for a couple of days, sometimes it's 15 days, 13 days a week, sometimes for a session or sometimes per one usage. It depends on the capability and it depends on the browser.

[00:07:12]
For example, camera and microphone, it's typically per session. Geolocation is typically per usage, so it depends. It depends on the capability. You cannot manage that, okay? Just keep in mind and that's the user experience. It's the best scenario world.