Disposable, anonymous email forwarding is a massive step forward for privacy. I know we've all been doing it for a while, but this on a consumer level is fantastic.
And being done by Apple, most services can’t just reject these the way they do with Mailinator addresses, since it would be throwing away a giant chunk of their revenue. Apps with huge consumer demand like Uber or Facebook could get away with it, but not the vast majority of apps.
Right. One of the big things about Apple getting into something, even if it's been done before, is that they carry enough influence to strongarm other companies into respecting their paying customers. It's great.
It strikes me as terrifying, personally, but to each their own.
I have been responsible for creating and maintaining an app generation system. Among other things, it taught me that App Store Connect has many sharp edges showing how easy it is to abuse the kind of power you've correctly pointed out Apple has.
In a world where every other tech company swindles and manipulates consumers at every opportunity, I'm happy that at least one is incentivized to do the opposite, and has the power to do so.
Apple swindles, manipulates and mistreats developers to further their own ends.
It's perhaps less evil than the kind of wholesale data-farming the other big tech companies are engaged in, but it still doesn't make me like the idea of Apple ascendant.
And I was raised on Macs, giving Apple a heavy nostalgia bonus that they burned years ago.
Apple takes powers from developers hired by greedy companies and puts that power in the hands of the users.
You find that you're being strongarmed. As a oonsumer, I could not care less. Hell, I am thrilled that developers are being strongarmed when it comes to user privacy and security.
I'm not concerned with Apple refusing apps that do seamy things (though "seamy things" is more subjective than you might think, as Apple is well aware).
I am concerned with things like Apple's terms of service saying "If you put an app in the store, we reserve the right to copy it and ban yours."
Yes, there are more charitable interpretations possible, but Apple does have some history of cloning and killing off third party software, so I see no reason to apply the more charitable interpretation.
How is it evil? Apple is saying that their customers aren't yours to pillage. No developer is forced to write for the Apple platform. If a developer doesn't like the terms, there will always be another developer willing to fill the gap.
Who said the Windows/Android model is the morally correct one anyway?
As a customer I'm glad that Apple is providing a truly different alternative.
I guess I was not especially clear, so my apologies for that.
I'm not scared of this anonymous signin feature, per se.
I'm scared of the sheer amount of power Apple has, and that they can abuse it to force third parties into compliance with what they think software should be.
Apple swindles and manipulates the user to buying a new device whenever there is any fault at all because everything is glued and soldered together so fixing anything requires buying half of the device.
Personal experience. Battery change on iphone SE, cost $75. They couldn't safely do the replacement (broken tabs on battery) and they simply replaced the phone.
I'm not sure how this is manipulating to get me to purchase a new phone.
That's not much better. Another phone goes to landfill because not even apple was able to repair it due to their horrendous practicices. It took me half an hour to remove a battery from an iPhone and I had to get the hair dryer out to melt the glue. With other devices I just unscrew a bracket holding the battery down and it takes me 5 minutes.
Has a recycling program =/= everyone who ever purchased an iPhone is using that recycling program.
7.8 million "Apple devices"[0] in 2018 is a lot, but an average iPhone is far more likely to end up on a landfill. If it were easy to extract the battery, that wouldn't be such a problem.
I don’t think that is a fair comparison. Aside from hardware va software I personally have never had an issue with apple products last 3 or more years. Get apple care and they just fix or replace it when anything goes wrong. Better experience then my friends seem to have with other manufactures.
I have a collection of broken apple products from other people who were going to throw them out. Usually they have a fairly minor issue but its just about impossible to fix because of the use of insane amounts of glue or one way clips
It’s pretty funny though that you consider a few dozen Apple broken devices as "a collection" meanwhile a few dozen of Android broken devices is generally considered "a pile of thrash".
And this effect is massive last week I offered two of my old laptops to a friend child wanabee hacker. He quickly considered a 2012 HP for parts, then he kept on thanking me for a working state 2002 PPC iBook.
PS: To be honest he might be ranting about it in a few day, I’ve played around it a little and that 2002 iBook bios is a mostly undocumented nightmare!
I went through the pile of Apple stuff we'd collected over the last few years and repaired them myself. Annoying + fiddly but simple and extremely possible with some spare parts, a $20 toolkit, and care + patience.
The battery glue is like a 3M command strip, you're supposed to remove it by applying tension to the side. You need the heat source if the strip breaks and gets trapped underneath, but I used dental floss instead.
I’m tired of gmail and hotmail forcing me to sign up using my personal cell phone number. Finally I can create throwaway emails without resorting to gmail!
I think this will be proven wrong. Do you think that the folks using Mailinator are strictly non-Apple users? As an Apple user that signs up with a mailinator ID, if rejected I either move on or use a more palatable address, as the case may be depending on my desire to use that service. The same will hold true for any private appleid address.
I’d say that one month from release, 100 times as many people will know about Sign in With Apple as have ever used Mailinator. And Apple marketing will drill into them why they should use it, and mark apps in the App Store that support it. Eventually for experimental apps that they are not 100% decided on getting, there will be a large fraction of users who simply won’t try an app that doesn’t support it.
1. Services have little incentive to support mailinator, and indeed may deliberately choose not to if they feel it is leading to signups they don’t like. On the other hand it would be hard to argue with an incentive like the App Store requiring you to support apple’s service.
2. Because the service is built in to apple’s systems there seems to be an implicit contract that apple wont let it be abused for the purposes that many sites claim mailinator is used for (because it isn’t useful to apple customers if sites don’t trust it and it). So they might be more willing to accept these email addresses.
I guess neither of these help services like mailinator gain credibility.
You're missing the scale. Mailinator users are a very small percentage of users, while Apple Sign In users are likely to represent a much larger slice of your potential users, given that you have a honking great button there waiting for them.
They also have pretty strict whitelisting requirements around who can send emails to these privacy addresses.
"In order to send email messages through the relay service to the users’ personal inboxes, you will need to register your outbound email domains. All registered domains must create Sender Policy Framework (SPF) DNS TXT records in order to transit Apple's private mail relay. You can register up to 10 domains and communication emails."
Neat. It sounds like this extra step prevents a situation where, for example, a dev's server-side database gets hacked and the users' relay e-mail addresses are exposed.
The attacker wouldn't even be able to send e-mail messages to the users. He'd also need to compromise the registered domain's mailservers, or their DNS servers (to modify the SPF records), or their Apple dev account to add their own registered domain.
From the web page, I cannot tell what pricing is going to be - looks like you go out of your way to not scare off potential users. I can't find pricing information at all via Google searches, either.
That's something I really dislike. Perhaps it's a necessary evil.
That page should have some sort of indication that it's scrollable since browsers increasingly don't show visible scrollbars until you're already scrolling. Something like Bootstrap's scrollspy might be useful since it could also show you the sections further down before you scroll through the intermediate sections.
I pay $30/year for a cpanel host that includes unlimited mail forwarding for any address on any domain. This is a byproduct of what I really do which is host a bunch of sites. $48/year for email scrubbing seems like a high price.
I think it’s great, and use it a lot. Just wonder how you got to that price vs like $10/year.
Pro users subsidise the free ones, unfortunately. Assuming a 1% conversion rate to pay server costs and 1-2 devs full time at 4 usd/pro user/month you need 2500 pro users, which is 250,000 users.
That and people pay 4 bucks for a coke these days so it’s not really much. Also cPanel is most definitely an expert tool.
I might make it paid only soon and reduce the price but at present there’s not much option to get real feedback and user traction.
Thanks, this helps me understand and I appreciate you going into cost model for something that’s really up to you to decide.
$4 is not very much, you’re right, but that doesn’t mean that it should be spent unwisely otherwise it adds up quickly. It seems unlikely that this would need a full time dev to operate and seems more like a “4 hour workweek” type business once it’s set up that would have pretty minimal maintenance, or a super bored developer waiting around for a bug to patch.
Do you think you’ll drop the price once you no longer need a dev?
This looks a lot like 33mail (https://33mail.com/) which I've been using pretty happily for 4-5 years now (and paying I think $10-15 a year for, so a lot less than this on a per month basis, but they're not strictly unlimited)
33mail is cool but the domain being the same & unique for each user removes the privacy element, and it asks users to make up their own addresses (and remember them), which can be dangerous. For example you might create facebook@dave.33mail.com, so it’s very easy to guess what Dave’s twitter login is or other target.
With Idbloc (and apple sign in) the address is completely random and untraceable, and it’s impossible to tell which addresses belong to which users.
the super annoying "can i help you?" popup after 10s is revolting. i closed the tab immediately without learning more. it's cheesy, pushy, and seems antithetical to a service that offers privacy. i recommend you turn that thing off.
Thanks for the feedback, I’ll try to tone that thing down a bit. The thing is, some people LOVE the chat widget. Especially for those users who don’t want reveal their real email address but have a quick question. I’ve had at least 3x more chats on there than support emails.
Chat is awesome. Personally I love it. You get to talk to someone in real time. What's not to like about it. I'm not sure why the OP is so revolted by it. Maybe remove the sound but leave the popup and chat.
Except it’s not real time until a support person is notified and responds minutes or sometimes hours later. Chat pop ups feel like a lame trick these days every time I try to use them; they pretend like they’re going to be fast and then make you waste your own time waiting. The last one I used the other day made me wait more than 10 minutes, so I did something else, and when the support person responded and asked a follow up question and I didn’t answer in 5 seconds, they closed the support ticket, making me start over. I’d rather use email.
Maybe just have a chat button or a link to the chat on your support page? I'm in the strange position of both liking the chat approach (I've used it on Dell's site, probably others), and also very much disliking chat popups. It feels like it's really there so that someone can convince you to buy something. It's even worse when there's a fake initial message - "Hi there, I'm Jen. Can I help you?" - it seems especially imposing.
Great! I used a service like this many years ago and they shut down after a few years. Have been looking for the same thing for years but seems like nobody's been doing it, or at least not in a user friendly way. Will give this a try.
I've been trying for some time to explain to my friends and family how a unique email/password + 2FA strategy is the best thing to do and how it would allow them to cut one in case it gets leaked. I guess I will just tell everybody about "Sign in with Apple" now, it will be easier.
Family is easy, I made them switch to Apple years ago and things have been a breeze since. Most of my friends using Android are also working in IT and are already using disposable/forwarding emails AFAIK. And... to be honest, I don't have friends using Windows :D
I agree that it is great. I'm not sure how we convince people to not signup on sites that don't offer this SSO option. I've always struggled with the question of 'How do we convince people to care about privacy when they post their location and meal to a public social media every hour?'.
My rule, and it is a semi-idiotic one, is "i don't impulse buy from independent merchant websites that don't support apple pay at checkout".
I usually email them after, too. "I actually clicked through your instagram ad, looked at some clothes that looked nice, and didn't buy anything because I was on my phone and didn't want to make a new account and add credentials to my password manager. Have you considered adding apple pay support to your shopify account?"
I think it's not an idiotic idea, it's just that your idea of what counts as third-party payment support is a single smaller payment provider located mainly in the United States. I follow a similar policy, but in my case the third-party payment services are Paypal, Stripe, and Coinbase, all of which are reliable and don't require me to give financial data to the seller. Paypal seems to be near-universally supported on small ecommerce sites.
Note that PayPal gives away your email address, and I’m not a fan of that. If a third party wants my email address, they should ask me directly (and I’ll give them a unique one); PayPal shouldn’t distribute my email address for me.
Look, I use three email domains for online accounts, in addition to a unique address for each account — one domain that links to my actual identity (my public-facing, professional domain), one domain that’s somewhat anonymous, and one domain reserved for highly sensitive accounts, e.g. online banking, PayPal, AppleID, etc. And PayPal sharing my email address with third parties breaks the model, making my sensitive domain less secure.
i picked shopify because i know they have an apple pay switch.
i don’t care who processes the payment, i just like being able to buy physical goods without making a new account, and ideally without any more friction than faceID while impulse-buying nonsense while i’m on the toilet :)
Convenience. This feature is good even if you don’t care about privacy.
Password management is a big problem for non-technical users. Even for people who don’t know/care about security and reuse the same password everywhere, it presents a huge issue when their preferred password doesn’t meet the website’s requirements. They are then forced to make one up which they’ll never remember so it’s gonna be a headache down the line when they need to sign in again.
When they learn that the magic “Sign in with Apple” button allows them to avoid all that, they’ll want it even if they don’t care about privacy.
No worries. I am at least glad the product is still alive. Despite being a competitor, there is a lot to admire about the offering. I am really bummed it didn't come out ahead of other competitors :)
Mailinator can be pretty hard to use, since so many sites can detect the addresses and block their use.
I've pretty much given up on it, and use Fastmail's very easy aliasing features with my domain. It's not quite as private, but it's a lot more reliable.
If I recall correctly, mailinator lets you host your own DNS record that sends mail to them. While I have never had any problems, back in the day I had nospam.jrock.us forward to mailinator and that worked every time.
The truly clever programmer could open an SMTP session to the mail exchangers specified in your email address, and reject you because they point to mailinator. I know of 0 programmers in the world that have written this code. I think you could ask the vast majority of programmers that work with email addresses and dark patterns to do this, and they wouldn't even know how. So you're probably pretty safe.
I use mailinator all the time and I have never had a problem, however, which is why I don't even have the MX records to host my own anymore.
> If I recall correctly, mailinator lets you host your own DNS record that sends mail to them.
While I'm sure that works. The main reason I'd use mailinator is for privacy (i.e. not exposing anything associated to me). If I have to use my domain, rather than their free ones, I'm still identifying my domain, so I might as well use my own aliases with my own mail system.
Domains are cheap, and mailinator really ought to register and discard a bunch of $1 specials on a regular basis.
I'm not the commenter. But taken at face value, your comment could be either bye bye mailinator.com (I'm not using you anymore) or bye bye mailinator.com (no one is going to use you anymore). Fwiw, I thought you meant the latter until I read your reply.
The knee jerk comment is yours. 'Bye Bye Mailinator' is too short to convey anything useful other than the general case, that you believe that you or those that use Apple will defect from Mailinator in droves. The typical use case for Mailinator and the overlap between the Apple eco-system as well as the fact that they specialize in this and that for Apple it is 'just another feature' makes me question whether or not you have thought through the ambiguity in your comment, by taking the most probably meaning and responding to that you have a chance to clarify your position.
Why would this break any databases? Accounts will still have valid emails. The difference is just that there won't be data for that email in third-party tracking databases, which is a good thing.
I think the email is consistent for each app, so there should only be a problem if the user wants to change their email, right? Plus, apps would have to opt-in to support this.
In case anyone needs something similar today: Outlook already allows you to create ephemeral top-level aliases, i.e. XXXX@outlook.com. You can use this to sign up, then delete the alias. It can't be traced back to your account and nobody blocks @outlook.com.
Microsoft's email management has some neat perks here: You can change which one's the primary as well. It's entirely possible for you to change the email address of your Microsoft account, by adding an alias, making it primary, and then deleting the original. In fairness, there are some quirks with this, my old email address would still get sent some receipts or some newsletters because the configuration for service A, B, or C was buried somewhere else in the account. But generally speaking, it works pretty well.
As someone who changed their name but had to keep their Google account with the old one because of how much Google account data/purchases can't be moved to a new account, this felt positively revolutionary. Google accounts can only have one Gmail address for their entire lifetime.
I dont think thats quite the same thing as an Identity Service, its just a component. In Microsoft's world im either using my Microsoft Account to sign in OR using throwaway email addresses, not both.
.
Apple can get way ahead of the competition by combining about 3 things.
1) Ephemeral email addresses
2) OAuth or apples equivalent tokens
3) Keychain autogenerate and auto-populate
If all those products are integrated correctly, this becomes the SINGLE sign on of single sign ons. If a service supports Apple OAuth, your name is hidden, and you only have one Apple password to remember. If the service doesnt support Apple Tokens, then apple fills in a private email address and a random password, and abstracts away the fact that the service doesnt support Apple Tokens. The user experience is nearly the same regardless. Tokens and randomly generated passwords should be managed from the same interface, allowing you to either revoke access (token) or cycle the key (both.)
I've felt it for a while, but the banking industry needs to arrive at something similar. Chase, BoA, WF, and Citi should turn Zelle into a banking OAuth Identity Service.
Why do users need to have a 3rd party managing their identity? It seems like it would be _safer_ if users could setup their own OAuth infra which would then be certified for use with other systems. For people who lack the expertise or will to roll their own infra then they can use something like Apple ID.
How many people do you know running Mastodon nodes instead of using twitter or facebook?
>For people who lack the expertise or will to roll their own infra then they can use something like Apple ID.
SO 99.9% of the population. It's a nice sentiment, but for what apple is doing to work (random username generation, and identity obfuscation) the only way for it to work is strength in numbers, that the Apple userbase of people who will only use frictionless sign in, becomes too big to ignore, and to tempting too left uncourted.
>It seems like it would be _safer_
Im not sure I would say safer. Depending on millions of people to keep their software up to date hasnt historically worked super well for Windows and Wordpress. One central authority patching all its services and 24/7 devops sounds a lot safer than trusting millions of self hosted OAuth servers to be up to date and not compromised. What percent of people who have non-self-updating home routers, do you think go in regularly and press the update firmware button?
Sorry I meant by the service you're signing into, any of their 3rd party trackers, or in case of a data breach. This sets it apart from e.g. gmail's username+servicename@gmail.com, or a wildcard on a private domainname which only you ever use.
In some countries, it's fiscal liability - such as paying hefty fines. In others, that are not so friendly, the HR representative who receives/processes the legal request and/or whomever the country wishes to charge could very well land in jail[0].
In a choice between strictly maintaining your privacy and fines/jail time, most - if not all - companies will sell you down the river (if given a feasible chance that it doesn't entirely ruin them, say for example, if they weren't purely in the privacy trade) to save their own hide[s] (e.g.: see the whole PRISM scandal and its fall-out).
I'm so mad I missed the window where you were supposedly able to merge email accounts. If I want to merge existing separate accounts now I have to terminate the old account, wait like a 9 months/a year(??) for it to expire and be purged, and then add it as an alias, assuming MS doesn't hold the expired account name >:C
According to the App Store review guidelines update posted today, Sign In with Apple will be required for any iOS app that implements a single-sign in button.
"Sign In with Apple will be available for beta testing this summer. It will be required as an option for users in apps that support third-party sign-in when it is commercially available later this year."
This is Apple sensing weakness and dropping a bomb right on facebook’s doorstep. And they sidestep the anticompetitive angle by arguing that instant anonymous sign on is simply a better UX, which it is.
It is an incredibly bold move. Just as tech monopoly power comes under scrutiny--in Apple's case the AppStore--they wield said monopoly power...but for a seemingly good cause.
Lol, I doubt it. Apple is years late and sucks at doing the leg work of getting third parties to adopt its suck. Look at Apple Pay which was launched at the perfect time.
Great 1% of online stores supports it. I am sure only a fraction of that traffic actually uses apple pay. You are comparing it to google pay that had a terrible UX and like four conflicting versions. They had to catch up to apple pay once it launched. Apple had the perfect product at the perfect time. They complete wasted the US chip switchover. They could have dominated retail purchases.
Practically any point-of-sale that supports NFC also supports Apple Pay. Adoption rates may vary by region but NFC penetration is very good where I live.
I have switched almost exclusively to Apple Pay, and frequent only one chain of gas station because they rolled out NFC at all of their pumps last year. After the introduction of chip readers gas pump mag stripe readers became the main vector for card skimming in my area and even with the security stickers all of the gas stations have been putting on their pumps I don't trust any mag reader anymore.
At locations that don't have an Apple Pay logo on their card readers, like my local movie theater, I have spied the NFC logo and given it a try and it works.
Except for Amazon, almost all of my online shopping is now done through Apple Pay. I have a shirt out for delivery today from a small retailer I had never heard of before that I purchased with one click and a fingerprint via Apple Pay.
It has not only changed how I buy things, but how I dress. Instead of my George Costanza wallet I only carry an ID and two cards in a slim front pocket wallet, relying on Apple Pay for almost everything and walking out of a store if they are cash-only or don't support chip/NFC.
Regardless of your chosen NFC platform, I recommend that everyone use it and shun points of sale that don't have it.
Apple Pay has been my primary payment method since the day it launched in the UK.
Fortunately, most payment terminals in London already supported NFC payments thanks to NFC debit and credit cards long being prevalent here, and Apple Pay is just tokenised NFC payments.
Same is true of literally every iPhone owner I know, and usage simply increased as payment limits went from £20 to £30 to unlimited (unlimited on Apple Pay, but still limited to £30 on NFC cards or when using older payment terminals).
Plus I got to ditch my oyster card and just use weekly fare capping after a while too. Good times.
I use Apple Pay for almost all my purchases in Singapore, where almost ~80% of merchant terminals support it. Recently, Singapore's train system started allowing Apple Pay payments at the turnstiles. Using the Apple Watch at the turnstiles without having to fumble for the stored value card is amazing.
Even the existing Sign In with Facebook is implemented terribly by many apps, e.g. requiring me to enter my password in app instead of calling out to the Facebook app like maybe 50 of apps support properly.
I think honestly this comes from apps that are built with cross platform frameworks but its still frustrating.
Further more it drives me crazy new apps (and websites) released this year focused on mobile (e.g. pay for fuel at a fuel station with your phone) and I can't even auto complete the credit card or name using the new keyboard extensions because they somehow labelled the forms in a way apple can't figure out.
I'm really curious to see if this impacts enterprise apps that are configured by an administrator to use an internal SSO provider, or if this only applies to apps that allow users to sign up.
For example, Slack can be (and is often) configured to use Okta or some other SSO provider. Does the Slack app have to implement some kind of support for Apple Sign In when such use cases are involved?
Apple have always had excellent Enterprise support on iOS, including "private apps" and what not. There is no reason to believe the same exception wouldn't be extended to Enterprise Devices and Apps.
Therefore, anyone offering Facebook/Google login will also have to accept Apple's anonymized forwarded email addresses, like fc452bd5ea@privaterelay.appleid.com.
But this explicitly doesn’t work as an SSO. How can I tie that back to the actual email address they would have used to create an account using their FB / Google account?
This sounds like a tremendous headache that I really don’t want to worry about. But Apple is looking to leverage their power in the app market to force me to implement a tool I may not be interested in as a merchant?
I despise being strong armed. I hope the EU crushes this.
It seems the email part is optional (ie you can choose to share your verified email with the company if you want).
The above scenario goes against what they are trying to achieve though
1) If you support SSO and email/password - then the email and password are still stored (and possibly not hashed and salted if the developer is incompetent) - so you are at risk of compromise if you reuse passwords
2) If you store the users actual email, you are putting them at risk of credential stuffing, as well as opening them up to tracking
The EU can always surprise, but I suspect they would actually like this because it addresses key risks to consumers of password reuse, credential stuffing, and tracking. Additionally it competes against their ideological targets, Facebook and Google.
EU is not picking on FB and Google specifically. This mindset is toxic. They are picking on all monopolies for European customers and have been for a long time. Basically we believe the market is not healthy if there isn’t any competition.
This is a bit rose tinted outlook. GDPR does not increase competition, the amount of regulation in EU and worker protections in place raise barriers for new competitors. France has laws that prohibit new movies from being put on Netflix in order to support local distributors etc.
Not saying what the EU does is goos or bad, but painting it as pro free market competition seems unfounded.
GDPR isn’t about addressing monopolies. It’s about addressing privacy and data ownership.
Every tech related legislation doesn’t and shouldn’t need to so,be every tech related problem. The EU has other, non GDPR related, mechanisms to handle monopoly issues.
My point is EU will adopt regulation that actively harms competition (such as GDPR), because they have different priorities (e.g. privacy, data ownership as you mentioned).
So to me it seems unfounded to say EU cares about market health and is not, in fact, just picking on FB and Google.
I am honestly curious what you think are examples of EU mechanisms fostering healthy markets. Maybe the MS case but that is the same “EU picks on US tech giant” genre.
Presumably it’s always the same address every time they sign in. It is used for single sign on after all!
However, I wish email and sms would go away as a way to authenticate. Until it does I will be using foo+aliashere@gmail.com so that my account can’t get transferred to someone else through socially engineering a tired rep.
But someone who has already signed up via FB is going to click that button and then get angry when we can’t log them into their account.
I personally don’t use FB login. And I use `+merchant` to keep track of bad actors. But from a merchant perspective this will likely be a chore. And Apple has decided that we don’t get to decide if it’s worth it. We can’t disable FB login because we’ve supported it for a long time and a ton of accounts only have a FB-synced profile.
To be clear, it’s not the product I have issue with. It’s the draconian ultimatum that because we are in bed with FB we have to also get in bed with Apple Sign In.
They could have just built this into their form system. It already recommends my personal email / credit card / auto generated password. Why not prepopulate / suggest an Apple-generated email? Why force the merchant to implement another standard which breaks all other SSO integrations _by design_?
I don’t have answers to those questions. If this was a consumer feature embedded into their keyboard I’d be ecstatic. Strong arming merchants to implement and bear the full cost of confused consumers who can’t seem to login to their app _even when they click the Apple button_ is inexplicable (to me).
"+merchant" doesn't do squat to prevent bad actors from selling your email address. Anyone so inclined to sell your address would just strip off the postfix since they know it's unnecessary per the spec.
One of the many advantages of using a hosted solution with your own domain is that you can receive email from arbitrary addresses in the same inbox. For example merchant1@inboxname.mydomain.com gets sent to my inbox at Fastmail. inboxname@mydomain.com doesn't exist, so there's no way to get my "real" email address from what I give out to merchants. If I start getting spam on an address, whoops, you and everyone you sold my email to get sent to a black hole in the cloud.
I wonder whether that's GDPR compliant. If I give you permission to contact me on me+alias@example.com and you strip off +alias and then contact me on me@example.com, you've inferred data about me I haven't explicitly given you. One could argue that's in a similar ballpark to running a geoIP lookup and then sending me mail through the post.
It seems rude (like if I told you to drop off a package at my back door and you put it by the front door), but I given the existence of RFC 5233 I don't see how this would be "data about me I haven't explicitly given you".
Also, if you try to mail people based on GeoIP data, you're going to have a bad time.
It's about permission. If I give a company a certain set of contact details, and they run some process to find other ways to contact me that seems unfair and beyond what I've given permission for. The fact that it's trival to find my real email from an alias I think is irrelevant - it's still an abuse of trust. Like I say, I can see a correlation with more invasive methods of finding other ways to contact me that I hadn't granted the company (imagine if they start contacting you on social media just because they could look up your profile from your name).
You could argue that a major feature of the GDPR is to legislate that just because a company can do something, doesn't mean it's allowed to do it.
The 'detail' is optional, and doesn't infer any privacy.
It's kind of like if you get mail delivered to:
nprateem, office 2, university of ycombinator
and instead they only store:
nprateem, university of ycombinator
Odds are, mail will still be delivered to you, but it might not come to office 2, and might come to office 1 instead. It's not what you wanted, but there's absolutely no impact to your privacy by them stripping away additional details.
If you decide you no longer want to receive email from user+detail@domain.com it's easy to set up a blacklist filter. If they circumvent that and email you at user@domain.com you've lost that alias and easy way of blacklisting them. And presumably if someone had wanted to be contacted at user@domain.com they would have provided that email in the first place. So I don't think your analogy holds.
Fair, the analogy doesn't hold onto the functions provided, but RFC 5233 is very clear that the user+detail separation does not provide any privacy protections, nor can it.
The 'user' part is still public information, as is what it's used for. There should be no expectation of privacy for information being used per specification design.
The usability trade-off is a shame, but the solution was half-baked at best, and is primarily useful when combined with privacy-sacrificing public email providers. When you have greater control of your email, distinct 'user' parts can be used, which does provide the privacy aspect desired.
we’re a B2B app, it’s unlikely a random user will sign up for our service as it’s quite expensive and contract negotiations happen before the account is activated. we also never send marketing blasts or sell (or even collect) any information about our users. we also don’t operate in any country requiring compliance with the GDPR.
> we also don’t operate in any country requiring compliance with the GDPR
You know it's nothing to do with the country you operate in but the nationalities of your customers though don't you? You could only have a presence on the moon but if you had any EU customers you'd still be bound by the GDPR AFAIK.
to avoid duplicate user signup. allowing the + would not allow me to use a unique constraint for email address on the user table and be sure an email is only used once.
Gmail ignores (or ignored?) dots on the left of the @, so some.person@gmail.com and someperson@gmail.com and s.om.e.person@gmail.com all went to the same inbox. That is gmail-specific.
Because thousands of people already have an account tied to a specific email and are going to click the Apple button and get really mad when we can’t log them in.
Apparently they want to use it, otherwise they wouldn’t, right? This way they can have the easy login using Face ID and you can use the account they already have.
You send information to the apple address, that's what its for. You can still send it invoices or a magic link, the user gets it and clicks on it, nothing is changed in that regard. The difference is they can turn off that email address and never hear from you again if that is what they want.
Stuff sent to the fake email address will be forwarded to the user’s real email address, from what I understand. So you will still be able to communicate with them.
My problem is that I don’t get to choose if your business is worth the implementation cost. Because we’re already in bed with FB we will be forced to implement. It’s the “have to” I’m arguing against, not the feature.
this is the same problem you get from any identity provider — what happens when you finally delete your facebook? — it's just more obvious with Apple. With a 97% satisfaction rate, most iPhone users don’t want to go anywhere else… but yes, if you want to stay free, you should always create credentials directly with any app or service you use, when possible.
That said, the concept of "Apple Sign-In" for Android and other platforms is an interesting one, not likely in the short term, but possible someday!
I'm speculating here, but Apple Sign-In for Android would work just fine if the sign-in process was based on an OAuth flow where the credentials are entered into a web form. From the limited details I've seen that sounds like how Apple Sign In will work.
A service supporting alternate identity providers via OAuth (Facebook, Twitter, Google, Github) via a flow like this shouldn't have trouble with Apple Sign In from a web page, iOS app, or Android app.
It is not about deleting accounts or moving over. Heavy user has multi-device setup, I use Android tablet, iPhone, Mac and sometimes PC, some appliances like Synology with bundled apps also. Nowdays even my printer has online sign in, for file sharing apps. I expect same account to work everywhere. If they provide reasonable platform-independent email solution, it may work.
Yes, but while I can choose to log in with facebook, or google, or whatever, it appears that Apple are mandating that app providers use the Apple sign-in, which means app users no longer get to choose.
Unless I'm misunderstanding what the mandatory part is.
They are mandating that if you offer any other authentication provider (e.g. Facebook, Google, etc), that you have to offer Apple sign-in as an option as well.
The option is mandatory. End users using it is optional.
If the policy is "if you offer one or more authentication providers, you must include Apple sign-in", while it's still a little harsh, I think it's much more defendable and reasonable.
Only if they grandfather existing apps. We made the decision a long time ago to support FB login. That decision now requires us to either stop having an app in iOS, remove FB login (which a good portion of people use exclusively), or implement a new authentication provider _that won't work for people that already have an account with us_.
Again, the tech is fine. The strong-arm is indefensible.
Why would someone already authenticating via an existing identity provider be affected by you adding an additional identity provider?
If you support FB login now and decided to add Google, for example, that doesn't require your existing FB users to do anything different. It should only affect new users who are creating an account and choosing to use the new provider. Wouldn't that be the same for Apple Sign In?
Note, I'm not taking a position on the strong arm tactics, just pushing back on your claim regarding existing users being affected by a new identity provider. That doesn't sound right to me.
I expect the disposable email will end up in Keychain, and you can export from there. Not the most user-friendly thing, but doable. Well, at least on a Mac.
How will this work for apps that depend on the third party for more than just identity? For instance, does an app built on Spotify's API have to include a Sign in with Apple option? Or something like CI2Go, which is an app for CircleCI, which only offers log in via GitHub or Bitbucket.
If you are built on Spotify, then the use is not signing in to your app, but to Spotify (and then authorizing your app), so it should be up to them to provide the Apple Sign In feature, I assume.
Probably Apple is hoping the entire Apple ecosystem not to be defined as "a market" in terms of antitrust laws. I am not sure if the Justice Department will agree with it though; we'll see.
If it's defined as a market, then Apple will be surely in trouble but enforcing Apple ID alone doesn't make much differences from the current situation as it always has been doing similar things for web browsers, music apps, app store itself etc. So it's pretty natural to enforce this policy for Apple; no additional risks but only benefits.
Excluding other third party sign on options would be problematic if Apple were abusing a dominant position among smartphone makers, which is not the case by any objective measure.
Leveraging their status as the controller of the platform to require support for their solution is not the same thing as their solution competing head to head with other solutions.
Note that I'm not making an argument about how to classify the behavior legally, I'm arguing that calling it "competing" is pretty generous.
The trouble here is the definition of "market". Apple's ecosystem (which Apple has an absolute control on) doesn't seem to be very safe from being defined as a sole market since there's no viable substitute to the app store for Apple users.
For instance, even if Apple decides to increase the app store fee to 50% so its app's prices as well, still consumers don't have much choice since buying a new phone is typically more expensive by order of magnitude than buying an app. This is also a part of Spotify's claim as well and Apple is trying to defend itself for this time unlike Apple v. Pepper.
I already have explained; there's no alternative to iOS for apple mobile devices unless you're willing to pay more than $500 for an equivalent level of android device. If Apple allows Android to be installed to Apple devices, then things can be different though.
In fact software monopolies on hardware isn't pretty much the standard, it's a universal reality in just about all consumer products except one—the personal computer. And even then it's exceedingly rare for a consumer to deviate from the shipped software.
"Dominant player" isn't especially relevant in European market law. Essentially the test is that you are of sufficient import to materially affect pricing in that market, which Apple definitely is.
Yes it is anticompetitive. It is using Apple’s monopoly as gatekeeper of their app store.
Apple would have long ago been cited for Antitrust if Android hadn’t had most of the market. I personally think that the definition of a trust is too narrow — one member of an oligopoly abusing its position as a platform provider and strongarming people is also pretty bad.
That’s not how antitrust law works. It’s not a test of whether a company exerts too much control over its own customers. It’s a test of whether customers have some alternatives and a real opportunity to vote with their dollars.
Apple has argued that developers are its customers (in the Pepper lawsuit). What options do developers have? Ignore the iOS market (those most likely to pay money)? There isn't a choice here: you let Apple have 1/3 of all of your revenue and you implement Apple Sign In. Because... competition?...
Antitrust is among the most mature areas of law, in terms of how these concepts have been thoughtfully wrangled over. I definitely encourage you to dig deep on how market scope is determined, if that’s interesting to you. There are many ways to manipulate a market but very few rise to the level of requiring state or regional government intervention.
Fun thing is, Apple themselves block name+addon@gmail.com addresses when using their dev console. You can bet that some companies will disallow Apple’s signature private passwords similarly if they can, in the name of ‘security’ or what have you.
Or am I being too cynical? Feel free to CMV.
EDIT: best response addressing this seems to be ‘The addresses are only generated from the "Sign In With Apple" workflow that a developer has to enable in the first place’
Presumably such services won't implement Sign In With Apple in the first place. People will accept it because they want the sheer quantity of users Apple provides.
The useful thing about Apple is that they can force people to do things they don't particularly want to do, like accept anonymous e-mail addresses or stop using Flash. (unfortunately this is also the bad thing about Apple)
"[Sign In with Apple] will be required as an option for users in apps that support third-party sign-in when it is commercially available later this year." https://developer.apple.com/news/?id=06032019j
There by, when apple passes a XXXXXXX@privaterelay.appleid.com address back, it won't match the existing account's email address = Sorry, matching account not found ?
One other thing that seems powerful is that users that use Sign In With Apple have some guarantee of quality; with Apple using FaceId to authenticate, there's some amount of guarantee that you're not a bot.
I think this is something that people are missing when they suggest services will just block the Apple relay address.
Of course they wont. They still want the business and as you've pointed out, these accounts will be in a different customer engagement category. They are almost certainly real people and they a lot of value to marketers, even is you don't have all of their other personal details.
Or they already rely on FB login and are now _obligated_ by Apple to implement this feature. I work for a company that has allowed people to create accounts with FB login (meaning we don’t have an internal password associated with them). This change would ostensibly require us to also allow Apple Sign In _even if we don’t want to_ just to continue to service existing users.
There really isn’t much choice here for us. Leave Apple / iOS? Abandon FB login and piss off thousands of people? Implement Apple Sign In regardless of its tech stack / requirements?
As someone who also run a service where the only login option is using Facebook, I'm curious about how you regard the negative press regarding Facebook, the recommendations to leave Facebook, and the many users who is sceptic to or has already left Facebook.
Do you have any plans to adopt any other login provider? I would really like to, but other than email/password, I'm not really sure what would be a good alternative, and I'd really like not having any personal information stored at all - email addresses included.
We let people create a username/password but can also use FB if they prefer. Turns out having their email is nice; we need to send them notices and reminders from time-to-time.
I’m not a FB fan. I post on social media maybe twice a year. As an advertiser I don’t trust the numbers they report. None of my criticisms of Apple in this decision should be interpreted as pro-FB. I just have a very strong distaste for Apple deciding that they get to decide how we run our apps.
They have to mandate usage because it’s the only way devs will do it. And it seems like a fine enough product for Apple-only hardware. But when you get to supporting multiple connected devices it falls apart. Are they going to support this for PCs? What about on the Roku? How will anyone who uses Apple Sign In on the iPhone log in anywhere else?
The addresses are only generated from the "Sign In With Apple" workflow that a developer has to enable in the first place, so it wouldn't make any sense to do that and then reject the addresses.
No, you're clearly correct. But Apple pushing this does give it a sense of legitimacy and blocking signups from this service might just cause less signups than actually forcing people to use their real address.
If Apple makes this extremely user friendly and quick to use than blocking it will cause a loss of signups.
‘Error: We love Apple and anonymity but we require a real email address to prevent fraud and to properly secure your account. Please enter your real email address.’
It would work roughly the same way. Integrating an OAuth provider like this requires registering an application with revokable ClientIDs, so Apple can technically pull them just as easily as they can pull Apps.
(It remains to be seen if they'll put in the legwork to actually police these things, though)
> ‘Error: We love Apple and anonymity but we require a real email address to prevent fraud and to properly secure your account. Please enter your real email address.’
GDPR would probably want to know specifically why you need someone's real email address.
However they most likely won't for the same reason that people who are upset about Apple's 30% App Store cut still develop apps for iOS: they have their customers spend far more on average than other phone / OS users.
But in return for that, the services that choose to employ this will get a soft guarantee that the person signing up is unique/real. Its a way to get real-name/real-id with some amount of privacy.
Apple IDs cannot guarantee a real or unique user - users can have multiple accounts (some users will create a second account by mistake, others have a separate work account, etc), users can share accounts (especially ones tied to generic email addresses), and there are people selling app store reviews, so some bad actors definitely have a lot of accounts.
Thanks for your comment. I used the word soft guarantee, which is meant to encapsulate those caveats. Maybe I should have used a better term since I guess people were confused as to what it meant.
Facebook is trending downwards and privacy concerns with Google are trending up.
Critical mass might be achieved where if you don't include Apple Sign-In you might lose more users than whatever benefit you see from having more identifiable personal information.
They surely can do whatever they want, they can definitely choose to deny service to users that are traditionally high spenders and limit the fake accounts to professional scammers that use account farms from Asia.
Yes. Back when Google+ oauth launched, "sharing user identity info" was the carrot that incentivized developers to build the integration. Otherwise, devs preferred Facebook so they could get user info.
Sure, they really could. But for me, it could be a reason to pick Lyft over Uber for example. I hope they add support to the App Store description, that would really help filter apps.
Is that block a recent thing? It might be different as for my on GSuite account I can add the name+addon@mydomain.com - it might just be a difference between the "public" Gmail system vs the Gsuite Gmail system. In which case, my question is completely invalid and feel free to ignore ;)
Note: This comes from my own developer account having 3 name+addon@ accounts live, and working with things like ApplePay etc for testing.
Developer with a name+addon@gmail.com Apple ID here. No idea what OP is talking about, I was able to generate my Apple ID and sign up for the dev console no problem.
Apple now strips the +... part when you create an ID. So if name@gmail.com is already in use, name+addon@gmail.com will be refused with the message that name@gmail.com is already an Apple ID.
If Apple users use Apple Sign-In en masse then any services which blocks it will face harsh negative publicity. If enough people use it then services will have no choice but to acquiesce.
This is a huge move. Apple striking at the core of Facebook's play to own your identity, which they had with Facebook Connect but have completely fudged out with countless breaches of user privacy and trust. I used to be the biggest fanboy of facebook connect, but now I have to say: Go Apple.
Apple ID as SSO, iMessage Profile, Memoji, and Apple Pay. Apple is near FB Messenger parity, now that it functions as an account for external services. It's an extremely strong move on Apple's part, especially considering how close to it they have been for a while. They sure like taking their time sometimes.
True, but Facebook’s overwhelming majority of users is completely irrelevant now that their brand is irreparably tarnished. People will still use Facebook for a long time, but nobody other than a few diehards and people who work there want FB to own their identity. I believe that particular grand vision is dead for FB despite their user base.
I own several Apple products. My 2015 MBP is my primary computing device outside of work. I am a paying customer, and this service is useless to me unless I replace every device I own with an Apple device. I couldn't do that even if I actually wanted to.
The conversation was "The ability to run on my phone seems like an important feature."
Either you have an iPhone or you dont. Sure they might have an ipad and imac and an android phone. I suppose thats possible. But at that point, you are the exact kind of customer this business model is designed to get to switch over to the full ecosystem.
Are we really arguing if the "Sign in with apple" button will work on websites from chrome on windows? If apple wants to be an identity provider, their web sso will work everywhere. Or are we talking about iMessage, the flagship iPhone app, not working on android phones? Apple will lose more customers to Android, who only want an iPhone for iMessage, than they will gain.
We're talking at different levels. You keep repeating obvious facts everyone already knows as if they're novel, and I keep pointing about that all those facts clearly imply that Apple wants to make money off of you through abusive lock-in practices.
(I really doubt the sign in with Apple button is going to be available in Android apps. If you create an account with the button, it becomes ever so harder to switch to Android. How convenient for Apple.)
I don't think continuing this discussion is helpful. Have a nice day.
I agree, after making an account with the button, you are stuck with Apple forever. If the sign in id buttons are not cross platform, thats abusive lock-in.
The create account button might not be available on android apps, but hopefully the sign in sso buttons works. Maybe identity portability will become law someday, like cell number portability and being able to change your address at the post office.
Fb and G screwed themselves by: forcing users to submit real cell phone numbers (no forwarding numbers allowed) and real names. I’m laughing all the way to the apple oauth signup. So tired of G and Fb abusing users
True. Apple definitely playing the long game here, effectively. When iMessage came out I totally didn't see it ever becoming a viable identity play. But with all these privacy concerns, now it feels like the one to beat.
There is an app you can use on a jailbroken ios device that turns it in to a relay/web server which allows you to use imessage on any device. I guess if you really wanted to use it you could just buy an ancient iphone and leave it always plugged in.
Not sure if that's possible. iMessage is a mobile first product, so presumably you need an iPhone to start using it. Then a Mac computer. It's definitely a closed system that works great if you buy into Apple's family of products, less great otherwise.
>He works in IT at an unnamed company, and his team noticed something crazy: of the 500 employees at the company, only 8 of them chose to use an Android phone. Everyone else — all 492 of them — chose an iPhone over Android phones. It was because they didn’t want to be “green bubbles,” a reference to the fact that iMessage chats in the iPhone’s Messages app use blue bubbles while SMS chats are displayed with green bubbles. Forget all of the great advantages iPhones might offer, iMessage is the main reason all these people wanted an iPhone. 98% of the employees at this company went with Apple over Android, and for the majority of them, it was mainly because of a single service.
If people didnt "throw away the key" services like Google ID, Microsoft ID, and Facebook ID wouldnt exist. Centralized OAuth providers are here to say, even if a lot of us on HN dont like them. You want to get into your tshirtclub account after facebook locks your account, too bad!
>Sensible people do not deliberately handcuff themselves to trillion dollar megacorps and then throw away the key.
>Yes they do
>It was because they didn’t want to be “green bubbles,” a reference to the fact that iMessage chats in the iPhone’s Messages app use blue bubbles while SMS chats are displayed with green bubbles
Sorry, it seems to me like the story you're relating supports the point of the post you disagree with. Surely "sensible" people don't choose a phone on the basis of what color their messages appear as on other people's phones.
(I think there are sensible reasons to choose either platform. But the reason you're talking about here certainly isn't.)
I guess to each their own - I don't consider that sensible. Personally I've never been in an environment where it was common to judge others for the model of their phone, and complying with that level of control over my life and decisions, even for a moderate social reward, doesn't seem sensible to me.
If you've never dealt with this level of pettiness, signaling, and superficiality, then you've never operated at any meaningful level of power, unfortunately.
Apple doesn't care. (despite me thinking they should, their biggest growth was right after iTunes for windows.) They care about offering services to their paying customers, not anyone else. If you don't buy their stuff, they don't care about you. Compared to fb/Google who care about you to make you pay attention to ads, it's a refreshing twist.
Facebook/Google care about offering services to everyone on the planet, not just the richest that have more disposable income than most people have in lifetime savings. Compared to Apple that cares about you only to make you pay ever-increasing amounts of money to maintain membership in its closed ecosystems, and blocks off any sort of mixed-ecosystem use, it's a refreshing twist.
I've been anti-Apple since I was a high school kid in the 90's. Those big colourful Mac's looked dumb. They're close to winning me over and I'm probably buying a new laptop within 12 months
I highly recommend buying a 2015 Macbook Pro, if you can find someone willing to part with theirs. Apple laptop hardware started going off the rails after they shipped that one with touch bar + keyboard shenanigans.
I have the previous generation hardware design as my personal laptop and a late-2019 macbook pro for work and I really don't hate the new one. I know some people have had some issues with keys getting stuck and what not, but I've actually had a pretty good experience with mine. I touch-type and I can type just fine on the newer keyboards. I would have liked to have a physical escape key, but besides that it's fine. I'm happy with the thinner and lighter design. The options of core i9 + 32GB of ram alone is worth getting one of the newer ones over a 2015 model.
Same, I own a 2014 15" and have a 2018 15" from work. I haven't had any keys break on the 2018 (yet...) and actually prefer the key travel on it to the 2014. The smaller size is an improvement and the dongle situation isn't a problem for my use cases. Not a fan of the keyboard layout and TouchBar, though.
If Apple let me spec a physical ESC key, inverted-T arrow keys, and native 1920x1200 point screen size @2x on the existing form factor I'd be VERY happy. Assuming, of course, the keyboard is actually reliable.
Ditto situation here. My work MacBook has been working great as well - the inability to charge my iPhone without a dongle has been frustrating but hopefully Apple switches out of lightning soon.
As for the ESC key, I rebound my Caps Lock key to Esc & Ctrl. Works great!
Ok, thanks. I know nothing at all about Apple hardware. It's still a very daunting decision to make. I like the ability to buy my own hardware, for desktops, and to build what I like at a cheaper price. Apple charges a premium but now I have more of an idea of what that premium will get me.
It would be a huge migration for me. Everything I own is tied to one of a few Gmail accounts. My photo history, my uni work in GDrive, my contact lists, my email history, everything about my entire online identity. I'm just increasingly fed up with how Google approaches privacy.
At my office every single one of the new macbooks (since about 3-4 years ago) has had the keyboard fail. Some of them have had the keyboard fail repeatedly after getting apple to fix it.
The ifixit tear down shows that the 2019 model has done nothing to fix the issue. I highly recommend the Dell XPS over a macbook pro. The form factor is very similar but the hardware is much more reliable and fixing it is way way easier as most parts can be replaced separately.
I own a 2016 Macbook Pro and 2018 Macbook Pro and I have to agree with the others in this thread: don't buy a modern Mac laptop. I really regret purchasing the 2018, my next laptop will probably a Linux based machine.
I recently switched to iPhone after using Android devices for many years to get away from Google and that was actually a purchase I can recommend. The Macbook Pro, not so much.
You can use everything gmail on Apple products. But, as he said, Macbooks 2015 were the top of their art, and it’s all going downhill now. Since 2014 they start to have kernel panics, since 2016 they have a failure-prone keyboard with no hardware “Esc” key. And it now costs 150$ for an external keyboard. Prices up, quality down, emojis in.
Moving to Apple/Mac has been amazing. The interface is just so much smoother. The UX is thought out with much more care than anything Google/Microsoft offer. And I don't feel like I'm selling my soul when I'm using an Apple product - a huge plus.
I have a Early 2015 MacBook Pro. I would not recommend it as a new laptop unless you're getting a significant discount on it, since it's starting to get old.
I agree it's not a perfect solution, and mine is starting to get old as well, but so far it's things that are replaceable (i.e. battery). And I still vastly prefer it to a 2018 MBP I had for a while and then sold at a heavy discount due to keyboard/touchbar/no Esc key/USB-C dongle hell. But if you don't care about any of that and just want the fastest CPU, it's not the best choice.
This single feature shown off today at WWDC has solidified my forever lock-in on all things Apple and especially iOS: no longer will my email be sold needlessly or be spammed and my logging into to different web properties sold to marketers and ad networks and data aggregators. I trust Apple a whole lot more becaUe they charge and arm-and-a-leg for high end hardware and soon services because the products and services are the products not their users.
As soon as Keychain can abstract away passwords completely (rando generation, never need to show the user the password), so an end user cant tell if a site supports Apple SSO or if Apple is just emulating SSO, Apple deserves to be crowned the Identity Winner.
There appears to be a web API for this, which would be cross compatible.
If you have used Apple's service - which is completely opt-in - you could always go into an account and change the email you associated with it if they let you do that. And if you don't, this would be in the ballpark of switching email providers - yup, you'll need to change some accounts, because you've decided to no longer pay for the service from the Apple email forwarding.
I don't think that really means what you think it means. It's very similar to the way "Apple Pay has a Web API"—websites may implement it for authentication BUT it won't allow users on a Linux/Windows machine to Pay, either. This is the same thing. You'll need to use Safari on a Mac, or it won't appear.
From the developer documentation, "Sign In with Apple works natively on iOS, macOS, tvOS, and watchOS. And it works in any browser, which means you can deploy it on your website and in versions of your apps running on other platforms"
The "works in any browser" and "apps running on other platforms" parts seem to suggest it will work fine on Linux or Windows machines or even Android devices.
Maybe I'm cynical, but this looks more like a data hording scheme than a protect my privacy enhancement. If I use Google to sign in, Google and the app has that data and can monetize it.
Now if I sign in using Apple, they are going to have the data to monetize. They may keep the app from getting my information, but that means that their data is better than someone else's data, so it is more valuable. Also, they are getting app usage statistics that I may have opted out of at the OS level, but they now have due to having the sign in history.
Problem is, today I agree, 10 years ago it would've been a tossup, and 5 years from now, who knows? These "trusted central broker" privacy models are nicer than giving your info to dozens of individual actors (when you trust that central broker more than anyone else), but they also become a single point of attack/failure.
My point is some of the information available now is that historically, companies that respect your privacy today might not tomorrow. And might only be respecting your privacy to get a monopoly on your data so they can exploit it later.
Neither would be the only sane choice. Multinational corporations will always screw individual customers for profit.
And the issue with trusting any entity with data isn't really what it will do with it today. The bigger problem is what the entity will do with it tomorrow - under new leadership.
It might also be interesting to know that Apple is also in the business of selling "relevant adds". Its a tiny amount if compared to Google, but gives them the same incentives if the platform ever became the most used one around the globe.
That danger is basically nonexistent considering the pricing of Apple devices but makes most claims of apples trustworthiness pretty hollow.
Some of Apple's services use end-to-end encryption. That makes them better from a privacy angle than Google for example... But still... Don't trust multinational corporations. That can never end well
The question was not "who do you trust", but "who do you trust more".
Given that Google's business model depends on data sharing whereas Apple has made privacy one of their core features, I think the answer has to be Apple, even if you don't trust them entirely.
Absolutely. One would still be able to do that (Apple's providing SSO here, not enforcing any guidelines, as of today). Though, I'm happy that friends and family would be able to choose anonymous per-app email-ids on the fly and still be able to SSO.
op mentioned apple core is privacy. i implies that they care it only for their high end customers. They could anytime do a low end mobile if privacy was their core. Their core is like any other business get maximum profits.
Apple's premium price is exactly what allows them to focus on privacy.
Google/Facebook/etc. are able to offer you cheap products and services because they're selling your privacy to the highest bidder.
Apple is not doing this (because they care about privacy), so they need to charge a much higher price for similar products.
This is somewhat of a chicken and egg problem (did Apple care about privacy and charge a premium price, or did charging a premium price allow them to start caring about privacy?), but that's arguably not important. What's important is that Apple cares about privacy when their competitors do not.
If Apple cared about privacy they would have left China instead of giving up it's iCloud key.
They are focusing on it because of business sense. To upsell people who are able to buy those expensive devices otherwise all devices are now more or less can do the work.
Apple can easily lower their price to match android. They do have insane profits. But I don't see they care about lower class people.
How about 'neither of them'? Trusting Google with your data is like trusting a fox with guarding your hen house, trusting Apple with your data is trusting a fox which claims it turned vegetarian.
Run your own mail server and you'll have all the addresses you care to use, using any scheme you might think off. I've been doing this for decades now and it just plain works. A day or so to get the thing setup, 8 hours of maintenance per year and you're done. Use Google-free Android devices in your pocket, Linux or *BSD on your lap and in the server/broom cupboard and those foxes can claim to be vegans for all I care.
Where do you host your mail server? I've been running my own for years on Rackspace, and it works great, except they recently started adding on a $5/month support fee that old accounts like mine had been grandfathered out of. With that, and other price increases over the years, it now costs about twice what I originally paid.
I originally picked Rackspace over AWS because Rackspace's cheapest acceptable option was about the same price I had been paying for space on a shared hosting service, and that was about half of the cheapest viable AWS option.
But now it looks like AWS is quite a bit cheaper than Rackspace, and it is getting time to build a new server anyway [1], so it is time to consider alternatives.
One thing I'm concerned about is IP blacklists. Every time someone posts an article about setting up your own email server, there are comments about this being a pain because spammers will set up service on neighboring IP addresses, and you'll often get caught up when that gets the whole block blacklisted.
I've never had that problem at Rackspace. I don't know if spammers just don't use them for some reason, or if they are really good at kicking off spammers...but in the 7.5 years I've been doing this at Rackspace I don't think my outgoing mail has ever been caught in an IP-based blacklist (or had any other delivery problems, for that matter).
While I'd like to spend less than I'm spending now, it would not be worth the savings if it makes my mail unreliable.
[1] I'm on Debian 8, which is in the last year of long term support. I prefer to built a new server from scratch with the latest and move to it rather than trying an in place update across major distro versions.
The server sits in a special cupboard I made which has servers, a switch and storage on top, drying racks on the bottom. All the way in the bottom is a forced draft fan (meant for modern air-tight homes, low-power and -noise) which pulls the warm air from the top through the drying racks. All the way on top sits a large air filter. This keeps the equipment clean and relatively cool while using the waste heat to dry produce (now filled with mint leaves, later it will be used to dry apple, possibly some jerky, etc).
The whole is connected through our gigabit fiber to the outside with a possibility for a wireless backup connection should the fiber go down (which it hasn't thus far).
The hardware runs a combination of Debian stable with some unstable packages plus home-grown tools. I've done Debian upgrades on these servers for years, generally without much breakage. That is actually why I moved to Debian from Redhat which I used earlier (before the Fedora days) as upgrading RH was always a hit-and-miss experience compared to Debian.
So, in short: my own hardware on my own connection on my own premises, with off-site (and even out-of-country) backup in a reciprocal agreement: I run backups for my brother in the Netherlands and get to put my (encrypted) backups on his NAS.
Can we stop being hyperbolic please? If not blocking ads in a very specific way is what it takes to be counted as "evil", that word has officially lost all meaning.
The difference is that one is a hardware company making services to sell devices; the other is an advertising company making services to get more data for ads. One of them can live without your data, the other cannot.
Except Google is an advertising company and Apple is a consumer electronics and software company. Their objectives are different, and historically, Apple has been one of the most privacy-focused tech companies.
Not saying Apple can't use your data, but as far as auth providers go, I'd rank Apple higher than all the other Big Tech Cos.
Apple doesn't, to the best of my knowledge, monetize data, either through ads or selling it to third parties. I'd welcome a clarification if I'm wrong.
It seems you must first have an *OS app in order to use Apple Sign In on the web, a $100/year barrier to entry for web developers verses Google/Facebook auth.
"To configure web authentication, you must create a Services ID and associate your website to an existing primary iOS, macOS, tvOS, or watchOS App ID enabled for Sign In with Apple."
Sounds like a good time to remind people about Telegram having a similar function for quite some time now. And just yesterday they announced a feature to simplify logging into web sites using TG bots: https://telegram.org/blog/privacy-discussions-web-bots
It might be a personal choice, but for stuff when privacy is really important I'd definitely pick Telegram over Apple, no matter how much the latter claims to keep me safe from three-letter agencies as well as marketers.
Telegram is unencrypted by default. All standard messages are stored on the server. Telegrams secret chat mode (end-to-end encryption) uses home made cryptography, and has been panned by experts in past. All group chat is in the clear and stored on the server. This is not the case with imessage. Comparing Telegram to iMessage, telegram is not in the same league as Apple. I don't trust either from TLA's or well funded adversaries.
It's a feature: history synchronization between different devices and fast search through hundreds of thousands of messages is, for most uses and users, more important than concerns that Telegram or nation-state level attackers (one capable of silently breaching Telegram infrastructure) would choose to read your chats.
Signal also does historical synchronization between devices. It bootstraps the history from another device. It also has search which can be done locally. Telegram is, by design, capable of being accessed by 3rd parties (beyond governments). iMessage is capable of being accessed by 3rd parties via iCloud backups, which is an opt-in situation.
Be aware, wechat sends every message with geolocation to the authorities in real time. It is more critical than ever that we be aware of the mechanisms in the systems we build and use -- else dystopia awaits.
Plain wrong. It's not end-to-end encrypted by default, that's true. But all chats are encrypted with key portions distributed between different jurisdictions in case some country gets funny ideas.
Chat archives are stored encrypted, not in plain text. Please cite your sources if you claim otherwise.
> think saying "chats are stored in plain text" is a reasonable way to convey that message
If I keep your messages encrypted in my database and your keys on another unonnected database in another building, would it then be fair to say that I store your messages in plaintext?
No. They are encrypted. It is a matter of fact.
The word you are looking for is "not E2E encrypted" which can be a problem, but a different and smaller problem.
>If I keep your messages encrypted in my database and your keys on another unonnected database in another building, would it then be fair to say that I store your messages in plaintext?
If you can still access them, I don't think it is fair (or maybe rather: it is misleading) to say that you store them encrypted.
But it’s absolutely homemade by math PhDs (not crypto specialists). And if you search for ‘telegram security’ you’ll find any number of articles pointing out a bunch of weaknesses. It’s also only half open source.
Granted, there are no known weaknesses with their protocol -- however, Telegram leads the user to believe their conversations are encrypted, which, unless they opted in to secret chats (and this is not supported on desktop ), its all in the clear.
So if you are using it on desktop, all your messages belong to Telegram, and whomever they are sharing it with.
Signal requires a phone number. If anything, use Keybase, you'll also get good team handling, file sharing and bunch of other nice convinience features.
Like I said, the chats are stored (or are claimed to be stored) in an encrypted form. But I think I understand why it may count as "stored unencrypted" in your eyes. Still, Signal won't cut it. It's too inconvenient to use, and while maybe it provides better security it's like a very strong password policy in a company that entices users to just write down passwords on Post-it notes.
I couldn't get my friends use Signal, it's not there yet in terms of user friendliness (hell, I wouldn't use it). But Telegram works for me, and I consider it a substantial improvement over Whatsapp. YMMV.
Mozilla dropped the ball on this? They never had an opportunity to do this. Apple will only succeed by bulling developers that want to stay in the AppStore. Mozilla doesn’t have the market share or financial leverage to do anything like this.
Elaboration with example: LinkedIn is notarious for swiping up any data points that it can find. Your carrier, your GPS location, etc.
As long as there are two or more data points to successfully tie you to that id, it's already game over. It'll just be added to your "targeted advertising profile" and, given the wrong company getting ahold of it (looking at you, Equifax), sold/traded on the advertising market to third-party advertisers to build better profiles because... ...advertising dollars?
Anyways, the premise is cool but I think - without addressing the dragnet that is targeted advertising - it'll just be a minor inconvenience, which will be conquered over time with the collection of enough data points to tie it back to the "you" that they already know.
...unless you start-off with a brand new phone (new IMEI) and don't associate any old accounts with it, that is.
Apple doesn't allow you access the IMEI or even Mac address. And they announced at WWDC today that they're locking down people scanning for wifi access points + bluetooth beacons to determine location also.
The purpose of this isn't to make you anonymous. It's just to make sign on a little simpler and for apps that you think might not be super trustworthy or apps that don't actually need your email address you can choose to give them this proxied one. Obviously social accounts and other applications that will ask for your real name will know who you are.
I develop apps myself and I am 100% onboard with using this instead of offering the signup with google or facebook buttons (can offer those as secondary options). I might even push users slightly to use this instead of others as it gives my apps a bit of extra trust worthiness imo.
Only question I have is if it's possible to integrate this on websites and for non-apple products too? Because I would like my app which is available on Android too to be able to use this.
EDIT: Apple's site says it will be available on websites too. Let's hope it's available on non-apple devices too:
> Apple is introducing a new, more private way to simply and quickly sign into apps and websites.
Thanks, I was reading the docs and apparently it will be available for websites too and comes with a JS library which will let me use it on Android too. I am quite excited for this as a developer.
This is a natural step that I’ve been waiting for for years. This can almost remove the need for password typing, as you don’t even need one to unlock the device anymore. Let’s hope Microsoft does the same, and integrates with apple’s solution. A lot of people are on iOS+Win10 for laptops.
Hopefully, more devices will move away from requiring you to type anything into the device to sign in.
Quite a few devices or apps on devices have already done so. Instead of having you enter the account ID and password directly, they give you a URL to visit that is something like https://<device-maker>.com/add-device, and show you a random code.
You go to the given URL in your normal browser on whatever device you normally use for web browsing, where you can login to your account at <device-maker> and enter the code the device gave you.
A few seconds later the device notices you've completed this, and you are then automatically signed in on that device.
I can already see devs implementing things such as `if email domain ends in privaterelay.appleid.com reject the email address and ask for a "real" one`, like what already exists for yopmail and others.
Some screenshots display that it also works on the web, I'd love to find out how exactly but I ain't buying an Apple device and a developer license for that.
I love that TC chose a picture of "fc452bd5ea@privaterelay.appleid.com" to illustrate the article. When was the last time you saw a service that could be described by a single "word"?
If I showed it to my mom, she still wouldn't know what was up. The genius would be in to make the UX frictionless and disposable addresses the default. Let's see how Apple executes this. They do absolutely pull UX stuff off from time to time. So, that's there.
I updated my AppleID since I haven't used it in years (have other devices) in anticipation of implementing this as soon as it's available on a site I'm working on. It appeared they offered two-factor authentication to get away from those 1990's type of security questions. Ah, not so fast - 2FA is only enabled with Apple devices. Poor play there, Apple. This service looks like something sorely needed - bring the rest of the flock into the fold and let everyone plug in their Yubi key.
If you're not paying them, they need to pay for you to use their services. And to do that, they will want to make their money back on that.
It is a good thing that they're not giving their services away for free; they're putting their money where their mouth is. If you look at all the companies that give their stuff away for free, they do it to collect data for advertising, and they make money from advertising, in most cases (unless they're using investor money to fund you).
Apple is not an advertising company, and I do not see any problem in them using this to draw in customers. It is a major selling point for Apple that they respect your privacy. They do a lot of their ML stuff on-device to preserve your privacy, they encrypt your data on their servers or anonymise it whenever possible, they do a lot to prevent apps from tracking you like limiting location access and other data, etc.
Free disposable forwarding email addresses that you can turn off. Built on the startup bus years ago:
http://boun.cr
MailGun ( a YC company ) was providing their API for free, until another company came along and offered to take over the project. All of the code and design was built on a bus from CA to ATX.
(and one of the team members met their co-founder on that (StartupBus) trip and went through YC. I believe they are a unicorn now)
PMs don't make it easy, they make it reliable and central. The default password generation usually doesn't work, and a web form doesn't capture everything, but I'm never clicking and guessing even when I haven't used an account in years.
But SSO wins on mobile, because the PM is clunky even with a custom keyboard. Even then, I keep a dummy entry in my PM just so I'm tracking it.
Mobile Dashlane and Lastpass work much better on Android, where the OS allows you to set default apps. If Apple deserves any antitrust spankings its for not allowing user control of protocol handlers and default programs.
You can create/generate & save new login on the fly from the sign-in screen. At least with 1Password. It's clunkier than I think is strictly necessary, but it is effective.
Yep, works through the keyboard. Click on the login or password field, then it gives you a key icon to get into 1Password, where you are prompted to generate a password and provide a username. Then you tell it to autofill that into the form. A little clunky but effective.
What is forcing the sites that I'd want to use a fake email address with to use this? It wouldn't be in their interest to. They will just stick with their current SSO setup of Google/Facebook/whatever and never touch this, if they have SSO at all. I LOVE LOVE LOVE the idea, I just don't know if it will be useful and successful.
Nothing is forcing them to, and lots probably won't. The carrot is the much lower friction for sign up for users. It's similar to Apple Pay, where you don't get credit card info, but you do get a much easier user flow that will get you more signups.
But will it be lower friction than login with Google or Facebook? It feels like it's more common for someone to have an account from one of those two than from Apple, and so "sign on with Apple" will never be able to be the only SSO option, while Google or Facebook could be.
If the better (for the site) SSO options also have near-universal market penetration, what's the incentive to add Apple?
I would venture a guess that apple/icloud accounts are the highest % account type amongst iPhone holders. All sorts of people have reasons for not having gmail / facebook / etc., but apple account setup is pretty prominent in device setup.
Sure, it might be the highest % among iPhone holders - but for a website, what portion of your users are going to be iPhone holders, and what portion of the Windows/Android crowd have Apple accounts?
You don't have to implement it to the exclusion of other methods. There are plenty of merchants on the web with Apple Pay and also Paypal, straight up credit card numbers, etc.
Of course you don't have to implement it to the exclusion of all others! But let's suppose that, say, 65% of users have a Google account, 75% have a Facebook account, and 40% have an Apple account - and the circles overlap such that adding Apple adds 10% to the total coverage. Now, if everyone who has an Apple account prefers it, and users with an Apple login yield 30% less revenue... gaining that extra 10% of users costs you revenue, because for every user you gained at 70%, three existing users cut their revenue by 30%.
It's lower friction in that instead of having to click through an OAuth screen (and possibly re-enter your Google password), you just auth with FaceID/TouchID. And if you're writing an iOS app, then obviously the user has an Apple account.
I'm on Android, so I don't know how it works on iOS devices, but is reentering the Google credentials common? On my Android phone I doubt I had to enter my password more than 5 times in 2 years.
And the OAuth screen would be required anyway, as they have also shown on stage.
I frequently have to re-enter my Google credentials on the web on Google properties. I assume Android is storing those deeper in the OS, like Apple is storing your Apple credentials.
Some apps don't open the "sign in with Google"(/facebook) popup correctly and so cookies end up not being enabled for that browser session, so users need to re-enter their google credentials.
This is being fixed over time with proper implementation.
For a while now I’ve been using “someservice.com@account.mydomain.me” when signing up for accounts.
I use FastMail for my email hosting, and they allow you to turn on wildcards for any custom domain. I don’t get any spam because it’s at a subdomain — never enable *@mydomain.me because you will get a mountain of spam to admin@, webmaster@, etc.
We've been thinking about this for Mailsac.com. It is already possibly but clunky. Considered making browser plugins to make it easier to create and route disposable addresses, and "black hole" disposable email addresses once it's clear they've been resold to advertisers.
This is very cool in terms of security principles (no email that can be used to track you by default, mandatory 2FA, mandatory SPF for emails).
The mandatory inclusion if you use third party SSO already (smart I think as otherwise FB and Google would probably start paying developers not to include it) aside, this will probably get a lot of uptake for apps that dont use SSO.
Apps that people mainly use on mobile devices and TV's would benefit a lot from this (as these devices arent good for typing in complex passwords). Additionally larger companies would be concerned about letting Google or FB sell their user list to competitors for targeting. Apple already has all this information, so nothing is lost by enabling SSO.
I develop apps myself and I am 100% onboard with using this instead of offering the signup with google or facebook buttons. I might even push users slightly to use this instead of others as it give my apps a bit of extra trust worthiness imo.
There are plenty of applications that don't actually care about the additional data they could arguably get from a Google/Facebook login, and only offer it because one click sign-up/login drives more signups.
In cases of a trustworthy third party, what is the concern of linking to Google/Facebook account compared to an Apple account that doesn't offer any data? I don't think I've seen any instances of Facebook integration credentials being hacked/stolen.
In reality, pretty much nothing (particularly since now, third parties basically only get name + email). The value is that some (small or large) number of potential users might not know or believe that and trust Apple more.
I'm not an Apple user, and don't own any of their products, but this is a great step forward for privacy. I'm happy to see companies prioritizing privacy for users.
That being said, any company that actually cares about collecting users' identities (you know, the ones you'd actually want to use this for) will definitely block @privaterelay.appleid.com from being used. Apple would've been better off using a well-known domain and having both private and non-private addresses on it, like @me.com .
Will this service be available on the web? I get the feeling that this will only be available on iOS, meaning that you lose access to all your accounts if you decide to switch to Android.
"Apple says it can authenticate a user using Face ID on their iPhone without turning over any of their personal data to a 3-p company."
So is this feature exclusive to Face ID and iPhone? Would users, Face ID enabled or not, be able to use it with only their iCloud email/ID? And would older iPhone models incapable of FaceID still be eligible?
These may be just questions of a skeptical mind, but I really hope Apple isn't using a pro-user, pro-privacy feature to phase users out of older models.
I used to do something similar when I ran my own mail server. Whenever I created an account for a new service, I would add an entry to /etc/aliases e.g.
news.ycombinator.com: stirner
and sign up for the service as news.ycombinator.com@mydomain.com. If I ever left a service, I would just remove the corresponding alias and restart Postfix.
I eventually got tired of the work required to avoid spam filters and switched to iCloud Mail, so I’m glad to see this feature built in.
This is the ultimate way to manage your incoming email - I’ll be filtering everything based on the `to:` address when this rolls out and my life will be wonderful again
Emails from companies already have a unsubscribe button. So if I unsubscribe they shouldn't send me emails. That is not changing with the new Apple Sign In feature. Emails will still have the unsubscribe feature. The only reason for devs to push for a real email is to sell it to advertisers. They are not deleting the email once I unsubscribe. So giving them an ankoymized email is good. I hope this succeeds.
Many spam emails I get these days from companies say things like "Unsubscribe from this list" so for example I have to unsubscribe from their "Daily Digest", "Weekly Digest", "Recommendations", etc. all one at a time.
And there's no guarantee how many of those "lists" you are on with some softwares. You might have a one-click unsubscribe, but you just one-click unsubscribed from the first of 100 lists you were placed on for that company.
Some sites now seem to check whether an address is valid from some database or heuristic, because a random email with a valid domain is still rejected.
There is definitely a phenomenon of checking for prohibited email domains. However, absent extra-functional motivations like user data collection, smart developers don't bother with heuristics for email addresses much beyond the presence of an '@' character.
If you want to know if a purported email address is deliverable, try to deliver email to it.
Companies already massive dislike fake/temporary emails. Go find a throwaway email service and you'll find many many websites blacklist them. I'll actually be angry if Apple succeeds, because it'll just mean I can only have private email address as an apple customer and not anywhere else. Many companies might make an exception for Apple, but not anyone else.
This is neither a fake nor a temporary email. It is unique, made specific by the combination of the user's appleid and the target app/website, and permanent in that it will remain the same. The ability of the user to automatically discard/block content sent to the email address doesn't change this, as it's no different other than (probably) more convenient than setting up a bunch of spam filter rules for those "services" that refuse to remove your address.
It says in the article that it's a 'unique, random address', so I don't know where you're getting the 'combination of the user's appleid and the target app/website' from. The purpose of the service is the same as other temporary email services, to anonymize signing up for services by providing a fake email.
This is neat. But I'd have thought the lower-hanging fruit anti-spam wise for Apple would've been to add a "mark as spam" button next to push notifications so users can start reporting all the apps that abuse push notifications to send them advertisements.
This is similar to Abine's Blur service, which provides a throwaway phone number, and (seemingly) infinite throwaway emails addresses that can forward to your own personal email address.
Unfortunately there's no way to implement this as a OAuth2 flow and without having an Apple device. Seems unreasonable to require an Apple dev account just for providing sign up - it can be tested without installing apps or just borrowing an iPhone.
How will this be different that anon.penet.fi? (Besides the data being held in the US, where it is very much in reach of the authorities; Apple isn't going to shut down the service to uphold some privacy principle vs a government authority.)
I'm no big fan of Apple, but I must say I get a perverse pleasure out of moves like this because you'd probably find that 90% of Facebook employees swear by and love Apple products.
This is really good for consumers, but I'm afraid that many websites simply won't bother to implement this. Apple just doesn't have the unique marketshare that Google and FB have. The set of users that would use such a thing is the union of privacy focused users and users with an Apple ID and not a Facebook or Google account. This set is heavily overrepresented on HN but is relatively small overall.
If I run foo dot com, is that set of users attractive enough to me that I'll spend the engineering time to implement this? I can't think of many instances where it would be.
Isn't there a flaw? What does stop service provider/application vendor from banning this relay domain and force users to provide real email address for data-mining purposes aka "ensuring that service/app will work"? Unless of course that Apple would deal with those who would go for this
So this is only for mac/iphone users? That's not a large enough segment to warrant adding a sign in option for most sites. Would be nice if Mozilla had done something similar with Persona.
Something like 58% of site visits are from mobile browsers, and mobile Safari makes up over half of all mobile browsers. Of course, your mileage may vary, but that's a pretty large segment.
So its like 25% of Americans and much less everyone else. Plus you will be at the mercy of apple if they decide to remove your app, plus if you need an actual usable email, you have to ask for a second email. Sounds a bit confusing, they shouldnt have tied this to email address.
In order to read this article you must redeem your privacy to more than a dozen companies or go through five screens with a confusing UX to change parameters. Oh Irony
Not really. It's still linked transparently behind the scenes to your Apple ID. The connection won't be visible to the developers but the fraud etc will already be taken care of when signing up for your Apple ID.
The reality is that it won't do much to protect users privacy or prevent tracking, although it will make it easier for users to avoid spam filling up their inboxes.
Am I correct that TechCrunch page violates GDPR? I don't see any option to opt-out from being tracked. There is OK button and manage option link, but I can't manage anything, I can only agree for tracking...
While websites do blacklist temporary email providers like Mailinator, I think Apple has more power here; blocking the domain can be pegged as more of an anti-privacy move than blocking Mailinator, which is more anti-spam.
Orr you could buy a domain, and use a catch all email rule and then use an unique rmail address per site. Like mybank@mydomain, yourepamsite@mydomain ect.. I've never had any security problems.
While I like this for privacy purpose this is pretty nafarious.
There is no mechanism by which you can use this sign-on without Apple. That means you are stuck with these specialized accounts you would need to re-setup once you leave apple. Just another lock-in.
This is definitely not the first time apple does anything like this. If apple really cared they would make a tool for any device or operating system to enable this. But they will not.
You might be misunderstanding what the poster was talking about -- it's not that you'll need an Apple ID to sign up for a site, it's that once you sign up with an Apple ID, you might not have a way to link your account to a different email address. That effectively means that you'd need to recreate your account when you move away from Apple.
Of course, the other side of that is that sites are probably going to have ways to link accounts, and it likely won't be a huge deal. They certainly have no motivation to help Apple with lock in. It's not going to be any different from the process that exists today for moving associating an email with an account you created through Google/Github signin.
Still, it would be nice to have a way to use this without an iPhone, or it will be a (small) extra piece of friction you just have to deal before moving ecosystems, rather than piecemeal after getting a new phone.
Also note that the same exact concerns exist with Google/Facebook sign in, it's just that they aren't tied to a physical device so you only need to worry about losing them if you're making a conscious decision to delete your account.
This is something solvable by the service provider. Services can allow you to sign up with Apple, but hopefully they also allow you to link other social accounts and/or set up a password for login without IDP.
