mr__y

Do you actually read whole papers? It's an honest question. I usually scan the introduction, quickly skim through charts/tables and jump directly to conclusions. If I find anything remotely interesting during that process, then and only then I would even consider reading the whole paper.

>area that sorely needs improvement. the simplest idea would be to improve peer-reviewing with moving it to something similiar to hacker-news discussion board (but possibly not open to everyone), where reviewers would comment, authors could respond to questions or clarify something.

I guess that for most apps a Raspberry 0 or something similiar would be sufficient and to make it easier on the consumer side it could be built-in into the wifi-router[0] to avoid the necessity of having additional device.

On the other hand another approach would be to use more client-side processing[1] in the existing environment. This would not completely remove the need for the server on app maker side, but could possibly offer a significant reduction of the resources needed.

The third approach could be to change the billing model only, where processing would be done on a (very small and short term) cloud instance run by the mobile operator and the customer being billed for usage of that. In other words have computation-as-a-service as a part of mobile operator service. This would also have quite complicated privacy implications.

[0] And if the router-route would be taken, it would make things much cheaper since the routers CPU could be used. Even if additional cores would be required this is still much cheaper than having a separate server-device. Also much better energy-wise since for most of the time the server cores could be off/stand-by and a small process on router-cores would wake them up only if needed.

[1]Given how diverse client-devices are it's not that easy to have client side processing on all platforms. I wonder if WASM will make client-side processing more common.

I was commenting on this from parent posts:

>>another (probably more invasive) species will rise to take it's place.

>Eventually, but evolution is slow.

While the evolution is indeed slow, I was trying to point out that there are other ways to introduce new species, that are not slow.

>problem that exists independently yes, of course, but... if new species in small amounts are introduced to an ecosystem there is relatively high probability that they might not survive in that ecosystem. Now if there was some void in that ecostystem, the chances of that new species could be higher since their competition was removed/reduced. This of course requires some kind of coincidence - when the species accidentally introduced to the ecosystem can take over the place of moths being reduced. Since there are so many variables I believe it is close to impossible to asses the probability of such coincidence. I assume that this probability is very close to "unlikely" but still non-zero.

>Eventually, but evolution is slow. Why would the replacement be “probably” more invasive?

You don't have to wait for the evolution. There were already cases when a species from other country/continent was accidentally introduced to a new environment due to "parasite passengers" in shipping containers. While this problem exists independently of genetically engineered moths, since this already happened before[0], creating a void in an ecosystem might make this process easier.

[0] the first thing that pops in my head would be chinese mitten crabs in Germany https://cutt.ly/1rTUHN3

...or the introducend gene combined with some previously existing genes will create an unexpected feature which will dominate the species and wipe out specimens without it[0].

I believe we don't know enough (yet) to take a risk of such experiments in the wild. More, I think that possibly even proper assesment of such risk is currently not possible

[0] while this scenario is probably very unlikely I'm not sure that such risk should be taken

From my (limited) experience RDP is significantly better than VNC in terms of sluggishness and glitches. The second thing is that both VNC and RDP will try to transmit those parts of the screen that changed since the last frame rather than simply sending full "screenshots" for every frame. As a result the final effect highly depends on what are you using the remote desktop for.

Since my work is mainly coding in IDE and working with several ssh sessions, I almost exclusively work with text which is much easier for a great remote desktop experience. On the other hand, when I tried watching videos over remote desktop it was really bad.

The other things that you might consider is UDP vs. TCP, especially since some routers can handle long UDP connections badly. Since you are using VPN tunneling, you should probably avoid TCP over TCP scenario: if the VPN connection is using TCP, then I would rather use UDP for remote desktop connection. I would aim for UDP over UDP, but in a situation where the router can't handle UDP properly you could try TCP over UDP (that is VPN: TCP, VNC: UDP). You could also try to tune mtu size in tincvpn config.

Since the GP mentioned it is a machine from 1998 I would expect it to be PII with a clock above 200MHz. Since the Moore's law actually worked in the 90's that machine will be a lot more powerfull than that 586 (from 94-95 I guess).

On top of that curves and chacha20 could be used for ssh to reduce the CPU load.

I use an old laptop (single core, 1g ram) as a remote desktop client. Since I work regularly in two different locations this allowed me to buy only one workstation which I keep at one location and that old laptop allows me to use it from the other one. TBH I initialy did it as a fun project/experiment but was amazed how well it worked[0] and stayed with it.

[0]That being said both locations have a fibre and the distance between them is below 20 miles so neither bandwidth nor response times cause any issues

Given numerous examples from the past this is what "no trust" equals to. I'm not advocating publicly accusing them of being evil without evidence, but assuming they are when deciding if and how to use their services is at least reasonable.

In other words in public my opinion on them is "neutral" until I have some information/data/signs to form/change my opinion, but internally I assume they are doing[0] something evil until proven otherwise.

