Looks like Push notifications are finally usable for web-apps! Unfortunately, this requires https for ServiceWorker, which not all sites may have.
One thing I noticed in the spec it mentions:
if r's url's scheme is not one of "http" and "https", then:
Throw a TypeError."
So I'm confused - can the site be http, as long as it includes a serviceworker that is from https? For example, mydomain.com could include an https serviceworker from https://anotherdomain.com?
Another standard, web-api simple-push, doesn't mention requiring https (likely an omission in the documentation?), and "The user experience on Firefox Desktop has not been drawn out yet". Is the documentation on this outdated, or is push really only supported in FirefoxOS??
Simple-push, that is the current push solution in Firefox OS doesn't have anything to do with ServiceWorkers.
The next generation of push, implemented by both Google and Mozilla will be done through ServiceWorkers:
Push API spec
In that case yes, your content will need to be served over HTTPS.
Probably you will be interested in the LetsEncrypt initiative:
letsencrypt.org
A new certification authority that will help developers to transition their content over HTTPS.
Also just for development purposes, both Google and Mozilla implementations of ServiceWorkers allow you to bypass the check of the secure content, if you develop against localhost.
In the case of Mozilla you will need to enable the flag:
devtools.serviceWorkers.testing.enabled: true
But again this will be just for development, and AFAIK, Mozilla push landed or is about to land, and will be available in the nightly builds, you can follow the work here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1038811
No, the new generation of push notifications (i.e. Push API) requires HTTPS.
If you need to add push notifications to a website without HTTPS you can use a third-party service like Pushpad (I am the founder) that delivers notifications on your behalf.
The text you cited from the spec is from the Cache.addAll() section (5.4).
Here's the summary of addAll() on MDN:
The addAll() method of the Cache interface takes an array of URLS, retrieves them, and adds the resulting response objects to the given cache. The request objects created during retrieval become keys to the stored response operations.
Service workers can request & cache URLs that are either HTTP or HTTPS, but a Service Worker itself can only work in its registered Scope (which must be HTTPS).
simple-push is not related to Service Workers; it seems comparable to the approaches other platforms have taken:
Apple Push Notifications
Google Cloud Messaging
I found a nice bypass workaround to allow notifications from websites and domains without SSL, hence http:// and not https:// for Firefox.
Firefox holds a file inside the Mozilla directory called permissions.sqlite which is a sqlite database file that holds the permissions for domains. You can add your domain there http://yourdomainname with permissions for notifications and it will work.
I have created a demonstration for Windows here https://gist.github.com/caviv/8df5fa11a98e0e33557f75215f691d54 in golang
Related
We have an in-house (.Net) application that runs on our corporate desktops. It runs a small web server listening on for HTTP requests on a specific port on localhost. We have a separate HTTPS website that communicates with this application by setting the ImageUrl of a hidden image to the URL of the - this invokes an HTTP request to localhost, which the application picks up on and actions. For example, the site will set the URL of the image to:
http://127.0.0.1:5000/?command=dostuff
This was to work around any kind of "mixed content" messages from the site, as images seemed to be exempt from mixed-content rules. A bit of a hack but it worked well.
I'd seen that Chrome was making moves towards completely blocking mixed content on pages, and sure enough Chrome 87 (currently on the beta channel) now shows these warnings in the Console:
Mixed Content: The page at 'https://oursite.company.com/' was loaded
over HTTPS, but requested an insecure element
'http://127.0.0.1:5000/?command=dostuff'. This request was
automatically upgraded to HTTPS, For more information see
https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html
However, despite the warning saying the request is being automatically upgraded, it hasn't been - the application still gets a plain HTTP request and continues to work normally.
I can't find any clear guidance on whether this warning is a "soft fail", and whether future versions of Chrome will enforce the auto-upgrade to HTTPS (which would break things). We have plans to replace the application in the longer term, but I'd like to be ahead of anything that will suddenly stop the application from working before then.
Will using HTTP to localhost for images and other mixed content, as used in the scenario above, be an actual issue in the future?
This answer will focus on your main question: Will using HTTP to localhost for images and other mixed content, as used in the scenario above, be an actual issue in the future?
The answer is yes.
The blog post you linked to says:
Update (April 6, 2020): Mixed image autoupgrading was originally scheduled for Chrome 81, but will be delayed until at least Chrome 84. Check the Chrome Platform Status entry for the latest information about when mixed images will be autoupgraded and blocked if they fail to load over https://.
That status entry says:
In developer trial (Behind a flag) (tracking bug) in:
Chrome for desktop release 86
Chrome for Android release 86
Android WebView release 86
…
Last updated on 2020-11-03
So this feature has been delayed, but it is coming.
Going through your question and all comments - and putting myself in your shoes, I would do the following:
Not messing with either the currently working .Net app/localhost server (HTTP), nor the user-facing (HTTPS) front-end.
Write a simple/cheap cloud function (GCP Cloud Function or AWS Lambda) to completely abstract away your .Net app from the front-end. Your current HTTPS app would only call the cloud function (HTTPS to HTTPS - not having to pray anymore that Google will not shut-down mixed traffic, which will happen eventually, although nobody knows when).
The cloud function would simply temporarily copy the image/data coming from the (insecure) .Net app to cloud storage and then serve it straight away through HTTPS to your client-side.
Almost all useful extensions require permission to access and modify all data on a page.
We can't be sure that a chrome extension is malicious in the sense if it's leaking my data or not.
I realise that many extensions which I use for example the great suspender, even though it needs access to all site data, it doesn't need to communicate with outside world.
Is there a way to block specific chrome extensions from making any network requests at all. ( can we block all outgoing/incoming traffic to a chrome extension. )
I can't keep monitoring a extension 24/7 to see when is it leaking data, For all you know it could be leaking once a month.
No, there's no way to block just the network communication of an extension without blocking its site access (aka "host permissions") entirely. That's because a malicious extension can open a tab with its controlling site (or a hidden iframe in the background script) and insert js code as a standard DOM script which the browser will attribute to the page itself so it'll be able to communicate with the site's domain to upload the exfiltrated data.
So, what you can do practically is to protect the most sensitive sites you use from all extensions by adding a local ExtensionSettings policy with runtime_blocked_hosts that contains that site(s). This will prevent all extensions from accessing the entire site either via content scripts or network requests. Example: {"*": {"runtime_blocked_hosts": ["*://lastpass.com"]}}. And if you have an extension you trust then you can relax this rule for that extension by using runtime_allowed_hosts. See the policy link above for more examples.
I have a browser extension which POSTs to a server. I want to whitelist the extension's origin in my server. For instance, requests for the Chrome extension originate from a location like: chrome-extension://fjhbdidbplpijoncnlfoadfadfasdf and from Firefox like: moz-extension://cadf4351-e4f3-ca4d-b974-812309843dafd
I realize that I can whitelist those particular addresses on my server, but I'm not sure if they're static addresses. Do these randomly generated locations ever change, like if I ever submit an update? Is there anyway to set them permanently?
Do those change?
Situation differs for Chrome and Firefox.
Chrome
For released extensions that are on the Web Store, the ID is fixed. You can rely on it.
For unpacked extensions in development, the ID is determined either by the "key" value in the manifest, if present, or the absolute path to the extension folder. So it may change if you move the extension about. But you can "pin" it by providing a valid "key".
Firefox
What you see in Mozilla is an installation-specific origin. No matter what the extension's ID is, the UUID you see here will differ on each extension install (but should persist through updates).
There's some discussion of the mechanism in this bug.
Essentially, this is an anti-extension-blocking technique.
This means you can't whitelist just one origin and be done with it, unfortunately.
Is it a good idea to rely on this?
Probably not. While browsers tend to report Origin faithfully, other tools capable of generating requests don't follow that. So it would be relatively easy to spoof.
I'd like to set up Web Push notifications on my progressive web application (PWA) using Service Workers. But I'm having trouble understanding the role of third-party services like Google Cloud Messaging and Amazon SNS, and if I need them at all.
From what I understand, when the user clicks the Allow notifications button, you get a unique subscription endpoint. Then in your backend, you can use this endpoint to send notifications to that specific user.
However, all back end libraries that I've found (like pywebpush or web-push for Node.js), mention that you need a GCM API key in order to send notifications.
But here is what the MDN Push API documentation says:
Chrome versions earlier than 52 require you to set up a project on
Google Cloud Messaging to send push messages [...]
So I'm assuming that the new versions of Chrome (version 58 today) should be able to display notifications without the help of a third party.
Here is an example of what I want to achieve. I'm just not sure of what they do in the backend.
Note: I'm not trying to send native push notifications to Android or iOS devices, but only to my progressive web application on Chrome using the Web Push API.
The Browser Push Service
As I have explained in another answer, in order to send web push notifications, you need to interact with the browser push service. Basically each browser, when the user allows push notifications, returns an endpoint (URL) that is specific for its own push service.
For example:
Chrome and Opera endpoints start with prefix https://fcm.googleapis.com/, because they use FCM (ex GCM)
Firefox endpoints start with prefix https://updates.push.services.mozilla.com/, because Firefox uses Mozilla autopush
So notifications will always pass through FCM and autopush, there's no alternative: the push service is hardcoded inside the browser.
Web Push Notification Services as a layer of abstraction
There is also another kind of web push services. Their aim is to provide a layer of abstraction and additional features over the browser push service. For example Pushpad is one of them (I am the founder).
Instead of interacting directly with the different browser push services (e.g. FCM, autopush), your web app can interact just with one push service (e.g. Pushpad), which then interacts with the browser push services for you (automating many tasks, like VAPID and providing additional features like monitoring and integrations).
Confusion about FCM
FCM is quite confusing because it acts both as a "browser push service" for Chrome and Opera, but it also acts as a general "web push notification service" for other browsers. So for Firefox for example, FCM acts as a proxy towards Mozilla autopush.
Could a chrome extension be made that maintains a bitcoin wallet while also making it easy for web stores to integrate a one-click purchase experience.
Suppose a button on a webpage is clicked. Is it possible for that to trigger a function call to the chrome extension to send bitcoins?
Obviously letting webpages unlimited access to chrome extensions would never have been designed. But is there some way to make this work securely?
Chrome extensions can insert arbitrary code into web pages (content scripts).
Content scripts are JavaScript files that run in the context of web
pages. By using the standard Document Object Model (DOM), they can
read details of the web pages the browser visits, or make changes to
them.
This code can communicate with the original web page via the DOM and with the rest of the extension via message passing.
In theory, this should suffice. But make it secure, please.
Multibit provides an external application solution
Clicking on a "bitcoin:" protocol URI in Chrome (or any other browser) will transfer the URI over to MultiBit (v0.3+), starting the application if necessary. This approach removes the need for private keys to be held (and potentially shared) within the browser.
This is very dangerous because a single security hole in Chrome could allow any website to empty your wallet.
First, any payment have to be confirmed with the wallet password. But, as that password is typed inside Chrome itself, it might be possible for an attacker to read that password.
In fact, there are so many security issues to solve that I think it's better to let the bitcoin client do that job.
What should be done is a way for any software to ask the bitcoin client for a transaction. The first idea that comes to mind is using DBus.
That way, the Chrome extension would only have to transform any bitcoin address by a button which calls a DBus method.
The blockchain.info Bitcoin Wallet provides some support for this
by using navigator.registerProtocolHandler and Bitcoin URI's. Unfortunately it only works in firefox at present.