Safari share menu now violates privacy
lapcatsoftware.com
lapcatsoftware.com
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.
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.
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.
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
https://portswigger.net/daily-swig/duckduckgo-ceo-clarifies-...
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.
GUI based
It looks neat
<https://www.example.com>
If you paste in a URL it will automatically load and preview the link.