8 ms·

Closing The Portal App

125 points by DarkCrusader2 5y ago

deleted 5y ago
[deleted]
DeathArrow 5y ago
Android and Google apps are becoming more and more locked down. Google still has the "don't do evil" motto?
- wetpaws 5y ago
  > Google still has the "don't do evil" motto? It ditched it quite a while ago.
  - input_sh 5y ago
    No, every single article that said that has always been inaccurate. It used to be in the first and last sentence of its code of conduct (https://abc.xyz/investor/other/google-code-of-conduct/ https://abc.xyz/investor/other/google-code-of-conduct/). They've removed it from the preface, but it's still in the last sentence.
    - atatatat 5y ago
      Reprioritised.
- square_usual 5y ago
  These are reasonable security measures, but it does bother me that there's no way around them. I don't use android (or Chrome) so I don't know, but could anyone more knowledgable about these moves chime in about whether it's possible to circumvent them with user permission?
  - red_trumpet 5y ago
    > Starting with Chrome 94, Chrome no longer allows HTTP requests to local IP addresses. What kind of scenario does that prevent?
    - jand 5y ago
      Enumeration and more - as far as i understood. My evil website can no longer access the top secret stuff you are developing on localhost. My evil website can no longer enumerate the http servers in your local LAN.
      - franga2000 5y ago
        "This website would like to scan your local network and communicate with other devices" "Allow Once/Deny/Block"
        wildrhythms 5y ago
        Well maybe I want to grant the site access to a particular internal IP without the ability to send requests everywhere... at what point would Chrome just have its own separate firewall?
        franga2000 5y ago
        The modern browser is already an operating system by all definitions I know so yes, it might as well have a firewall. But that isn't very elegant, so I propose version 2.0: "This site has requested communication with a local device. Please select it from this list:" [the user is presented with a list of devices discovered by zeroconf/dns-sd/mdns/upnp matching the service descriptor given by the page] Turns out, this was an actual spec [0] pushed by Opera of all companies. Here's a quote from the spec: > window . navigator . getNetworkServices ( type , successCallback [, errorCallback ] ) > > Prompts the user to select discovered network services that have advertised support for the requested service type. > > The type argument contains one or more valid service type tokens that the web page would like to interact with. > > If the user accepts, the successCallback is invoked, with zero or more NetworkService objects as its argument. > > If the user declines, the errorCallback (if any) is invoked. [0] https://www.w3.org/TR/2012/WD-discovery-api-20121004/ https://www.w3.org/TR/2012/WD-discovery-api-20121004/
- syntheticnature 5y ago
  Note that it was always "Don't be evil", rather than "Don't do evil." A lot of evil is done by people believing themselves good the whole time.
franga2000 5y ago
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. 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)... 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.
- deleted 5y ago
  [deleted]
- Thorrez 5y ago
  >No local access Local access itself isn't killed, there are still some ways to do it. This Chrome post lists a number of options. I think the WebTransport and Reverse embedding options would both work for Portal. https://developer.chrome.com/blog/private-network-access-update/ https://developer.chrome.com/blog/private-network-access-upd... Full disclosure I work at Google, but not on Chrome or any of the other products you mentioned.
  - DonHopkins 5y ago
    Any word on how long until the remaining ways to do it are removed? All Google APIs should include a call that tells you how long until the API stops working.
    - smoyer 5y ago
      Remember when all the Google products had a beta label on them (except search)? ... when you're designing software that interacts with Google, always imagine it has a beta tag and plan on what you'd do if the beta was abandoned. I personally miss what Wave could have been (better than Slack) and think the trajectory of GWT could have been dramatically better if Google had remained the primary developer. I'm now devoid of Google dependencies with one exception - the Go UUID library. Other implementations exist and it would be trivial to wrap one.
