Allow beacons to announce themselves as public

[cco3]

Given that most beacons are public, most notifications should be displayed on the lock screen as public when the user has "hide sensitive information" on. Could metadata in the website or something in the beacon signal itself communicate this?

See also: https://github.com/google/physical-web/pull/299

[scottjenson]

Thanks for the issue! This is an Android feature that doesn't have an equivalent on any other platform is that correct? As a web based standard, we want to make sure we things in a cross platform way.

We have considered using JSON+LD for a range of metadata tasks. The main issue is that the vast majority of companies will likely not support anything so it's likely that showing this option has a high likelihood of not working properly. Please correct me if I'm misunderstanding anything here.

I'm not opposed to this request, I just feel we need to flesh it out a bit more to understand how it should work and how we handle failure gracefully.

[scottjenson]

I just read #299 and it's clear this is a tricky issue. The assumption is that most URLs are public so should be shown. However, even public web pages can show personal information. Let's take an example: We are both in a cafe and we both have our phones. At this point, both of our phones will display EXACTLY the same beacons in the same order. So if you have 'hide sensitive info' turned on, all I have to do is turn on my phone to see the same list. Not clear that honoring this request will help.

[cco3]

Not clear that honoring this request will help.

Right, it only matters when the website shows private info, which is why it seems that the website should declare itself as private or public.

Check out open graph tags http://ogp.me/. This reports the description and title and you could use that instead of an auto-generated notification description. It's used by companies like FB (its creator) to decide what image and title to show in the link summary. Since the webapp would know what will be shown, it could decide whether or not it's public info. If we let apps decide what notifications are public or not, why not mini-webapps?

Of course, it would take some decision making as to whether or not you want to endorse open graph since it's not exactly a widely-accepted standard.

Anyway, this is the kind of thing I'm imagining...this would also open up the door for the web site to declare other action buttons that would get put in the notifications.

[cco3]

FWIW, Google+ supports open graph as well as some other things: https://developers.google.com/+/web/snippet/

[scottjenson]

This is a good discuss, we want very much to protect private data. I'm just trying to keep the website URL/Title separate from the contents.

If you are in a clinic and there is a Physical Web beacon that shows you your test results, that clearly private, but you have to log in in order to see that data. Everyone in the clinic can see "XYZClinic.com" as a beacon. It's just the domain name. That doesn't appear to be private so blocking it doesn't seem to be a breach of personal information.

[g-ortuno]

I don't see an issue with always showing Title and Content for all UriBeacons. They will never show any private information. My issue with #299 was that it was also exposing mDNS and SSDP devices which I believe could contain sensitive information.

[cco3]

I'm just trying to keep the website URL/Title separate from the contents.

Why do you want to limit yourself to displaying the url/title in the notification? The title is part of the content (in the sense that you have to download the html to get it). Also, wouldn't it be nice to display a favicon?

Everyone in the clinic can see "XYZClinic.com" as a beacon. It's just the domain name.

Right, which is a good reason to make them all public. However, I'm not sure how the code grabs the title from the site...if it uses any credentials, the site could possibly put sensitive content in the title. So, it seems like the website itself (assuming we want to trust the developers) should optionally declare itself as public/private (depending on what the default would be).

[cco3]

They will never show any private information.

Do you have that guarantee? Do you ensure that there is never any auth done? If you do, it seems like that could be a limiting feature of the product.

[g-ortuno]

Yes. That's how it's designed. The app fetches the Url metadata through a proxy server to protect the user's privacy.

[scottjenson]

Right now the notifications are just title, description, favicon. All things that are public as well. We plan on keeping it that way. Everything that is displayed by the beacon is public info

[cco3]

Everything that is displayed by the beacon is public info

Public, assuming you have access to the same beacon, given g-ortuno's comment.

[Jerren34]

I have been keeping up with this project for quite some time now and as a Digital Marketer and Growth hacker I want to give my thoughts on why I think the suggestion @cc03 is making is a awesome idea. I believe using the open graph standard and displaying notifacations as mini web apps should be a feature. Users engagement with the notifacations will increase especially if you can put call to action buttons inside the notifaction. Thats a lot more engaging than just a traditional notifacation. Everything about the physical web is different so dont limit it to anything traditional. If not the main feature I believe it should be a option for websites to chose or not chose.

Also for beacons to be able to annouce themselves to users is a great Idea. When this technology is rolled out into browsers and operating systems there will be a lot of educating the users on what this technology is and how it works. People dont like searching for things they just want to be told. If beacons announce them selves the acceptance and scale of this technology will have a massive positive viral like effect. You cant expect to roll the technology out and it be a instant hit if your depending on educating user that this new technology is available but if you tell the user its avalibale every single smartphone user will know.

