Apple funds creation of new factories in return for exclusive use of the parts they produce. I believe they also prefer to negotiate pricing down to cost, then pay bonuses for meeting quantity/date goals.
Supposedly, the reason there weren't more iPod competitors back in the day was that Apple already had negotiated exclusive rights at pre-negotiated prices to buy a big chunk of the flash memory that otherwise would have been on the market.
> (I'm not only taking the person's word for it: the device is also IP certified as waterproof 30 mins at 1m depth)
Many expect phones these days to be the more stringent IP 68, this would correspond to a device with the lesser water resistance of IP X7.
That phone only needs to be restored to IP X5 to handle usage in rain.
So it is great they got it (somewhat? completely?) restored, but it was a device with less water resistance than many flagships phone today, tested with a lower level of water resistance than it was originally rated for.
It is hard to tell what the EU is actually looking for when you compare against the meter stick of reality.
Even ignoring potential design impacts from transitioning from sealed batteries to ones padded with safety features to avoid harm to someone armed with a conductive screwdriver, I have to imagine there will be quite a few people who do not restore the device to its ip 68 rating.
So you risk people stockpiling batteries in case they need them later, and people who after repair increase the risk of them turning their phone into a pile of e-waste because they thought they could still get it wet. People also won't necessarily know the proper way to dispose of the old battery.
This compared to just having rules about needing to supply batteries which are replaceable by any appropriate state-licensed technician at cost for X number of years, and mandating the old batteries be properly recycled by said technicians.
My understanding was that Google was withholding access to features (vector tiles, turn by turn) to renegotiate maps usage. The two things I heard they wanted - features gated on Google login, and advertisements.
Apple had been developing their own maps solution already and accelerated it to land before the end of their existing agreement with Google, when Apple would have to accept Google's terms to continue usage. Google apparently had no idea negotiations had fallen through until the keynote.
It was going to ship as beta quality anyway (they were merging multiple sources of third party data), but the timeline meant it became a replacement in whatever form it was in.
One could add the Vision Pro, MacBook Neo, Mac Studio, HomePods, and so on to the list as well.
The reality is everyone just wants another hit product like the iPhone, but its success was based on it being a personal convergence device. You can't really create a second carryable/wearable convergence device and expect it to be wildly successful at the level of the iPhone without it killing off the iPhone.
So far that revolutionary approach by third parties has not succeeded against the iPhone, and the evolutionary approach apple takes with the iPhone means there is no clear inflection point anywhere in the future where the phone form factor goes away.
The web and native app platforms have very different security models.
Nobody is vetting websites for you. There is no guarantee the same company operates a website today that did yesterday. There is no obvious distribution or regulatory authority instituting penalties for illegal actions (and often is no legal presence in a country when illegal actions take place).
That means for the web, every consent prompt has a large, sometimes even unbounded amount of harm behind it if the user picks incorrectly, and browsers have limited capacity to help them pick correctly outside of reactive block lists once substantial harm has been done and recognized.
This is why, for example, the major browsers have all moved to restricting web extensions behind their own review processes/stores, and put restrictions that make unaudited web extensions difficult to install outside of development workflows. The risk is just too great.
Chrome pushed many of these API early in the Chromebook product cycle, because their idea was that you would only build apps using web technologies. I somewhat doubt they would have pushed for WebUSB themselves if Chromebook started in its current state, where it primarily runs android apps and is about to transition to be android-based.
> The web and native app platforms have very different security models.
Yes, and as a result, the web is much more sandboxed than native app stores (which are mostly based on the illusion that vetting apps can somehow achieve better security than minimizing what resources apps can access in the first place and making access more fine grained).
This is exactly why I'd rather run e.g. shady USB aftermarket firmware flashing apps in my browser (where I know they can at most compromise the device I'm flashing) than as a native app (where USB access is the default and requires zero permissions to be approved).
> This is why, for example, the major browsers have all moved to restricting web extensions behind their own review processes/stores, and put restrictions that make unaudited web extensions difficult to install outside of development workflows. The risk is just too great.
Web extensions very often have access to your complete browsing data, including all cookies. That's orders of magnitude more risky than access to an explicitly selected USB device, in my view.
> I somewhat doubt they would have pushed for WebUSB themselves if Chromebook started in its current state, where it primarily runs android apps and is about to transition to be android-based.
Android has an USB API as well, and if Google only wanted "apps" to have USB access, nothing was stopping them from making Web USB "Chrome App Store" only.
Sure, but some people are concerned about any website being one confirmation prompt away from being able to have full access to hardware in the user's physical environment, and being able to permanently change the behavior of that hardware.
A hacker may think such things are convenient for them, but an end user does not know the ramification of a random website (WebUSB IIRC still does not have origin restrictions) getting hardware access - nor can we categorize the risk in order to protect them.
What physical access and what permanent behavior changes in particular are you concerned about? Most common "dangerous" USB device classes are explicitly excluded in Web USB.
I've heard about rogue keyboard firmware, but that requires having a programmable/updatable firmware keyboard in the first place. And that closes the loop of my argument: People that want to update the firmware in their keyboard will do so, whether it's in the browser or by installing a potentially shady and not at all sandboxed third party application.
At least in the browser, permissions are time limited and scoped to explicitly granted devices.
> WebUSB IIRC still does not have origin restrictions
The most important USB thing I have are storage devices. Keyboards/mice/etc are much less of a concern. If something rogue happens to a drive, that's a "major problem in Australia. Please help us stop it" situation.
It's a good thing that history has shown us that things have never happened that were designed not to happen. Sure, my tinfoil hat is securely fashioned, but I've been around long enough to see things get subverted even if it's not until long after release.
On a modern laptop, the keyboard is on the top half of the lower case these days, not the bottom.
My palms are hovering over or resting on the chassis, and I sit high enough that my wrists do not come in contact with the edge of the case or desk. The majority of the weight of my arms is supported by my shoulders. For me, the ideal height happens to be pretty close to a neutral wrist position.
reply