Mike Kosak:
LastPass would like to alert our customers to a fraudulent app attempting to impersonate our LastPass app on the Apple App Store. The app in question is called “LassPass Password Manager” and lists Parvati Patel as the developer. The app attempts to copy our branding and user interface, though close examination of the posted screenshots reveal misspellings and other indicators the app is fraudulent.
Juli Clover:
It doesn’t use exactly the same icon and the name is a letter off, but the similarities could confuse some LastPass users.
It is unclear if the fake LassPass app is attempting to steal login information from users, but it does have options for adding passwords, email accounts, addresses, bank accounts, credit cards, debit cards, and more. It doesn’t ask for a LastPass login of any kind, but it is possible that the developer can see information added to the app.
[…]
Clone apps often make their way into the App Store , but the app impersonating LastPass is particularly concerning because it could be accessing sensitive information. It is not clear how an app mimicking one of the most popular password management apps was approved by Apple, and its discovery comes at a critical time for the company.
John Gruber:
Branscombe is correct that even isolated incidents like this hurt Apple’s arguments in favor of App Store exclusivity. But what’s the counterargument? That anything short of 100 percent accuracy at flagging scams and rip-offs renders the entire App Store review process pointless? That if, say, 1 in every 1,000 scam attempts slips through, the entire process should be scrapped? That argument can’t be taken seriously.
A few points:
The question isn’t whether it’s pointless—it’s whether it does more harm than good. Aside from bad apps getting through, there are many legitimate apps that are inappropriately blocked or delayed.
And whether one half of a duopoly should be able to dictate which software is available for what is many people’s primary computing platform.
We have no idea what the real numbers are, but various third-party reports suggest that many scam apps remain in the store, even after reporting to Apple. And, of course, some have even been featured by Apple.
The App Store enables these scams. If users downloaded apps from the Web, such scams wouldn’t have the Google juice to get traction, but they can rocket to the top of the App Store search results just by having a name that’s shares a prefix with a hit product. Secondly, Apple has successfully convinced the general public that the App Store is curated, so people are trusting of what they download. They’re lulled into a false sense of security.
Previously:
Update (2024-02-14): Francisco Tolmasky:
Imagine an FDA as half-assed as the App Store, accidentally only requiring cancer warnings on some cigarettes, leading people to buy the cigarettes that “don’t cause cancer.” That’s the App Store.
[…]
A curated hellhole full of gambling traps for children that somehow still manages to let scams run for a week is nothing to be proud of, even if it is better than a competitor that isn’t even trying. Once upon a time we expected more from Apple.
App Store App Store Scams iOS iOS 17 LassPass LastPass
Thomas Claburn (Hacker News):
Apple has argued for years that developers who don’t want to abide by its rules for native iOS apps can always write web apps.
It has done so in its platform guidelines, in congressional testimony, and in court. Web developers, for their part, maintain that Safari and its underlying WebKit engine still lack the technical capabilities to allow web apps to compete with native apps on iOS hardware. To this day, it’s argued, the fruit cart’s laggardly implementation of Push Notifications remains subpar.
The enforcement of Europe’s Digital Markets Act was expected to change that – to promote competition held back by gatekeepers. But Apple, in a policy change critics have called “malicious compliance,” appears to be putting web apps at an even greater disadvantage under the guise of compliance with European law.
James Moore:
We have been alerted that Apple has broken Web App (PWA) support in the EU via iOS 17.4 Beta. Sites installed to the homescreen failed to launch in their own top-level activities, opening in Safari instead. This demotes Web Apps from first-class citizens in the OS to mere shortcuts. Developers confirmed the bug did not occur outside the EU.
Hartley Charlton:
Now, when a user in Europe taps a web app icon, they will see a system message asking if they wish to open it in Safari or cancel. The message adds that the web app “will open in your default browser from now on.” When opened in Safari, the web app opens like a bookmark, with no dedicated windowing, notifications, or long-term local storage. Users have seen issues with existing web apps such as data loss, since the Safari version can no longer access local data, as well as broken notifications.
Previously:
Update (2024-02-14): Bruce Lawson (via Hacker News):
Presumably Apple doesn’t want PWAs to open in third-party browsers that have more powerful features than Safari, because those would directly compete with native apps in its own App Store. However, in the EU, it can’t privilege PWAs in Safari with its own private APIs any more. And so its solution, in its spirit of malicious compliance, seems to be “if we can’t have them, nobody can!”.
Update (2024-02-16): Apple (MacRumors, Hacker, News, 3, Slashdot):
Why don’t users in the EU have access to Home Screen web apps?
[…]
The iOS system has traditionally provided support for Home Screen web apps by building directly on WebKit and its security architecture. That integration means Home Screen web apps are managed to align with the security and privacy model for native apps on iOS, including isolation of storage and enforcement of system prompts to access privacy impacting capabilities on a per-site basis.
Without this type of isolation and enforcement, malicious web apps could read data from other web apps and recapture their permissions to gain access to a user’s camera, microphone or location without a user’s consent. Browsers also could install web apps on the system without a user’s awareness and consent. Addressing the complex security and privacy concerns associated with web apps using alternative browser engines would require building an entirely new integration architecture that does not currently exist in iOS and was not practical to undertake given the other demands of the DMA and the very low user adoption of Home Screen web apps. And so, to comply with the DMA’s requirements, we had to remove the Home Screen web apps feature in the EU.
Apple had two years or so to prepare for the DMA, but they “had to” to remove the feature entirely (and throw away user data) rather than give the third-party API parity with what Safari can do. I find the privacy argument totally unconvincing because the alternative they chose is to put all the sites in the same browser. If you’re concerned about buggy data isolation or permissions, isn’t this even worse?
Open Web Advocacy:
There is no way to have a reliable web app that is bound to the default browser. It would mean every time you changed default browser, you would lose all your data.
Kosta Eleftheriou:
Apple citing “low user adoption” of PWAs as a reason for the lack of support. [image]
Steve Troughton-Smith:
It’s a complete coincidence that iOS killing PWAs in Europe means that PWA developers should move to the App Store if they want to be on the platform.
John Voorhees:
For anyone who was there when Steve Jobs declared web apps a ‘Sweet Solution’ when developers clamored for Apple to open up the iPhone’s OS to native apps, taking them away in the face of regulations that force Apple to open up to alternative browser engines carries a heavy dose of irony.
Thomas Claburn:
Apple made this change without notice to developers, despite Cupertino’s repeated insistence that web apps represent an alternative to native iOS apps for those unable or unwilling to abide by its platform restrictions.
[…]
Maximiliano Firtman, a web developer who works on PWAs, added, “The technical reasons behind the decision published in the document are childish and it contains many lies.”
Heath Borders:
The EU isn’t forcing Apple to make awful policy choices.
Manton Reece:
Was this statement from Apple written by a hallucinating AI? All mainstream web browsers have a strict security model for JavaScript. Cookies and local storage cannot be accessed across web apps. It’s even difficult or impossible to make certain web requests from JavaScript because of cross-site scripting and CORS limitations. The only way this could be circumvented is with a rogue web browser engine that did away with these standard constraints, but Apple already has this scenario covered because they approve every browser engine[…]
Rui Carmo:
In fact, I actually have less and less interest in developing (or even supporting developing) for Apple platforms due to this kind of deliberate and maliciously arbitrary amputation of existing features.
Steve Troughton-Smith:
Apple thought its bullshit Core Technology Fee was worth investing effort in, but not homescreen web apps 😛
“If Apple ever asked its engineers to make iOS worse in favor of making the company money, they would quit”
Turns out that was a lie. Who knew
Ian Betteridge:
I kind of think assuming that the EU is just going to go “oh noes, Apple has beated us!” is maybe, just maybe, underestimating quite how pissed off they’re going to be about Apple’s arsing about.
See also: the WebKit bug.
Update (2024-02-20): Open Web Advocacy (Hacker News):
This is emphatically not required by the EU’s Digital Markets Act (DMA). It’s a circumvention of both the spirit and the letter of the Act, and if the EU allows it, then the DMA will have failed in its aim to allow fair and effective browser and web app competition.
It’s telling that this is the feature that Apple refused to share. And it makes sense: the idea that users could install safe and secure apps that Apple can’t tax, block or control is terrifying to them.
The legal obligation to allow third-party browsers onto iOS removes their ability to set a ceiling on web app functionality via their control of Safari and the WKWebView. Suddenly Web Apps would be a viable competitor. It is particularly galling for them to cite low adoption when they have had their thumb on the scale suppressing them for over a decade.
[…]
Apple also makes tenuous, bordering on laughable, claims regarding web app security. In addition to unwarranted and unjustifiable attempts to project their own model onto competing browsers, Apple makes claims that ignore the history of web applications and browsers in providing strong privacy and security separation. Apple offers no evidence to back these assertions, and ignores the long track record of superior security of PWAs on other OSes.
Ian Betteridge:
The company has had years to prepare for this. If it got blindsided, that’s a management failure. If it’s being petulant, that’s a management failure. If it can’t devote the resources to make this work, that’s a management failure. And if this is an attempt to enforce using native APIs and the App Store rather than PWAs… well, that too is a management failure.
Mike Rockwell:
I don’t understand what Apple’s end game is with this and the rest of their “compliance” with the DMA. It seems foolish to expect regulators in the EU to turn a blind eye to Apple’s changes, which are obviously outside of the spirit the DMA’s intentions.
Tim Sweeney (Sarah Perez, Hacker News):
I suspect Apple’s real reason for killing PWAs is the realization that competing web browsers could do a vastly better job of supporting PWAs - unlike Safari’s intentionally crippled web functionality - and turn PWAs into legit, untaxed competitors to native apps.
Nick Heer:
Apple has long promoted web apps as an open and free — as in speech — alternative to the more restrictive policies of the App Store. No matter why Apple made this decision, it is trading the inherently competitive web for third-party browser engines and app distribution for reasons that, as Reece explains, are difficult to believe.
Jeremy Keith (via Hacker News):
Now Apple need to provide parity on iOS, at least for users in the EU. Again, Apple are decribing this coming scenario as an absolute security nightmare. But again, the conditions they’re describing are what already exist on macOS.
All Apple is being asked to do is offer than the same level of choice on mobile that everyone already enjoys on their computers. Rather than comply reasonably, Apple have found a way to throw their toys out of the pram.
[…]
This is a huge regression that only serves to harm and confuse users.
[…]
Presumably Apple is hoping that users will direct their anger at the EU commission instead. They’re doing their best to claim that they’re being forced to make this change. That’s completely untrue.
Update (2024-03-01): Hartley Charlton:
Following intense criticism, Apple today walked back its plan to disable Home Screen web apps in the European Union starting with iOS 17.4.
Apple (Hacker News):
Previously, Apple announced plans to remove the Home Screen web apps capability in the EU as part of our efforts to comply with the DMA. The need to remove the capability was informed by the complex security and privacy concerns associated with web apps to support alternative browser engines that would require building a new integration architecture that does not currently exist in iOS.
We have received requests to continue to offer support for Home Screen web apps in iOS, therefore we will continue to offer the existing Home Screen web apps capability in the EU. This support means Home Screen web apps continue to be built directly on WebKit and its security architecture, and align with the security and privacy model for native apps on iOS.
Developers and users who may have been impacted by the removal of Home Screen web apps in the beta release of iOS in the EU can expect the return of the existing functionality for Home Screen web apps with the availability of iOS 17.4 in early March.
Poor grammar and no clarification about what the DMA requires here, but this is good news.
Update (2024-03-05): Nick Heer:
Apple is framing this as a decision it made because it is just so dang nice — “[w]e have received requests to continue to offer support for Home Screen web apps in iOS, therefore we will continue to offer the existing Home Screen web apps capability”. If this is true, that means its earlier statement must have been wrong — there was no legal rationale for web app regressions, only a preference.
[…]
A version of this entire debacle which is fair to Apple is that it misunderstood its obligations, and would never have degraded PWAs in the E.U. if not for its too-careful interpretation of the law. But it does not get to take credit for undoing its mistake.
Antitrust Datacide Digital Markets Act (DMA) European Union iOS iOS 17 Web
Juli Clover (release notes, full installer, IPSW):
Today’s update addresses a frustrating macOS Sonoma bug that could cause text to get randomly replaced while typing. There have been multiple complaints about the issue, which affected web pages and apps like Mail and Messages.
The problem has persisted for several months, and has been an issue through multiple versions of Sonoma.
This was clearly caused by a WebKit bug, but I’ve been intermittently seeing a similar issue with NSTextView for several years. If I replace the text storage with a new string, parts of the previous contents will sometimes come back.
See also: Howard Oakley and Mr. Macintosh.
Previously:
Update (2024-02-14): Pierre Igot:
You’ve got to be kidding me… Another very MINOR update (macOS 14.3 to macOS 14.3.1), yet another avalanche of dialogs asking me reauthorize all kinds of things? All kinds of things gone or disabled AGAIN under “Privacy and Security”?
Bug Mac macOS 14 Sonoma macOS Release WebKit
Emilia David:
Apple researchers released a new model that lets users describe in plain language what they want to change in a photo without ever touching photo editing software.
The MGIE model, which Apple worked on with the University of California, Santa Barbara, can crop, resize, flip, and add filters to images all through text prompts.
MGIE, which stands for MLLM-Guided Image Editing, can be applied to simple and more complex image editing tasks like modifying specific objects in a photo to make them a different shape or come off brighter. The model blends two different uses of multimodal language models. First, it learns how to interpret user prompts. Then it “imagines” what the edit would look like (asking for a bluer sky in a photo becomes bumping up the brightness on the sky portion of an image, for example).
Amber Neely:
MGIE is open-source and available on GitHub for anyone to try. The GitHub page allows users to snag the code, data, and pre-trained models.
Previously:
Apple Artificial Intelligence Graphics Open Source
Jeff Johnson:
Instead, you get harassed by frequent notifications imploring you to “Upgrade to macOS Sonoma”, notifications that won’t take no for an answer. They don’t even have no for an answer! And if you click the wrong thing, you’ll accidentally, silently install Sonoma.
[…]
The solution in this case is actually quite simple, one little Terminal command:
defaults write com.apple.SoftwareUpdate MajorOSUserNotificationDate -date "2025-02-07 23:22:47 +0000"
Previously:
Update (2024-02-14): Howard Oakley:
Although a detailed analysis by Adam Engst on TidBITS laid the blame on what could only have been a serious bug in the upgrade notification, I’ve had reports from users who insist that they never saw or dismissed that.
[…]
For Macs with more than one user, that key-value pair must be set in each user’s ~/Library/Preferences/com.apple.SoftwareUpdate.plist to ensure the notification doesn’t occur.
[…]
If those forced upgrades had been initiated independently of that notification, as some accounts imply, then blocking its appearance wouldn’t have prevented the upgrade from occurring.
See also: Ric Ford.
Dark Patterns Esoteric Preferences Mac macOS 14 Sonoma Software Update