@Scottjenson @g-ortuno

[Jerren34]

@cco3

[scottjenson]

There are a few points here and I'd like to make sure there is no misunderstandings: 1) Beacons broadcast a URL publically 2) The phone app harvests those URLs, and uses our metadata server to fetch title/description/favicon 3) This is considered public information and displayed to any users nearby 4) We are, in effect, simulating a web search, showing public web page info 5) The user picks one from the list 6) The web page is shown but as it's the web, auth can then take place (e.g. cookies) and sensitive info can be shown (but only then)

Everything we show in the picker is considered public information and is under control of the phone all and the meta data server.

Note that there is no 'announcing' or 'notifications' in this process, this list is only shown when the user asks to see the list. As this is public and can occur at any time, we strongly want to avoid your phone buzzing constantly when you enter a mall. However, by using service worker you can opt into notifications after you visit a website once.

[Jerren34]

Ok I understand but let me ask you this. How will the user be educated to ask for a list? How much time do you think thats going to take before their are enough smartphone users aware of the tecnology to call it a success? I imagine many years. If the physical web is being created I believe a deeper look at how the digital web works should be in consideration. Of course I have to search or type a url in my browser when I wanna find a website ( walking into a area where url beacons are installed) after the site loads im directed to a landing page that informs me on how I can opt in/sign up to become a user of the site (notification in mini web app format that may have a simple message like "Welcome to the physical web. Interact with the things and places around you in a new and exciting way") the point that im making is the user wants things as easy as possible and having to educate and then go and find the physical web feature takes that away. Login with Facebook button is a prime example. People adopted to it because instead of having to give my name, bday, email adress, and create a password I can just tap this login with facebook button because its easier to use. User experience has to be easy with minimal steps in order to be successful. User privacy is important but user experience is even more important because without a great user experience there is no need to worry about privacy because you have no users. On Mar 25, 2015 9:40 AM, "scottjenson" notifications@github.com wrote:

There are a few points here and I'd like to make sure there is no misunderstandings: 1) Beacons broadcast a URL publically 2) The phone app harvests those URLs, and uses our metadata server to fetch title/description/favicon 3) This is considered public information and displayed to any users nearby 4) We are, in effect, simulating a web search, showing public web page info 5) The user picks one from the list 6) The web page is shown but as it's the web, auth can then take place (e.g. cookies) and sensitive info can be shown (but only then)

Everything we show in the picker is considered public information and is under control of the phone all and the meta data server.

Note that there is no 'announcing' or 'notifications' in this process, this list is only shown when the user asks to see the list. As this is public and can occur at any time, we strongly want to avoid your phone buzzing constantly when you enter a mall. However, by using service worker you can opt into notifications after you visit a website once.

— Reply to this email directly or view it on GitHub https://github.com/google/physical-web/issues/300#issuecomment-86028578.

[Jerren34]

Heres a cool picture to support my point On Mar 25, 2015 9:40 AM, "scottjenson" notifications@github.com wrote:

There are a few points here and I'd like to make sure there is no misunderstandings: 1) Beacons broadcast a URL publically 2) The phone app harvests those URLs, and uses our metadata server to fetch title/description/favicon 3) This is considered public information and displayed to any users nearby 4) We are, in effect, simulating a web search, showing public web page info 5) The user picks one from the list 6) The web page is shown but as it's the web, auth can then take place (e.g. cookies) and sensitive info can be shown (but only then)

Everything we show in the picker is considered public information and is under control of the phone all and the meta data server.

Note that there is no 'announcing' or 'notifications' in this process, this list is only shown when the user asks to see the list. As this is public and can occur at any time, we strongly want to avoid your phone buzzing constantly when you enter a mall. However, by using service worker you can opt into notifications after you visit a website once.

— Reply to this email directly or view it on GitHub https://github.com/google/physical-web/issues/300#issuecomment-86028578.

[Jerren34]

Ok I understand but let me ask you this. How will the user be educated to ask for a list? How much time do you think thats going to take before their are enough smartphone users aware of the tecnology to call it a success? I imagine many years. If the physical web is being created I believe a deeper look at how the digital web works should be in consideration. Of course I have to search or type a url in my browser when I wanna find a website ( walking into a area where url beacons are installed) after the site loads im directed to a landing page that informs me on how I can opt in/sign up to become a user of the site (notification in mini web app format that may have a simple message like "Welcome to the physical web. Interact with the things and places around you in a new and exciting way") the point that im making is the user wants things as easy as possible and having to educate and then go and find the physical web feature takes that away. Login with Facebook button is a prime example. People adopted to it because instead of having to give my name, bday, email adress, and create a password I can just tap this login with facebook button because its easier to use. User experience has to be easy with minimal steps in order to be successful. User privacy is important but user experience is even more important because without a great user experience there is no need to worry about privacy because you have no users.

