The DUNS number thing is such a disaster even for companies with it. We had a the account under a DUNS of a subsidiary but somehow they wanted us to upload verification docs for the main company, of course not matching exactly how they expect, and there is no way to change it without jumping through a bunch of hoops. Similar issues at Apple. Eventually they let us verify the account with "company letterhead" as if that proves anything (despite them insisting the letterhead needs to say dev@company.com instead of support@company.com, again proving nothing really)
For both Apple and Google it's one of those processes where the support doesn't even really seem to understand how it works (they probably don't know what automated emails are being sent, and what the dev side looks like). They would randomly close cases for "no response" immediately after they replied, ask us to upload something despite their being no way to upload it, tell us to ignore the "your account will be closed email" because it actually won't be (wrong again), etc.
DUNS own lookup page doesn't even let you look up by DUNS number (so we could figure out what company some ancient number was associated with). I bet it's because you have to pay for one of their "solutions" to do this.
It seems like to Google, "customers" will only ever be anonymous data points in an A/B test.
They would have gone down quickly if they hadn't "borrowed" Overture's business model of paid ads.
They have no culture of valuing the customers, or (like Amazon) obsessing about what they need.
Apple is at least slightly different: hardware customers and high-value employees are treated okay from what I hear, but devs are left alone.
Indie developers bring both Apple and Google a lot of revenue indirectly, but they don't really have much of a lobby (maybe they should unionize/hire a lobby firm together).
Why would # of app submissions to be what they test on? It’s revenue to Google. Wouldn’t surprise me if many of the apps that stopped appearing were free apps. Why junk through 20 hoops to make no money?
Indie developers are a nothing burger for Apple. It came out in the Epic trial that over 90% of App Store revenue comes from the major game companies with pay to win games and loot boxes.
I get where you're coming from and I find it just as bad how individual devs are being treated - but talk with some of your family members and non-tech friends about what they've got installed on their phones... And what they'd miss if it got removed.
It's gonna be
1. Social media / chat / SMS apps
2. Games (not one specific one - they'd be fine if any one game is removed, because alternatives exist)
Most if them will not even have a single app installed that can remotely be categorized as indie developed.
There are countless indie devs around that make great games etc - they're just not being discovered by normal people.
Following the money insinuates that is by design, but there is no proof for that... Only circumstantial evidence like the previously mentioned statistic of app store revenue and the way they treat individuals. But still no conclusive proof and both can be argued to be coincidences (i.e. because of low user count they don't consider them important to their platform, hence low visibility in store etc)
Personally, I find it highly suspect that the app/play store so heavily favors apps/games that are borderline user-hostile. Especially if I look to probably the only mainstream store that's looks pretty neutral to me: Steam.
Here your often get 1-4 dev projects hitting the charts. It makes you wonder if the same would happen if Valve became just as profit oriented and started to siphon money via in-app/game purchases too
Probably something more like a trade organization/association would be better. Like the Dairy Farmers Association. Which may or may not hire lobbyists.
It’s not hard. Start a 501(c)3, ask for members to donate and/or pay dues, hold some annual conventions (paid for by vendors) to evangelize the broader mission(s) and recruit new members, hire lobbyists to pursue the collective interests of members, rinse/repeat.
Yeah, DUNS numbers are super easy IME for companies to get, but its hell after that. We had some crazy problems with the App Store where our legal address with DUNS didn't match what we provided Apple, even though we had updated it with D&B, but Apple's systems weren't pulling in that update, Apple told us to talk to D&B, D&B told us to talk to Apple... we ended up literally just making a new corporation and starting from scratch.
I first encountered Electronic Data Interchange in the early 90's. The small shop I worked for at the time had no idea and just wanted to make the parts they quoted and send them when done.
The EDI request came in a box, with external modem, a paper with phone number and directions and then a smaller box with PROGRESS database software for MSDOS in side and a handful of disks containing the EDI system.
Good lord that was painful! I just plowed through it and all that pain completed a check box at Honeywell, who then sent us jobs electronically!
Yes, via FTP.
The CAD they were sending was Computer Vision and it was a full on solid model representation! At the time we were running CAD from the early enlightenment, CADKEY 3.5 for MSDOS!
Our best micro computer lacked the storage to handle the uncompressed file, which arrived on another handful of floppies that formed a multi part. Zip file, which uncompressed totaled about 40 megabytes and change! Entire systems only had 20!
The CAD system failed to translate the data too. 16bit pointers lacked the range needed. They had me fetch a patch a day or two later and it took a few hours to do.
300 kilobytes of wireframe CAD, and the parts we made were basically 5 percent of that data!
FTP can be as secure as any other protocol. Enabling encryption on the server side is generally as simple as installing a certificate and turning on an option. And most FTP clients will default to using encryption if it is available; for the clients that don’t do that, it’s just another server option to require clients to use encryption.
> And when companies say they use FTP to exchange data, they don't tend to mean SFTP. They really do mean FTP.
Because SFTP is a different and entirely unrelated protocol. The encrypted version of FTP is sometimes known as FTPS, but it’s really just a variant of FTP. So it would be inaccurate to call it SFTP, but referring to it as simply FTP doesn’t imply a lack of security.
> The AUTH command is generally sent before encryption of the connection is made.
So…? What is the danger of negotiating an encryption protocol over plaintext? No credentials or sensitive information are sent via the AUTH command, and a server that disallows unencrypted connections will simply refuse to go any further with a client that doesn’t support encryption.
> It’s also vulnerable to a huge swathe of timing and weak hash attacks.
Gonna need a source on that. And even if such attacks potentially exist, in the use case you mentioned above I’m still not seeing how encryption combined with, for example, IP whitelisting can’t effectively be as secure as anything else you could use.
I mean, if they’re really not using encryption then yeah, that’s stupid and all bets are off. But there’s nothing inherently insecure about the FTP protocol.
Negotiation over plaintext is a vulnerability, yes.
Neither side of the pipe is secured, so absolutely everyone inbetween is a MITM waiting to happen. Someone else can negotiate what encryption gets used. Such as the still supported MD5 signing-only.
Which also means your IP whitelisting does bupkus, unless you trust every single interchange of your, and your clients, telcos.
It’s only a vulnerability if you’re using vulnerable encryption methods, at which point you’ve already introduced a vulnerability. You could make the exact same argument about STARTTLS vs implicit TLS, but it’s generally understood that, as long as the only allowable protocols are themselves secure, there is no difference in security between the two.
No, the negotiation is in plaintext. You don't get to choose whether or not you use a vulnerable encryption method.
That same problem in STARTTLS is how we ended up with CVE-2011-0411.
> The TLS protocol encrypts communication and protects it against modification by other parties. This protection exists only if a) software is free of flaws, and b) clients verify the server's TLS certificate, so that there can be no "man in the middle" (servers usually don't verify client certificates).
There's no certificate verification in FTPS - it's too early - so you're screwed. [1]
FTPS is the vulnerable encryption method. It's the reason that SFTP is recommended, and FTPS is not. [2]
Validation issues happen all the time for subsidiaries when the parent company likes to own/manage things. Always fun when e.g. EV certificate validation (sigh windows update stuff) calls the parent company reception and asks for the manager listed as owner, and they just go "who?".
The One Weird Trick I learned was to to get a company attorney to write a professional opinion letter saying that you are indeed authorized to get a cert on behalf of your company.
Incredible experience with this: our App Store account was from an acquired company that was no longer doing business. The Apple representative requested documentation that the no longer in use LLC was in fact, no longer in use.
When I requested what documents they might think a defunct LLC was creating that would prove it was defunct, they didn't have an answer. Same as others we ended up just making a new fucking developer account.
Same issue but we actually got the account assigned to the new company, but I think the DUNS was still the old company so any time they require verification (e.g. for trader status), the account is stuck in some weird state that is halfway between two companies.
This happens to Google Cloud partners all the time, too, when there are acquisitions, mergers, or DBAs where the legal business entity changes even though the practical relationship stays the same (with the same people, same contact details, same billing/payment accounts, same contract terms, etc). It's extremely irritating.
Both Apple and Google need to be regulated. Their vice grip on app distribution, app defaults, search defaults, payments defaults, user credential saving defaults, messaging defaults, browser defaults, and then their brutal taxation of almost all web e-commerce and businesses is beyond the scale of whatever Standard Oil had.
You cannot do business on the Internet without paying the Apple and Google toll. They control all the points of ingress and egress, and they tax everything that moves.
It'd be bad enough if they were just charging money, but they also make you jump through hoops to design software their way, do unplanned upgrades to their cadence, prevent you from deploying emergency hot patches, prevent you from updating software dynamically, prevent you from knowing your own customer, etc. etc. etc.
And they're happy to sell your competitors ads to outrank you for your own trademark.
These companies need to lose their control over this. Web distributed apps must become the norm.
You can't tell me that with sandboxing, signature scanning, and some clever heuristics, that we can't make mobile completely safe for free and open distribution.
For reference, the regulation you are probably referring to is Article 30[1] and Article 31[2] of REGULATION (EU) 2022/2065 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 19 October 2022 on a Single Market For Digital Services and amending Directive 2000/31/EC (Digital Services Act).
Article 30 requires capturing and vaguely defined validation of the following information supplied by a trader (includes traders of software):
- the name, address, telephone number and email address of the trader;
- a copy of the identification document of the trader or any other electronic identification as defined by Article 3 of Regulation (EU) No 910/2014 of the European Parliament and of the Council;
- the payment account details of the trader;
- where the trader is registered in a trade register or similar public register, the trade register in which the trader is registered and its registration number or equivalent means of identification in that register;
- a self-certification by the trader committing to only offer products or services that comply with the applicable rules of Union law.
Article 31 requires at least the following trader information to be displayed to potential buyers:
- name;
- address;
- telephone number;
- email address;
- clear and unambiguous identification of the products or the services;
- information concerning the labelling and marking in compliance with rules of applicable Union law on product safety and product compliance.
Do you think I somehow personally chose where my apps would be more popular or less popular? If they wanted to cut off my apps in only European regions due to European regs it would be disappointing but understandable.
It's amazing to me that there are some people that will go to these lengths to defend the profits of one of the largest corporations in the world.
At no point does it even occur to you that Google are already bending you over a table with their cut, and you're already white knighting for them even in a completely hypothetical situation.
Do you have very strong investments on Google? Otherwise, I really can't explain why an entrepreneur would ever think the way you do.
For both Apple and Google it's one of those processes where the support doesn't even really seem to understand how it works (they probably don't know what automated emails are being sent, and what the dev side looks like). They would randomly close cases for "no response" immediately after they replied, ask us to upload something despite their being no way to upload it, tell us to ignore the "your account will be closed email" because it actually won't be (wrong again), etc.
DUNS own lookup page doesn't even let you look up by DUNS number (so we could figure out what company some ancient number was associated with). I bet it's because you have to pay for one of their "solutions" to do this.