It uses native APIs to request the media file from the OS and since the app doesn't request the permission to receive location data along with it, the OS provides the files without the location

Related permission: https://developer.android.com/training/data-storage/shared/m...

On OS-level there is no reduction in functionality, the implementation just ensures that the user agrees on sharing his location data to an app, and until that has been agreed it is not being shared (as to not hinder any normal app-operation).

Now the fact that the Chrome app doesn't trigger to ask the user-permissions is another topic, with its own (huge) complexity: If the user disagrees to share his location-history to a webpage, and Android can only ensure this for known media file types (while i.e. Windows cannot do this for ANY filetype, and on iOS I believe the user cannot even decide to not have it stripped), Chrome actually cannot commit to any decision taken by the user.

It's a known dilemma in the W3C, the Browser should ensure user privacy but for binary data it technically can't...

#. Post on your personal account, repost or "talk about your post" from your startup account --> be a person on LinkedIn belonging to a company, don't be a company.

#. Don't direct your posts to customers, direct it to "the industry", by talking about observations, challenges, etc. --> This will create more initial engagement as you likely have more peers than customers in your network --> more engagement increases visibility of your posts to 2nd/3rd degree connections.

#. Tell stories on the issues you saw, thoughts you had, how you helped a person/team (!) in a company, always add some picture, try to have "open ended" thoughts or ask questions.

#. Comment on other people's posts if they help you shape the image of a knowledgable guy enjoying to help others.

#. Don't talk about how great you are, talk about how/why your company/product/service is great for business problems like xyz. (if needed, let your company account talk about how great you are)

As on all social networks, the algorithm keeps changing. But I found that this behavior will establish and show you as a connected and knowledgeable person, and by proxy the company gets visibility as well.

I was with a company in digital transformation services which got ~30% of its leads from LinkedIn (and equal conversion rates to jobs than other means but at much lower cost), just by coaching its Sales to post stories on how excited they are to help others solve some business problems --> Customers got in touch because they could relate to the problem or considered them knowledgeable on similar topics.

And soon, also you will be part of this modern style of doing business that many of us would love to stop /s

My lack of knowledge shines through: I didn't know they made a sequel...

/S

A standardized attribute on an HTML-form would be difficult to define, because in this context the page just requests/receives a binary file, so a generic "strip embedded location information" decision from the user would be hard to enforce and uphold (also, by whom?).

In this case Android only knows the file-structure and EXIF because the file is requested by Chrome from a Media Library in the OS, not a file-manager.

W3C keeps thinking about this data-minimization topic repeatedly [0], so far they managed to define the principles [1], but enforcing them technically is quite hard if any kind of content can be submitted from a storage to a webpage...

[0] https://www.w3.org/blog/2019/adding-another-permission/

[1] https://www.w3.org/TR/security-privacy-questionnaire/#data-m...

Now an app maybe just wants to set the image as wallpaper, send it to a printer or set as an avatar, so it requests to read it from storage. The OS injecting a watermark here or adding some UI would break decades of apps...

The prior threat-model was, that e.g. a camera/gallery app which may/may not have a permission to a users current location, also has access to the history of a users' locations just by scanning the images when showing the camera roll.

It frankly makes sense to create a separate permission just for this location metadata AND strip this data when no permission was granted, I believe everything else would be MUCH harder to explain the user...

The article is actually about Google's web browser stripping the EXIF location-data when uploading a photo to a webpage, and the author complains about that behavior.

This is not an implementation of the browser itself. Android Chrome is behaving in that way because the app didn't request the required permission for that data from the OS (which would ask the user), so the files it receives to upload already has the data removed

Chrome doesn't seem to request that permission, so the OS doesn't provide the location-data to the app. So Chrome rather ended up in this state by doing nothing, not by explicitly doing something...

If your app targets Android 10 (API level 29) or higher and needs to retrieve unredacted EXIF metadata from photos, you need to declare the ACCESS_MEDIA_LOCATION permission in your app's manifest, then request this permission at runtime.

Source: https://developer.android.com/training/data-storage/shared/m...

Chrome doesn't seem to request that permission, so the OS doesn't provide the location-data to the app. So Chrome rather ended up in this state by doing nothing, not by explicitly doing something...

