4 ms·

With regards to exporting and importing: The idea is definitely not any more dangerous than the already existant functionality for `<input type="file">`. And y

With regards to exporting and importing: The idea is definitely not any more dangerous than the already existant functionality for `<input type="file">`. And yes, of course in real life such features would be designed in such a way that the site can only access the entries relevant to itself. I do agree that the article was a bit loose in its language here. But why you would ever think that a standard would give more flexibility to certificates than it does cookies?

rakoo 11y ago
> But why you would ever think that a standard would give more flexibility to certificates than it does cookies? Cookies management, as seen from the user, is straightforward: there's a way to delete them all for a given site, and recently, thanks to the EU there's a banner telling him that there are cookies. The user can't do much more than that. Moreover, cookies are a crutch for the server to handle state. Certificate management, on the other hand, is going to be a whole another animal, not only because there are much more things to handle, but also because we start dealing with crypto; moreover, we're talking about client certificates here, so IMO it should absolutely remain under the user control. I like to think that the website is a potential enemy (whether it wants to or not), and the browser is an ally so the less a website controls, the better.