iframes pass explanatory string

[michael-oneill]

There should be a way for embedded contexts (e.g. iframes) to communicate an explanatory string to explain to the user (in the confirm prompt) what the purpose is for storage access, along with a declaration of who is asking, i..e. an independently verifiable indication of the data controllers identity.

The controller identity should be associated with the domain name somehow, perhaps as a JSON resource at a .well-known location similar to the DNT Tracking Status Resource, or tied to a DNS record using something like DBOUND.

The user-agent should refuse to deliver explanatory strings, and probably always deny storage access, to origins that are discovered to be lying.

[annevk]

I don't think we should give sites control over UI. Whenever this was done historically it has led to abuse and therefore was removed.

[michael-oneill]

I have hard this before, but this API is allowing embeds to request access to storage. The user is (as they should be) informed when that happens, so they need to know what the reason is so they can make an informed decision. Otherwise they will get used to seeing disconnected requests for storage and many will automatically just agree. This is not giving users respect. I agree abuse will occur, but that does not mean we cannot inform the user. Procedures and protocols should be developed to deal with it (the abuse).

[johnwilander]

Thanks for filing, Michael!

This was discussed already at W3C TPAC 2017 at WebAppSec WG's meeting where I first pitched the Storage Access API. The joint conclusion was exactly what Anne says – history has shown that websites deciding what goes in browser UI is an anti pattern because it will always be used in confusing ways and abused for malicious purposes.

I think a crucial insight here is that the cross-site iframe is asking the browser for cookie access and the browser is asking the user. The best chance we have of users making informed choices when faced with this prompt is consistency. At least over time, users will learn to understand what this prompt means.

The one thing we have considered is to offer some preset purposes for well known use cases, like a menu to choose from, but we haven't arrived at anything concrete.

[Brandr0id]

Agreed on the issue surrounding allowing sites to specify the content arbitrarily. The implementers (perhaps even the spec) should provide meaningful and clear prompt verbiage, as needed.

We did some user research to help inform our decisions regarding a prompt for this API as we also echoed the same concerns about users being able to make an informed decision about what they are being asked to accept. Here are some of the outcomes I can share regarding one of the prompts we tested:

Ensuring we adequately describe what is being asked is important and I don't believe a simple string like "embedded_tracker.site wants to access cookie and storage data." will suffice like some other permissions prompts. Especially when dealing with abstract or foreign concepts such as cross site tracking or storage access the presence of a learn more link where users can dive deeper if they want, was determined to be important.

[hober]

Given @annevk and @johnwilander's comments, I'm going to close this issue. Please let me know if you think we should re-open.