If your app targets Android 10 (API level 29) or higher and needs to retrieve unredacted EXIF metadata from photos, you need to declare the ACCESS_MEDIA_LOCATION permission in your app's manifest, then request this permission at runtime.

Source: https://developer.android.com/training/data-storage/shared/m...

Chrome doesn't seem to request that permission, so the OS doesn't provide the location-data to the app. So Chrome rather ended up in this state by doing nothing, not by explicitly doing something...

If your app targets Android 10 (API level 29) or higher and needs to retrieve unredacted EXIF metadata from photos, you need to declare the ACCESS_MEDIA_LOCATION permission in your app's manifest, then request this permission at runtime.

Source: https://developer.android.com/training/data-storage/shared/m...

Chrome doesn't seem to request that permission, so the OS doesn't provide the location-data to the app.

If your app targets Android 10 (API level 29) or higher and needs to retrieve unredacted EXIF metadata from photos, you need to declare the ACCESS_MEDIA_LOCATION permission in your app's manifest, then request this permission at runtime.

Source: https://developer.android.com/training/data-storage/shared/m...

If the app that creates the compressed file uses the media API to get the file and doesn't have the permission to get location-info, the data will be stripped before the OS is handing the file over to that app. This is likely different if the app uses the READ_EXTERNAL_STORAGE permission and API's to read the files though, which is a legacy permission that was mainly kept for file managers now...

If your app targets Android 10 (API level 29) or higher and needs to retrieve unredacted EXIF metadata from photos, you need to declare the ACCESS_MEDIA_LOCATION permission in your app's manifest, then request this permission at runtime.

Source: https://developer.android.com/training/data-storage/shared/m...

If your app targets Android 10 (API level 29) or higher and needs to retrieve unredacted EXIF metadata from photos, you need to declare the ACCESS_MEDIA_LOCATION permission in your app's manifest, then request this permission at runtime.

So if the app-developer didn't take explicit effort to request this data (and the user-permission for it), his app will not receive it.

[0] https://developer.android.com/training/data-storage/shared/m...

If your app targets Android 10 (API level 29) or higher and needs to retrieve unredacted EXIF metadata from photos, you need to declare the ACCESS_MEDIA_LOCATION permission in your app's manifest, then request this permission at runtime.

Caution: Because you request the ACCESS_MEDIA_LOCATION permission at runtime, there is no guarantee that your app has access to unredacted EXIF metadata from photos. Your app requires explicit user consent to gain access to this information.

I made another quick check on my device, Chrome doesn't have the ACCESS_MEDIA_LOCATION permission and doesn't seem to request it at runtime, so the location info is stripped from the EXIF data (by the OS!) when a file is selected.

Chromium also seems have no feature to ask the user whether he agrees to share the stored location when uploading images, so there is probably no capability to request the permission at runtime.

Not satisfying, I know, but despite some judgements in the tickets the implementation seems to work as designed.

