Earlier quoted context omitted.
Are you saying that Google banned the whole organization based on the association of one employee with a banned account? And they withheld your data with no recourse? Did you consult a lawyer?
It's a widespread issue: http://www.slate.com/articles/technology/future_tense/2013/0... https://www.perrymarshall.com/2270/google-bans-your-account/ https://www.reddit.com/r/GooglePixel/comments/7nrx07/google_... Just curious, how can you even get a lawyer for issues like this? And in US it would all be a sham show (like the Zuckerberg senate hearing)
Introducing .app, a more secure home for apps on the web
371–378 of 378 posts
Re: Introducing .app, a more secure home for apps on the web
#372Earlier quoted context omitted.
It's a widespread issue: http://www.slate.com/articles/technology/future_tense/2013/0... https://www.perrymarshall.com/2270/google-bans-your-account/ https://www.reddit.com/r/GooglePixel/comments/7nrx07/google_... Just curious, how can you even get a lawyer for issues like this? And in US it would all be a sham show (like the Zuckerberg senate hearing)
I was specifically asking about the business's organization being shut down because of an employee's unrelated banning.
Re: Introducing .app, a more secure home for apps on the web
#373Earlier quoted context omitted.
Tech lead of Google Registry here. I can help answer some questions. HSTS preloading offers the highest possible level of security, as the user's browser is enforcing the use of HTTPS. Merely serving via HTTPS is only optional security, as any man-in-the-middle attacker can strip that encryption (see sslstrip, released six years ago). For more information see my blog post from last year: https://security.googleblog.c…
As nice as an HSTS preload list is, using .app and .dev for this is infuriating. Thanks for wasting about 6 hours of my time a few months ago by forcing me to change all my non-https local DNS entries to something other than .app and .dev, and then dealing with various flow on repercussions. Really helpful that was. Especially the latter. How many decades of man hours are you wasting from this I wonder...
I wasn't even aware of the fact that .dev was going into the preload list and was quite surprised when my browser started erroring out on my dev sites. Had to spend time figuring out what was even happening, then I had to reconfigure my web server and DNS resolution.
Was I wrong to use .dev? Debatable. Pretty rude way to find out, though.
Re: Introducing .app, a more secure home for apps on the web
#374Earlier quoted context omitted.
I'm not saying I agree with his stance, but I think it's important to mention Dave Winer's concerns re how the ongoing transition to HTTPS will affect older sites. Many of these played an important role in the web's rise to prominence, but could lose out if HTTPS becomes the baseline for trustworthy content. Some can be moved - Let's Encrypt has been a great help to this effort - but many others can't. Has there been…
Can you give an example of a site that couldn't be moved to HTTPS? I would expect that even if the serving stack doesn't support HTTPS you could put a proxy in front of it.
Knowing him, as long as the private keys to S3 don't leak somewhere, it's harder for me or anyone else to impersonate him and take the site down or start posting BS.
As for something that couldn't be moved, I suppose if the original source to a site was lost or corrupted and all that existed was a bunch of pages generated from a tool, it might be harder to migrate. Proxies help, but that isn't going to cover all bases.
You would have to figure out how to reverse transform that content into the original. Which might require a tool that can't run on modern hardware, which is a whole other headache to deal with.
The simpler non-technical answer is memories fade and people eventually die, so you need to plan for that too at some point and make sure somebody else can take over when that happens.
Re: Introducing .app, a more secure home for apps on the web
#375Earlier quoted context omitted.
It works with shell scripts. Having a name ending in '.sh' is less reliable than the output of file for identifying shell scripts, since any file can be named with that ending. cat199 said '.sh' is unnecessary and that is correct. I am surprised that this is controversial. (except wait, no, this is the internet... I'm not surprised. ;-)
> It works with shell scripts. No. It works with some of them, because, as the parent wrote, it’s just the automated equivalent of "let’s look at content of the file and guess what it is". It’s not perfect, and so doesn’t always work. If you write "echo 42" in a file, `file` will only tell you it’s "ASCII text". We humans are used to identify things with their name. `.sh` is not necessary to execute a shell script; b…
Ending the filename of a shell script in '.sh', while a useful and common convention, is unnecessary (I appreciate you that you acknowledge that) so using that to identify shell scripts is a heuristic, just like what file does.
Look, I don't want to argue about this. cat199 was catching downvotes for pointing out, quite correctly, that the '.sh' extension was just a convention, and, well... https://www.xkcd.com/386/
Filename extensions have always been a crappy hack to get around the omission of useful metadata associated with a file on some early filesystems. Gnome file viewer thing doesn't even sort by them!
Re: Introducing .app, a more secure home for apps on the web
#376Earlier quoted context omitted.
Jane Doe is not reading the Google Blog. The article is directed at developers.
When grandparents start seeing .app urls, they are going to be naturally wary. And they might even avoid clicking them. Then someone is going to ask about them to someone who is only partially tech savvy. And that someone will tell them that those are safer URLs. And that gets misinterpreted and soon you have people saying they are special approved by google URLs that are guaranteed to be safe. Regardless of who the…
"What's .app?"
"it's like .com or .org, don't worry about it"
Re: Introducing .app, a more secure home for apps on the web
#377It is very strange. 101domains wanted to charge me ~13,000 USD for a domain / year. gandi, however, allowed me to purchase it (the same domain!) for ~650 GBP / year. What is going on?
I noticed this too. Has the domain actually been registered with Gandi yet? Maybe 13k gets you a fully registered domain, and the £650 is like buying an option or a chance to be in the running.
Indeed, Gandi did not actually obtain the domain. But merely offered to try to bid with the money once the price of the domain reached that point where it was available for that price.
In my case, that failed. The domain was purchased by someone else at a higher price.
I now have to fight to get my money back into my bank account. Gandi made their life extra hard by not being fully transparent.
Re: Introducing .app, a more secure home for apps on the web
#378Earlier quoted context omitted.
When grandparents start seeing .app urls, they are going to be naturally wary. And they might even avoid clicking them. Then someone is going to ask about them to someone who is only partially tech savvy. And that someone will tell them that those are safer URLs. And that gets misinterpreted and soon you have people saying they are special approved by google URLs that are guaranteed to be safe. Regardless of who the…
I don't see what's so difficult about explaining this to your grandpa: "What's .app?" "it's like .com or .org, don't worry about it"
"it's like .com or .org, but it has some stuff in there to make it more secure, and it's managed by Google"
I'm also not the only person my grandparents get to ask about things.
I'm not saying this is all a bad thing. Just that we should be aware that giving things a little security can make people more careless.