Considering browsers to be a central place for federated identity, they should be able to share data they previously collected, if user agrees to do so. It also means browsers provide a screen to fill this kind of information, like a digital identity card.

Inspired by Oauth2 and GDPR consent screens, but with 2 flavors : short box, long box.

If you click on “Customize”, you get the long box.

You can also call the long box directly.

4-bis669×1200 92 KB

Tune labels

You can also tune some labels, like the Title, or the Accept button.

Check the See also section for a similar tuning example.

See also

[Proposal] Multi Permissions API

This looks like a terribly invasive thing to put behind a confirmation box.

Instead of just asking for a generic feature, can you explain in your situation what you’re trying to allow a user to do? Use-cases drive discussion and support for new APIs. Something this broad is terrifying and unlikely to ever get any momentum.

Let’s take a concrete example :

s685×515 82 KB

From this picture we can deduce this social network user is willing to share :

• Photo
• Name
• Company
• Gender
• Sexual Orientation
• City
• Country
• Website

Which is already a lot of information.

In 2021, the line between public and private spheres tends to blur & fade. With the advent of woke & proud cultures, lots of people are willing to share more and more about them, and they particularly like to declare themselves being part of physical / behavioral / social groups, in one word, communities.

I think it is a good idea to centralize all that information in one place, so user can control its informations and granularly decide what to share, as to avoid to repeat myself every time I register on a new website, which is particularly annoying.

This is especially true on mobile, where typing information takes a long time. Registration and checkout are currently painful processes. The best form you can think is no form at all. Having buttons makes the experience fast and seamless.

The shared information proposed in the mockups can of course be discussed. I mixed information generally available on social networks, dating networks, ID card.

Letting the browser become a digital ID card is something I find exciting.

Browser would become the reference in terms of user information.

Also, this mechanic can be used to comply local regulations. I have two example in mind.

The first one is obvious : GDPR. Every shared data must be linked to a user consent. Per type of data shared. In France, lots of dating websites were condemned because they didn’t provide somehow a granular consent (It was all or nothing, or no consent at all).

The second one, in France, the government now asks porn websites to justify both identity and a minimum age to access those sites. Having these informations embed in browser can help to comply local laws here.

Whether you like these laws or not, editors have to comply. It’s better to find a common approach (official solution emanating from the industry) to comply with governement regulations rather than letting each editor fight alone and do worst things.

I hope we can trust the browser to do the right thing here.

In conclusion, this is not pervasive at all, on the contrary, it fits well in the contemporary age we are living in.

Anyway, this feature is like all features, optional. If a user don’t like it, it shall not use it. It is a progressive enhancement. Not an obligation.

Willing to share with that social network. That doesn’t mean they are willing to share said information with any given site online.

While this API seems useful to lessen repeated form filling, it is also extremely dangerous given how most users just say OK to things and don’t give it much thought.

The browser shouldn’t become the arbiter of this information.

On the legal front, other APIs are being discussed over GDPR and kin regulation. I don’t think the browser needs to start handing out personal information like this.

FLoC is already getting enough hate in the community and it is anonymized. This is almost the equivalent of giving a UUID to each user that can be easily shared to sites. It just won’t get steam.

This is the number one objective.

Because FLoC is activated by default in browsers, it is opt-out by all major frameworks in their Feature Policy.

We need opt-in, non-forced solutions.

The Share User Data proposal is one of them.

That’s why there are 2 other buttons : Customize and Cancel. There are more non-OK buttons (2) than OK buttons (1).

If some people say OK to any contract without reading it first, even IRL, the problem is not on the interface side, it lies between the chair and the keyboard.

The Share User Data proposal keeps the contract short, readable and customizable

If you’re open to redefine and limit the data, I have a strong feeling we’ll just end up back at Autofill APIs as they exist today.

So why don’t we attempt to support doing some work on that front in UAs rather than introducing some new API specifically for the same thing?

Not sure you can autofill everything.

Some data are lists by nature, and do not fit well in a single field.

No examples to show what exactly doesn’t fit and why the web should support them?

Without concrete use cases requests don’t go that far.

The lists can be seen in mockups of the first post, but I’ll write them in case images are not properly displayed nor accessible on your end.

Example of lists

Photos (of you), emails, phones, adresses, social accounts, sexual preferences, spiritual beliefs, political opinions interests, musics, movies & series

You can’t resolve these ones with autofill, or it would take a huge amount of clicks and a kafkaian GUI.

Knowing this data makes sites able to link users between them, let them discover and meet each other, share common interests, and create communities with a seamless UX.