commoner 5y ago
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.) Here are some FOSS alternatives to Portal that don't depend on Chrome: - ShareDrop (https://www.sharedrop.io https://www.sharedrop.io): WebRTC-based P2P file transfers through the browser - Sharik (https://github.com/marchellodev/sharik https://github.com/marchellodev/sharik): File transfers via Wi-Fi or mobile hotspot for Android, iOS, Linux, and Windows - KDE Connect (https://kdeconnect.kde.org https://kdeconnect.kde.org): File transfers, notification sync, and other integrations between Android, Linux, Windows, and SailfishOS. Other compatible clients: Soduto for macOS (https://soduto.com https://soduto.com), GSConnect for GNOME (https://extensions.gnome.org/extension/1319/gsconnect/ https://extensions.gnome.org/extension/1319/gsconnect/) - Syncthing (https://syncthing.net https://syncthing.net): Continuous P2P file syncing for Android, Linux, macOS, Windows, and BSD - Wormhole (https://wormhole.app https://wormhole.app): File sharing from the browser through encrypted uploads that expire after a set amount of time or number of downloads
- batrat 5y ago
  And Snapdrop (https://snapdrop.net https://snapdrop.net)
  - commoner 5y ago
    Snapdrop has the edge over ShareDrop since its server can optionally be self-hosted using Docker and it doesn't depend on Firebase. I confuse Snapdrop with ShareDrop sometimes.
- genewitch 5y ago
  I use syncthing but not as peer to peer, but as client-server-client. My phone takes images so large - 108MP - that my normal service (an instance of Up1 pastebin) hangs on complex scenes while encrypting in android Chrome. Installed syncthing on a VM I already had with public facing httpd and I can just hit "share to syncthing". The linking part isn't automated, I type it by hand then copy and paste to recipients. I looked around for another way to do this, including ssh, and syncthing fit the bill and has been running fine for about 2 years. I have no idea what it's doing on the backend, though, and now I am wondering if my "node" is passing traffic for people who are not me... I still prefer my pastebin service, even if it won't accept the largest images from my phone, because you can zoom forever, for some reason, whereas windows viewer, syncthing direct jpeg mime type, etc, will not actually let you zoom 1:1 or beyond on 108 megapixel images. This also ignores the fact that my pastebin only has 200MB of tmpfs storage available, so perhaps 2 crazy images before I have to reboot it... Still worth the zooming, though.
ghostly_s 5y ago
Was expecting this to be about the Pushbullet app since its become mostly broken for me in the past months.
yccs27 5y ago
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.
- izerik 5y ago
  https://snapdrop.net https://snapdrop.net - it's like Apples AirDrop
  - syncbehind 5y ago
    It really isn't.
modeless 5y ago
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.
- yarcob 5y ago
  Google, Apple and Microsoft have been making a lot of security-related changes in the OSes in the last few years. The result is that a lot of apps need updating or just no longer work. It's not an issue for apps that are actively developed -- but it's devastating for side projects or open source apps that rely on volunteers. Some changes (like new code signing requirements) might be possible to implement in a few days, but if you need to make bigger changes you are quickly looking at weeks of development time -- which is kinda hard sell for people who develop software in their free time.
  - Noumenon72 5y ago
    It's really killing my enthusiasm for mobile phones that all my old apps are stopping working. My sleep alarm and Tasker screen blocker fell prey to permissions/battery saving issues, and Swype and a few others shut down.
- xeromal 5y ago
  That's the impression I got from their post. It was a passion project (meaning goodwill, costs more than it makes) that Google has forced them to rewrite and it's not going to happen because passion projects can only cost so much of the budget.
floatboth 5y ago
It seems that the linked chromium change mostly mentions CORS from plaintext unsecured HTTP to local addresses. Why would this thing rely on that?
seanwilson 5y ago
> 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. The linked post (https://developer.chrome.com/blog/private-network-access-update/#accessing-localhost https://developer.chrome.com/blog/private-network-access-upd...) 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 http://localhost http://localhost so maybe that's an option too? Am I missing something?
- kevingadd 5y ago
  "local ip address", not localhost. They're doing file sharing on the local network. This also means that the common 'install a custom root for localhost' https trick won't work because it's machine-to-machine communication - https everywhere specifically stops machines from communicating locally. You could probably hack it with a relay server but at that point, why bother?

125 points by DarkCrusader2 5y ago

deleted 5y ago

[deleted]

DeathArrow 5y ago

Android and Google apps are becoming more and more locked down. Google still has the "don't do evil" motto?

wetpaws 5y ago
> Google still has the "don't do evil" motto? It ditched it quite a while ago.
- input_sh 5y ago
  No, every single article that said that has always been inaccurate. It used to be in the first and last sentence of its code of conduct (https://abc.xyz/investor/other/google-code-of-conduct/ https://abc.xyz/investor/other/google-code-of-conduct/). They've removed it from the preface, but it's still in the last sentence.
  - atatatat 5y ago
    Reprioritised.
square_usual 5y ago
These are reasonable security measures, but it does bother me that there's no way around them. I don't use android (or Chrome) so I don't know, but could anyone more knowledgable about these moves chime in about whether it's possible to circumvent them with user permission?
- red_trumpet 5y ago
  > Starting with Chrome 94, Chrome no longer allows HTTP requests to local IP addresses. What kind of scenario does that prevent?
  - jand 5y ago
    Enumeration and more - as far as i understood. My evil website can no longer access the top secret stuff you are developing on localhost. My evil website can no longer enumerate the http servers in your local LAN.
    - franga2000 5y ago
      "This website would like to scan your local network and communicate with other devices" "Allow Once/Deny/Block"
      - wildrhythms 5y ago
        Well maybe I want to grant the site access to a particular internal IP without the ability to send requests everywhere... at what point would Chrome just have its own separate firewall?
        franga2000 5y ago
        The modern browser is already an operating system by all definitions I know so yes, it might as well have a firewall. But that isn't very elegant, so I propose version 2.0: "This site has requested communication with a local device. Please select it from this list:" [the user is presented with a list of devices discovered by zeroconf/dns-sd/mdns/upnp matching the service descriptor given by the page] Turns out, this was an actual spec [0] pushed by Opera of all companies. Here's a quote from the spec: > window . navigator . getNetworkServices ( type , successCallback [, errorCallback ] ) > > Prompts the user to select discovered network services that have advertised support for the requested service type. > > The type argument contains one or more valid service type tokens that the web page would like to interact with. > > If the user accepts, the successCallback is invoked, with zero or more NetworkService objects as its argument. > > If the user declines, the errorCallback (if any) is invoked. [0] https://www.w3.org/TR/2012/WD-discovery-api-20121004/ https://www.w3.org/TR/2012/WD-discovery-api-20121004/
syntheticnature 5y ago
Note that it was always "Don't be evil", rather than "Don't do evil." A lot of evil is done by people believing themselves good the whole time.

franga2000 5y ago

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. 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)... 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.

deleted 5y ago
[deleted]
Thorrez 5y ago
>No local access Local access itself isn't killed, there are still some ways to do it. This Chrome post lists a number of options. I think the WebTransport and Reverse embedding options would both work for Portal. https://developer.chrome.com/blog/private-network-access-update/ https://developer.chrome.com/blog/private-network-access-upd... Full disclosure I work at Google, but not on Chrome or any of the other products you mentioned.
- DonHopkins 5y ago
  Any word on how long until the remaining ways to do it are removed? All Google APIs should include a call that tells you how long until the API stops working.
  - smoyer 5y ago
    Remember when all the Google products had a beta label on them (except search)? ... when you're designing software that interacts with Google, always imagine it has a beta tag and plan on what you'd do if the beta was abandoned. I personally miss what Wave could have been (better than Slack) and think the trajectory of GWT could have been dramatically better if Google had remained the primary developer. I'm now devoid of Google dependencies with one exception - the Go UUID library. Other implementations exist and it would be trivial to wrap one.

commoner 5y ago

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.) Here are some FOSS alternatives to Portal that don't depend on Chrome: - ShareDrop (https://www.sharedrop.io https://www.sharedrop.io): WebRTC-based P2P file transfers through the browser - Sharik (https://github.com/marchellodev/sharik https://github.com/marchellodev/sharik): File transfers via Wi-Fi or mobile hotspot for Android, iOS, Linux, and Windows - KDE Connect (https://kdeconnect.kde.org https://kdeconnect.kde.org): File transfers, notification sync, and other integrations between Android, Linux, Windows, and SailfishOS. Other compatible clients: Soduto for macOS (https://soduto.com https://soduto.com), GSConnect for GNOME (https://extensions.gnome.org/extension/1319/gsconnect/ https://extensions.gnome.org/extension/1319/gsconnect/) - Syncthing (https://syncthing.net https://syncthing.net): Continuous P2P file syncing for Android, Linux, macOS, Windows, and BSD - Wormhole (https://wormhole.app https://wormhole.app): File sharing from the browser through encrypted uploads that expire after a set amount of time or number of downloads

batrat 5y ago
And Snapdrop (https://snapdrop.net https://snapdrop.net)
- commoner 5y ago
  Snapdrop has the edge over ShareDrop since its server can optionally be self-hosted using Docker and it doesn't depend on Firebase. I confuse Snapdrop with ShareDrop sometimes.
genewitch 5y ago
I use syncthing but not as peer to peer, but as client-server-client. My phone takes images so large - 108MP - that my normal service (an instance of Up1 pastebin) hangs on complex scenes while encrypting in android Chrome. Installed syncthing on a VM I already had with public facing httpd and I can just hit "share to syncthing". The linking part isn't automated, I type it by hand then copy and paste to recipients. I looked around for another way to do this, including ssh, and syncthing fit the bill and has been running fine for about 2 years. I have no idea what it's doing on the backend, though, and now I am wondering if my "node" is passing traffic for people who are not me... I still prefer my pastebin service, even if it won't accept the largest images from my phone, because you can zoom forever, for some reason, whereas windows viewer, syncthing direct jpeg mime type, etc, will not actually let you zoom 1:1 or beyond on 108 megapixel images. This also ignores the fact that my pastebin only has 200MB of tmpfs storage available, so perhaps 2 crazy images before I have to reboot it... Still worth the zooming, though.

ghostly_s 5y ago

Was expecting this to be about the Pushbullet app since its become mostly broken for me in the past months.

yccs27 5y ago

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.

izerik 5y ago
https://snapdrop.net https://snapdrop.net - it's like Apples AirDrop
- syncbehind 5y ago
  It really isn't.

modeless 5y ago

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.

yarcob 5y ago
Google, Apple and Microsoft have been making a lot of security-related changes in the OSes in the last few years. The result is that a lot of apps need updating or just no longer work. It's not an issue for apps that are actively developed -- but it's devastating for side projects or open source apps that rely on volunteers. Some changes (like new code signing requirements) might be possible to implement in a few days, but if you need to make bigger changes you are quickly looking at weeks of development time -- which is kinda hard sell for people who develop software in their free time.
- Noumenon72 5y ago
  It's really killing my enthusiasm for mobile phones that all my old apps are stopping working. My sleep alarm and Tasker screen blocker fell prey to permissions/battery saving issues, and Swype and a few others shut down.
xeromal 5y ago
That's the impression I got from their post. It was a passion project (meaning goodwill, costs more than it makes) that Google has forced them to rewrite and it's not going to happen because passion projects can only cost so much of the budget.

floatboth 5y ago

It seems that the linked chromium change mostly mentions CORS from plaintext unsecured HTTP to local addresses. Why would this thing rely on that?

seanwilson 5y ago

> 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. The linked post (https://developer.chrome.com/blog/private-network-access-update/#accessing-localhost https://developer.chrome.com/blog/private-network-access-upd...) 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 http://localhost http://localhost so maybe that's an option too? Am I missing something?

kevingadd 5y ago
"local ip address", not localhost. They're doing file sharing on the local network. This also means that the common 'install a custom root for localhost' https trick won't work because it's machine-to-machine communication - https everywhere specifically stops machines from communicating locally. You could probably hack it with a relay server but at that point, why bother?