miguelg: Would you happen to have screenshots for notifications with and without attribution as well as platform notifications? I lean towards showing an attribution regardless of how the notification is created, but there might be subtleties I'm missing.

No attribution:

https://drive.google.com/a/google.com/file/d/0BwOJ-sC7EPRIb2Z4ejJyMVlWNW8/view?usp=sharing (Uploaded to google.com only because it's an in house extension)


Platform notification (always with attribution)

http://imgur.com/a/qgaZz (the position of the domain has changed a bit in mac as you can see there)

 Issue 659904  has been merged into this issue.

I just came across this coincidentally. It was rather confusing (even in a non-security way) because there was no indication where the notification was coming from.

dewittj@, how hard would it be have attribution here?  If we already have it for web notifications, it seems like it should be pretty straightforward...

Attribution for Web Notifications is shown in the context_message field, which is exposed as part of the extensions API.

We identified two significant (>1M users, non-spammy usage) extensions that use the field in April. Google Hangouts uses it to display your account information, i.e. your e-mail address. Google Share to Classroom uses it to display some URL. Many other extensions use it for branding or advertisement purposes.

A simple non-breaking path for getting there would be to *always* attribute in the context_message, and allow extensions to display their own context message in whatever space remains. E.g.:

http://imgur.com/a/Q7gtC

Note that context messages cannot be supported in either case by the native notification centers.

While it seems simple to add attribution, there simply isn't much space left in the notification for more text.  I think that UI review would want to chime in on changing the layout significantly.

Peter's option is reasonable, but given the limited width of notifications and the relatively long extension names in the web store, I think that it'd be de-facto removing the context message anyway.  This might work if we were to start allowing multiple lines in the context message (perhaps only if there were few lines in the main message?)

The logic was that apps, being installed by the user, get to control their entire UI in the notifications.  At the time there was a right-click handler that would allow you to disable the extension/app generating the notification but that's been since removed if I recall correctly.

Peter's point about native notifications is also very relevant because going forward eventually CrOS & Linux will be the only OSes using the built-in notification center.

This might be something worth bringing up with UI review (though I imagine it would be simple enough over email), once we have a concrete proposal.  felt@, meacer@ - does anyone on the enamel team have an idea how this should look, ideally?

> Note that context messages cannot be supported in either case by the native notification centers.

Does this mean that web notifications don't have attribution?  Or what do they do?

+emilyschechter for UI opinion.

Would adding a new line and showing the extension name there make the dialog too crowded? (given that only two popular extensions use context messages, maybe not)

The added benefit of separating extension name from context message is that we could make the extension name clickable and take the user to extension details.

Can we still make it clickable in the same line, or is that a technical restraint?

I'm not familiar with the implementation but I'd be very surprised if there was a technical restraint. I thought it would be cleaner if the name and the message was separated.

> Does this mean that web notifications don't have attribution?  Or what do they do?

They will certainly have attribution. I don't have screenshots handy, but I guess extension context messages may be able to use the same field.

re: clickable lines

That's rather undiscoverable. Instead, notifications already support a settings cog that can easily be hooked up for extensions.

See the following (random) image: https://s3.amazonaws.com/tagnpin/static/site/home/webpush.jpg

For what it's worth, I'd be happy to make the necessary changes we decide on here.

available + owner -> assigned