In the end these millions of communities increase user exchanges and knowledge sharing among users, at a worldwide scale, which makes the world a better place.

To be clear: I have no association with this proposal and I don’t endorse it.

Absolutely.

Surma’s Twitter profile was just taken as a random example because it was open in my Chrome tabs.

1. Autofill could be used for these things if properly scoped and defined.
2. Do we want this though? Very much no. The Web Platform has a vested interest in keeping users’ private data just that. Why make it easier for people to accidentally, unknowingly, or by deceitful tactics give up this information?

To point 2 here, we already see sites abusing APIs such as notification. “Click OK Here to get access” with an arrow pointing to where the notification from the browser comes up. Having this level of information available via an API where a user can be tricked into providing so much personal data automatically is terrifying.

An API like this would never get off the ground. It runs entirely contradictory to the Web Platform Design Principles.

A new feature which introduces safety risks may still improve user safety overall, if it allows users to perform a task more safely on a web page than it would be for them to install a native app to do the same thing. However, this benefit needs to be weighed against the common goal of users having a reasonable expectation of safety on web pages.

Native APIs don’t exist to share this kind of information. So why should the web be the first platform to allow this? It is ripe for abuse by malicious app developers and isn’t useful to the majority of apps when forms and autofill work just fine.

Please raise specific cases where you feel Autofill can be improved. Preferably in isolated threads with use-cases to drive the discussion. But remember, user privacy and safety will be weighed against them. Some things we just don’t want to handle, even autofill is fallible.

Ah, so the goal is to link users between apps. Essentially creating a UUID per user. Yea, that’s not happening. See above on privacy and security for users coming first on the platform.

Legally speaking, the french CNIL says it is forbidden to disallow the access of a website if no consent approval is given, which would transform the consent into a forced one. Browser can intervene here just like they do with websites embedding virus payloads. But having people abusing is not an excuse to prevent good people to use it. Or else it would be a collective punishment. Blame individuals, not the tool. If someone use a fork to do bad things, would you forbid all forks ? No.

Not at all, since consent, thus sharing, is optional. Moreover, it is optional per site : each site will ask different things, and user can select / unselect differents things per site. The evil scheme you describe does not work.

This user data is required to match users into common groups of interests so they can safely exchange point of views without any harm.

Few safe bubbles examples :

• On some social networks, teenagers might not want to exchange with adults
• On some social networks, black people might not want to exchange with white people
• On some social networks, red-eye people might not want to exchange with non-red eye people
• On some social networks, women might not want to exchange with men
• On some social networks, fat people might not want to exchange with non-fat people
• On some social networks, small people might not want to exchange with tall people
• On some social networks, gays might not want to exchange with straights
• On some social networks, democrats might not want to exchange with republicans
• On some social networks, religious people might not want to exchange with non-religious people
• …etc.

I read a lot of jurisprudencial litterature (from both french and european courts) on the subject of user consent & data sharing. Reading the sole GDPR took me 7 hours. All these texts conclude that sharing data is perfectly fine if user gives a consent.

Can anyone explain why it would be bad for users to give consent before sharing their data ?

See point 2 in my previous post. Abuse. Especially from sites that say, “You can only submit information through this API” so then in order to give a site the values you wish you need to go edit your profile information in the browser to then submit. Then go change it back after.

Overall, the idea is anti-user, anti-privacy, and anti-safety.

You keep talking about “user selection”. Most normal users (meaning as in over a billion web browsers being active) extremely few of those change defaults or ever dig into any kind of advanced menu. Those of us in the know tend to do it far more often then regular people because we understand these things. The vast majority of people do whatever gets them to what they want faster.

Nope.

You click on “Cancel”.

Because the site has no clue on you, it shows you the forms and you type the data you want in forms.

This API is a progressive enhancement, allowing you to bypass forms.

If you refuse to give your data, then you are exposed to the forms.

And the best is you can give partial consent.

+1, someone being convinced to click Accept on a request like this, or accidentally clicking Accept, or someone else clicking Accept while sitting at their computer, would have potentially catastrophic privacy implications. Revelation of data is typically not revocable, and this could potentially be an enormous amount of data to reveal simultaneously. Explaining those risks to users so they have an informed choice or genuinely consent to the disclosure (to whom and for what purpose) would be both high-stakes and difficult.

I don’t think it’s generally beneficial to encourage browsers to collect much more granular data on the user, but providing a dangerous, irrevocable action to reveal it all to a website at once would be even scarier. (To be clear, we should maybe be looking at the privacy implications of autofill more closely as that can sometimes reveal multiple data fields at once as well.)

