Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Potential user interface elements / changing user behavior #31

Open
pbannist opened this issue Oct 8, 2020 · 5 comments
Open

Potential user interface elements / changing user behavior #31

pbannist opened this issue Oct 8, 2020 · 5 comments

Comments

@pbannist
Copy link

pbannist commented Oct 8, 2020

One of the challenges of this proposal is imagining a future world where users understand this concept and then figuring out how to get from the world we're in today to that future state. One way to do that is to have a more specific conversation around what the user interface might look like for First Party Sets/Site Groups. I am far from a designer but mocked up the attached example (modifying the default Firefox UI) as to how this concept could be explained to users.

With an interface like this, the FPS/SG name would always be exposed in the URL bar so the user can always see the domain they are on, but also the set/group that it belongs to. If that element became standard across browsers, this would become an easier concept for users to understand. The idea would be that you could click on (or mouse-over) the group name and get more information about what this meant and how you can interact with it. This interface would need to be simplified for mobile browsers due to space constraints, but perhaps an icon similar to the secure "padlock" can be created to show that this site is part of a group and to tap it to get more information.

In the early days of the web, there was significant confusion about how to type "HTTP://", when you needed to put "www." in front of a domain, and what a domain name even was. But over time, through education, reinforcement and repeated usage, users understood how the concept of site names/domains works - generally speaking. If all browsers adopted this feature and standardized on the interface (relatively), the same process would happen here.

The key question is what are the true user benefits that can be offered via sets/groups - and then if those have real value, we can collectively figure out a path to get there. But it's certainly true that to push the web platform forward, sometimes users will be confused about new features, but they will learn them over time.

site groups example

@pbannist pbannist changed the title Potential user interface elements Potential user interface elements / changing user behavior Oct 8, 2020
@arthuredelstein
Copy link

I think the copy here (which I understand is just an example), "This allows sites in this group to share your information in order to provide better services to you" brings forth an underlying assumption that I don't agree with.

I think a better description would be "Ad networks can track you across sites in the Site Group invisibly, and use that data to profile you for purposes of microtargeting, including suppressing your vote if you are in a target demographic."

If this is truly for the user's benefit, and not primarily for the benefit advertisers and data brokers, why can't we make this kind of data sharing across sites opt-in, and require user consent? Why should my YouTube viewing habits be associated with my identity on Google (such as my gmail account)?

@annevk
Copy link

annevk commented Oct 9, 2020

I recommend reading up on Extended Validation. (And in this case I guess the "Google, Inc." string would be controlled by the website? That would be even worse.)

@pbannist
Copy link
Author

pbannist commented Oct 9, 2020

Thanks for your thoughts!

@arthuredelstein My opinion is different from yours, but regardless of that, your point speaks to the fact that I don't think FPS has a clearly defined set of use cases, so everyone has different ideas in their head. Some of those use cases are good and others are certainly bad. I really do think it's worth us figuring out what those are, as without them it feels unclear why it should be done at all.

@annevk Thanks for that background, I have been reading about EV all morning and understand the issues better now! To be fair to the Chrome team, they had said that the UI element should be inside the existing "site bubble" rather than in the URL bar.. Adding the name directly into the URL bar is clearly a bad idea based on the EV experience. In my opinion, the name would have to go through some kind of CA-like approval/attestation process, but even with that it's clearly a pretty weak piece of data.

Much more thought is needed here.

@annevk
Copy link

annevk commented Oct 9, 2020

FWIW, I think the problem with hiding it in the "site bubble" is that at that point it's completely opaque to the user that data is being shared, unless they proactively take action. That is still the status quo in most browsers, but it's also bad. (Which is also why Mozilla's stance is more or less that if you want to share data in that way, you group the sites that want to share data under the same registrable domain.)

@dmarti
Copy link

dmarti commented Feb 11, 2021

If two sites have completely different design, different logos and other trademarks, and different domain names, is it realistic to expect the user to remember that they clicked a dialog, possibly a long time ago?

Not everybody reads the business section and remembers all the stories about which companies are now part of which other companies. Today's netscape.com does not have the same owner as mozilla.com, it has the same owner as techcrunch.com. (I was going to say huffpost.com but fortunately I looked it up...huffpost.com was part of oath.com, but now has a new owner.)

In order to be clear to the user it seems like we would have to require some level of obvious user-visible branding in addition to the common privacy policy and common data stewardship policy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants