How is "playing the numbers game" no longer the good advice? This article (and your comments) only seem to cement that idea further.

When there are 20 qualified applicants per job you can apply to dozens or hundreds of jobs and beat or negate the unfavorable numbers. When there are hundreds or thousands of applicants for jobs, you can't apply for tens of thousands of jobs. The listings just don't exist. Your only real chance is to find an inside connection and skip the anonymous application portal.

Internet services in the US aren't even a public utility. I don't see this ever happening.

Maybe in a market with real competitors. But like others have said, what usually happens is people with existing unlimited plans lose them overnight to ISP's with a monopoly in their area. Then, ISP's charge $50 more per month for them to get the service they already had.

Pray for the team that has to handle this ticket.

That’ll be fine, a post mortem will show that ops weren’t the cause and their comp package will help them get over this little package of stress

If you like synths on the web, check this out.

https://learningsynths.ableton.com/

Cheers, but that is the exact article we're discussing lol

It's never been awful for me. Even when running it on an iPhone 6S, it has always been nice and responsive.

It is native on iOS but not for desktop.

Convenience and access to Apple's user base who partake in the service. Those are the main reasons I used Google and Facebook sign-in on my website.

It says on the page, the service costs 0.4% per transaction.

That's for the service in the original link. Not sure that's the same for the potential service under discussion here.

To be fair, you can't blame them for disallowing things like that. Protection against cross-site scripting, I'm sure.

I just don't see a realistic attack vector with cross-origin drag-n-drop.

This one's actually pretty easy: clickjacking.

Imagine permitting cross-origin drag-n-drop and a page is clickjacked: the user may end up dragging a sensitive item in the clickjacked page into an invisible iframe with a drop point layered on top of whatever target the user thinks they're dropping data into, and the end result would be that data intended for one endpoint, in this case the endpoint that was clickjacked, is sent to another.

It'd be a nontrivial attack to mount, but as you posed the challenge, I can see it done as part of e.g. a phish where a site like dropbox is iframed in a clickjacking attack (assuming they haven't mitigated it).

I can sketch (literally) what the dom might physically look like if it helps convey the attack I have in mind more effectively.

Here's some stuff you used to be able to do by combining UI-redressing (clickjacking) with cross-origin drag and drop.

https://www.contextis.com/media/downloads/Context-Clickjacki...

There have also been plenty of UXSS bugs in various browsers caused by cross-origin drag-and-drop.

Anything cross-origin is a potential XSS attack.