I’m also not sure how it helps websites to do the right thing. Asking for a large list of information simultaneously without user involvement makes it less likely that the user will understand the context of the request, and less likely that the user will provide more detailed information specific to the use case. Sites can’t explain inline in a form why this or that field is necessary and users can’t see or edit what information about them is about to be submitted. Sites that ask for less information wouldn’t see much of an advantage over sites that ask for everything.

While there have been some negotiation-style proposals for automated access to user data in the past, connected to early P3P drafts, those would have specifically included detailed negotiation about the parties involve, needs for the data, rules about how it was used, etc. Currently none of that is implemented and it isn’t proposed here.

+1, particular autofill use cases and feedback could be very useful.

I also think the Contact Picker suggestion is a promising one: that also requires some serious privacy work to help users understand the implications, but that could be a user-involved or user-initiated contact-info-only process.

One of the capabilities of revealing a list of user profile information simultaneously is certainly the ability to identify and re-identify the user, across websites. Even if not all fields are requested by every site, subsets of collections of fields would be extremely useful for the purpose of identifying users and tracking behavior across websites.

This draft questionnaire on adding permissions to the Web might be useful in uncovering some of the incompatibilities of this approach with the Web (including: need for the feature; capabilities implicated; persistence and revocation; user understanding; asking for permission in context and just in time; progressive enhancement).

Tracking accross websites is only possible if those websites exchange data to consolidate user knowledge. Theses exchanges are not a consequence of the Share User Data API proposal. They already happen nowadays, as a consequence of databases and cookies introduced since the web exists. In addition, let’s remember that sharing data accross websites without user consent is illegal.

GDPR & french CNIL forbid you to collect information that is not stricly needed to operate your site. You risk to face enormous fees if you try to bypass the law. Fees are distributed each time the control entity analyzes your site. Once they caught you, the audit happens each year. Conclusion: it’s illegal.

There is no need for autofill when the goal is to evade 90% of the 1990’s form fields.

Just like with OAuth2, during the past 10 years (RFC dated from 2012).

We could improve that by using a good-faith endpoint where, when called, the site commits to remove the data from its database. Seems fair and comply with the GDPR laws (“right to be forgotten”).

–

Let’s have a look at few Google OAuth2 consent screens, randomly picked on the Internet :

10-google-authorization463×686 51.8 KB

stARh420×747 36.9 KB

Figure1589×999 171 KB

vKGZk689×915 17.9 KB

OAuth2 is a protocol acknowledged by IETF.

Browsers allow it so websites can ask user consent before their get their data.

The Share User Data API proposal is about porting this well-known mechanic of OAuth2 into the browser, so developers don’t need to implement a complex API machinery just to register users in a seamless way.

Benefits

• User is in control and can give partial consent
• User can remove consent after giving it (Browser send request to a well known site endpoint)
• User is exposed to only 1 prompt (exit multiple prompts)
• User evades 90% of the form fields
• Seamless registrations, mobile friendly
• Browser is responsible for storing the data and has user consent to store
• Browser is responsible for storing user data granular consent per site
• Respect the GDPR laws (datalist + accept/deny/partial + “right to be forgotten”)
• Respect the OAuth2 consent screen spirit, in a standardized way
• Decouples the authorization/sharing mechanic from the identification one
• Simple to implement : 100% front-end (no knowledge of the backend)

What international law says this that is agreed upon by the vast majority of nations in the world?

Unless you are a lawyer specializing in this field, best avoid such sweeping statements. What I’m seeing is a bunch of “Well in Europe/France my law says X and I want my law to apply everywhere on the web.” Which isn’t how this works. The web applies beyond any specific set of laws in a given region.

You’re missing the point of how crucial forms still are for this kind of information. Giving users direct actionable consent on what is provided to whom. You also proclaim “Forms are the fallback” without saying how that can be enforced by a browser. If this API exists, developers are free to say, “Give us the info through this or you can’t get access”.

Now more context is being stuffed in here. This is a red alarm.

You’ve been given the best guidance, help refine the Autofill API with specific improvements for what you desire to be easier for users. Is it the absolute simplest? No. Is it a good starting point? Absolutely.

Build on top of something that exists. Get some experience having thoughtful, use-case driven discussions on building new pieces out. Once that is improved a bit and the situations browsers need to consider are more well understood. Then, try to take on adding a new API in such a crucial area for privacy.

You can’t forbid access to information

