- dwaiteDoes anyone know what this adds beyond AccessorySetupKit, which shipped over a year ago?
- The problem is you can’t regulate interoperability where it doesn’t exist.
What does it mean to open the “default map app”? Maps apps typically act a native rendering for a web site, and have their own web-parameter based API for locations, navigation, and points of interest, as well as customizing informational layers.
So if I set say Bing maps to be the default map app, does that mean:
1. The OS hijacks attempts to link to sites such as Google Maps (https://maps.google.com) and Apple Maps (https://maps.apple.com) and send them to Bing Maps instead?
2. Bing Maps reverse engineers as much as possible of the various other mapping products and tries to support them with roughly equivalent features or error messages?
What the default maps app setting Apple created does is create an entirely new URI scheme of geo-navigation and an entitlement for apps which wish to support it to be the default map app. This appears to be roughly limited to a subset of parameters common between Apple and Google Maps.
So this setting in the EU and Japan.. mostly does nothing currently. Every developer needs to change their native apps and web pages to call out to this new custom scheme that only works on Apple platforms. Each of these mapping apps needs to support this scheme. That hasn’t happened yet.
The EU (and in this case Japan) gets early access and the potential exposure of multiple breaking revisions.
It is also certainly possible that a good number of web/app developers decide they don’t _want_ to support multiple mapping apps, since they’ve only verified one or two of them actually provide proper navigation/visualization/POI, and that the whole concept is flawed.
- > For example, you need to root and patch your Bluetooth stack on your phone if you want to use all of your AirPods features on Android, and not because Android is doing something wrong, it's because the Android Bluetooth stack actually sticks to the spec and AirPods don't.
It’s a mix of bad Bluetooth implementations still on the Android side, and Apple extensions to cram audio features into the BLE envelope.
> And even when you do that, you can't do native AAC streaming like you can with iOS/macOS. Even if you're listening to AAC encoded audio, it'll be transcoded again as 256kbps AAC over Bluetooth.
How would this be Apple’s fault if the OS audio stack can’t do direct AAC streaming? Or are you saying the headphones themselves decode, re-encode and then re-decode the AAC?
- Commercial software support is not free. Contracting out for professional services or diverting internal developers to fix issues with open source software are also not free.
- > yes I know there was one iPad that could do USB 3 with one special dongle - and it couldn’t even do video out well with the dongle. The video adapter had hardware to decompress a compressed video stream and convert it.
Those are two separate things.
These iPad models had USB 3.0 over lightning. Lighting however was designed to solve the 30 pin connector "alt mode" problem. USB-C recreated the "alt mode" problem.
In the original 30-pin iPod, iPhone and iPad days, you had multiple video out adapters to support RCA, VGA, composite, and so on. These were also _different_ with the different i-device models - the adapters were not backward compatible, so when they came out with a new higher-resolution model of dongle, it wouldn't work on older devices. Conversely, the complexity of supporting various hardware mappings onto the 30 pin connector meant that older dongles could get deprecated from new devices.
There weren't a lot of people who invested in video output for their I-devices, but for those who did this was a very frustrating issue.
So for lightning, they went to serial protocols. So rather than negotiate a hardware mode where certain pins acted like HDMI pins in a pass-through mode, they streamed a H.264 video to the dongle - the dongle then rendered it and used its own HDMI output support.
Since this was software negotiation, a newer dongle could support new video formats and higher resolutions while still supporting older devices. There were also examples of improvements pushed to more complicated dongles like the HDMI adapter via software updates. But fundamentally, the complexity of supporting a broad hardware accessory ecosystem wasn't pushed into the physical port - it could evolve over time via more complex software rather than via increasingly complicated hardware in every phone.
With USB-C we are back to guessing whether the connector is expecting the phone to support HDMI alt mode, DisplayPort alt mode, MHL alt mode, or to output a proprietary system like DisplayLink data.
USB 3.0 (which is what these iPads supported) never had these alt modes. It was USB-C which became a connector for (optionally) supporting a lot of other, non-USB protocols. The lack of USB-C support is why these iPads only supported video out with the lightning to HDMI adapter.
USB-C is decent, but it suffers quite a bit from there not being strong certification. This is partly why Thunderbolt 5 has shifted to becoming a compatibility- and capability- oriented certification mark. You know for example that thunderbolt 5 video will always work, because the cables have all the data pins and the devices are going to support DisplayPort alt mode.
- More of a person with IETF participation experience than as a cryptographer (I enjoy watching numbers dance but am not a choreographer):
This ( https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ ) is a document describing how to use the ML-KEM algorithm with TLS 1.3 in an interoperable manner.
It does not preclude other post-quantum algorithms from being described for use with TLS 1.3. It also does not preclude hybrid approaches from being used with TLS 1.3.
It is however a document scoped so it cannot be expanded to include either of those things. Work to define interoperable use of other algorithms, including hybrid algorithms, would be in other documents.
There is no MTI (mandatory-to-implement) once these are documented from the IETF directly, but there could be market and regulatory pressures.
My suspicion is that this is bleed-out from a larger (and uglier) fight in the sister organization, the IRTF. There, the crypto forum research group (CFRG) has been having discussions on KEMs which have gotten significantly more heated.
A person with concern that there may be weaknesses in a post quantum technique may want a hybrid option to provide additional security. They may then be concerned that standardization of non-hybrid options would discourage hybrid usage, where hybrid is not yet standardized and would likely be standardized later (or not at all).
The pressure now with post quantum is to create key negotiation algorithms are not vulnerable to theoretical post quantum computer attack. This is because of the risk of potentially valuable encrypted traffic being logged now in the hopes that it could later be targeted by a post-quantum computer.
Non-negotiated encrypted (e.g. just using a static AES key) is already safe, and signature algorithms can be updated much closer to viable attacks to protect transactional data.
- You may misunderstand how the IETF works. Participation is open. This means that it is possible that people who want the work to fail for their own reasons rather than technical merit can join and attempt to sabotage work.
So consensus by your definition is rarely possible given the structure of the organization itself.
This is why there are rough consensus rules, and why there are processes to proceed with dissent. That is also why you have the ability to temporarily ban people, as you would have with pretty much any well-run open forum.
It is also important to note that the goal of IETF is also to create interoperable protocol standards. That means the work in question is a document describing how to apply ML-KEM to TLS in an interoperable way. It is not a discussion of whether ML-KEM is a potentially risky algorithm.
DJB regularly acts like someone who is attempting to sabotage work. It is clear here that they _are_ attempting to prevent a description of how to use ML-KEM with TLS 1.3 from being published. They regularly resort to personal attacks when they don't get their way, and make arguments that are non-technical in nature (e.g. it is NSA sabotage, and chairs are corrupt agents). And this behavior is self-documented in their blog series.
DJB's behavior is why there are rules for how to address dissent. Unfortunately, after decades DJB still does not seem to realize how self-sabotaging this behavior is.
- So all someone who is being abusive has to do to force me to be stand there and be abused by them is to call me corrupt?
- A lot of zigbee infrastructure also expect an internet connection.
These border routers also double as admins, and people want their smart home stuff to be available while they are outside their home network.
Thread devices can mandate internet connectivity the same way Wifi devices can.
Matter defines profiles and does certification that says your light bulbs cannot require an internet connection. The admin your water leak detector connects into can (and arguably should) alert you even when you are away from home, but the leak detector _itself_ cannot do that and be certified.
- Yes, USB extenders are not spec-legal (because the device isn't built expecting to be extended).
But you can have an extension cord which accepts USB on one end but doesn't accept USB on the other.
So the keyboard has a superset connector so that it can go in regular USB and notched USB, because it is verified to work right when using the extension cord.
This design also means you can't plug one extension cord into another to get an even longer distance (which the keyboard wouldn't expect). Pretty clever solution.
- The lowest level of the three is not a useful number. The case serves as a battery pack to recharge the headphones (something I did earlier today while on an international flight).
The reality is the sort of compatibility being talked about is a new feature with design choices, not just unwired functionality.
I'd rather them work on features to report charging time or expected playback time on iOS, or write their own app for Android, than try to arbitrarily increase their bluetooth profile compatibility checklist.
- Which of the three battery level values should be reported in the one slot Bluetooth provides?
- This is based off of a biometric passport, which have been digitally signed for a very long time now.
- Four points:
1. Apple potentially loses giving ground to regulators before the regulators ask for something. They don't want to allow alternative app stores and then have a regulator say they are also not allowed to mandate royalties for digital good/service sales in their own store. Apple is likely nudging regulators to go a particular way, but is effectively trying to barter.
2. Likewise, individual regulatory bodies solving the issues they see in different ways has and will continue to create complexity in app developers, in some cases meaning their app needs different business models in different countries to take advantage of the individual regulated changes. That is a consequence of regulators pushing Apple to themselves have different business models to fund the App Store in different countries.
3. If Apple doesn't want a feature to be used or thinks the feature is actively harmful, they aren't going to encourage its use by making it available in jurisdictions where it isn't required.
4. Some of these features (such as default maps app) are semi-baked and without industry consensus, but rolled out because they were required for regulatory timelines. I can emphasize with not wanting to roll out broken features where you aren't being required to.
- The largest impact would be that the reversion would only affect native macOS apps, while catalyst apps, remote iPhone apps and locally installed iPad apps would still have Liquid Glass UX.
- What else did you imagine?
- The issue is that static content only sites do not exist - unless browsers change their stance to disabling long-relied-upon features like Javascript and embedded frames for content served over plain HTTP.
They've taken that strategy with newer enhancements (for instance, you can't use passkeys over non-secured channels), but the bar for widespread breakage of existing deployments is pretty high - even if changes like this make it harder to navigate to those existing deployments.
- The line for market success for a first generation, $3500 VR headset is drawn in different places for different people.