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 includes an image when sent as a message rather than just text saying "It's Waffles!" which is meaningless without context.
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/
> 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.
>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.
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.
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.
Websites can contain links to other websites. But, even for links to the same website, the user agent and unique combination of requests is enough to identify this as use of the share menu and track which users/IPs/whatever shared links to your website.
Say I was in a web chatroom using SSL and someone posted a link to a piracy site. I right click and want to share it. Previously only the chatroom administrator could have known that my IP saw that link. But now, my ISP or anyone sniffing packets on the network would be able to see that I inadvertently accessed the URL. Regardless of whether or not I did anything else on the website, I could possibly get into trouble for simply requesting content from it.
Maybe instead it's a link to a site that sells abortion pills and I'm a pregnant woman under a government that forbids them. I share it with someone else but don't access it myself. Maybe I have a miscarriage and the government suspects it's actually an abortion. They get a warrant for ISP records and now there's proof I accessed a site selling abortion pills despite never actually going to the website.
Or maybe it's a link to an IP stealer. Someone asks you to share it with someone else. You don't click the link but they still grab your IP anyway when you go to share it.
I can think of numerous other examples of how a compromising URL could expose your activities even if you didn't actually click on the link. I don't really see a need for downloading a preview favicon. It just exposes you for no reason and could provide just another possible attack vector
If the site uses HTTPS and you're using DoS then this is not an issue. If you're extremely worried about this sort of things (which are bizarrely unlikely scenarios in first place) then you're already playing with fire by browsing the internet or going anywhere near these sites in general, because it's really not that hard to accidentally end up on these type of things (load wrong page, mis-click, whatever).
> 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.
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.
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.
> 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.
Says who?
It's used to show the icon and page title. That seems useful.
I think your expectations are unrealistic. If it's somehow extremely critical you don't actually make any requests to this URL then you're already playing with fire here, as it's not too hard to accidentally click the wrong mouse button or whatnot.
> It's used to show the icon and page title. That seems useful.
How so? Please explain how the iana.org icon in the blog post screenshot is useful.
Moreover, as the Addendum explains, that information is not even passed along to the other app when the URL is shared. It only appears in the share menu but ironically doesn't get shared.
Yes, I read that; in the screenshot it shows the icon and title of the page you're about to share. That seems useful. You may personally not find that useful, but clearly people do.
> You may personally not find that useful, but clearly people do.
How is that clear? I understand that someone inside Apple decided this was a good idea, perhaps for aesthetic reasons, but that's not the same as being clearly useful to people.
I agree that GP is kind of misusing the word "useful", but I do think you're missing the point. People like using aesthetically-pleasing software; improving aesthetics adds "value" if perhaps not "usefulness".
Except the new Ventura-style share sheet is ugly as hell, and it's oddly detached from the contextual menu. I critiqued the UI of the new share sheet in a previous blog post, linked at the beginning of this one.
It seems to be yet another example of Apple bringing iOS UI to macOS.
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.
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.
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”?
> 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 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.
> Do you want the operating system to load the URL every time you simply copy and paste a URL?
Honestly, I wouldn't mind at all. Link previews are becoming super common everywhere in the OS and apps. If somebody texts me a URL, it shows up as a link preview. Certain websites show link previews when you hover over a link. Not to mention browsers precache tons of URLs you never explicitly visit.
Visiting copied URL's to generate link previews, even if I never use the clipboard viewer to see it, seems entirely in line with expected behavior of using URLs in an OS. The last thing I need is a complicated mental model of which OS behaviors will load URL previews and which won't. Easier to just assume they all will.
So yes, if I'm dealing with a URL in any GUI context, I expect it might be accessed at any time for preview/precache purposes. If it's vitally important that it not be, I'll disconnect from the internet entirely.
> 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?
No, and here I think there is some burden of proof to suggest that they’re the same. Copying a URL does not imply that anyone will access it. Sharing it to another recipient has no purpose other than to prompt accessing it.
Of those, the most compelling is the abortion pills site. It shares with the piracy example the possibility of being implicated in visiting a site when one hasn’t, and undue repercussions for that implication. Both are a stretch in terms of the likelihood of legal success (because neither actually produces a visit to the actual web page), but the abortion pills example is more compelling because political realities make injustice in that case more likely. I’ll admit this does give me some pause, but I’m not convinced it’s any more a threat than sharing the unvisited link.
> 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.
I chose the term carefully, specifically because the most obvious use case I could think of is categorically not legitimate: sending known-harmful resources to unwitting others for malicious purposes.
> 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.
I’m not sure why you feel this is necessary to point out as a response here. It’s possible to agree with this principle and still determine that certain applications of it are impertinent.
> No, and here I think there is some burden of proof to suggest that they’re the same.
That's exactly the way sharing worked for many years, until Ventura.
> Sharing it to another recipient has no purpose other than to prompt accessing it.
Says you, but that's not universally true. And when you talk about another "recipient", it's important to clarify that sharing is between apps on your own system. Sharing between people may or may not occur as a result of that, which is another reason why I liken it to copy and paste.
> I’m not sure why you feel this is necessary to point out as a response here.
The point is that privacy is the default. It doesn't need to be justified. As Apple says repeatedly and vehemently, "We believe privacy is a fundamental human right."
> That's exactly the way sharing worked for many years, until Ventura.
I don’t mean that the burden of proof is to show that they could or even should work the same way. I mean the burden of proof is to demonstrate the same principle applies to copying a link as applies to sharing it.
> And when you talk about another "recipient", it's important to clarify that sharing is between apps on your own system. Sharing between people may or may not occur as a result of that, which is another reason why I liken it to copy and paste.
This is a fair point! Particularly because the “share” functionality is overloaded for things which it conceptually shouldn’t be.
> The point is that privacy is the default. It doesn't need to be justified. As Apple says repeatedly and vehemently, "We believe privacy is a fundamental human right."
I’m still not sure why you’re pointing this out to me here. I was never arguing that this warrants an exception to privacy, by default or otherwise. I was questioning the applicability of privacy to the functionality in question. You’ve given me some reason to reconsider that. Not on the basis that I’ve reevaluated the value of privacy per se, but on the basis that I do better see how it might apply in this case.
43 comments
[ 3.4 ms ] story [ 92.3 ms ] threadThat'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 includes an image when sent as a message rather than just text saying "It's Waffles!" which is meaningless without context.
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/
But it makes the share menu look nice. That has value.
GUI based
It looks neat
https://github.com/evilsocket/opensnitch
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.
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.
Definitely can be classed as a privacy violation.
Maybe instead it's a link to a site that sells abortion pills and I'm a pregnant woman under a government that forbids them. I share it with someone else but don't access it myself. Maybe I have a miscarriage and the government suspects it's actually an abortion. They get a warrant for ISP records and now there's proof I accessed a site selling abortion pills despite never actually going to the website.
Or maybe it's a link to an IP stealer. Someone asks you to share it with someone else. You don't click the link but they still grab your IP anyway when you go to share it.
I can think of numerous other examples of how a compromising URL could expose your activities even if you didn't actually click on the link. I don't really see a need for downloading a preview favicon. It just exposes you for no reason and could provide just another possible attack vector
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.
It's not. See the addendum to the blog post.
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.
Says who?
It's used to show the icon and page title. That seems useful.
I think your expectations are unrealistic. If it's somehow extremely critical you don't actually make any requests to this URL then you're already playing with fire here, as it's not too hard to accidentally click the wrong mouse button or whatnot.
How so? Please explain how the iana.org icon in the blog post screenshot is useful.
Moreover, as the Addendum explains, that information is not even passed along to the other app when the URL is shared. It only appears in the share menu but ironically doesn't get shared.
How is that clear? I understand that someone inside Apple decided this was a good idea, perhaps for aesthetic reasons, but that's not the same as being clearly useful to people.
It seems to be yet another example of Apple bringing iOS UI to macOS.
https://portswigger.net/daily-swig/duckduckgo-ceo-clarifies-...
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.
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”?
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 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.
Honestly, I wouldn't mind at all. Link previews are becoming super common everywhere in the OS and apps. If somebody texts me a URL, it shows up as a link preview. Certain websites show link previews when you hover over a link. Not to mention browsers precache tons of URLs you never explicitly visit.
Visiting copied URL's to generate link previews, even if I never use the clipboard viewer to see it, seems entirely in line with expected behavior of using URLs in an OS. The last thing I need is a complicated mental model of which OS behaviors will load URL previews and which won't. Easier to just assume they all will.
So yes, if I'm dealing with a URL in any GUI context, I expect it might be accessed at any time for preview/precache purposes. If it's vitally important that it not be, I'll disconnect from the internet entirely.
That's great for you, but Apple claims that "privacy is a fundamental human right". So I'm going to hold Apple to that principle.
And reasonable people disagree as to whether practices like link previews and precaching invade privacy or not.
Obviously, I'm someone who doesn't think it does.
No, I asked eyelidlessness, whose answer was the opposite of yours.
No, and here I think there is some burden of proof to suggest that they’re the same. Copying a URL does not imply that anyone will access it. Sharing it to another recipient has no purpose other than to prompt accessing it.
> There's some discussion of use cases in another comment: https://news.ycombinator.com/item?id=38031177
Of those, the most compelling is the abortion pills site. It shares with the piracy example the possibility of being implicated in visiting a site when one hasn’t, and undue repercussions for that implication. Both are a stretch in terms of the likelihood of legal success (because neither actually produces a visit to the actual web page), but the abortion pills example is more compelling because political realities make injustice in that case more likely. I’ll admit this does give me some pause, but I’m not convinced it’s any more a threat than sharing the unvisited link.
> 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.
I chose the term carefully, specifically because the most obvious use case I could think of is categorically not legitimate: sending known-harmful resources to unwitting others for malicious purposes.
> 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.
I’m not sure why you feel this is necessary to point out as a response here. It’s possible to agree with this principle and still determine that certain applications of it are impertinent.
That's exactly the way sharing worked for many years, until Ventura.
> Sharing it to another recipient has no purpose other than to prompt accessing it.
Says you, but that's not universally true. And when you talk about another "recipient", it's important to clarify that sharing is between apps on your own system. Sharing between people may or may not occur as a result of that, which is another reason why I liken it to copy and paste.
> I’m not sure why you feel this is necessary to point out as a response here.
The point is that privacy is the default. It doesn't need to be justified. As Apple says repeatedly and vehemently, "We believe privacy is a fundamental human right."
I don’t mean that the burden of proof is to show that they could or even should work the same way. I mean the burden of proof is to demonstrate the same principle applies to copying a link as applies to sharing it.
> And when you talk about another "recipient", it's important to clarify that sharing is between apps on your own system. Sharing between people may or may not occur as a result of that, which is another reason why I liken it to copy and paste.
This is a fair point! Particularly because the “share” functionality is overloaded for things which it conceptually shouldn’t be.
> The point is that privacy is the default. It doesn't need to be justified. As Apple says repeatedly and vehemently, "We believe privacy is a fundamental human right."
I’m still not sure why you’re pointing this out to me here. I was never arguing that this warrants an exception to privacy, by default or otherwise. I was questioning the applicability of privacy to the functionality in question. You’ve given me some reason to reconsider that. Not on the basis that I’ve reevaluated the value of privacy per se, but on the basis that I do better see how it might apply in this case.
If you paste in a URL it will automatically load and preview the link.