Like I said previously, GDPR and french CNIL (CNIL being the authority that inspired GDPR, based on the famous french law, “Loi Informatique et Libertés” created in January 6th 1978, 43 years ago) say that user consent must be freely given without any gain or loss. You can’t give access to content in exchange of user consent. This is illegal.

I am surprised how people interacting in this thread know so little about the basic principles of GDPR introduced in 2016, 5 years ago.

See GDPR, point 32

Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject’s agreement to the processing of personal data relating to him or her (…) the request must be clear, concise and not unnecessarily disruptive to the use of the service for which it is provided.

https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX%3A32016R0679

Conclusion : In case of refusal, user must still access to the site.

In addition, the right to freely access to information on any media is backuped by the Article 19 of Universal Declaration of Human Rights, which was introduced the 10 December 1948, 73 years ago.

Everyone has the right to freedom of opinion and expression; this right includes freedom to hold opinions without interference and to seek, receive and impart information and ideas through any media and regardless of frontiers.

https://www.un.org/en/about-us/universal-declaration-of-human-rights

GDPR applies to the world

I have already answered on basics, but let’s dive in in more recent threads.

Free trade agreements. Ratified between nations, they have a higher priority than constitution when they are synallagmatically signed. Individuals, companies and states can mutually sue themselves. You have to think globally.

Few examples:

2017 - Facebook condemned to 1.2 millions € (datalist and usages)

2020 - Ireland - Twitter condemned to 450 K (private tweets being public)

2020 - France - Google condemned to 100 millions € (cookies)

https://www.cnil.fr/fr/cookies-sanction-de-60-millions-deuros-lencontre-de-google-llc-et-de-40-millions-deuros-lencontre-de

2021 - Italy - Google condemned to 100 millions € (ASO / dominant position)

A website listing 251 GDPR fines accross the world :

List of fines | GDPR Fines - INPLP

Please note that most of GDPR fines are not publicy disclosed when a private agreement is found. These few example are only publicy disclosed when the company choose to confront regulation authorities (not the best move IMHO).

Tim Cook, CEO of Apple, on GDPR applying to the world

On February 3rd 2021, Tim Cook recorded an historical message about the GDPR compliance at a worldwide scale.

Proving cynics and doomsayers wrong, the GDPR has provided an important foundation for privacy rights around the world, and its implementation and enforcement must continue.

tim1165×656 171 KB

tim21165×656 173 KB

tim31165×656 176 KB

tim41165×656 169 KB

But we can’t stop there. We must do more. And we already seeing hopeful steps forward, including a successful ballot initiative strengthening consumer protection right here in California. Together, we must send a universal humanistic response to those who claim a right to users’ private information about what should not and will not be tolerated.

As I said in Brussels two years ago, it is certainly time not only for a comprehensive privacy law here in United States, but also for worldwide laws, and new international agreements that enshrine the principles of data minimization, user knowledge, user access, and data security accross the globe.

We’ve set new industry standards for data minimization, user-control, and on-device processing for everything, from location data to your contacts and photos

And last but not least, we are deploying powerful new requirements to advance user privacy throughout the Appstore ecosystem. The first is a simple but revolutionnary idea that we call the Privacy Nutrition Label. Every App, including our own, must share their data collection and privacy practices. Information that App Store presents in a way every user can understand and act on. The second is called App tracking transparency. At its foundation, ATT is about returning control to users, about giving them a say over how their data is handled. Users have ask this feature for a long time. We have worked closely with developers to give them the time and resources to implement it. And we are passionate about it because we think it has great potential to make things better for everybody because ATT responds to a very real issue.

Technology does not need vast troves of personal data stitched together accross dozen of websites and apps in order to succeed. Advertising existed and thrived for decades without it. We are here today because the path of least resistance is rarely the path of wisdom. If a business is built on misleading users to data exploitation, on choices that are no choices at all, then it does not deserve our praise. It deserves reform.

Call us naive. But we still believe that technology made by people, for the people, and with people’s wellbeing in mind is too valuable a tool to abandon. We still believe that the best measure of technology is the lives it improves. We are not perfect. We will make mistakes. That’s what makes us human. But our commitment to you, now and always, is that we will keep faith with the values that have inspired our products from the very beginning, because what we share with the world is nothing without the trust our users have in it.

To all of you who have joined us today, please keep pushing us all forward, keep setting high standards that put privacy first, and take new and necessary steps to reform what is broken. We’ve made progress together, and we must make more, because the time is always right to be bold and brave in service of a world where, as Giovanni Bittarelli put it, technology serves people, and not the other way around.