4 ms·

Safari share menu now violates privacy

46 points by ingve 3y ago

olliej 3y ago
Ok, so people want previews with links, it's been around for a while. Generally at least a page title + favicon, if not the actual summary text. That's a feature that has been supported for years, and while it's interesting that you're only just seeing the "share" link hitting the site now, the behaviour is somewhat required. The alternative to you, the sender, loading the page is the recipient loading the page. As you're the one who has chosen the page to share it seems reasonable that you should be the one taking the "leak the page load to the site" hit, and you send the recipient a nice message packaging up the preview image and text and when they receive it they can choose whether or not to actually contact that server. To answer "why not just reuse the loaded content": the title on the page may have been influenced by JS, specific login, etc and in addition sites may want to serve different content for a preview (maybe a headline image or whatever) and they may require additional queries. For example http://waffles.dog http://waffles.dog includes an image when sent as a message rather than just text saying "It's Waffles!" which is meaningless without context.
- lapcat 3y ago
  There's no preview. There's an icon and a page title, which only appears in the share menu. See the addendum to the blog post: "The only purpose of the HTTP requests in Safari's share menu appears to be to display the link's icon and title in the share menu. Crucially, that information is not passed along to the other apps!" I actually wrote a Mac app with a share extension, by the way (it's in the blog post screenshots), so I do know what I'm talking about: https://underpassapp.com/LinkUnshortener/ https://underpassapp.com/LinkUnshortener/
  - Wowfunhappy 3y ago
    > The only purpose of the HTTP requests in Safari's share menu appears to be to display the link's icon and title in the share menu. Crucially, that information is not passed along to the other apps! But it makes the share menu look nice. That has value.
flashback2199 3y ago
Is there anything like Little Snitch for Linux? GUI based It looks neat
- extraduder_ire 3y ago
  opensnitch has existed for a while now. I've never used it, so I can't comment on how well it works. https://github.com/evilsocket/opensnitch https://github.com/evilsocket/opensnitch
  - flashback2199 3y ago
    Thank you! It's working for me
ThePowerOfFuet 3y ago
>My belief is that a website should not be notified and given your IP address and other information such as hardware device type and web browser version when you share the URL of the website. The user was just on that website, so that was water under the bridge before they even brought up the Share menu. All respect to Jeff, but this is a nothingburger.
- lapcat 3y ago
  > The user was just on that website No, the user was not just on that website. You didn't look at the example closely enough. The contextual menu was on an external link.
  - olliej 3y ago
    When you share links with people, many (most? at this point) include previews. Those previews are performed on the sender side, e.g. the person sharing the link. The "Sharing" view is part of macOS and iOS, not part of the browser - any other browser or app can also use the sharing pane and also be a recipient of the information being shared. If the recipient service/sharing extension needs or supports preview images, then the sharing view produces them, which requires network loads. In this specific case there isn't even a question of "can you use, or is it appropriate to use, safari's local render?" because no such render exists.
    - lapcat 3y ago
      You've repeated your main comment https://news.ycombinator.com/item?id=38028909 https://news.ycombinator.com/item?id=38028909 multiple times in these threads, but you're misinformed. Read my reply to that comment.
- fturst 3y ago
  Website A can link to Website B which you might want to share. You might not want to visit B however, for some arbitrary reason. Plus, it seems like its very easy to track who shares your website on iOS now since only favicons will be requested.
zaxomi 3y ago
It's getting the favicon, and while doing so gives information about the client in the user-agent and the IP-address. How is this different from any other request to a website?
- lapcat 3y ago
  > How is this different from any other request to a website? It's not. Which is the point. The share menu is supposed to just pass a URL from Safari to another app. It's a glorified copy and paste, not a page load.
  - xenonite 3y ago
    Yes, and it therefore should not yield a page load.
    - olliej 3y ago
      Go to your message client, type in a url (say a tweet on twitter) and send it, most clients these days include a preview, and that's the load you're seeing.
      - lapcat 3y ago
        > that's the load you're seeing. It's not. See the addendum to the blog post.
  - olliej 3y ago
    First off, the share menu is an OS feature, not part of Safari. So this isn't Safari doing anything other than sending the URL to the share sheet, and the person has selected to share through a medium that allows previews. When you send a url through the share menu to a share extension that supports previews the share sheet needs to include: the title of page and a preview, and that's what's happening. Scraping the content from the currently open page would require the share sheet to be able to read state from the app triggering the send, or if the API allowed that app (safari in this case) to just include everything the app would need to do to a fresh request from an private context to give the best approximation of what the recipient would get, and so the "re-load of everything" would still be required. Finally, even if the app did want to use the existing page state, people seem to like the open graph meta tags that provide summary text or images which may not have been loaded, so they'd have to be requested instead.
jraph 3y ago
It reminds me of a related favicon issue with the Duck Duck Go Android app. https://portswigger.net/daily-swig/duckduckgo-ceo-clarifies-favicon-script-use-seeks-to-dispel-privacy-worries https://portswigger.net/daily-swig/duckduckgo-ceo-clarifies-...
eyelidlessness 3y ago
I’m sure there are use cases for sharing a link you wouldn’t want to visit yourself… but that seems fairly far on the paranoia spectrum to frame as a general “privacy” concern. Typically people are sharing stuff they have some comfort consuming themselves. Even if they haven’t opened the link yet, the same request would almost definitely be performed once they did so.
- lapcat 3y ago
  I think you're placing the burden of proof on the wrong side. It's up to the software vendor to explain and justify why HTTP requests that are not initiated by the user are necessary and harmless. In this case, they're definitely not necessary, as explained in the Addendum to the blog post, because the fetched info isn't even passed along to the other app when the URL is shared, and of course the share menu worked fine without them for many years before Ventura. The easiest, best, foolproof method of protecting a user's privacy is by not making any connection requests that aren't initiated by the user. That should be the default, unless there's a very good reason why it needs to be otherwise. "Typically..." is cold comfort.
  - eyelidlessness 3y ago
    I’m not placing any burden of proof on anything? I’m saying I don’t have any problem with the privacy implications of my computer making requests to a link I explicitly take action to share with others, and I think objections to it on principle require disregarding the vast majority of legitimate use. If “share” isn’t a sufficiently explicit user interaction to perform a request to the thing being shared, I can think of very few if any reasonable justifications for going through with sharing it either. What is the legitimate use case for “I don’t want to access this network resource but I do want to distribute it to another recipient”?
    - lapcat 3y ago
      > I’m not placing any burden of proof on anything? And yet... > What is the legitimate use case for “I don’t want to access this network resource but I do want to distribute it to another recipient”? Let me ask this question: Do you want the operating system to load the URL every time you simply copy and paste a URL? If not, then how is this case any different? There's some discussion of use cases in another comment: https://news.ycombinator.com/item?id=38031177 https://news.ycombinator.com/item?id=38031177 However, in general, I consider the term "legitimate" to be user-hostile. Who decides which use cases are legitimate or not? We shouldn't need to prove that our usage is "legitimate", by your standard. Some people claim, "You don't need privacy if you have nothing to hide", and that's fundamentally wrongheaded. The right to privacy should be assumed, unless there's a serious, overriding counterpoint.
m463 3y ago
when sharing links using messages I copy/paste use angle brackets: <https://www.example.com> no preview loaded. If you paste in a URL it will automatically load and preview the link.

46 points by ingve 3y ago

Ok, so people want previews with links, it's been around for a while. Generally at least a page title + favicon, if not the actual summary text. That's a feature that has been supported for years, and while it's interesting that you're only just seeing the "share" link hitting the site now, the behaviour is somewhat required. The alternative to you, the sender, loading the page is the recipient loading the page. As you're the one who has chosen the page to share it seems reasonable that you should be the one taking the "leak the page load to the site" hit, and you send the recipient a nice message packaging up the preview image and text and when they receive it they can choose whether or not to actually contact that server. To answer "why not just reuse the loaded content": the title on the page may have been influenced by JS, specific login, etc and in addition sites may want to serve different content for a preview (maybe a headline image or whatever) and they may require additional queries. For example http://waffles.dog http://waffles.dog includes an image when sent as a message rather than just text saying "It's Waffles!" which is meaningless without context.

lapcat 3y ago
There's no preview. There's an icon and a page title, which only appears in the share menu. See the addendum to the blog post: "The only purpose of the HTTP requests in Safari's share menu appears to be to display the link's icon and title in the share menu. Crucially, that information is not passed along to the other apps!" I actually wrote a Mac app with a share extension, by the way (it's in the blog post screenshots), so I do know what I'm talking about: https://underpassapp.com/LinkUnshortener/ https://underpassapp.com/LinkUnshortener/
- Wowfunhappy 3y ago
  > The only purpose of the HTTP requests in Safari's share menu appears to be to display the link's icon and title in the share menu. Crucially, that information is not passed along to the other apps! But it makes the share menu look nice. That has value.

flashback2199 3y ago

Is there anything like Little Snitch for Linux? GUI based It looks neat

extraduder_ire 3y ago
opensnitch has existed for a while now. I've never used it, so I can't comment on how well it works. https://github.com/evilsocket/opensnitch https://github.com/evilsocket/opensnitch
- flashback2199 3y ago
  Thank you! It's working for me

ThePowerOfFuet 3y ago

>My belief is that a website should not be notified and given your IP address and other information such as hardware device type and web browser version when you share the URL of the website. The user was just on that website, so that was water under the bridge before they even brought up the Share menu. All respect to Jeff, but this is a nothingburger.

lapcat 3y ago
> The user was just on that website No, the user was not just on that website. You didn't look at the example closely enough. The contextual menu was on an external link.
- olliej 3y ago
  When you share links with people, many (most? at this point) include previews. Those previews are performed on the sender side, e.g. the person sharing the link. The "Sharing" view is part of macOS and iOS, not part of the browser - any other browser or app can also use the sharing pane and also be a recipient of the information being shared. If the recipient service/sharing extension needs or supports preview images, then the sharing view produces them, which requires network loads. In this specific case there isn't even a question of "can you use, or is it appropriate to use, safari's local render?" because no such render exists.
  - lapcat 3y ago
    You've repeated your main comment https://news.ycombinator.com/item?id=38028909 https://news.ycombinator.com/item?id=38028909 multiple times in these threads, but you're misinformed. Read my reply to that comment.
fturst 3y ago
Website A can link to Website B which you might want to share. You might not want to visit B however, for some arbitrary reason. Plus, it seems like its very easy to track who shares your website on iOS now since only favicons will be requested.

zaxomi 3y ago

It's getting the favicon, and while doing so gives information about the client in the user-agent and the IP-address. How is this different from any other request to a website?

lapcat 3y ago
> How is this different from any other request to a website? It's not. Which is the point. The share menu is supposed to just pass a URL from Safari to another app. It's a glorified copy and paste, not a page load.
- xenonite 3y ago
  Yes, and it therefore should not yield a page load.
  - olliej 3y ago
    Go to your message client, type in a url (say a tweet on twitter) and send it, most clients these days include a preview, and that's the load you're seeing.
    - lapcat 3y ago
      > that's the load you're seeing. It's not. See the addendum to the blog post.
- olliej 3y ago
  First off, the share menu is an OS feature, not part of Safari. So this isn't Safari doing anything other than sending the URL to the share sheet, and the person has selected to share through a medium that allows previews. When you send a url through the share menu to a share extension that supports previews the share sheet needs to include: the title of page and a preview, and that's what's happening. Scraping the content from the currently open page would require the share sheet to be able to read state from the app triggering the send, or if the API allowed that app (safari in this case) to just include everything the app would need to do to a fresh request from an private context to give the best approximation of what the recipient would get, and so the "re-load of everything" would still be required. Finally, even if the app did want to use the existing page state, people seem to like the open graph meta tags that provide summary text or images which may not have been loaded, so they'd have to be requested instead.

jraph 3y ago

It reminds me of a related favicon issue with the Duck Duck Go Android app. https://portswigger.net/daily-swig/duckduckgo-ceo-clarifies-favicon-script-use-seeks-to-dispel-privacy-worries https://portswigger.net/daily-swig/duckduckgo-ceo-clarifies-...

eyelidlessness 3y ago

I’m sure there are use cases for sharing a link you wouldn’t want to visit yourself… but that seems fairly far on the paranoia spectrum to frame as a general “privacy” concern. Typically people are sharing stuff they have some comfort consuming themselves. Even if they haven’t opened the link yet, the same request would almost definitely be performed once they did so.

lapcat 3y ago
I think you're placing the burden of proof on the wrong side. It's up to the software vendor to explain and justify why HTTP requests that are not initiated by the user are necessary and harmless. In this case, they're definitely not necessary, as explained in the Addendum to the blog post, because the fetched info isn't even passed along to the other app when the URL is shared, and of course the share menu worked fine without them for many years before Ventura. The easiest, best, foolproof method of protecting a user's privacy is by not making any connection requests that aren't initiated by the user. That should be the default, unless there's a very good reason why it needs to be otherwise. "Typically..." is cold comfort.
- eyelidlessness 3y ago
  I’m not placing any burden of proof on anything? I’m saying I don’t have any problem with the privacy implications of my computer making requests to a link I explicitly take action to share with others, and I think objections to it on principle require disregarding the vast majority of legitimate use. If “share” isn’t a sufficiently explicit user interaction to perform a request to the thing being shared, I can think of very few if any reasonable justifications for going through with sharing it either. What is the legitimate use case for “I don’t want to access this network resource but I do want to distribute it to another recipient”?
  - lapcat 3y ago
    > I’m not placing any burden of proof on anything? And yet... > What is the legitimate use case for “I don’t want to access this network resource but I do want to distribute it to another recipient”? Let me ask this question: Do you want the operating system to load the URL every time you simply copy and paste a URL? If not, then how is this case any different? There's some discussion of use cases in another comment: https://news.ycombinator.com/item?id=38031177 https://news.ycombinator.com/item?id=38031177 However, in general, I consider the term "legitimate" to be user-hostile. Who decides which use cases are legitimate or not? We shouldn't need to prove that our usage is "legitimate", by your standard. Some people claim, "You don't need privacy if you have nothing to hide", and that's fundamentally wrongheaded. The right to privacy should be assumed, unless there's a serious, overriding counterpoint.

m463 3y ago

when sharing links using messages I copy/paste use angle brackets: <https://www.example.com> no preview loaded. If you paste in a URL it will automatically load and preview the link.