Instead, it could be considered a feature-request for Chrome to ask the user about this on upload, or couple the location-permission of a website to the permission to share EXIF-location data when uploading files (Although I think the logic on that is not really tight, the user giving permission to share his location now doesn't necessarily mean that he agrees to share all his locations from the past from EXIF-data)

[0] https://developer.android.com/training/data-storage/shared/m...

Even if the investment is overblown, there is market-demand for the services offered in the AI-industry. In a competitive playing field with equal opportunities, Apple would be affected by not participating. But they are establishing again their digital market concept, where they hinder a level playing field for Apple users.

Like they did with the Appstore (where Apple is owning the marketplace but also competes in it) they are setting themselves up as the "the bakn always wins" gatekeeper in the Apple ecosystem for AI services, by making "Apple Intelligence" an ecosystem orchestration layer (and thus themselves the gatekeeper).

1. They made a deal with OpenAI to close Apple's competitive gap on consumer AI, allowing users to upgrade to paid ChatGPT subscriptions from within the iOS menu. OpenAI has to pay at least (!) the usual revenue share for this, but considering that Apple integrated them directly into iOS I'm sure OpenAI has to pay MORE than that. (also supported by the fact that OpenAI doesn't allow users to upgrade to the 200USD PRO tier using this path, but only the 20USD Plus tier) [1]

2. Apple's integration is set up to collect data from this AI digital market they created: Their legal text for the initial release with OpenAI already states that all requests sent to ChatGPT are first evaluated by "Apple Intelligence & Siri" and "your request is analyzed to determine whether ChatGPT might have useful results" [2]. This architecture requires(!) them to not only collect and analyze data about the type of requests, but also gives them first-right-to-refuse for all tasks.

3. Developers are "encouraged" to integrate Apple Intelligence right into their apps [3]. This will have AI-tasks first evaluated by Apple

4. Apple has confirmed that they are interested to enable other AI-providers using the same path [4]

--> Apple will be the gatekeeper to decide whether they can fulfill a task by themselves or offer the user to hand it off to a 3rd party service provider.

--> Apple will be in control of the "Neural Engine" on the device, and I expect them to use it to run inference models they created based on statistics of step#2 above

--> I expect that AI orchestration, including training those models and distributing/maintaining them on the devices will be a significant part of Apple's AI strategy. This could cover alot of text and image processing and already significantly reduce their datacenter cost for cloud-based AI-services. For the remaining, more compute-intensive AI-services they will be able to closely monitor (via above step#2) when it will be most economic to in-source a service instead of "just" getting revenue-share for it (via above step#1).

So the juggernaut Apple is making sure to get the reward from those taking the risk. I don't see the US doing much about this anti-competitive practice so far, but at least in the EU this strategy has been identified and is being scrutinized.

[1] https://help.openai.com/en/articles/7905739-chatgpt-ios-app-...

[2] https://www.apple.com/legal/privacy/data/en/chatgpt-extensio...

[3] https://developer.apple.com/apple-intelligence/

[4] https://9to5mac.com/2024/06/10/craig-federighi-says-apple-ho...

Meanwhile sales of the last flagships LG G8, V50, V60 was behind expectations, the period required a massive increase in R&D investment to commercialize 5G technology and Chinese vendors (Xiaomi, Oppo/Vivo/OnePlus, Lenovo) made a huge push into international carrier-markets.

It was all on thin ice already, but there were also some great Mid/High-tier devices in the pipeline, LG was in the lead for commercializing 5G in many markets and had a few aces up its sleeve for the coming quarters like this rollable device.

Then COVID came. Global Sales of the industry collapsed, everything became slower and also semiconductor pricing exploded.

The companies which made it through COVID better than others were those who already had solid brands and high-volume sales before that period. They had the warehouses filled with tested and launched devices, they cut a bit on profit, increased a bit on price and prepared a semi-hibernation mode.

LG's mobile division was not in such a state in most markets. It wasn't profitable for several quarters at this point, and it was clear that it won't be profitable for several quarters to come.

The key tech is less in the panel itself than the supporting structure (the skeleton supporting and stabilizing the panel, you can also see this in the R&D involved in the hinge-tech of folding devices)

Oppo (and Lenovo iirc) were presenting similar rollable form-factors on roadshows or press-events ~2019, but this was prior to the patents (especially [0]) being granted, likely also used the OLED Panel from LG Display (but I'm not sure the designs were actually considering durability as much as LG already did at this stage)

[0] https://patents.google.com/patent/EP3506247A1

[1] https://patents.google.com/patent/WO2014123272A1

[2] https://patents.google.com/patent/US10564676B2

Some bits of background information:

##. The sample shown here is not production-ready, it's a revision "DV2" (visible at timestamp 5:50 in the upper left corner of the device) which was hand-assembled approximately one year before the planned launch (~Oct/Nov 2019) to be presented at CES and closed-door customer meetings.

DV stands for "Development version", which is the phase where all the parts are assembled to proceed development in the various SW/HW/Quality Teams.

In LG-terms that means it was only the SECOND revision of that hardware that the R&D built. Usually there were 4-5 additional revisions on mechanical design, board layout, RF-tuning etc. before entering mass-production (LG cycle: EV->DV1->DV2->DVx->PV1->PV2->MP--> Mass-production)

The MP-revision is the initial mass-production test, where the factory tested if they can efficiently mass-produce this design by producing ~500pcs and keeping notes on issues and difficulties to fix before entering actual high-volume production.