[g-ortuno]

@Jerren34 I'm not entirely sure what you're proposing... Please correct me if I misunderstood but you want each single beacon to be able to have their own notification with possible actions?

[Jerren34]

@g-ortuno yes im agreeing that @cco3 idea and point he was making regarding beacons being able to announce themselves with notifactions and not just traditional notifacations but a possible interactive notifacation with call to action buttons. He described it a mini web app as the notifaction. During my argument im explaining from a digital marketer point view who focus on user experience that making users have to look for beacons instead of allowing them to announce them selfs creates bad user experience because users want things as easy as possible. You dont wanna spend all this time creating this awesome technogy and have to depend on educating smarthphine users about a how they can go find beacons vs beacons just announcing them selves. Dosent have to be every beacon popping up on my phone but I believe there is a better than just relying on a user to know about ths technology and look for beacons.

[scottjenson]

We have very strongly opposed any type of 'proactive notifications' for the simple reason that it can be so easily abused and create spam for the user. Walking into a mall should not turn your phone into a dance machine. We appreciate that value that notifications has but has this would NOT be opt in, we feel we must be very protective of users in this case.

There is a service worker example that does have a stronger notification but that's built on top of the Physical Web, the user loads the web page first and then opts into the stronger notification. That is very different as the user has explicitly asked to be notified.

Scott

On Wed, Mar 25, 2015 at 11:12 AM, Jerren34 notifications@github.com wrote:

@g-ortuno https://github.com/g-ortuno yes im agreeing that @cco3 https://github.com/cco3 idea and point he was making regarding beacons being able to announce themselves with notifactions and not just traditional notifacations but a possible interactive notifacation with call to action buttons. He described it a mini web app as the notifaction. During my argument im explaining from a digital marketer point view who focus on user experience that making users have to look for beacons instead of allowing them to announce them selfs creates bad user experience because users want things as easy as possible. You dont wanna spend all this time creating this awesome technogy and have to depend on educating smarthphine users about a how they can go find beacons vs beacons just announcing them selves. Dosent have to be every beacon popping up on my phone but I believe there is a better than just relying on a user to know about ths technology and look for beacons.

— Reply to this email directly or view it on GitHub https://github.com/google/physical-web/issues/300#issuecomment-86154865.

[tolson2000]

Right. The PW icons shows up at the top of the screen just like WiFI, Signal strength etc. The user really doesn't have to learn anything about the PW feature since it is (will) just be there.

Once a user actually selects a website, then that website can do whatever it wants with the beacon if the beacon were designed to become an interactive (non-beacon) device at that point.

On 03/25/2015 12:47 PM, scottjenson wrote:

We have very strongly opposed any type of 'proactive notifications' for the simple reason that it can be so easily abused and create spam for the user. Walking into a mall should not turn your phone into a dance machine. We appreciate that value that notifications has but has this would NOT be opt in, we feel we must be very protective of users in this case.

There is a service worker example that does have a stronger notification but that's built on top of the Physical Web, the user loads the web page first and then opts into the stronger notification. That is very different as the user has explicitly asked to be notified.

Scott

On Wed, Mar 25, 2015 at 11:12 AM, Jerren34 notifications@github.com wrote:

@g-ortuno https://github.com/g-ortuno yes im agreeing that @cco3 https://github.com/cco3 idea and point he was making regarding beacons being able to announce themselves with notifactions and not just traditional notifacations but a possible interactive notifacation with call to action buttons. He described it a mini web app as the notifaction. During my argument im explaining from a digital marketer point view who focus on user experience that making users have to look for beacons instead of allowing them to announce them selfs creates bad user experience because users want things as easy as possible. You dont wanna spend all this time creating this awesome technogy and have to depend on educating smarthphine users about a how they can go find beacons vs beacons just announcing them selves. Dosent have to be every beacon popping up on my phone but I believe there is a better than just relying on a user to know about ths technology and look for beacons.

— Reply to this email directly or view it on GitHub

https://github.com/google/physical-web/issues/300#issuecomment-86154865.

— Reply to this email directly or view it on GitHub https://github.com/google/physical-web/issues/300#issuecomment-86189526.

[Jerren34]

Ok thanks for that comment @tolson2000 this is a feature I didnt know about. This puts it in a new perspective for me and makes more since now. Sorry for the confusion @scottjenson

[scottjenson]

not a problem. Closing unless further comment.