Google's insistence on using security as an excuse to remove functionality that they want to keep exclusive to their products is so blatant it either is or should be illegal.<p>No local access kills Google Cast competitors as well as things like this (Nearby Share competitor), Android SMS limitations nearly killed most Android Messenger competitors, removing clipboard access forced people to use one of 2 decent Android keyboards to get clipboard sync back (one of which is conveniently enough developed by Google)...<p>I have not seen one single instance of Google killing some functionality for security that wouldn't have been easily implemented with permissions instead and that wasn't clearly designed to stomp out competition.
The Google Chrome change looks like the most significant of the two factors that caused Portal to shut down, although it's a shame that they didn't continue running the service for users of other browsers. (Android file transfer apps that implement scoped storage have similar functionality as before if users grant them access to the entire "sdcard" directory.)<p>Here are some FOSS alternatives to Portal that don't depend on Chrome:<p>- ShareDrop (<a href="https://www.sharedrop.io" rel="nofollow">https://www.sharedrop.io</a>): WebRTC-based P2P file transfers through the browser<p>- Sharik (<a href="https://github.com/marchellodev/sharik" rel="nofollow">https://github.com/marchellodev/sharik</a>): File transfers via Wi-Fi or mobile hotspot for Android, iOS, Linux, and Windows<p>- KDE Connect (<a href="https://kdeconnect.kde.org" rel="nofollow">https://kdeconnect.kde.org</a>): File transfers, notification sync, and other integrations between Android, Linux, Windows, and SailfishOS. Other compatible clients: Soduto for macOS (<a href="https://soduto.com" rel="nofollow">https://soduto.com</a>), GSConnect for GNOME (<a href="https://extensions.gnome.org/extension/1319/gsconnect/" rel="nofollow">https://extensions.gnome.org/extension/1319/gsconnect/</a>)<p>- Syncthing (<a href="https://syncthing.net" rel="nofollow">https://syncthing.net</a>): Continuous P2P file syncing for Android, Linux, macOS, Windows, and BSD<p>- Wormhole (<a href="https://wormhole.app" rel="nofollow">https://wormhole.app</a>): File sharing from the browser through encrypted uploads that expire after a set amount of time or number of downloads
It's not clear to me that these changes make an app like this impossible. There would be a lot of implementation churn, and maybe some user visible differences, but I think the main issue here is they don't want to spend the time to rewrite the app, and maybe there's some fear of future changes breaking it again. Which is totally fair, churn sucks. But on the other hand there are real, serious security issues motivating these changes that should not be minimized.
> Starting with Chrome 94, Chrome no longer allows HTTP requests to local IP addresses. Since Portal worked by accessing a local server running on your phone to do all file transfers locally over WiFi, this means Portal no longer works for anyone using Chrome. Since Chrome and Chromium variants have overwhelming browser dominance, this means Portal will soon no longer work for the vast majority of people.<p>The linked post (<a href="https://developer.chrome.com/blog/private-network-access-update/#accessing-localhost" rel="nofollow">https://developer.chrome.com/blog/private-network-access-upd...</a>) says "If your website needs to issue requests to localhost, then you just need to upgrade your website to HTTPS". Also, I just tested a Chrome extension on Chrome 94 and it has no problem sending a fetch API request to <a href="http://localhost" rel="nofollow">http://localhost</a> so maybe that's an option too?<p>Am I missing something?
Does anyone know an app like Portal/Pushbullet which also works on iOS? I'm hanging between the ecosystems and file sending like this would be great.
It seems that the linked chromium change mostly mentions CORS from plaintext unsecured HTTP to local addresses. Why would this thing rely on <i>that</i>?