Confirmed users
716
edits
Talk:WebAPI/PushAPI: Difference between revisions
no edit summary
No edit summary |
|||
| Line 10: | Line 10: | ||
<i> | <i> | ||
=== Comments from Gerv === | |||
* Is the "body" plain text or HTML, or something else? | * Is the "body" plain text or HTML, or something else? | ||
* Are clients forced to support actionURL (the notification system currently used in Ubuntu, for example, specifically removed support for clicking on a notification to take an action)? | * Are clients forced to support actionURL (the notification system currently used in Ubuntu, for example, specifically removed support for clicking on a notification to take an action)? | ||
| Line 20: | Line 20: | ||
* How can we mitigate the problem of one (authorized) site spoofing notifications that look like those from another site? Will the in-browser UI show the origin of the notification? | * How can we mitigate the problem of one (authorized) site spoofing notifications that look like those from another site? Will the in-browser UI show the origin of the notification? | ||
Responses from Sicking: | |||
Responses | |||
* plain text | * plain text | ||
* We can definitely make it optional. I wonder if we should return a set of capabilities along with the URL to let the page know what parts are supported. This will work well when we expand the API to support things like setting "badge numbers" for apps etc. | * We can definitely make it optional. I wonder if we should return a set of capabilities along with the URL to let the page know what parts are supported. This will work well when we expand the API to support things like setting "badge numbers" for apps etc. | ||
| Line 33: | Line 29: | ||
* replaceIDs are scoped to within the origin, so sites can use whatever scheme they want. | * replaceIDs are scoped to within the origin, so sites can use whatever scheme they want. | ||
* How do we handle this for the Notification API? | * How do we handle this for the Notification API? | ||
=== Comments from Hixie === | |||
* How does this handle a user who uses two different Web browsers? (e.g. IE at work and Firefox at home) | * How does this handle a user who uses two different Web browsers? (e.g. IE at work and Firefox at home) | ||
Responses from Sicking | |||
Responses | |||
* UAs should allow setting custom notification services. For example, in Firefox we would by default deliver messages through a Mozilla server, but allow users to choose other notification delivery providers. By choosing the same delivery provider in all browsers, it should be quite possible to make it work. The main problem would be making sure that the delivery provider knows your identity in all browsers, possibly by making you log in when you first set up the service. | * UAs should allow setting custom notification services. For example, in Firefox we would by default deliver messages through a Mozilla server, but allow users to choose other notification delivery providers. By choosing the same delivery provider in all browsers, it should be quite possible to make it work. The main problem would be making sure that the delivery provider knows your identity in all browsers, possibly by making you log in when you first set up the service. | ||
=== Comments from Ben Bucksch === | |||
* How is the privacy impact of following the user (IP addresses, usage times) reduced to the absolute minimum possible? | * How is the privacy impact of following the user (IP addresses, usage times) reduced to the absolute minimum possible? | ||
* Why the middle man Mozilla? Decentralization is a core principle of the Internet. | * Why the middle man Mozilla? Decentralization is a core principle of the Internet. | ||
-- Ben Bucksch | -- Ben Bucksch | ||
* We "only" leak that information to the delivery service. I can't think of a way to allow the delivery service to send messages to the client without knowing the clients address. Suggestions welcome. | * We "only" leak that information to the delivery service. I can't think of a way to allow the delivery service to send messages to the client without knowing the clients address. Suggestions welcome. | ||
* Nothing in the API or protocol forces this to go through Mozilla. We can easily let the user choose any delivery service. However we need to go through a delivery service rather than having each website send messages to the device directly in order to reduce IP address/phone number/usage time leakage. | * Nothing in the API or protocol forces this to go through Mozilla. We can easily let the user choose any delivery service. However we need to go through a delivery service rather than having each website send messages to the device directly in order to reduce IP address/phone number/usage time leakage. | ||
-- Sicking | -- Sicking | ||
We don't "need" to go through Mozilla or anybody. When I browse the web, I already contact servers directly and they already see my IP address. Moreover, the server sees every webpage I visit and when. I can only prevent that by using a proxy all the time, but then the proxy can monitor me, and I'd rather avoid that. We have a similar tradeoff here. I argue the sensibility of my Internet usage times is less sensitive than the information which concrete webpages I visit, and the latter already leaks. | |||
This is changing core principles ("decentralization") of the Internet, and I don't see a good justification for that. You are basically forcing a proxy on everybody. If we wanted that, we'd all use HTTP proxies already. | |||
-- Ben Bucksch | -- Ben Bucksch | ||
Ben, you're missing the point of this feature. We already have decentralized data pipes: XHR, WebSockets, EventSource. This feature allows web services to "push" notifications to a client without having to worry about whether the client is on- or off-line. It's "store and forward", sort of a one-way micro e-mail (or app-specific SMS?). This feature is more interesting for mobile web apps than browser web sites, and it would be easy to imagine that the default middleman for a B2G device could be the carrier rather than Mozilla (and the carrier already knows where you are). | |||
-- Dan Veditz | -- Dan Veditz | ||
=== Comments from Ryan Schipper === | |||
* From a security viewpoint, the obvious choice to prevent spoofing is digital signatures. However, client-side (in this case the notifying website) developers who aren't familiar with PKI often find it too complex, resulting in a lack of third-party API implementations (see OAuth!). If Mozilla intends to develop, distribute and support the client API themselves, this is less of an issue. If this is not the case, OAuth 2.0 has some non-PKI options. Implementing all of the OAuth 2.0 protocol may be too heavyweight, but it would at least offer some inspiration. | * From a security viewpoint, the obvious choice to prevent spoofing is digital signatures. However, client-side (in this case the notifying website) developers who aren't familiar with PKI often find it too complex, resulting in a lack of third-party API implementations (see OAuth!). If Mozilla intends to develop, distribute and support the client API themselves, this is less of an issue. If this is not the case, OAuth 2.0 has some non-PKI options. Implementing all of the OAuth 2.0 protocol may be too heavyweight, but it would at least offer some inspiration. | ||
* The designers should also consider verifying the integrity and source of notifications received by the browser. | * The designers should also consider verifying the integrity and source of notifications received by the browser. | ||
=== Comments from JR Conlin === | |||
A few extra notes based on some design pushes from outside (notably privacy and federation) | |||
The RequestURL requires an optional (UseEncryption) boolean flag argument to indicate if the notification will be encrypted. If this value is set to "true", the PushURLResult will include a keyBundle object (to be used by the encryption libraries) | |||
The keyBundle would also be returned by the getCurrentURL() result, should it have already been defined. | |||
the request.response object would also optionally contain the following fields: | |||
pushServer: URL for the UserAgent to poll when looking for notifications from a server (this allows for federation to non Mozilla servers) | |||
pushWebsocket: Websocket address for Notifications. | |||
Please note, for domains other than those owned by mozilla, the pushServer and pushWebsocket should be domain constrained much as XHR calls are, for obvious security reasons. | |||
For the server, we'll need to add a "cryptoBlock" argument to Notification POSTs. This argument contains the encrypted replacement values and keybundle for the secure exchange encoded in JSON format. | |||