[0] or at least assume they are capable of doing something evil and there is a non-zero chance that they will engage in evil-doing. (but again, not accusing them publicly until there are reasons to do so; I'm just describing internal thought-process)

>"I'll pay $100 per month and have no adverts at all" or "I'll only $5 per month, and I'm happy to have a lot of adverts".

there is another problem with that model. As long as ads revenue is a significant portion of publisher's income there is a risk of advertisers influencing the content. At $100/month you won't see the ads, but the news themselves could still be influenced by advertisers in some way. I'm afraid that this would need all or nothing approach to be effective.

> they deserve no more and no less initial trust than any other company

that is they deserve none. No company gets any trust from me until they prove that they deserve it.

>exact same information

you could actually get more from plain old log parsing in some cases. First of all with GA you can't access the raw data. With logs you can create new type of stats/metrics/charts and apply them on past data. Also, IIRC GA uses random sampling - only a % of connections are recorded and the data being shown is extrapolated from those samples. While I'm not arguing that given the vast amount of data at disposal, huge capacity and great engineers they can make those extrapolations very accurate, I'm not entirely convinced it is precise for (very) small traffic websites. And since a small traffic logging requires both small storage space and small processing capacity the resources needed for keeping and processing your own logs are insignificant while the results might be useful.

>Most of the container use-cases that aren’t layers work fine under jails

I'm pretty sure that with unionfs you could get layer-ish equivalent for most use cases. Not going to question that it wouldn't be user friendly though

On the other hand, automatically labeling everything temperature related as "caused by climate change" is not a proper argument as well.

I mean this is most likely actually related to climate change, but this should be verified/modelled before coming to conclusions. Even when it is absolutely obvious.

(Disclaimer: I don't mean to question that bushfires are related to climate change. I just mean that ideas should be verified no matter how obvious they seem to be.)

>Australia's bushfires are definitely climate change related

Australia's bushfires are most likely related to climate change and this is probably the best hypothesis for their cause. It should be verified by actual scientists before we can say "definietly climate change" with confidence.

>Snooping ISPs, public IP, and geoblocking are not prevented by a VPN server in your home network

It really depends...

If you are connecting to that VPN from remote location it does. Whatever is your actual physical location your IP will appear to be your home IP.

Geoblocking might also be solved if you happen to be in a country that has the content blocked while your home location can access that content.

However, as you pointed out, making a VPN accessible from outside is not covered.

On the other hand a manufacturer capable of designing and producing SHA-256 chips could be also capable of designing and manufacturing $other_commonly_used_hash_algo chips allowing for brute-forcing $other_commonly_used_hash_algo encoded passwords. The same manufacturer/design team could also probably prepare $popular_block_cipher chips. So, while BTC miner chips would not be useful themselves, having an industry capable of creating those chips is.

if those were equipment dedicated to brute-forcing I would expect it to be ASICs/FPGAs rather than typical servers. You'd get orders of magnitude faster solution[0]. At the expense of flexibility of course since those chips would be single purpose.

[0] For a very simple example compare the hashrate on any CPU vs a bitcoin miner ASIC with a comparable size.

The thing is that not all servers in datacenters are maxed out to 100% usage all the time. A low priority process using idle resources could be used allowing for huge total cpu-power (given the scale of goog/fb/amzn datacenters) at no additional cost while if an agency wants $5B worth datacenter an agency must buy a $5B datacenter.

On the other hand those idle resources could be rented to an agency at a discount price

4. Attempts to create cryogenic CPUs were made well before 2005 and failed. The project was made somewhat public in order to misdirect adversaries into spending their budget and efforts on cryogenic processors.

5. The project was funded as a black project without the intention to actually deliver results but rather to justify RSFQ circuits R&D to later use those results elsewhere

The usual answer to such question is "it depends".

That being said, heart related sounds are generally low-frequency while breathing/lung related sounds are broadband so they do contain a significant higher frequency part.

Oh yes, a simple [a-z]{2,3} in regexp. I'm pretty sure I've seen exactly this on many different occasions

>tools for creating an AR ecosystem

all they really need is a collection of millions of AR-related patents allowing to sue any entity doing anything AR-related

if you manage to convince almost entire population to use an app that you can easily tap to I wouldn't call that "incompetent"

>It is not general purpose crypto strength

This made me curious. Is it because at this stage it is a proposal that has not yet been verified/analysed or are there actual reasons that you know of that make this not "general purpose strong"?

>some NHS systems in the UK (one of their target audiences) refused to accept emails that finished with .healthcare

not suprising at all, I've seen e-mail address validation code that (among other things) used a fixed list of TLDs. I could imagine some spam filters doing a similiar thing.

Do you know what possible fines or other consequences they could be facing? I'm really corious about that.

(this paragraph does not refer to NDPR or Nigeria) I have a general impression that very often the possible fines are far too low and it could be perfectly sound business decision to ignore the security or just keep it to a very minimum. Why spend a lot of money on auditing, improving the software, buying additional infrastructure when the cost of ignoring those and even the probability of anything happening is relatively low. For example why spend hundreds of thousands or possibly millions of dolars on security when the worst thing that could happen is a low fine with a marginal probability of breach happening then being discovered, then being reported, then being investigated and then actually a legal action actually being taken.

My point is that it might actually be a lot cheaper to face the consequences of a breach than to improve security. I'm not sure what could be done to improve that situation.

Assuming that all the information in the troyhunt article is true I wish them the worst possible outcome from the bottom of my heart

According to the article they were contacted via email and DMs first, many days before it went public. They were given enough time to verify this and respond accordingly. Also due to GDPR they are obliged to inform the users (at least those from EU) about the data breach - it is not their right to decide whether to inform or not anymore. They do not have to make a public announcement and could just send emails directly to affected users, but considering the total number of affected users I really doubt it would not become a public issue anyways.

But one thing holds: it is still not their legal right to remain silent, they are required to inform the affected users (at minimum those from EU)