Sometimes you also find hidden things lurking accidentally left behind in IPAs and APKs that are nice and juicy and realize they've been shipped on Google Play/App Store for years.
I've found everything from entire copies of internal company manuals to working test credentials for a physical place with a membership barcode in debug logs left inside the app from developers.
Also sometimes changelogs left inside by accident which include things like "It hasn't been sanitized for outside consumption and thus should remain internal
to <company>. Deliver it externally at your own risk of embarassment."
.docx and .xlsx are also just zip files with XML and attachments. The bad thing is that the XML is Word's internal document structure serialized and behavior for some values is only defined in Microsoft's code.
I've worked on docx and xlsx import/export and the public documentation for the formats was sufficient for normal documents (maybe excluding some very exotic features). That was ca 2010.
Well the executable binaries inside IPAs are encrypted, but the IPA bundles themselves are typically unencrypted. You should be able to see unencrypted assets inside of them
Even better, wait until people discover 7zip's 'parser mode' on Windows (especially). Right click a file -> 7zip -> Open archive -> #:e mode. Really fun way to quickly carve out files and snoop around. I use it like a poor man's binwalk to extract firmware files and updates and etc out of things to usual success.
(#:e Parser mode, ignoring full archives, and checks every single byte position of a file for 'start of archive' bytes to parse archives out of a larger file.)
There is much more to a web browser than just its rendering engine. When you install Firefox on iOS, you get Firefox. It uses the WebKit rendering engine, but it’s still the Firefox browser.
To be frank, it’s pretty insulting and dismissive to all the people putting huge amounts of work into building browsers only to for you go around telling people that all their work is really just a mirage.
It absolutely is a mirage. It's like those Ferrari kit cars where you take a Ford or whatever car frame and remove the outer shell and put a Ferrari shell on top of it. It's not a Ferrari, it only looks like a Ferrari.
The browser engine is the majority part of the browser, everything else around it is window dressing. So when you install Firefox on iOS, you are getting Safari with a thin wrapper around it. You are not getting the Firefox rendering engine, which is the most important part of a web browser.
The problem is that it has to use the WebKit rendering engine, and not that it happens to.
I think it's more insulting to browser vendors that they have to throw away their browser engines to appease the monopolistic tendencies of one company.
It’s been there since literally iPhoneOS 1.0. They are calling it “share” now, but really it’s always meant “put / send this somewhere”. The difference with recent versions of iOS is that the share button is no longer always visible but you need to press the ellipses button to reveal it. It’s there along with all the other dastardly actions Apple doesn’t want you to know about, such as “Add to Favourites”.
Here’s what Mozilla has to say about Web NFC, for example:
> We believe Web NFC poses risks to users security and privacy because of the wide range of functionality of the existing NFC devices on which it would be supported, because there is no system for ensuring that private information is not accidentally exposed other than relying on user consent, and because of the difficulty of meaningfully asking the user for permission to share or write data when the browser cannot explain to the user what is being shared or written.
And here’s what they have to say about Web Bluetooth:
> This API provides access to the Generic Attribute Profile (GATT) of Bluetooth, which is not the lowest level of access that the specifications allow, but its generic nature makes it impossible to clearly evaluate. Like WebUSB there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted to only rely on user consent, which we believe is not sufficient protection. This proposal also uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a significant risk to users and their devices.
The fact is that Google wrote these specifications, couldn’t convince any other rendering engine to implement them, and somehow it’s Apple’s fault the rest of the world rejected their idea.
These are not web standards, they are Blink-only APIs that Google decided to build unilaterally. The web is not defined by whatever Google wants. Web standards are supposed to be arrived at through consensus, and the consensus is that these things should not be part of the web.
>and because of the difficulty of meaningfully asking the user for permission to share or write data when the browser cannot explain to the user what is being shared or written
So fucking moronic privacy virtue signalling BS holding technology back.
They're doing the same thing with Web Bluetooth.
"hurr de durr we can't ask permission" Yes you fucking can, you give me a modal to confirm leaving the current page and being redirected to a new one (in some cases, but not all), you give me a pop up when a site asks to send shitty notifications (as they all do).
An app can sit and use nfc/bluetooth in the background all day long...a site can only do it while I actually have it open in the browser and presumably it's foregrounded etc.
It's really, really NOT hard for them to implement this stuff & I feel like it's less "this tech that has been in phones for more than a decade is unsafe!" and more "we need to cry about features that Chrome is pushing for us to support because otherwise we're letting them lead".
>The fact is that Google wrote these specifications, couldn’t convince any other rendering engine to implement them, and somehow it’s Apple’s fault the rest of the world rejected their idea.
Apple is on the W3C board that gets to decide which APIs become standards. They are preventing these APIs from becoming standards. They have an interest to forbid Web Bluetooth and NFC from becoming standards, because they profit heavily from native apps on their iOS platform, where they collect a percentage of all sales made through apps, so they want to force developers to create native apps instead of web apps.
I'll also point out that Opera, Edge, Samsung and others did implement the Web Bluetooth API, so you are wrong about your assertion that they "couldn't convince any other rendering engine to implement them".
If you don't think Apple is abusing their power here, then you are either lacking understanding of how Apple operates, or you just love Apple a little too much.
> Apple is on the W3C board that gets to decide which APIs become standards. They are preventing these APIs from becoming standards.
They are not. You have this almost entirely backwards. To become a standard, you only need two independent interoperable implementations. This means Apple cannot block something from becoming a standard. The only thing Google needs to do is convince anybody else to implement their proposals. So far they have managed to convince precisely zero other rendering engines to do so.
> I'll also point out that Opera, Edge, Samsung and others did implement the Web Bluetooth API, so you are wrong about your assertion that they "couldn't convince any other rendering engine to implement them".
All of these are Chromium / Blink users, not independent implementations.
If Apple won't allow an API onto Safari because it competes with native apps, then why should Firefox bother to implement it? Just because something moves forward in standards, does not mean Apple will ever implement it in their browser. They may never, and so why should Firefox do so, if Apple just blocks Firefox on their platform anyway? Chrome already has the APIs I want on Android, so Firefox won't spend the money to implement a non-standard before it is a standard.
Apple has a lot more control over this situation than Firefox does, and Firefox has limited resources.
The article as a whole makes no sense. They are generating UI with an LLM. How fast the UI appears to the user is going to be completely dictated by the speed of the LLM, not the speed of the serialisation.
The only thing it tells us is that they have received competent legal advice. Any counsel is going to tell you to shut up regardless of whether you are in the right or wrong.
> But that only really helps you when you're dealing with websites in a browser, and when you want the address to resolve back to your local machine. So it wont help you with other programs like python/wget/etc or any calls you make to getaddrinfo()
https://en.wikipedia.org/wiki/Threshold_pledge_system
reply